Ошибка 400 Bad Request: что означает и как исправить

Ошибка 400 означает, что сервер получил запрос, но не смог или не захотел обработать его из-за неверного формата. Причина бывает в адресе, cookies, заголовках, данных формы, прокси или серверных ограничениях.

14.10.2026 · 8 мин чтения

400 Bad Request относится к клиентским ошибкам HTTP. Это не значит, что пользователь обязательно сделал что-то неправильно. Сервер, CDN или защитный фильтр видит запрос как некорректный: например, URL обрезан, заголовок слишком большой, JSON сломан или порт не соответствует протоколу. Повторять тот же запрос без изменений обычно бесполезно.

С кодом 404 разница принципиальная. При 404 сервер понял запрос, но не нашёл ресурс. При 400 он не смог нормально разобрать само обращение. Ошибка 401 относится к авторизации, 403 — к запрету доступа, 413 — к слишком большому телу, 414 — к слишком длинному URL. На практике серверы иногда используют общий 400 вместо более точного кода, поэтому я всегда смотрю детали ответа и лог.

Я начинаю с вопроса: ошибка повторяется у одного человека или у всех? Это быстро делит поиск причины на две ветки. Если страница открывается в другом браузере и с другого устройства, сервер, скорее всего, исправен. Если одинаковый 400 получают все, чистка кэша у посетителя ничего не решит.

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

Я не начинаю с переустановки браузера, драйверов или системы. Для единичной ошибки на одном домене это слишком широкий шаг. Также не стоит отключать защиту компьютера насовсем: краткая проверка нужна только для локализации причины, после неё настройки возвращают.

У формы запрос часто ломается незаметно для посетителя: пустое обязательное поле, неправильная кодировка, неверный Content-Type или JSON с лишней запятой. В инструментах разработчика открываю вкладку Network, повторяю действие и смотрю URL, метод, заголовки, тело запроса и ответ. Пароли и токены перед отправкой кому-либо удаляю.

Запрос разбираю по частям: адрес, метод, заголовки и тело.

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

Страница с сообщением Bad Request почти не объясняет причину. Полезные данные находятся в access.log, error.log, журнале приложения, CDN и WAF. Я фиксирую время, URL, метод, IP или идентификатор запроса — так одну запись можно провести через все уровни инфраструктуры.

Большие cookies и заголовки упираются в буферы, а загрузки — в лимит тела. На Nginx смотрю client_header_buffer_size, large_client_header_buffers и client_max_body_size, но не увеличиваю их вслепую. Сначала измеряю реальный запрос и выясняю, почему он разросся. Лимит может существовать и на CDN, и на балансировщике, и в приложении.

Защитный фильтр способен принять обычное поле формы за атаку. В его журнале обычно видно сработавшее правило. Правильное решение — точечное исключение или корректировка приложения, а не полное отключение защиты. За обратным прокси также проверяю Host, схему, порт и доверенные заголовки.

На стороне сайта проверяю всю цепочку: прокси, веб-сервер, защиту и приложение.

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

Практичный порядок такой: сначала определяю масштаб, затем воспроизвожу запрос, после этого читаю ответ и журнал того узла, который его отклонил. Чистить всё подряд не нужно — у ошибки 400 почти всегда есть конкретный проблемный фрагмент.

SEO

Проверю проблемный запрос, ответ сервера и логи, чтобы отделить ошибку браузера от настройки сайта.