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

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

Ошибка 400 встречается и у обычных пользователей в браузере, и у разработчиков при работе с API. В браузере она часто выглядит как «Bad Request», «HTTP Error 400» или «400. That's an error». В API это может быть JSON-ответ с описанием поля, которое не прошло проверку.

Разберём, что означает ошибка 400, чем она отличается от соседних HTTP-кодов, как быстро найти причину и что исправлять на стороне браузера, приложения, Nginx, прокси или API-клиента.

Что означает ошибка 400 Bad Request

Код 400 относится к классу 4xx: сервер считает проблему в запросе клиента — не обязательно в «вине пользователя» в бытовом смысле. Клиентом может быть браузер, мобильное приложение, интеграция, backend-сервис, API Gateway, reverse proxy или мониторинг, который шлёт HTTP-запросы по расписанию.

Сервер получил запрос, но не может его разобрать или принять — обычно это происходит на раннем этапе обработки: парсинг HTTP, проверка заголовков, чтение тела запроса, валидация формата и обязательных параметров, до выполнения бизнес-логики.

Типичные формулировки:

• 400 Bad Request;
• HTTP Error 400;
• Bad Request - Invalid URL;
• 400 Request Header Or Cookie Too Large;
• The request could not be understood by the server;
• JSON-ответ вида {"error":"invalid_request"} или {"message":"Bad Request"}.

Сам код не говорит, что именно сломано: один и тот же ответ может вернуть Nginx, CDN, API Gateway, backend-фреймворк или приложение. Поэтому первый шаг диагностики — понять, кто сгенерировал ответ: браузер, прокси, веб-сервер или backend.

Держите под рукой справочник всех кодов ответов HTTP: 400 — лишь один из кодов клиентских ошибок, рядом есть более точные варианты 401, 403, 404, 409, 413, 415, 422, 429.

Чем 400 отличается от 403, 404 и 500

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

1) 400 Bad Request — запрос некорректен по форме или параметрам: битый URL, неверный JSON, неожиданный заголовок, слишком длинные cookies, неправильный Content-Type. Сервер не может нормально его обработать.

2) 403 Forbidden — сервер понял запрос, но отказывает в доступе. Например, не хватает прав, IP заблокирован, сработал WAF, закрыт каталог, запрещён метод. Подробнее — в разборе ошибки 403 Forbidden.

3) 404 Not Found — сервер понял запрос, но не нашёл ресурс по указанному пути: битая ссылка, удалённая страница, неправильный маршрут или ошибка в роутинге. Подробнее — в статье про ошибку 404 Not Found.

4) 500 Internal Server Error — запрос мог быть корректным, но приложение упало или не смогло выполнить операцию. Это уже класс 5xx, серверная проблема. Сравните с ошибкой 500.

5) 422 Unprocessable Content — более точная альтернатива для API: синтаксис запроса нормальный, но данные не проходят бизнес-валидацию. Например, email невалиден или обязательное поле пустое. Некоторые фреймворки возвращают 400, другие — 422.

Граница между 400 и соседними кодами зависит от реализации. Старые API часто используют 400 почти для всех ошибок клиента. Более аккуратные разделяют: 400 — синтаксис и формат, 401 — нет аутентификации, 403 — нет прав, 404 — ресурс не найден, 409 — конфликт состояния, 413 — тело слишком большое, 415 — неподдерживаемый формат, 422 — данные не прошли валидацию.

Основные причины ошибки 400

У 400 Bad Request много источников, но большинство укладывается в несколько групп. Для диагностики полезно идти от простого к сложному: URL → cookies → заголовки → тело запроса → прокси → приложение.

1) Некорректный URL — недопустимые символы, неправильное экранирование, лишний %, сломанная кодировка, пробелы, дублирующиеся фрагменты, слишком длинная query-строка. Например, %E0%A4%A — незавершённая percent-encoded последовательность, которую сервер не сможет разобрать.

2) Слишком длинные cookies — частая причина в браузере: сайт накапливает сессии, A/B-тесты, аналитику, корзину, feature flags, и в какой-то момент заголовок Cookie становится слишком большим. Nginx, Apache, CDN или backend отвечают 400, иногда прямо с текстом Request Header Or Cookie Too Large.

3) Ошибочные HTTP-заголовки — недопустимые символы, неправильный формат или неожиданное значение: битый Host, некорректный Content-Length, невалидный Authorization, конфликт Transfer-Encoding и Content-Length.

4) Неверный Content-Type — клиент шлёт JSON с Content-Type: text/plain или форму с application/json. Backend пытается распарсить тело не тем парсером и возвращает 400.

5) Сломанное тело запроса — битый JSON, незакрытая строка, лишняя запятая, неверная кодировка, обрезанный payload. Для API это одна из самых частых причин.

6) Неправильные параметры API — нет обязательного поля, параметр передан не туда, не совпадает тип: строка вместо числа, массив вместо объекта, дата не в ожидаемом формате. Некоторые API называют это 400, хотя по смыслу иногда подходит 422.

7) Ограничения размера — слишком длинный URL, большие заголовки, крупное тело, большой файл, много параметров формы. Часть серверов вернёт более точные 413 Payload Too Large или 414 URI Too Long, но на практике встречается и 400.

8) Проблемы reverse proxy — Nginx, HAProxy, CDN или API Gateway меняет запрос: теряет Host, неправильно прокидывает заголовки, режет тело, не поддерживает метод, конфликтует с upstream. При проксировании нескольких сайтов см. материал про Nginx reverse proxy.

9) WAF, CDN или защита от ботов — защитный слой трактует запрос как подозрительный: SQL-инъекция в параметре, странный User-Agent, нестандартные заголовки, частые запросы. Иногда WAF возвращает 403, иногда 400.

10) Ошибки в клиентском коде — frontend, мобильное приложение или интеграция формируют запрос не так, как ожидает API: контракт изменился после релиза, а часть клиентов ещё отправляет старый формат.

Как исправить ошибку 400 на стороне пользователя

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

1) Обновите страницу и проверьте адрес — убедитесь, что URL без пробелов, лишних символов, обрезанных параметров, двойного https://, странных %-последовательностей. Если ссылка скопирована из письма или мессенджера, откройте сайт с главной и перейдите к разделу вручную.

2) Откройте сайт в режиме инкогнито — если там всё работает, причина в cookies, кэше или расширениях основного профиля.

3) Очистите cookies только для этого сайта — не обязательно чистить весь браузер: в настройках найдите данные сайта и удалите cookies для проблемного домена. Помогает при Request Header Or Cookie Too Large, битой сессии или конфликте cookies после переезда домена.

4) Отключите расширения — блокировщики рекламы, VPN, прокси-плагины и корпоративные агенты могут менять заголовки или cookies. Проверьте сайт без них.

5) Попробуйте другой браузер или сеть — если ошибка повторяется только в одном браузере, проблема локальная; если только в одной сети — возможно, запрос меняет корпоративный прокси, фильтр или VPN.

6) Проверьте время и системные настройки — с датой ошибка 400 связана редко, но некорректное время может ломать авторизацию, токены и cookies, особенно в личных кабинетах.

7) Сообщите владельцу сайта детали — URL, время, браузер, текст ошибки, действия перед появлением. Это поможет найти запись в access/error-логах.

Если сайт важен для бизнеса, разовая проверка вручную не заменяет наблюдение: сервис мониторинга проверяет URL с заданным интервалом и присылает уведомление о сбое, помогая быстрее заметить, что 400 стала массовой, а не осталась жалобой одного пользователя. Общий принцип описан в статье что такое uptime monitoring.

Как исправить 400 в API и клиентском коде

Для разработчика 400 — сигнал проверить контракт запроса: сначала воспроизведите его минимальным способом и сравните с документацией API, не начиная с сервера.

1) Проверьте метод и URL — GET, POST, PUT, PATCH, DELETE должны совпадать с ожидаемым endpoint. Часто клиент шлёт POST /api/users/ вместо POST /api/users, а backend или proxy настроен чувствительно к trailing slash.

2) Проверьте query-параметры — имена, типы, кодировку, обязательность. Значения в URL должны быть корректно encoded: пробел — это %20 или +, а не буквальный пробел. Кириллицу, спецсимволы и JSON в query лучше кодировать явно.

3) Проверьте Content-Type и Accept — для JSON нужен Content-Type: application/json, для ответа в JSON — Accept: application/json. Ошибочный заголовок часто заставляет сервер выбрать не тот парсер.

4) Проверьте тело запроса — валидность JSON, обязательные поля, типы, формат дат, enum-значения. Прогоните JSON через валидатор или распарсите локально: лишняя запятая — классическая причина 400.

5) Проверьте авторизацию — неверный формат Authorization может давать 400, хотя корректнее 401 или 403. Формат для Bearer-токена: Authorization: Bearer <token>, без кавычек и лишних префиксов.

6) Уберите лишние заголовки — если запрос формирует сложный SDK или браузерный клиент, соберите минимальный запрос через curl: только метод, URL, Content-Type, авторизация и тело. Подробнее — в материале что такое curl и как им пользоваться.

7) Сравните успешный и неуспешный запросы — в DevTools, Postman, Insomnia или логах: смотрите не только body, но и заголовки, cookies, query-строку, метод, redirect-цепочку.

8) Не путайте CORS и 400 — CORS-ошибки браузер обычно блокирует до чтения ответа, но preflight-запрос OPTIONS может получить 400, если backend не умеет его обрабатывать. Разбор — в статье как настроить CORS правильно.

Минимальный запрос для проверки API: curl -i -X POST https://example.com/api/orders -H 'Content-Type: application/json' -d '{"productId":123,"count":1}'. Ключ -i покажет статус и заголовки ответа, -v — детали соединения и отправляемые заголовки.

Что проверять на сервере, в Nginx и прокси

Если 400 встречается у многих пользователей или появилась после релиза инфраструктуры, ищите её на стороне веб-сервера, прокси и backend — главная задача понять, какой слой вернул ответ.

1) Access-логи веб-сервера — проверьте статус 400, URL, размер запроса, User-Agent, Referer, IP, upstream status. В Nginx полезно логировать $status, $request, $request_length, $http_user_agent, $upstream_status, $host, $http_cookie. Пустой upstream_status означает, что ответ вернул сам Nginx, не дойдя до приложения.

2) Error-логи Nginx — ищите client sent invalid request, client sent too long header line, client sent too large request, invalid host in request: они обычно прямо указывают причину.

3) Размер заголовков и cookies — за буферы заголовков в Nginx отвечает large_client_header_buffers. Если пользователи получают 400 Request Header Or Cookie Too Large, проверьте размер cookies и лимиты, но не лечите всё увеличением буфера — лучше удалить лишние cookies и ограничить их область через Domain, Path, Max-Age.

4) Размер тела запроса — для больших payload используется client_max_body_size, хотя превышение часто даёт 413. Лимиты есть и в приложении: body-parser в Node.js, настройки FastAPI/Starlette, Spring, Django, PHP-FPM, API Gateway.

5) Проксирование Host и схемы — backend может ожидать корректные Host, X-Forwarded-Proto, X-Forwarded-For, X-Real-IP. Если reverse proxy прокидывает не то, приложение иногда считает запрос некорректным и возвращает 400.

6) Символы в заголовках — Nginx по умолчанию может игнорировать или запрещать нестандартные заголовки: например, заголовки с подчёркиваниями требуют настройки underscores_in_headers. Включайте её только если понимаете последствия и контролируете клиентов.

7) HTTP-версия и keep-alive — редкая, но неприятная группа: некорректный Content-Length, обрыв соединения, конфликт chunked encoding, баг клиента или промежуточного прокси. Симптом — часть запросов падает с 400, часть проходит.

8) CDN и WAF — если перед сайтом стоит CDN, проверьте его логи и правила безопасности: запрос может не доходить до origin, тогда логи backend будут пустыми, а 400 вернёт внешний слой.

9) Релизы конфигурации — сопоставьте время появления ошибок с изменениями: деплой frontend, обновление API-контракта, новый Nginx-конфиг, включение CDN, изменение правил WAF, переезд на другой домен.

В контейнерных окружениях запрос проходит через несколько внутренних сетей, ingress, sidecar и service mesh. Фиксируйте request_id и прокидывайте его через все слои — иначе один 400 сложно собрать в единую цепочку.

Диагностика: короткий чеклист

Ошибка 400 диагностируется быстрее, если не гадать, а собрать минимальный набор фактов. Чеклист подходит и для сайта, и для API.

1) Зафиксируйте точный запрос — метод, полный URL, query-параметры, заголовки, cookies, body, IP клиента, время, статус, текст ответа. В браузере — вкладка Network в DevTools: клик по запросу → Headers → Payload → Response.

2) Повторите запрос без браузера — через curl или Postman. Если через curl запрос проходит, а в браузере нет, смотрите cookies, расширения, CORS, preflight, редиректы; если не проходит везде — проблема в URL, заголовках, body или на сервере.

3) Упростите запрос — уберите cookies, необязательные заголовки, лишние поля body, затем возвращайте элементы по одному: так быстрее найти конкретный параметр или заголовок, который ломает обработку.

4) Проверьте, кто вернул ответ — заголовки Server, Via, X-Request-Id, CF-Ray, X-Cache, HTML-шаблон ошибки: страницы Nginx, Cloudflare, API Gateway и backend обычно выглядят по-разному.

5) Найдите запись в логах — если в access-логе origin нет запроса, значит, ответ вернул CDN, балансировщик или другой промежуточный слой; если запрос есть в Nginx, но нет в backend-логах, вероятно, Nginx отсекает его до upstream.

6) Сравните с рабочим запросом — самый быстрый способ: возьмите запрос с 200 и запрос с 400 и сравните diff — URL, headers, cookies, body, размер, авторизация.

7) Проверьте последние изменения — релиз клиента, backend, схемы валидации, middleware, proxy-конфиг, правила WAF. Ошибка 400 часто появляется после частичного обновления: frontend уже отправляет новый формат, а часть backend-инстансов ещё ждёт старый.

8) Проверьте массовость — один пользователь, конкретный браузер, регион, версия мобильного приложения или все клиенты. Нужны логи, метрики и мониторинг HTTP API. Хороший ориентир — RED-метрики: rate, errors, duration; подробнее — в статье про мониторинг HTTP API.

Для публичного сайта имеет смысл отдельно проверять ключевые URL: главная, логин, корзина, API health endpoint. Statuser может проверять сайт с заданным интервалом и присылать уведомление, если вместо 200 начал приходить 400 или другой сбойный статус — особенно полезно после релизов, когда ручная проверка не покрывает все сценарии.

Как предотвратить ошибку 400

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

1) Валидируйте входные данные явно — схемы JSON Schema, OpenAPI, Zod, Joi, Pydantic, class-validator. Ошибка должна говорить, какое поле неверно: email must be a valid email, count must be greater than 0, from is required.

2) Разделяйте HTTP-коды — не возвращайте 400 на всё подряд: 401 для аутентификации, 403 для запрета, 404 для отсутствующего ресурса, 409 для конфликта, 413 для большого тела, 415 для неподдерживаемого формата, 422 для валидации, если это принято в вашем API.

3) Делайте стабильный формат ошибок — например, code, message, details, requestId: клиенту проще обработать ошибку, а поддержке — найти её в логах.

4) Ограничивайте cookies — следите за размером, областью действия и сроком жизни, не храните в cookies всё подряд. Не задавайте cookies на верхний домен без необходимости: иначе они будут отправляться на лишние поддомены и увеличивать каждый запрос.

5) Документируйте API-контракт — OpenAPI/Swagger, примеры запросов, допустимые значения enum, форматы дат, требования к заголовкам: чем точнее контракт, тем меньше случайных 400.

6) Тестируйте негативные сценарии — битый JSON, пустое тело, неправильный Content-Type, длинный URL, отсутствующий Host, лишние поля, старые версии клиента. Такие тесты помогают вернуть понятный ответ вместо неясного Bad Request.

7) Логируйте безопасно — для 400 полезны request id, endpoint, причина валидации, размер запроса, версия клиента, но не пароли, токены, cookies и персональные данные. Заголовок Authorization лучше маскировать.

8) Следите за всплесками 400 — единичные ошибки нормальны, массовый рост — сигнал: например, релиз frontend отправил неверное поле, устарела мобильная версия, CDN изменил заголовки, WAF стал блокировать легитимные запросы.

9) Проверяйте совместимость версий — если API меняется, старые клиенты должны получать понятную ошибку или продолжать работать в рамках versioning: /v1, /v2, заголовки версии, feature flags.

10) Настраивайте прокси осознанно — не увеличивайте лимиты без анализа, не отключайте проверки «чтобы заработало», не пропускайте опасные заголовки вслепую: иногда 400 защищает сервер от действительно некорректного или вредного запроса.

FAQ

Что значит ошибка 400 простыми словами?

Сервер получил запрос, но считает его некорректным: неправильный URL, заголовки, cookies, тело запроса или параметры. Поэтому он не стал выполнять операцию.

Ошибка 400 — это проблема сайта или пользователя?

Может быть и так, и так. У одного пользователя часто виноваты cookies, кэш или расширения. Если ошибка массовая, вероятнее проблема в API, веб-сервере, прокси, CDN или недавнем релизе.

Поможет ли очистка кэша при 400 Bad Request?

Иногда помогает, но чаще нужно очистить cookies конкретного сайта. Особенно если сообщение похоже на Request Header Or Cookie Too Large.

Почему API возвращает 400 вместо подробной ошибки?

Так бывает при плохой обработке ошибок или когда запрос отклоняет не приложение, а Nginx, API Gateway, WAF или парсер тела запроса. Проверьте логи и добавьте единый формат ошибок с requestId.