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

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

По RFC 9110 (раздел 15.5.1) сервер возвращает 400, когда не может или не хочет обрабатывать запрос из-за того, что воспринимает его как ошибку клиента: неверный синтаксис, неправильная структура сообщения или подмена маршрутизации. Это общий код: он не уточняет, что именно не так, и подробности нужно искать в теле ответа и логах сервера.

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error":"invalid_json","message":"Unexpected token } at position 41"}

Частые причины 400

• Слишком большие cookie или заголовки. Типичное сообщение nginx: «400 Request Header Or Cookie Too Large».
• Ошибки в URL: недопустимые символы, неэкранированные пробелы, повреждённая ссылка.
• Некорректное тело запроса: сломанный JSON, неверный Content-Type, обрезанная загрузка файла.
• Простой HTTP на порт HTTPS (сообщение nginx «The plain HTTP request was sent to HTTPS port»).
• Неверный заголовок `Host` или нарушение формата запроса клиентом или прокси.
• Слишком большой запрос на стороне веб-приложения или CDN.

Что делать посетителю

1. Проверьте адрес: нет ли в нём лишних символов, пробелов, обрывков чужой ссылки.
2. Очистите cookie и кеш для этого сайта: раздутые cookie самая частая причина 400 на нормальных сайтах.
3. Откройте страницу в режиме инкогнито или другом браузере и отключите расширения.
4. Если ошибка возникла при загрузке файла, проверьте размер и формат файла.
5. Если ничего не помогло, сообщите владельцу сайта точный адрес и время ошибки.

Что делать владельцу и разработчику

Начните с журнала ошибок веб-сервера: там обычно видна точная причина. Затем по сценариям.

Слишком большие заголовки и cookie

http {
    client_header_buffer_size 4k;
    large_client_header_buffers 4 16k;
}

LimitRequestFieldSize 16384
LimitRequestLine 16384

Но надёжнее убрать причину, а не поднимать лимиты: сократить число cookie, не хранить в них большие данные, чистить отслеживающие cookie поддоменов.

Некорректные запросы в API

Для ошибок клиента API возвращайте 400 с понятным телом: какое поле не прошло проверку и почему. Это упрощает отладку и снижает число повторных попыток. Для синтаксически верного, но семантически неверного запроса (например, не прошла бизнес-валидация) многие API используют 422.

app.post("/api/subscribe", express.json(), (req, res) => {
  if (typeof req.body.email !== "string" || !req.body.email.includes("@")) {
    return res.status(400).json({ error: "invalid_email" });
  }
  res.status(201).end();
});

Если вы получаете 400 в клиентском коде (в логах request failed with status code 400), проверьте тело запроса, заголовок Content-Type и URL, который реально отправляется: нередко в строку подставляется undefined или лишний символ.

Как найти причину по сообщению сервера

Журнал ошибок nginx обычно лежит в /var/log/nginx/error.log, Apache — в /var/log/apache2/error.log (или /var/log/httpd/error_log). Сопоставьте время запроса с записью: там часто есть точная причина.

Как 400 влияет на SEO

Для поисковых роботов 400 означает, что страница недоступна. Google относит все ошибки 4xx, кроме 429, к одной группе: URL без контента в индекс не попадает, а уже проиндексированные страницы постепенно исключаются. Яндекс также не включает такие страницы в поиск. Постоянный 400 на реальных страницах для робота, например из-за неправильной обработки кириллических URL или заголовков, означает потерю этих страниц в выдаче. Проверьте, что нужные страницы отдают 200 при запросе с обычными заголовками.

Как проверить

Откройте адрес в проверке кода ответа: инструмент отправит запрос как обычный клиент и покажет статус, редиректы и заголовки. Для отладки тела запроса используйте curl -i -X POST -H "Content-Type: application/json" -d '{"a":1}' https://example.com/api.