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

Что такое ошибка 400 Bad Request?

400 Bad Request («неверный запрос») — это код состояния HTTP, который означает, что сервер получил ваш запрос, но не будет его обрабатывать, потому что с самим запросом что-то не так. Стандарт HTTP (RFC 9110, раздел 15.5.1) определяет его так: сервер не может или не хочет обрабатывать запрос «из-за того, что воспринимается как ошибка клиента», например некорректного синтаксиса, неверного формирования сообщения или обманной маршрутизации запроса.

В отличие от ошибки 500, которая означает, что сломался сервер, код 400 указывает на запрос: URL, заголовки, cookie или данные, которые отправил ваш браузер или приложение. Для всех остальных сайт обычно работает нормально.

Для посетителей это хорошая новость: исправление обычно на вашей стороне и занимает минуту. За большинством ошибок 400 стоит опечатка в ссылке или повреждённый cookie.

Как выглядит ошибка 400

Текст сообщения зависит от серверного ПО, и дополнительная строка часто лучше всего подсказывает причину:

Причины ошибки 400 Bad Request

• Некорректный URL. Лишний знак %, пробел, символ, который следовало закодировать, или ссылка, которая обрезалась или была вставлена дважды.

• Повреждённые или слишком большие cookie. Сайты, которые ставят много cookie (авторизация, A/B-тесты, аналитика), могут раздуть заголовок Cookie сверх лимита сервера. Cookie, испорченный во время обновления, тоже может быть отклонён.

• Слишком большие заголовки запроса. Помимо cookie, объём набирают длинные токены авторизации и заголовки, которые добавляют расширения и прокси.

• Неверные данные, отправленные в API. Не хватает обязательных полей, JSON сформирован с ошибкой или указан неверный заголовок Content-Type.

• HTTP отправлен на HTTPS-порт. Частая ситуация за балансировщиками нагрузки и обратными прокси.

• Слишком большой файл. Многие серверы отвечают 413 Content Too Large, но некоторые приложения и фреймворки вместо этого возвращают 400.

Решение 1: проверьте URL

Внимательно посмотрите на адресную строку. На что обратить внимание:

• Знак %, после которого не идут два шестнадцатеричных символа (%20 — нормально, %2 или %zz — нет).

• Пробелы, { }, |, \ или другие необычные символы, особенно в ссылках, скопированных из писем, PDF или мессенджеров.

• Ссылка, вставленная дважды (https://example.com/https://example.com/...) или обрезанная на середине.

• Очень длинный URL с параметрами отслеживания. Удалите всё, начиная со знака ?, и попробуйте снова.

Если вы перешли по ссылке с другого сайта, откройте главную страницу нужного сайта и перейдите к странице оттуда.

Решение 2: очистите cookie одного этого сайта

Это исправляет большинство ошибок 400 на сайтах, которыми вы уже пользовались, особенно если в сообщении упоминаются cookie или заголовки, которые «слишком большие» или «слишком длинные» (too large, too long). Удалять cookie всех сайтов не нужно — только этого:

• Chrome / Edge: нажмите значок слева от адресной строки → Файлы cookie и данные сайтов (или Настройки сайтов) → удалите данные сайта и обновите страницу.

• Firefox: нажмите на замок → Удалить куки и данные сайта… (Clear cookies and site data…)

• Safari (Mac): Safari → Настройки → Конфиденциальность → Управлять данными веб-сайтов… → найдите сайт → Удалить.

• iPhone: Настройки → Приложения → Safari → Дополнения → Данные сайтов → смахните строку сайта влево, чтобы удалить.

Решение 3: попробуйте режим инкогнито, затем очистите кеш

Откройте страницу в окне инкогнито / приватного просмотра (Ctrl + Shift + N в Chrome и Edge, Ctrl + Shift + P в Firefox, Cmd + Shift + N в Safari). Приватные окна запускаются без cookie и без расширений, поэтому если там страница работает, решение 2 или решение 4 устранит проблему насовсем.

Если и в режиме инкогнито ошибка остаётся, очистите кеш браузера (Ctrl + Shift + Delete → «Изображения и другие файлы, сохраненные в кеше»), а в качестве последнего шага очистите DNS-кеш. DNS редко бывает причиной ошибки 400, но после переезда сайта на другой сервер устаревший адрес может привести вас на сервер, который отклоняет ваш запрос.

Решение 4: отключите расширения и проверьте размер файлов

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

Если ошибка появляется при загрузке файла, попробуйте файл поменьше. Сожмите изображения или разделите большие файлы. Так вы узнаете, не отклоняет ли сервер файл из-за размера, даже если сообщает об этом кодом 400, а не 413.

Владельцам сайтов: как найти причину ошибок 400

Если пользователи сообщают об ошибках 400 на вашем сайте, начните с точного текста, который они видят, и с логов сервера. nginx и Apache записывают причину на уровне info, поэтому, если вы её не видите, временно повысьте уровень детализации журнала ошибок, а журнал доступа покажет, какие URL возвращают 400. Инструмент HTTP Headers от DNS Robot показывает код состояния, серверное ПО и каждый заголовок Set-Cookie, который отправляет страница, — так проще заметить cookie, которые постоянно разрастаются.

# Какие запросы получают 400? (формат лога nginx combined)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Причины, которые записал nginx (нужен error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

Ошибка «Request Header Or Cookie Too Large»

nginx считывает заголовки запроса в буферы, заданные директивой large_client_header_buffers, по умолчанию это 4 буфера по 8 КБ. Если одна строка заголовка — обычно заголовок Cookie — не помещается в один буфер, возникает эта ошибка 400. Аналогичный лимит в Apache — LimitRequestFieldSize, по умолчанию 8190 байт.

Правильное решение — отправлять меньше: удалите cookie, которые больше не нужны, держите сессионные cookie маленькими и ограничивайте cookie путями и поддоменами, которые их используют. Если вам действительно нужны заголовки больше, например для крупных токенов единого входа (SSO), поднимите лимит:

# nginx (блок http или server)
large_client_header_buffers 4 16k;

# Аналог для Apache (httpd.conf / vhost)
# LimitRequestFieldSize 16380

Ошибка «The plain HTTP request was sent to HTTPS port»

nginx возвращает эту ошибку 400, когда что-то отправляет обычный HTTP на порт, где nginx ожидает TLS, — как правило, на 443. Типичные причины: балансировщик нагрузки или прокси пересылает трафик http:// на порт 443, ссылка вида http://example.com:443 или старая настройка ssl on;, из-за которой порт ожидает TLS, хотя не должен.

Убедитесь, что каждая строка listen соответствует тому, что на неё приходит: listen 443 ssl; для HTTPS и listen 80; для обычного HTTP с редиректом с 80 на 443. Также проверьте, что прокси перед сервером обращается к порту 443 по HTTPS (или к порту 80 по HTTP).

Ошибки 400 от API

API используют код 400 для запросов, которые не прошли валидацию. Если вы обращаетесь к API, прочитайте тело ответа: большинство API объясняют, какое поле неверно. Затем проверьте, что отправляете корректный JSON, правильный заголовок Content-Type: application/json и все обязательные параметры.

Если вы разрабатываете API, возвращайте тело ответа с описанием проблемы (например, {"error": "email is required"}) и подумайте о коде 422 Unprocessable Content для запросов, которые сформированы правильно, но неверны по смыслу, оставив 400 для запросов, которые вообще невозможно разобрать.

400 и 401, 403, 404, 413, 429, 431: в чём разница

Наши руководства по соседним ошибкам: 403 Forbidden, 401 Unauthorized и 429 Too Many Requests. Если редиректы зацикливаются вместо ошибки, читайте про ERR_TOO_MANY_REDIRECTS, а Redirect Checker покажет каждый переход.