Ошибка 400 Bad Request: причины, диагностика и решение на WordPress
Ошибка 400 Bad Request — одна из самых распространённых HTTP-ошибок, с которой сталкиваются владельцы сайтов на WordPress. Сервер возвращает её, когда не может обработать запрос браузера из-за его некорректного синтаксиса. В отличие от ошибки 404 (страница не найдена), 400 говорит о том, что сервер получил запрос, но считает его «испорченным».
В этой статье разберём три основные причины ошибки 400 на WordPress и пошагово решим каждую.
Причина 1. Некорректный URL
Самая безобидная — пользователь вручную ввёл адрес с недопустимыми символами. WordPress допускает кириллицу в ЧПУ (через плагины вроде Cyr-To-Lat), но некоторые символы в URL запрещены:
- Пробелы (должны заменяться на
%20или-) - Символы
{}|\\^[]в нестандартных местах - Двойное кодирование (
%25вместо%)
Что делать
- Проверьте URL в адресной строке — нет ли там странных символов
- Если ссылка пришла из поисковика — проверьте, не изменилась ли структура ЧПУ после обновления плагина SEO
- Включите редирект 301 со старых URL на новые через плагин (Redirection или Rank Math)
Причина 2. Сбой кукисов и кэша браузера
Повреждённые или устаревшие cookie сессии WordPress — частая причина 400, особенно после обновления сайта или смены домена.
Симптомы
- Ошибка 400 появляется только в одном браузере, но не в других
- Помогает режим инкогнито
- После очистки браузера сайт открывается, но через день ошибка возвращается
Решение
Шаг 1. Очистите куки и кэш браузера:
— Chrome: Настройки → Конфиденциальность → Очистить данные браузера → Куки + Кэш
— Firefox: История → Очистить историю → Куки + Кэш
Шаг 2. Если проблема повторяется — проверьте настройки кэширования на WordPress и отключите кэш сессий временно.
Шаг 3. Сбросьте сессию администратора через БД (крайний случай):
DELETE FROM wp_usermeta WHERE meta_key = 'session_tokens';
После этого все пользователи (включая вас) должны будут заново войти.
Причина 3. Несоответствие DNS-кэша
После смены хостинга или DNS-записей старый IP-адрес может «застрять» в кэше DNS вашего компьютера или провайдера. Браузер пытается подключиться к старому серверу, который отвечает 400.
Как проверить
Откройте терминал и выполните:
nslookup vash-sait.ru
Сравните полученный IP с тем, что указан у хостинг-провайдера. Если адреса разные — проблема в DNS-кэше.
Решение
На локальном компьютере — сбросить DNS-кэш:
# Linux
sudo systemctl restart nscd || sudo systemd-resolve --flush-caches
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
На сервере — проверить настройки WordPress в wp-config.php:
define('WP_HOME', 'https://gurupractice.ru');
define('WP_SITEURL', 'https://gurupractice.ru');
Дополнительная диагностика
Если простые решения не помогают, включите отладку WordPress:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
После воспроизведения ошибки проверьте файл /wp-content/debug.log — там будет точная причина.
Также проверьте логи сервера (Apache/Nginx):
# Nginx
tail -100 /var/log/nginx/error.log
# Apache
tail -100 /var/log/apache2/error.log
Когда обращаться к хостингу
Если вы перепробовали всё, а ошибка 400 остаётся — проблема может быть на стороне хостинг-провайдера:
- Неверная конфигурация .htaccess (Apache)
- Сбой mod_security (блокирует запросы по ложному срабатыванию)
- Проблемы с балансировщиком нагрузки
Попросите поддержку хостинга проверить логи сервера на момент ошибки — они увидят точную причину отклонения запроса.
Краткий чек-лист
- Проверить URL на недопустимые символы
- Открыть сайт в режиме инкогнито — ушла ошибка? Чистите куки
- Проверить DNS: nslookup вашсайт.ру совпадает с IP хостинга?
- Сбросить DNS-кэш на компьютере
- Проверить WP_HOME и WP_SITEURL в wp-config.php
- Включить WP_DEBUG и прочитать debug.log
- Обратиться в поддержку хостинга с логами
Ошибка 400 Bad Request — почти никогда не проблема самого сайта. Это сбой «на стыке» браузера, DNS и промежуточных кэшей. Методично пройдите по чек-листу, и сайт снова заработает.
