Как ограничить доступ к админке WordPress по IP

Автор: Михаил Фомин | Опубликовано: 01.10.2026

Если на сайте редко заходят в админку с предсказуемых адресов, ограничение доступа по IP — один из самых простых способов снизить шум от брутфорса. Это не замена нормальной авторизации, но хороший дополнительный барьер: случайные запросы к /wp-login.php и /wp-admin/ перестают доходить до WordPress, а неудачные попытки входа не нагружают PHP и базу.

У этого подхода есть важная оговорка: он подходит только тогда, когда у вас действительно стабильные IP. Если вы работаете из дома, через мобильный интернет, VPN или у команды плавающие адреса, жесткая блокировка быстро начнет мешать. В таких случаях лучше ограничивать доступ к админке на уровне сервера только для части адресов, а для остальных использовать более мягкую схему: 2FA, ограничение попыток входа и отдельный VPN.

Когда ограничение по IP реально помогает

Сценарий типичный: в логах много запросов к wp-login.php, хостинг ругается на нагрузку, а в панели безопасности видно постоянные попытки подбора пароля. Если сайт — корпоративный, редакционный или обслуживается из офиса, список IP обычно небольшой и управляемый. В этом случае блокировка на веб-сервере работает лучше, чем попытка решать проблему только плагином.

Если же у вас несколько администраторов, подрядчики и доступ из разных сетей, сначала составьте список реальных точек входа. Иначе вы сами себе закроете админку в самый неудобный момент.

Диагностика проблемы перед изменениями

Перед настройкой проверьте, откуда сейчас идут входы и как устроен доступ к серверу. Это поможет выбрать правильный уровень блокировки — nginx, Apache или сам WordPress.

Что проверить в первую очередь

Есть ли у вас статический IP или диапазон IP у офиса/VPN.
Используется ли Cloudflare или другой прокси, который подменяет адрес клиента.
Есть ли доступ к конфигу nginx/Apache или только к панели хостинга.
Нужен ли доступ к wp-admin для мобильных устройств, редакторов, подрядчиков.
Есть ли уже плагин защиты входа, который может конфликтовать с серверной блокировкой.

Если сайт стоит за Cloudflare, блокировать нужно не REMOTE_ADDR прокси, а реальный IP клиента. Иначе правило будет работать не так, как ожидается. Это частая причина, почему «все сломалось после настройки».

Как ограничить доступ к wp-admin по IP на уровне nginx

Если у вас nginx, самый надежный вариант — закрыть /wp-admin/ и отдельно /wp-login.php для всех, кроме нужных адресов. Пример ниже рассчитан на один IP и один диапазон. Подставьте свои значения.

location ^~ /wp-admin/ {
    allow 203.0.113.10;
    allow 203.0.113.0/24;
    deny all;
}

location = /wp-login.php {
    allow 203.0.113.10;
    allow 203.0.113.0/24;
    deny all;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Здесь важно не забыть, что /wp-admin/admin-ajax.php иногда нужен фронтенду и плагинам. Если вы закрываете весь /wp-admin/ без исключений, проверьте, не ломаются ли формы, поиск, редактор и динамические блоки на сайте. Иногда для admin-ajax.php делают отдельное правило или оставляют доступ только для публичных запросов, если это оправдано архитектурой сайта.

Если нужен доступ только через VPN

В корпоративной среде удобнее разрешить доступ не по домашним IP, а только из VPN-сети. Тогда список адресов меняется реже, а контроль централизован. Для nginx это выглядит так же: разрешаете подсеть VPN и закрываете все остальное.

location = /wp-login.php {
    allow 10.8.0.0/24;
    deny all;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Как сделать то же самое в Apache

На Apache логика похожая, но синтаксис другой. Если есть доступ к .htaccess или конфигу виртуального хоста, можно ограничить вход по IP через Require.

<Files wp-login.php>
    Require ip 203.0.113.10
    Require ip 203.0.113.0/24
</Files>

<Directory "/var/www/site/wp-admin">
    Require ip 203.0.113.10
    Require ip 203.0.113.0/24
</Directory>

Если сервер старый и используется синтаксис Apache 2.2, встречается вариант с Order allow,deny, но на новых установках лучше придерживаться актуального Require. После правки конфигурации не забудьте перезагрузить веб-сервер и проверить, что правила применились именно к нужному виртуальному хосту.

Когда лучше использовать плагин, а когда — код

Если у вас нет доступа к серверной конфигурации, можно частично решить задачу на уровне WordPress. Но это слабее, чем блокировка на nginx или Apache: запрос уже дошел до PHP, а значит, нагрузка все равно возникла.

Подход	Плюсы	Минусы
nginx/Apache	Отсекает запросы до WordPress, меньше нагрузки	Нужен доступ к серверу или панели хостинга
Плагин безопасности	Проще включить без правок конфига	Запросы все равно доходят до PHP
Код в теме/плагине	Гибко для нестандартных правил	Легко ошибиться и закрыть админку себе

Если нужен именно код, можно добавить простую проверку в mu-plugin. Это полезно, когда серверные правила недоступны, а ограничить вход нужно быстро.

<?php
/**
 * Plugin Name: Restrict admin by IP
 */

add_action('init', function () {
    if (!is_admin() && !in_array($GLOBALS['pagenow'] ?? '', ['wp-login.php'], true)) {
        return;
    }

    $allowed_ips = [
        '203.0.113.10',
        '203.0.113.11',
    ];

    $ip = $_SERVER['REMOTE_ADDR'] ?? '';

    if ($ip && !in_array($ip, $allowed_ips, true)) {
        status_header(403);
        nocache_headers();
        exit('Access denied');
    }
});

Такой вариант рабочий, но его стоит рассматривать как временный. Он не защищает от лишней нагрузки так хорошо, как серверный уровень, и может конфликтовать с кэширующими или security-плагинами. Для постоянной схемы лучше перенести правило в nginx или Apache.

Пошаговая настройка без риска потерять доступ

Сначала добавьте в список разрешенных свой текущий IP и запасной адрес, если он есть.
Проверьте, что у вас есть альтернативный способ входа: VPN, резервный канал, доступ через консоль хостинга.
Примените правило сначала только к wp-login.php, а уже потом к /wp-admin/.
Откройте сайт в режиме инкогнито и попробуйте войти с разрешенного и запрещенного адреса.
Проверьте, не сломались ли формы, REST API и AJAX-запросы на фронтенде.

Если все работает, можно ужесточать правило. Если нет — откатить одну строку в конфиге проще, чем восстанавливать доступ к админке через поддержку хостинга.

Как проверить, что ограничение сработало

Проверка должна быть не только визуальной. Важно убедиться, что блокировка происходит именно на нужном уровне.

С запрещенного IP страница /wp-login.php должна отдавать 403 или не открываться вовсе.
С разрешенного IP вход должен работать без дополнительных редиректов.
В логах nginx/Apache должны появляться записи о запрете, а не ошибки PHP.
Фронтенд сайта не должен терять AJAX-функции, если они завязаны на admin-ajax.php.

Удобно проверить ответ через curl с сервера или из внешней среды. Например:

curl -I https://example.com/wp-login.php

Если правило настроено на сервере, вы увидите 403 или другой ожидаемый код ответа. Если вместо этого возвращается обычная страница логина, значит, правило не попало в нужный блок конфигурации или было переопределено другим location/Directory.

Частые ошибки и как их исправить

Блокируют не тот IP

Это случается за прокси, CDN и балансировщиками. На сервере вы видите IP прокси, а не пользователя. Решение — настроить получение реального IP на уровне веб-сервера и только потом писать правила доступа.

Закрывают весь /wp-admin/ без исключений

После этого перестают работать части интерфейса, которые используют admin-ajax.php. Если сайт активно использует AJAX на фронтенде, проверьте зависимости перед блокировкой. Иногда достаточно ограничить только wp-login.php, а не весь каталог админки.

Забывают про запасной доступ

Если вы меняете сеть, переезжаете в другой офис или у провайдера меняется внешний IP, можно потерять доступ к панели. Перед внедрением всегда держите под рукой альтернативный способ отката: SSH, панель хостинга, резервный IP или VPN.

Ставят плагин и думают, что сервер уже защищен

Плагин может помочь, но он не заменяет блокировку на веб-сервере. Если цель — снизить нагрузку и убрать лишние запросы до WordPress, серверное правило надежнее.

Что учесть для безопасности и производительности

Ограничение по IP хорошо работает в связке с другими мерами: сложные пароли, двухфакторная аутентификация, отключение лишних учетных записей администратора, ограничение попыток входа. Если у вас редакционный сайт, имеет смысл разделить роли: не всем нужен доступ к полному админскому интерфейсу.

Если доступ к админке нужен нескольким людям, лучше не раздавать общий IP-список без контроля. Добавляйте адреса осознанно, удаляйте старые, а при уходе подрядчика сразу убирайте его VPN или внешний IP из разрешений. Так правило остается полезным, а не превращается в формальную запись, которую никто не поддерживает.

Для сайтов на управляемом хостинге иногда проще включить ограничение через панель безопасности или обратиться в поддержку, чем править конфиги вручную. Но принцип остается тем же: чем раньше запрос отсекается, тем меньше он стоит серверу.