Коротко. 400 Bad Request означает, что сервер не смог разобрать запрос: битый URL, неверные заголовки, слишком длинная строка, повреждённая cookie или JSON. Ошибка почти всегда на стороне запроса, но причиной может быть и WAF, который принял нормальный запрос за атаку.
Как читать материал. Сначала воспроизводим запрос и смотрим, что именно ломается. Потом правим URL, cookie, форму или правило WAF. Нейросеть помогает разобрать текст ошибки, но проверка остаётся за командой и логами.
Что означает ошибка 400
По RFC 9110 сервер возвращает 400, если считает запрос ошибкой клиента: нарушен синтаксис, структура сообщения или маршрутизация. Проще говоря, сервер не понял, что ему прислали.
400 — общий код. В теле ответа часто есть подсказка: «invalid request», «bad header», «malformed JSON». Именно её и нужно читать первой.
400, 404 и 422: в чём разница
| Код | Что означает | Когда ставят |
|---|---|---|
| 400 Bad Request | Запрос не разобран | Битая строка, заголовок, cookie |
| 404 Not Found | Адрес не найден | Нет такого URL |
| 422 Unprocessable Content | Запрос разобран, но данные неверны | Ошибка валидации формы |
400 — про форму запроса. 422 — про смысл данных. На практике сайты часто отвечают 400 на оба случая.
Почему появляется 400
- Некорректный URL. Пробел, спецсимвол или неверно перекодированная кириллица.
- Слишком длинный запрос. Большие заголовки, cookie или query-строка.
- Битые cookie. Старое значение после смены домена или формата.
- Неверный JSON. Лишняя запятая, неверная кавычка, пустое тело.
- WAF или CDN. Правило блокирует запрос и отдаёт 400 вместо 403.
- HTTP/2 и прокси. Несовместимые заголовки после балансировщика.
- Форма с файлом. Тело не соответствует
Content-Type.
Как проверить
Сначала воспроизведите запрос в терминале и посмотрите детали:
curl -v "https://site.ru/search?q=test"Флаг -v покажет строку запроса, заголовки и ответ. Если 400 появляется только в браузере, проверьте чистый профиль без cookie и расширений.
В DevTools откройте Network, найдите красный запрос и посмотрите Request URL, Request Headers и Payload. Часто видно пробел в URL или двойное кодирование.
Классический путь. Сравните рабочий и нерабочий запрос: URL, заголовки, тело.
С нейросетью. Отдайте оба запроса и текст ответа, попросите найти различие.
Вот два curl-запроса: рабочий и с ошибкой 400, и текст ответа сервера.
Найди различие в URL, заголовках и теле. Назови минимальную правку.
Не предлагай отключать WAF, пока не проверишь сам запрос.Проверка. Повторите запрос после правки и убедитесь, что код стал 200 или 302. Если 400 остаётся, смотрите логи сервера и WAF.
Как исправить
| Причина | Что делать |
|---|---|
| Пробел или спецсимвол в URL | кодировать через encodeURIComponent |
| Двойное кодирование | убрать лишний encodeURI на бэкенде |
| Длинные заголовки | увеличить буфер или сократить cookie |
| Битые cookie | очистить cookie и проверить домен |
| Неверный JSON | проверить тело и Content-Type |
| Ложное срабатывание WAF | добавить исключение по правилу, а не отключать защиту |
| Ошибка после прокси | сравнить заголовки до и после балансировщика |
Пример nginx: увеличить число и размер буферов для длинных заголовков, если запрос приходит с большими cookie.
large_client_header_buffers 4 16k;Меняйте значение только после того, как увидите в логах строку о превышении буфера.
Влияет ли 400 на SEO
Если 400 отдаёт обычная страница, робот не получит её содержимое. Постоянные 400 на важных URL могут привести к выпадению из индекса.
Если 400 стоит на битых ссылках, мусорных параметрах или атаках, на индексацию это не влияет. Но такие URL лучше отдавать 404 или 410, чтобы не плодить ошибки.
Где помогает нейросеть
| Задача | Что делает модель | Что проверять руками |
|---|---|---|
| Разбор текста ошибки | объясняет формулировку сервера | код и логи |
| Сравнение запросов | находит различие | фактический URL и заголовки |
| Правка формы | предлагает проверку полей | отправка в браузере |
| Письмо хостингу | описывает воспроизведение | точные команды и время |
Частые ошибки
- Отключать WAF вместо поиска правила.
- Кодировать URL дважды.
- Чинить бэкенд, когда ошибка в cookie браузера.
- Игнорировать текст ответа.
- Ставить 400 на все ошибки валидации, хотя для данных есть 422.
- Не проверять запрос после прокси и CDN.
Вопросы
400 — ошибка клиента или сервера?
Формально 4xx: сервер считает запрос некорректным. Но причина может быть в сайте: форма, прокси, WAF или конфиг.
Чем 400 отличается от 422?
400 — запрос не разобран. 422 — разобран, но данные не прошли валидацию.
Влияет ли 400 на индексацию?
Если код получают обычные страницы, да. Если только битые ссылки и параметры, влияния на индекс нет.
Может ли нейросеть исправить 400?
Она объясняет причину и предлагает правку, но проверить её нужно реальным запросом.
Связанные материалы
Источники
Официальные документы 5
- RFC 9110: 400 Bad Requestrfc-editor.org
- MDN: 400 Bad Requestdeveloper.mozilla.org
- MDN: процентное кодирование URLdeveloper.mozilla.org
- nginx: large_client_header_buffersnginx.org
- Google Search Central: HTTP status codesdevelopers.google.com