403 Forbidden при доступе к wp-login.php — как исправить
Симптом характерный: главная и внутренние страницы открываются, а при переходе на /wp-login.php браузер отдаёт «Forbidden — You don't have permission to access this resource». В большинстве случаев отказ выдаёт веб-сервер, WAF или защитный плагин. Если блокировку устанавливает плагин безопасности WordPress, запрос может быть отклонён ещё до обычной обработки страницы.
Почему 403 появляется только на wp-login.php
Основные причины:
- Плагин безопасности WordPress. Wordfence, All-In-One Security и Solid Security (ранее iThemes Security) после нескольких неудачных попыток входа блокируют адрес на уровне правила: в списке блокировок лежит либо конкретный IP, либо маска, закрывающая только wp-login.php и wp-admin.
- Правила веб-сервера. .htaccess, конфигурация Nginx и аналогичные механизмы. Запрет по IP, по User-Agent или «Deny from all» для подпапки — такое правило мог добавить плагин защиты или оно осталось после ручной правки, переезда хостинга.
- Cloudflare/WAF/CDN. Само наличие Cloudflare не означает, что wp-login.php будет заблокирован: блокировка появляется только при срабатывании настроенного механизма безопасности — Managed Rules, кастомного правила или другого security feature, закрывающего страницы входа.
- Серверные средства защиты. fail2ban, ModSecurity и аналогичные механизмы могут блокировать запросы по IP или по определённым признакам запроса. Конкретное поведение зависит от настроенной конфигурации. На shared-хостинге блокировку может устанавливать серверная система защиты провайдера.
Как исправить — пошаговая инструкция
Шаг 1. Подтвердите, что 403 только на wp-login.php
Проверьте с сервера или через терминал, чтобы исключить кэш браузера:
curl -sI https://ваш-сайт.ru/wp-login.php | head -1
# HTTP/1.1 403 ForbiddenПараллельно проверьте главную страницу и любой пост:
curl -sI https://ваш-сайт.ru/ | head -1
# HTTP/1.1 200 OK200 на страницах и 403 на wp-login подтверждают точечную блокировку. Если 403 везде — переходите к общей статье по ссылке выше.
Смотрите не только код ответа. По заголовкам и телу страницы 403 часто можно определить, кто сформировал отказ — Wordfence, Cloudflare, веб-сервер или хостинг:
curl -sS -D - -o /dev/null https://ваш-сайт.ru/wp-login.phpОтдельно посмотрите тело ответа:
curl -sS https://ваш-сайт.ru/wp-login.php | headВ заголовках обращайте внимание на Server и cf-ray (Cloudflare), в тексте 403 — на упоминание плагина, WAF или веб-сервера. Так вы сразу сузите поиск до конкретного механизма.
Шаг 2. Проверьте блокировки в плагине безопасности
Wordfence. Если админка недоступна, временно переименуйте каталог wp-content/plugins/wordfence через FTP/SFTP или файловый менеджер хостинга. Wordfence официально рекомендует этот способ для восстановления доступа. Если доступ к админке есть — зайдите в Wordfence → Firewall → Blocking: там можно найти свой IP среди блокировок и снять блокировку кнопкой Unblock. После восстановления доступа верните каталогу исходное имя и включите плагин обратно.
All-In-One Security. Откройте настройки блокировки входа и проверьте список временно заблокированных IP. Если админка недоступна, временно отключите плагин через файловый менеджер или FTP, переименовав его каталог, после чего проверьте доступ к wp-login.php.
Solid Security (ранее iThemes Security). Если админка недоступна, временно переименуйте каталог плагина wp-content/plugins/better-wp-security через FTP/SFTP или файловый менеджер: плагин перестанет применяться, и блокировка не будет действовать. Это способ временного отключения установленного плагина, а не удаление настроек — после проверки верните каталогу исходное имя.
Шаг 3. Проверьте .htaccess
Откройте .htaccess в корне сайта и поищите упоминания wp-login, wp-admin, Deny или Require:
# Через SSH или файловый менеджер
grep -n -iE 'wp-login|wp-admin|Deny|Require|mod_security' .htaccessКоманда предназначена для сервера с SSH. В файловом менеджере хостинга эти строки нужно искать вручную, и правило может оказаться не в корневом .htaccess, а в конфигурации веб-сервера или в .htaccess подпапок.
Если нашли правило вроде:
RewriteRule ^wp-login\.php - [F,L]— закомментируйте его решёткой в начале строки и сохраните файл. Это лишь пример возможного запрета. Директива Require all denied, если встретится, зависит от контекста Apache и версии конфигурации — перед правкой убедитесь, что понимаете, откуда она взялась.
После изменения .htaccess сразу повторите запрос. Если результат не изменился, проверьте другие уровни блокировки и серверный error log.
Шаг 4. Проверьте Cloudflare WAF
Если сайт за Cloudflare (часто на VPS), зайдите в панель и посмотрите события файрвола:
Cloudflare Dashboard → Security → EventsТам видно заблокированные запросы: IP, URI/path, страну и источник срабатывания. Ищите блокировки по URI, содержащему wp-login.php. Типичные виновники:
- Managed Rules, включая Cloudflare Managed Ruleset и OWASP Core Ruleset (блокируют запросы с признаками атаки);
- кастомное правило из раздела Security → WAF → Custom rules — Custom Rules могут фильтровать по IP, URL path и другим параметрам и выполнять действие Block, Challenge или Skip;
- блокировка по стране, если ваш IP вне разрешённой географии.
Если блокирует собственное правило Cloudflare, скорректируйте его условие. Если запрос ошибочно блокируется Managed Rules или другим механизмом WAF, используйте соответствующее исключение или Skip rule для доверенного трафика — конкретный способ зависит от того, какой именно механизм сработал. Подробнее про Cloudflare и админку — в статье «Cloudflare ломает админку WordPress — как исправить».
Шаг 5. Проверьте fail2ban и логи веб-сервера на VPS
На сервере посмотрите активные jails:
sudo fail2ban-client statusНайдите jail, который отвечает за блокировку HTTP/WordPress, и проверьте его статус:
sudo fail2ban-client status ИМЯ_JAILЕсли IP заблокирован этим jail, он появится в Banned IP list:
Banned IP list: ...Снимите блокировку:
sudo fail2ban-client set ИМЯ_JAIL unbanip ВАШ_IPЗаодно проверьте, не режет ли доступ Nginx напрямую — deny-правила в server-блоке:
sudo grep -RniE 'wp-login|deny|location' /etc/nginx/sites-available/Конфигурации могут лежать не только в sites-available — их расположение зависит от дистрибутива и настроек сервера.
Если причина не найдена, смотрите error log веб-сервера в момент запроса к wp-login.php. Для Nginx:
sudo tail -f /var/log/nginx/error.logДля Apache путь зависит от конфигурации, часто используется:
sudo tail -f /var/log/apache2/error.logЭти пути существуют не на каждом сервере — точное расположение логов подскажет конфигурация вашего дистрибутива.
Шаг 6. Включите защиту обратно правильно
После снятия блокировки вход работает, но сайт снова беззащитен. Правильный порядок:
- Зайдите в админку со своего IP.
- Включите плагин безопасности, обновите белый список — добавьте свой IP в исключения.
- Настройте разумный лимит попыток входа и продолжительность временной блокировки, учитывая реальный сценарий использования сайта. Слишком агрессивные лимиты могут блокировать обычных пользователей и администраторов.
Для Wordfence отдельно: настройки Brute Force Protection поддерживают временную блокировку после превышения заданного числа неудачных попыток. Как настроить защиту без ложных блокировок, мы разбирали в статье «Как защитить WordPress от брутфорса: полная настройка».
Проверка результата
После каждого шага проверяйте запрос обычным GET, не HEAD:
curl -sS -o /dev/null -w "%{http_code}\n" https://ваш-сайт.ru/wp-login.phpКоманда curl -sI выполняет HEAD-запрос — её можно оставить как дополнительный вариант, но страницу входа стоит проверять именно GET. Для обычного прямого GET-запроса wp-login.php ожидается 200 OK. Если сайт или защитный механизм перенаправляет запрос, возможен ответ 3xx. Главное — отсутствие 403 и возможность открыть страницу входа.
/wp-login.phpотдаёт 200 или ожидаемый 3xx вместо 403- Форма логина открывается с вашего IP в обычном окне браузера
- WP-ADMIN после авторизации открывается без ошибок
Когда способ не сработает
Блокировка на стороне хостинга. На shared-хостинге блокировку может устанавливать серверная система защиты, например ModSecurity или собственный WAF хостинга. Конкретный механизм зависит от провайдера и тарифа. Зайдите в панель хостинга — там может быть уведомление о блокировке; снять её можно в панели или через поддержку.
Серверной защитой управляет провайдер, а не вы. На shared-тарифах ModSecurity и аналогичные механизмы настраивает хостинг. Если 403 стабильно на запросах к wp-login.php, а плагины и конфигурация чистые — запросите исключение или диагностику в поддержке.
Блокировка по географии, IP или другим характеристикам запроса. Защитный плагин, WAF или CDN может резать целые страны, а ваш IP оказался в подсети. Проверьте в плагине список заблокированных стран — WP Cerber и Solid Security (ранее iThemes Security) умеют это настраивать.
403 возвращается после снятия. Определите источник блокировки по логам и событиям безопасности: при повторной блокировке IP виновато правило, которое продолжает действовать (например, fail2ban снова заблокировал адрес после следующей ошибки входа), WAF, ModSecurity, плагин безопасности или другое серверное правило.
Частые вопросы
Итог: если wp-login.php возвращает 403, а остальные страницы работают, сначала определите источник блокировки. Проверяйте защитный плагин WordPress, .htaccess и конфигурацию веб-сервера, Cloudflare/WAF и серверные системы защиты. Не удаляйте записи из базы данных наугад: сначала определите механизм, который отдаёт 403.
Заблокирован вход в WordPress?
Сниму блокировку и настрою защиту входа за 1 час. Диагностика через удалённый доступ или подскажу пошагово.
