Как ограничить доступ к админке WordPress по IP без поломки входа и REST API

Если к сайту имеют доступ несколько администраторов, а панель управления регулярно атакуют перебором паролей, ограничение доступа к /wp-admin по IP — рабочая мера. Но включать её «в лоб» опасно: можно отрезать себе вход, сломать AJAX в админке, а в некоторых сценариях — задеть REST API и интеграции.

Ниже — не абстрактная теория, а схема, которую можно применить на реальном сайте: сначала понять, где именно нужно ограничение, потом выбрать способ, внедрить его и проверить, что ничего не сломалось.

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

Этот подход имеет смысл, если у вас:

• один или несколько статических IP у команды;
• админка не должна быть доступна из публичной сети;
• нужно снизить шум от брутфорса и сканеров;
• сайт обслуживается на VPS или выделенном сервере, где есть доступ к настройкам веб-сервера.

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

Диагностика: что именно нужно защищать

Перед настройкой проверьте, какие точки входа реально используются. На WordPress это не только /wp-login.php и /wp-admin/. Часто забывают про:

• /wp-admin/admin-ajax.php — нужен для многих плагинов и части интерфейса;
• /wp-json/ — REST API, который используют внешние сервисы и редактор блоков;
• cron-запросы и интеграции, если они завязаны на авторизацию;
• доступ редакторов и контент-менеджеров, если они работают не из офиса.

Если вы не уверены, кто и откуда входит в админку, сначала посмотрите логи веб-сервера. На nginx это обычно access.log, на Apache — аналогичный access log. Ищите запросы к /wp-login.php и /wp-admin/ с разных IP.

Что проверить до изменений

• Есть ли у вас статический IP или диапазон IP.
• Нужен ли доступ к админке с телефона, домашней сети, VPN.
• Используют ли плагины REST API извне.
• Есть ли у вас доступ к конфигу nginx/Apache или только к WordPress.

Какой способ выбрать: сервер, .htaccess или WordPress

Самый надёжный вариант — ограничение на уровне веб-сервера. WordPress здесь не нужен: если запрос не должен попасть в PHP, лучше отрубить его раньше. Но не всегда есть доступ к конфигу сервера, поэтому полезно понимать компромиссы.

Если задача именно «закрыть админку по IP», а не строить сложную политику доступа, начинайте с сервера. WordPress-решение оставьте как запасной вариант для случаев, когда сервер недоступен.

Пошаговая настройка на nginx

На nginx обычно достаточно отдельного правила для /wp-admin/ и /wp-login.php. Пример ниже допускает доступ только с одного IP и локального адреса сервера. Подставьте свои значения.

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

location = /wp-login.php {
    allow 203.0.113.10;
    allow 127.0.0.1;
    deny all;
}

Если у вас несколько офисных IP, добавьте их отдельными строками allow. После правки проверьте конфигурацию и перезагрузите nginx:

nginx -t
systemctl reload nginx

Важно: если вы используете редактор блоков и внешние интеграции, не закрывайте бездумно /wp-json/. Сначала убедитесь, что он не нужен сторонним сервисам.

Если за сайтом стоит Cloudflare или другой прокси

В таком случае nginx может видеть не реальный IP клиента, а адрес прокси. Тогда правило по IP будет работать неправильно, пока вы не настроите передачу настоящего IP. Это уже отдельная задача: сначала корректно настройте real_ip, и только потом ограничивайте доступ.

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

Вариант для Apache через .htaccess

Если сайт работает на Apache и у вас нет доступа к основному конфигу, можно ограничить доступ через .htaccess в корне сайта или в каталоге /wp-admin/. Для современных версий Apache используйте синтаксис Require.

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

Для каталога wp-admin удобнее отдельный .htaccess внутри папки /wp-admin/:

Require ip 203.0.113.10
Require ip 127.0.0.1

Старый синтаксис Order allow,deny лучше не использовать без необходимости: он зависит от конфигурации сервера и версии Apache. Если у вас смешанная среда, сначала проверьте, что модуль mod_authz_core включён.

Если нужен гибкий контроль внутри WordPress

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

Ниже пример: если пользователь пытается открыть админку или войти через wp-login.php не с разрешённого IP, WordPress отдаёт 403. Список IP хранится в коде, но его можно вынести в опцию или константу.

<?php
/**
 * Plugin Name: Admin IP Restriction
 */

add_action('init', function () {
    if (defined('WP_CLI') && WP_CLI) {
        return;
    }

    $allowed_ips = array(
        '203.0.113.10',
        '127.0.0.1',
    );

    $remote_ip = $_SERVER['REMOTE_ADDR'] ?? '';
    $request_uri = $_SERVER['REQUEST_URI'] ?? '';

    $is_admin_area = str_starts_with($request_uri, '/wp-admin') || $request_uri === '/wp-login.php';

    if ($is_admin_area && !in_array($remote_ip, $allowed_ips, true)) {
        status_header(403);
        exit('Access denied');
    }
}, 1);

Этот вариант проще внедрить, но он не заменяет серверную блокировку. Запрос всё равно дойдёт до PHP, а значит сайт потратит ресурсы на обработку. Используйте его как временное решение или как дополнительный слой защиты.

Проверка результата после внедрения

После настройки не ограничивайтесь тестом «страница открылась». Проверьте несколько сценариев:

• с разрешённого IP открывается /wp-login.php;
• с разрешённого IP открывается /wp-admin/;
• с запрещённого IP возвращается 403 или другой ожидаемый отказ;
• редактор блоков в админке не теряет доступ к нужным endpoint'ам;
• внешние интеграции, если они есть, не перестали работать.

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

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

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

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

Заблокировали себя

Самая частая проблема — забыли добавить свой текущий IP или VPN-адрес. Если доступ к серверу есть, временно снимите правило и проверьте текущий внешний IP через любой сервис или командой curl ifconfig.me с вашей машины.

Не учли прокси или CDN

Если сайт за Cloudflare, nginx может видеть IP прокси, а не посетителя. В результате правило по IP работает не так, как ожидается. Сначала настройте доверенные прокси и real_ip, потом снова тестируйте.

Сломались плагины и редактор

Некоторые плагины используют admin-ajax.php или REST API. Если вы закрыли слишком много URL, интерфейс начнёт вести себя странно: не сохраняются блоки, не подгружаются данные, не работает автосохранение. В таких случаях нужно не расширять запрет, а сузить его до действительно опасных точек входа.

Сделали ограничение только для wp-login.php

Это частая полумера. Страница логина закрыта, но /wp-admin/ всё ещё доступен и будет редиректить на логин, а значит вы не убрали лишний трафик полностью. Лучше закрывать оба пути согласованно.

Практические советы по безопасности и обслуживанию

Ограничение по IP хорошо работает в связке с другими мерами:

• включите двухфакторную аутентификацию для администраторов;
• используйте отдельные учётные записи для редакторов и админов;
• не держите доступ к серверу и к WordPress на одном и том же слабом пароле;
• регулярно проверяйте логи на повторяющиеся попытки входа;
• если команда распределённая, рассмотрите VPN вместо списка «вечных» IP.

Если вам нужна не только защита входа, но и чистка лишних следов в WordPress, имеет смысл посмотреть в сторону инструментов вроде Clearfy Pro: он помогает убрать часть технического шума и лишних сущностей в админке, но сам по себе не заменяет ограничение доступа по IP.

Главная идея простая: чем раньше вы отсекаете лишние запросы, тем меньше нагрузка и меньше поверхность атаки. Но любое ограничение нужно проверять на реальных сценариях — вход, редактор, AJAX, интеграции. Иначе можно получить «защищённую» админку, в которую никто не может войти, включая вас.