Ошибка 400 Bad Request означает, что сервер отказался обрабатывать запрос, потому что клиент прислал его в некорректном виде: сервер видит синтаксическую ошибку и не понимает, чего от него хотят. Чаще всего причина — испорченные или слишком большие cookie в браузере, но виноват может быть и битый JSON, длинный URL или неверный заголовок.
В этой статье разберём, что стандарт HTTP говорит про код 400, перечислим клиентские и серверные причины в наглядной таблице, покажем, как исправить ошибку обычному пользователю и разработчику, и как быстро диагностировать источник проблемы.
Что значит ошибка 400 Bad Request
Код 400 Bad Request относится к классу клиентских ошибок 4xx. Согласно RFC 9110, §15.5.1, сервер возвращает 400, когда «не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента» — например, искажённый синтаксис, недействительное обрамление сообщения или обманчивая маршрутизация запроса.
Ключевое слово здесь — «клиентская». В отличие от ошибок 5xx, где виноват сервер, при 400 сервер сообщает: «Я работаю нормально, но твой запрос собран неправильно». Поэтому первый шаг диагностики — понять, что именно в запросе не так.
Как выглядит ответ 400
HTTP/1.1 400 Bad RequestContent-Type: text/html; charset=utf-8Connection: close<html> <head><title>400 Bad Request</title></head> <body><h1>Bad Request</h1></body></html>Причины ошибки 400: клиент и сервер
Хотя формально 400 — всегда «вина» клиента, спровоцировать её может и конфигурация сервера (например, слишком строгие лимиты на размер заголовков). Ниже — сводная таблица типичных причин.
| Причина | Сторона | Что происходит | Как исправить |
|---|---|---|---|
| Испорченные или слишком большие cookie | Клиент | Браузер шлёт устаревшие/битые cookie, размер заголовка превышает лимит | Очистить cookie сайта |
| Битый синтаксис запроса | Клиент | Некорректная строка запроса, лишние символы, нарушено обрамление | Проверить формирование запроса в коде |
| Слишком длинный URL или заголовки | Клиент + Сервер | Длина URL/заголовков превышает лимит сервера | Сократить URL, увеличить буферы nginx |
| Неверный Content-Type / битый JSON | Клиент | Тело не соответствует заявленному типу, ошибка в JSON | Валидировать JSON, выставить верный заголовок |
| Устаревший кэш браузера | Клиент | Кэш хранит несовместимые данные запроса | Очистить кэш, обновить страницу |
| Строгие лимиты заголовков | Сервер | large_client_header_buffers слишком мал | Поднять лимиты в конфиге |
Испорченные cookie — причина №1
Самая частая причина 400 у обычных пользователей — «раздувшиеся» или повреждённые cookie. Когда сумма cookie превышает лимит буфера сервера (обычно 4–8 КБ), сервер обрывает запрос с кодом 400. Симптом: ошибка появляется только на одном сайте, а в режиме инкогнито сайт открывается нормально.
Битый JSON и неверный Content-Type
При работе с API документацию 400 часто вызывает некорректное тело запроса. Если вы объявили Content-Type: application/json, но прислали невалидный JSON, сервер ответит 400.
POST /api/v1/orders HTTP/1.1Host: example.comContent-Type: application/json{ "name": "Иван", "amount": } <-- висячая запятая, нет значенияКак исправить ошибку 400 пользователю
Если вы столкнулись с 400 как посетитель сайта, по порядку попробуйте:
- Очистите cookie этого сайта — в настройках браузера удалите данные конкретного домена.
- Очистите кэш и перезагрузите страницу (Ctrl+F5 / Cmd+Shift+R).
- Проверьте URL — уберите лишние символы, обрежьте слишком длинную ссылку.
- Откройте сайт в режиме инкогнито — если работает, проблема в cookie/кэше основного профиля.
- Отключите расширения, которые могут вмешиваться в запросы.
Как исправить ошибку 400 разработчику
Если 400 отдаёт ваш сервер, проверьте формирование запроса и лимиты. При отправке JSON всегда валидируйте тело и выставляйте корректный заголовок:
curl -v -X POST https://example.com/api/v1/orders -H "Content-Type: application/json" -d '{"name":"Иван","amount":100}'Если ошибка вызвана большими заголовками (например, длинный JWT в cookie или заголовке Authorization), увеличьте буферы в nginx:
http { large_client_header_buffers 4 16k; client_header_buffer_size 16k;}Флаг -v в curl показывает и отправленные заголовки запроса, и полученный ответ — это лучший способ увидеть, что реально ушло на сервер.
Как диагностировать источник 400
Чтобы понять, где именно ломается запрос, действуйте от простого к сложному:
- Воспроизведите ошибку в инкогнито — исключите влияние cookie/кэша.
- Повторите запрос через
curl -v— увидите точные заголовки и тело. - Сравните успешный и падающий запрос по заголовкам и телу.
- Проверьте логи сервера — nginx пишет причину (например, «client sent too long header»).
400 против других 4xx: не путайте коды
Код 400 — «общий» ответ на некорректный запрос. Но у него есть более конкретные соседи, и если сервер спроектирован грамотно, он вернёт именно их. Понимание разницы ускоряет диагностику.
- 400 Bad Request — синтаксис запроса битый, сервер не может его разобрать в принципе.
- 401 Unauthorized — синтаксис верный, но не хватает учётных данных аутентификации.
- 403 Forbidden — вы аутентифицированы, но прав на ресурс нет.
- 422 Unprocessable Content — синтаксис верный, но данные не проходят бизнес-валидацию (например, email в неверном формате).
Важный нюанс: некоторые фреймворки отвечают 400 там, где по смыслу подошёл бы 422. Если вы разработчик API, старайтесь разделять «не смог разобрать запрос» (400) и «разобрал, но данные логически некорректны» (422) — это упрощает отладку для клиентов вашего API.
Почему один и тот же запрос падает в одном браузере, но не в другом
Если 400 воспроизводится в Chrome, но не в Firefox или в инкогнито, дело почти всегда в состоянии, привязанном к профилю: накопленные cookie, расширения, переписывающие заголовки, или сохранённый в кэше устаревший запрос. Браузеры хранят cookie независимо, поэтому «раздутый» набор в одном профиле легко превышает буфер сервера, тогда как чистый профиль укладывается в лимит. Это же объясняет, почему очистка данных конкретного сайта — самое быстрое лечение.
Как проверить ответ сервера
Быстрее всего увидеть код ответа и полный набор заголовков — бесплатная проверка HTTP-заголовков и кода ответа на enterno.io. Введите адрес — и сразу увидите статус, заголовки запроса и ответа, редиректы и подсказки по безопасности. Это помогает отличить клиентскую ошибку 400 от серверной 5xx. Если вы диагностируете API, сравните заголовки успешного и падающего запроса: чаще всего разница видна сразу — лишний заголовок, неверный Content-Type или отсутствующий обязательный параметр.
Чек-лист для разработчика
Прежде чем закрывать баг с 400, пройдитесь по короткому списку. Он экономит часы отладки и предотвращает повторное появление ошибки в проде.
- Проверьте, что тело запроса соответствует заголовку
Content-Type. - Валидируйте JSON до отправки — линтером или схемой.
- Убедитесь, что заголовки и URL укладываются в лимиты сервера.
- Логируйте на сервере причину 400 — не отдавайте клиенту «голый» код без пояснения.
- Для API возвращайте машиночитаемое тело ошибки с полем
errorи описанием.
Связанные материалы
Чтобы разобраться в кодах ответа глубже, изучите полный справочник HTTP-кодов, а также разборы соседних ошибок: 403 Forbidden и 404 Not Found. Если 400 связан с cookie, полезен материал про флаги безопасности cookie.
Частые вопросы
400 Bad Request — это ошибка на моей стороне или на стороне сайта?
Формально код 400 относится к классу клиентских ошибок 4xx: сервер сообщает, что запрос собран некорректно. Но спровоцировать её могут и настройки сервера — например, слишком строгие лимиты на размер заголовков. Начинайте диагностику с очистки cookie и кэша, затем проверяйте формирование запроса.
Почему 400 появляется только на одном сайте?
Почти наверняка виноваты повреждённые или раздутые cookie именно этого домена. Каждый сайт хранит свои cookie отдельно, поэтому проблема изолирована. Очистите данные конкретного сайта в настройках браузера или откройте его в режиме инкогнито — если там всё работает, дело точно в cookie или кэше.
Как исправить 400 при отправке JSON в API?
Проверьте, что тело запроса — валидный JSON без висячих запятых и пропущенных значений, а заголовок Content-Type: application/json совпадает с фактическим форматом. Прогоните запрос через curl -v, чтобы увидеть, что реально уходит на сервер, и валидируйте JSON любым линтером перед отправкой.
Почему длинный URL вызывает 400?
У серверов есть лимит на длину строки запроса и размер заголовков (обычно несколько килобайт). Если URL или заголовки его превышают, nginx или Apache обрывают запрос кодом 400. Решение для пользователя — сократить ссылку, для разработчика — увеличить large_client_header_buffers или передавать данные в теле POST-запроса.
Помогает ли перезагрузка страницы при ошибке 400?
Простое обновление помогает редко, потому что причина обычно в сохранённых данных. Эффективнее жёсткая перезагрузка с очисткой кэша (Ctrl+F5) и удаление cookie сайта. Если после этого ошибка исчезает — виноваты были клиентские данные; если нет — проблема в самом запросе или конфигурации сервера.