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

Автор: Павел Комаров | Опубликовано: 11.08.2026

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

Ниже — рабочие варианты для Apache, nginx и WordPress-кода. Сразу оговорка: если у вас динамический IP, VPN, мобильный интернет или несколько офисов, жёсткая блокировка может отрезать доступ даже вам. В таких случаях лучше делать исключения или использовать более гибкую схему.

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

Сценарий простой: админка нужна только с одного офиса, домашнего адреса или VPN-сети. Тогда можно закрыть вход всем остальным и оставить доступ только с доверенных IP. Это уменьшает количество запросов к логину и убирает часть автоматических переборов.

Подходит для:

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

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

Диагностика: что проверить до настройки

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

Проверьте сервер

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

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

curl ifconfig.me

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

Проверьте, не используете ли вы кэш или защитный прокси

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

Подход	Где настраивается	Плюс	Минус
Apache .htaccess	Файлы сайта	Быстро внедрить	Не подходит для nginx
nginx allow/deny	Конфиг сервера	Надёжно и прозрачно	Нужен доступ к конфигу
WordPress-код	functions.php или mu-plugin	Гибко для логики	Поздно срабатывает, не защищает всё на уровне сервера

Пошаговое решение для Apache через .htaccess

Если сайт работает на Apache и у вас есть доступ к корню WordPress, можно ограничить доступ к админке на уровне .htaccess. Это практичный вариант, когда нужно быстро закрыть вход с чужих IP.

Обычно правило добавляют отдельно для wp-login.php и каталога /wp-admin/. Пример ниже разрешает доступ только с двух адресов:

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

<Directory "/path/to/wordpress/wp-admin">
    Require ip 203.0.113.10 198.51.100.25
</Directory>

Но есть нюанс: <Directory> в .htaccess обычно не работает. Для .htaccess чаще используют такой вариант:

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

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-admin/
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REMOTE_ADDR} !^198\.51\.100\.25$
RewriteRule .* - [F,L]
</IfModule>

Этот способ не идеален, но для типовой установки работает. Если у вас много IP, список можно расширять. Главное — не забыть про IPv6, если он используется у вас или у провайдера.

Пошаговое решение для nginx

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

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

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

location = /wp-admin/admin-ajax.php {
    allow all;
}

Последняя строка важна: admin-ajax.php часто нужен и фронтенду, и плагинам. Если закрыть его вместе с админкой без разбора, можно сломать формы, фильтры, корзину WooCommerce и другие AJAX-сценарии.

Если вы хотите ограничить только вход в админку, но оставить публичные AJAX-запросы, не ставьте общий deny all на весь /wp-admin/ без исключения для admin-ajax.php.

Как сделать ограничение гибче через WordPress-код

Иногда серверный доступ недоступен, а править .htaccess или nginx-конфиг неудобно. Тогда можно добавить проверку на уровне WordPress. Это менее надёжно, потому что WordPress уже загрузится, но для временного решения подходит.

Ниже пример, который не пускает в админку и на страницу логина, если IP не входит в список:

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

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

    $request_uri = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '';
    $remote_addr = isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : '';

    $is_admin_area = (strpos($request_uri, '/wp-admin') === 0);
    $is_login_page  = (strpos($request_uri, '/wp-login.php') === 0);

    if (($is_admin_area || $is_login_page) && !in_array($remote_addr, $allowed_ips, true)) {
        status_header(403);
        exit('Доступ запрещён');
    }
});

Такой код лучше размещать в mu-plugin, а не в теме. Тогда он не исчезнет при смене шаблона. Но повторю: это запасной вариант, а не замена серверной блокировке.

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

После настройки обязательно проверьте поведение с разрешённого и запрещённого адреса. Не ограничивайтесь открытием главной страницы — тестируйте именно те URL, которые защищали.

Откройте /wp-login.php с разрешённого IP — страница должна открываться.
Откройте /wp-admin/ с разрешённого IP — должен быть вход в админку или редирект на логин.
Откройте те же адреса с другого IP — сервер должен вернуть 403 Forbidden или аналогичный отказ.
Проверьте admin-ajax.php, если вы его не блокировали отдельно.
Зайдите в WooCommerce, формы, личный кабинет и убедитесь, что фронтенд не сломался.

Для быстрой проверки можно использовать команду с другой сети или VPN:

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

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

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

Забыли про wp-login.php

Ограничили только /wp-admin/, а страница входа осталась открытой. В итоге ботам всё ещё есть куда стучаться. Исправление простое: закрывайте оба адреса, если нет отдельной причины оставить один из них доступным.

Не учли admin-ajax.php

Жёсткий запрет на весь /wp-admin/ ломает AJAX на фронтенде. Это особенно заметно в WooCommerce, где часть функций завязана на admin-ajax.php. Решение — добавить исключение для этого файла или ограничивать только логин.

Список IP взят не с той стороны прокси

Если сайт за Cloudflare или другим прокси, сервер может видеть IP прокси, а не клиента. Тогда правило по REMOTE_ADDR работает не так, как ожидается. Нужно сначала настроить получение реального IP на уровне сервера, а уже потом строить ограничения.

Используется динамический IP

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

Правило добавили в тему

Если код лежит в functions.php активной темы, при смене темы защита исчезнет. Для служебной логики используйте mu-plugin или отдельный мини-плагин.

Безопасность и производительность: что учесть

IP-ограничение — это не самостоятельная защита, а дополнительный слой. Если у вас слабый пароль или нет двухфакторной аутентификации, один только allow/deny проблему не решит. Зато он уменьшает количество лишних запросов к логину и снижает нагрузку от ботов.

Практически полезно сочетать этот способ с:

уникальным и сложным паролем администратора;
двухфакторной аутентификацией;
ограничением числа попыток входа;
отдельной учётной записью для повседневной работы;
регулярной проверкой логов веб-сервера.

Если вам нужен более широкий набор мер по чистке и защите сайта, иногда удобнее собрать их в одном инструменте. Например, Clearfy Pro от WPShop закрывает часть типовых задач по оптимизации и удалению лишнего, но IP-фильтрацию админки всё равно лучше делать на уровне сервера или инфраструктуры: Clearfy Pro.

Что делать, если нужен доступ из разных мест

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

VPN с постоянным IP;
доступ к админке только через корпоративную сеть;
2FA плюс ограничение по IP для основной рабочей сети;
отдельный staging-домен с закрытым доступом для тестов.

Тогда блокировка по IP остаётся полезной, но не мешает ежедневной работе. Это тот случай, когда чуть более сложная настройка экономит время на постоянных разблокировках и поиске, почему «вчера работало, а сегодня нет».