Артём Савельев 
Ошибка 400 Bad Request: что означает и как исправить
400 — редкий случай, когда сервер обвиняет не себя, а запрос: «я не понял, что вы прислали». И это единственная ошибка из нашей серии, где совет «почистите куки» — не карго-культ, а реальное лечение главной причины. Разбираем, откуда берутся «плохие запросы», почему они прилетают на ровном месте и что делать по обе стороны экрана.
Что значит «плохой запрос»
Прежде чем обрабатывать запрос по существу, сервер проверяет его формальную корректность: синтаксис, размер заголовков, валидность кук, кодировку URL. Не прошёл контроль — 400, до приложения запрос даже не дошёл. Отсюда важное следствие: 400 почти никогда не означает «сайт сломался». Сломан сам запрос — а вот кто его испортил, браузер посетителя или код сайта, предстоит выяснить. Полная карта кодов ответов — в статье про коды HTTP.
Причина номер один: распухшие куки
У серверов есть лимит на суммарный размер заголовков запроса — у nginx по умолчанию буфер 8 КБ. Куки передаются в заголовках, и на сайтах, где годами копятся куки аналитики, рекламы, тестов и сессий, посетитель однажды упирается в потолок: сервер отвечает 400, а nginx — фирменной страницей «Request Header Or Cookie Too Large». Именно поэтому чистка кук для конкретного сайта действительно лечит 400 — в отличие от большинства других ошибок, где этот совет бесполезен:
| Шаг посетителя | Что закрывает |
|---|---|
| 1. Удалить куки конкретного сайта (не все!) | Распухшие или битые куки — главную причину 400. Достаточно кук одного домена, вся история браузера не нужна |
| 2. Проверить адрес страницы | Битые URL из мессенджеров и рассылок: обрезанные, с кривой кодировкой, с лишними символами |
| 3. Режим инкогнито | Быстрая проверка «дело в моём профиле браузера или в сайте» без чистки чего-либо |
| 4. Отключить расширения браузера | Расширения, которые дописывают заголовки или ломают запросы |
Если вы владелец: когда 400 — ваш баг
Сайт сам раздувает куки. Если жалобы «у меня ошибка 400, помогла чистка кук» повторяются, вопрос не к посетителям: посчитайте, сколько кук и какого размера ставит ваш сайт со всеми счётчиками и пикселями. Порог 8 КБ достигается быстрее, чем кажется, особенно когда куки пишутся на весь домен с поддоменами. Радикальное лечение — ревизия счётчиков (не течёт ли какой-то из них) и увеличение буферов заголовков, симптоматическое — но осознанное.
Кривые ссылки в рассылках и рекламе. Генератор UTM-меток или шаблон рассылки портит URL — и вся кампания ведёт на 400. Особенно обидно, что деньги на трафик уже потрачены. Любую массовую ссылку стоит прогонять через проверку до запуска кампании.
Формы и API, ломающие собственные запросы. Фронтенд после обновления шлёт запросы, которые бэкенд считает некорректными: не тот формат данных, лишние заголовки, битая кодировка. В логах это видно как всплеск 400 на конкретном эндпоинте ровно с момента релиза — откатывайте или чините фронтенд.
Смотрите на долю: единичные 400 в логе — это нормальный фон интернета (боты, кривые клиенты, обрезанные ссылки). Тревога — когда доля 400 растёт, привязана к конкретной странице или началась в момент релиза. Внешний мониторинг здесь даёт точку отсчёта: если проверка с чистым запросом без кук получает 400 — проблема точно на вашей стороне.
Читаем лог: 400 и его сосед 499
# Сколько 400 и от кого (nginx access.log):
grep ' 400 ' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# На какие пути:
grep ' 400 ' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
Если верхние строки — единичные IP со странными путями, это сканеры и боты, шлющие мусорные запросы: нормальный фон, не трогайте. Если один путь собирает сотни 400 от разных обычных посетителей — вот ваша сломанная форма или страница. Заодно о соседе по логу: код 499 — это не «плохой запрос», а специфический код nginx «клиент закрыл соединение, не дождавшись ответа». Много 499 — признак не битых запросов, а медленного бэкенда: посетители уходят раньше, чем сервер отвечает, и это уже сюжет статьи про таймауты.
Родственники 400, с которыми её путают
У «плохого запроса» есть уточняющие братья: 413 — «тело запроса слишком большое» (типично при загрузке файлов больше лимита client_max_body_size), 414 — «URL слишком длинный», 431 — «заголовки слишком большие» (более точный код для той самой куки-проблемы, который отдают некоторые серверы вместо 400). Лечатся они той же логикой: либо запрос действительно чрезмерный, либо лимиты сервера не соответствуют реальным задачам сайта — например, форма загрузки обещает «до 20 МБ», а сервер режет на 1 МБ по умолчанию.
Пруфен проверяет страницы «чистыми» HTTP-запросами без кук и наследия браузера: если такая проверка получает 400 — ошибка системная, а не у конкретного посетителя. В настройках проверки можно задать свои заголовки и метод запроса — удобно, чтобы мониторить и формы, и API-эндпоинты в том виде, в каком их зовёт реальный фронтенд.
Частые вопросы
Ошибка 400 — у меня или у сайта? Быстрый тест: режим инкогнито. Открылось — причина в вашем профиле браузера (куки, расширения), чистите куки сайта. Не открылось и с других устройств тоже 400 — проблема на стороне сайта.
Почему 400 возникает только на одном сайте, а остальные работают? Потому что и куки, и лимиты индивидуальны для каждого сайта: именно на этом домене накопился «мусор» или именно его сервер строже к заголовкам.
«Request Header Or Cookie Too Large» — что делать? Как посетителю — удалить куки этого сайта. Как владельцу — разобраться, почему куки растут (обычно виноват один из счётчиков или собственный код), и при необходимости увеличить буферы заголовков в nginx.
Может ли 400 быть массовым инцидентом? Да — после релиза, ломающего запросы фронтенда, или изменения конфигурации прокси. Признак: доля 400 в логе резко выросла в конкретный момент. Откат изменения обычно решает вопрос быстрее, чем поиск точной причины.