В WordPress панель управления уже закрыта для посетителей без авторизации, но страница входа остаётся доступной из интернета. Ограничение по IP дополнительно скрывает её от посторонних, а настройка по учетным записям позволяет не пускать в интерфейс управления пользователей без нужных прав. Это разные меры: IP-фильтр ограничивает, откуда открывается админка, а проверка прав — кто может работать в ней после входа.
Если у вас постоянный IP-адрес, наиболее прямой вариант — настроить разрешённые адреса на сервере. Если адреса часто меняются или в админку должны входить сотрудники из разных сетей, удобнее ограничить доступ по правам пользователя WordPress. Перед изменениями убедитесь, что у вас есть второй способ попасть на сайт — например, через панель хостинга или SFTP: ошибочное правило может заблокировать и вас.
Ограничение доступа по IP в Apache
На Apache можно добавить правило в файл .htaccess внутри каталога wp-admin. Это не основной файл WordPress в корне сайта, а отдельный файл по пути wp-admin/.htaccess. Создайте его, если его ещё нет, и укажите адреса, с которых разрешён доступ.
<RequireAny>
Require ip 203.0.113.24
Require ip 198.51.100.0/24
</RequireAny>
<Files "admin-ajax.php">
Require all granted
</Files>Замените примеры IP на свои: адреса из примера зарезервированы для документации и не откроют доступ с вашей сети. Директива Require ip принимает отдельный адрес или диапазон в формате CIDR. Несколько разрешённых адресов внутри RequireAny работают по принципу «подходит любой из них».
Исключение для admin-ajax.php нужно, потому что WordPress и некоторые плагины используют этот файл для запросов с публичной части сайта. Если закрыть весь каталог без исключения, могут перестать работать отдельные формы, фильтры или другие функции, использующие AJAX. Если сайт использует admin-post.php для обработки публичных форм, проверьте их отдельно: правило на каталог может блокировать и этот обработчик. Открывать его можно только понимая, какие обработчики на сайте используются; сами обработчики должны проверять права и данные запроса.
Этот пример рассчитан на Apache 2.4 с разрешёнными правилами авторизации в .htaccess. На старом Apache 2.2 синтаксис другой; не копируйте туда приведённые директивы. Если после сохранения появляется ошибка 500, удалите новое правило через SFTP или файловый менеджер и уточните у хостинга версию Apache и поддержку .htaccess.
Если сайт работает на Nginx или за прокси
Nginx не читает файлы .htaccess: правило из предыдущего раздела там не сработает. Ограничение настраивают в конфигурации виртуального хоста, и для этого обычно нужна помощь хостинга или доступ администратора сервера. Попросите ограничить доступ к /wp-admin/ указанными IP, сохранив корректную обработку PHP и нужных публичных обработчиков, например admin-ajax.php. Не вставляйте в конфигурацию Nginx случайный блок location: при неверном приоритете правил сервер может перестать выполнять PHP-скрипты в каталоге админки.
Если сайт работает через CDN или обратный прокси, сервер может видеть IP прокси, а не посетителя. Тогда обычное правило по IP заблокирует всех или будет проверять не тот адрес. Настоящий IP клиента должен быть корректно настроен на стороне сервера как доверенный заголовок; не используйте заголовок от прокси как источник IP, если сервер не проверяет, что запрос действительно пришёл от доверенного прокси. Уточните это у хостинга до включения фильтра.
На виртуальном хостинге проверьте панель управления: некоторые провайдеры предлагают защиту каталога или список разрешённых IP без ручной настройки конфигурации веб-сервера. Такой способ удобнее, если у вас нет доступа к серверу, но он также должен учитывать необходимые AJAX-запросы сайта.
Как закрыть панель управления для пользователей без нужных прав
По умолчанию WordPress допускает в админку авторизованных пользователей в соответствии с их ролью и правами. Если редакторам или подписчикам не нужен интерфейс wp-admin, можно перенаправлять пользователей без права управления сайтом на главную. Для обычного сайта проверка manage_options оставляет доступ пользователям, которые могут менять настройки WordPress, и закрывает административный интерфейс остальным.
Чтобы изменение не пропало при обновлении темы, добавьте его как отдельный Must-Use плагин. Если каталога wp-content/mu-plugins ещё нет, создайте его. Затем создайте в нём файл restrict-admin.php со следующим содержимым:
<?php
add_action( 'admin_init', function () {
if ( wp_doing_ajax() ) {
return;
}
if ( current_user_can( 'manage_options' ) ) {
return;
}
wp_safe_redirect( home_url( '/' ) );
exit;
} );Файл Must-Use плагина загружается WordPress автоматически, активировать его в разделе плагинов не нужно. Проверка пропускает AJAX-запросы, чтобы не мешать функциям сайта, и оставляет доступ пользователям с правом manage_options. Остальных пользователей, уже прошедших вход, она отправляет на главную страницу. Само наличие этого кода не ограничивает попытки входа и не заменяет пароль.
Проверьте, как на сайте устроена работа редакторов и других сотрудников: они не смогут открывать экранные разделы админки, даже если их роль обычно разрешает редактирование записей. Если редакторам нужен доступ к записям, но не к настройкам сайта, проверку следует подстроить под нужные возможности, а не просто копировать этот вариант. На многосайтовой установке права администратора сети устроены иначе — перед внедрением проверьте доступы на тестовой учетной записи.
Что выбрать и как проверить результат
Фильтр по IP подходит, когда администраторы подключаются с фиксированных адресов. Он уменьшает число доступных извне точек входа, но при смене IP придётся обновить список. При динамическом адресе можно потерять доступ после переподключения к интернету; заранее добавьте резервную сеть или подготовьте способ удалить правило через хостинг.
Ограничение по правам пользователя полезно, когда в WordPress есть сотрудники, которым не требуется админка. Оно не уменьшает число запросов к странице входа и не ограничивает саму форму авторизации. Для защиты от перебора паролей такие меры дополняют уникальными длинными паролями, двухфакторной авторизацией или ограничением попыток входа на уровне хостинга либо проверенного защитного решения.
После настройки проверьте сайт с двух разных условий: с разрешённого IP админка должна открываться, с неразрешённого — нет; пользователь без нужных прав не должен попадать в интерфейс управления. Отдельно проверьте вход администратора и функции публичной части, которые используют AJAX или отправку форм. Если вы заблокировали себя, удалите правило из wp-admin/.htaccess либо отключите добавленный Must-Use плагин через файловый менеджер или SFTP, затем исправьте настройку и повторите проверку.