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

HTTP 400 Bad Request означает, что сервер не может или не хочет обработать запрос из-за ошибки, которую считает ошибкой клиента. RFC 9110 приводит типичные классы причин: некорректный синтаксис запроса, неправильное framing сообщения или подозрительную маршрутизацию запроса.

На практике 400 не означает автоматически «сломался браузер». Ответ может сформировать CDN, reverse proxy, web-server, API gateway или само приложение. Поэтому полезная диагностика начинается с двух вопросов: какой именно запрос получает 400 и какой компонент его отклоняет.

Что означает HTTP 400

Упрощённая цепочка выглядит так:

клиент → CDN / WAF → reverse proxy → приложение
              ↓             ↓            ↓
             400           400          400

Одинаковый код может возникнуть на разных уровнях. Например, proxy способен отвергнуть слишком большой или синтаксически некорректный набор заголовков ещё до передачи запроса приложению. API, напротив, может принять HTTP-сообщение, распарсить его и вернуть 400 из-за неправильного формата входных данных.

Поэтому текст страницы ошибки полезен, но решающими остаются фактический HTTP-ответ и логи того компонента, который его сформировал.

Чем 400 отличается от соседних 4xx

Если приложение использует 400 для всех ошибок валидации, это допустимо как часть его API-контракта, но при диагностике важно читать тело ответа и документацию конкретного endpoint.

Основные причины 400 Bad Request

Ошибка в URL

Проверьте:

• опечатки в path;
• неправильное URL-кодирование;
• лишние или повреждённые escape-последовательности;
• неожиданно длинную query string;
• параметры, которые приложение не умеет разбирать.

Для ручной проверки сначала скопируйте URL без изменений и выполните:

curl -i 'https://example.com/path?key=value'

Кавычки важны: без них shell может интерпретировать &, ?, * и другие символы не так, как вы ожидаете.

Некорректные или слишком большие заголовки

Большие cookies, повторяющиеся заголовки или неверный Host могут привести к отклонению запроса на уровне proxy/web-server.

Полезно сравнить запрос браузера и минимальный запрос curl:

curl -i https://example.com/

Если curl получает 200, а браузер стабильно 400, одна из первых гипотез — различие в cookies, расширениях, proxy-настройках или заголовках браузера.

Повреждённые cookies

Большой или устаревший cookie-набор способен влиять на размер и содержимое заголовка Cookie.

Для проверки не обязательно сразу очищать все данные браузера. Сначала можно открыть приватное окно или отправить запрос без сохранённых cookies через curl. Если проблема исчезает, сравните запросы и найдите конкретное различие.

Невалидный JSON

Для API типичный сценарий:

{
  "name": "Иван",
  "enabled": true,
}

Лишняя запятая делает JSON невалидным. Сервер, который ожидает JSON, может вернуть 400.

Проверка:

curl -i \
  -X POST \
  -H 'Content-Type: application/json' \
  --data '{"name":"Иван","enabled":true}' \
  https://api.example.com/v1/items

Смотрите одновременно на HTTP-код и тело ответа: качественный API обычно сообщает, какое поле или часть запроса не удалось разобрать, если это безопасно раскрывать клиенту.

Неправильный Content-Type

Если отправляется JSON, а клиент сообщает другой media type, сервер может интерпретировать тело не тем parser. В зависимости от реализации это может закончиться 400 или более специфичным 415 Unsupported Media Type.

Проблема с Host или маршрутизацией

В HTTP/1.1 значение Host участвует в выборе virtual host. Некорректный host, конфликтующая proxy-конфигурация или защитное правило против подмены host способны завершиться 400 до приложения.

Некорректное тело формы или multipart-запроса

При ручной сборке multipart-запросов частая ошибка — самостоятельно задавать Content-Type: multipart/form-data без правильного boundary. Если curl формирует multipart через -F, boundary лучше доверить ему:

curl -i \
  -F 'file=@report.pdf' \
  https://example.com/upload

Шаг 1. Подтвердите настоящий статус

curl -i https://example.com/problem-url

Смотрите:

• первую строку ответа;
• Server;
• CDN/WAF-заголовки;
• request ID;
• тело ошибки.

Если браузер показывает собственную страницу, curl помогает отделить UI браузера от реального ответа сервера.

Шаг 2. Сведите запрос к минимальному

Начните с простого варианта:

curl -i https://example.com/api/items

Затем по одному добавляйте:

1. HTTP-метод;
2. query params;
3. заголовки;
4. авторизацию;
5. body.

Так быстрее определить, после какого элемента появляется 400.

Шаг 3. Сравните рабочий и нерабочий запрос

Если один клиент работает, а другой нет, сравните:

метод
URL
Host
Content-Type
Authorization
Cookie
Content-Length
body

Не публикуйте Authorization, session cookies и другие секреты в тикете или общем чате.

В браузере используйте DevTools → Network и смотрите Request Headers / Payload. Для curl полезен verbose-режим:

curl -v https://example.com/

-v может вывести чувствительные заголовки, поэтому перед передачей результата очистите секреты.

Шаг 4. Проверьте, доходит ли запрос до приложения

Это ключевое разделение.

Если application log вообще не содержит проблемного запроса, 400 вероятно формируется раньше:

клиент → CDN/WAF → proxy → приложение
                ↑
           искать здесь

Если запрос есть в application log, ищите ошибку парсинга, валидации или routing уже там.

Шаг 5. Сопоставьте access и error logs

Для Nginx типовая отправная точка:

sudo tail -n 200 /var/log/nginx/access.log
sudo tail -n 200 /var/log/nginx/error.log

Ищите точное время, URL и request ID. Формат и сообщения зависят от вашей конфигурации и версии Nginx, поэтому не делайте вывод по одной строке без контекста.

Шаг 6. Проверьте ограничения proxy и приложения

Проверьте отдельно ограничения на:

• размер request headers;
• размер body;
• допустимую длину URI;
• число параметров;
• parser limits;
• формат JSON/form data.

Если ограничение превышено, более специфический код вроде 413 или 414 может быть информативнее, но фактическое поведение зависит от компонента.

400 в REST API

API-клиенту важно не просто «починить 400», а понять контракт endpoint.

Например:

POST /v1/users HTTP/1.1
Content-Type: application/json

{
  "email": "not-an-email"
}

Синтаксически JSON корректен, но значение может не пройти application validation. Некоторые API используют 400, другие — 422 Unprocessable Content. Ориентируйтесь на документированный контракт конкретного API.

Связанный материал: как проверить доступность REST API.

Когда проблема только у одного пользователя

Если сайт работает у остальных, проверьте последовательно:

1. тот же URL в приватном окне;
2. другой браузер;
3. cookies конкретного домена;
4. корпоративный proxy/VPN;
5. расширения;
6. повторение через curl.

Не начинайте с очистки всех данных и переустановки браузера: сначала локализуйте различие.

Когда 400 появился после релиза

Сопоставьте первое появление с:

• новым routing;
• изменением схемы JSON;
• изменением proxy;
• новым WAF-правилом;
• изменением максимального размера заголовков/body;
• новым middleware валидации.

Если 400 резко вырос после deployment, полезно сравнить долю ответов по endpoint и версии приложения.

Как проверить восстановление

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

for i in {1..10}; do
  curl -sS -o /dev/null \
    -w '%{http_code} %{time_total}\n' \
    'https://example.com/problem-url'
  sleep 1
done

Если ошибка зависела от конкретного body или заголовка, тест восстановления должен их сохранять.

Как обнаруживать 400 автоматически

Автоматический HTTP-мониторинг полезен для URL, которые в норме обязаны возвращать определённый успешный код. Он фиксирует внешний симптом и время его появления. Но для поиска причины 400 всё равно понадобятся request details и server-side logs.

UpWatch уместно использовать для регулярного контроля критичного публичного URL, если его ожидаемый HTTP-ответ стабилен.

Типичные ошибки при диагностике

Считать любой 400 проблемой браузера

Ответ мог сформировать WAF, proxy или приложение.

Сразу очищать всё

Это уничтожает часть воспроизводимого контекста. Лучше сначала сравнить запросы.

Смотреть только body ошибки

Кастомная HTML-страница не доказывает, какой компонент вернул статус.

Повторять тот же запрос без изменений

Если причина в самом запросе, RFC-семантика 400 как раз указывает, что повтор без исправления обычно не решает проблему.

Практический чек-лист

1. Зафиксировать URL, метод и время.
2. Подтвердить реальный HTTP 400 через curl.
3. Определить компонент, сформировавший ответ.
4. Свести запрос к минимальному.
5. По одному вернуть headers, auth и body.
6. Сравнить рабочий и нерабочий запрос.
7. Проверить application log.
8. Проверить proxy/CDN/WAF logs.
9. Проверить parser и size limits.
10. Исправить причину и повторить исходный запрос серией проверок.

Источники и спецификации

• RFC 9110: 400 Bad Request
• curl: официальная документация