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

Что означает код 400

По стандарту HTTP код 400 значит: сервер не может или не хочет обрабатывать запрос, потому что видит в нём ошибку клиента — неверный синтаксис, испорченную структуру сообщения и тому подобное. Это самый общий код ошибки клиента: незнакомый браузеру код 4xx тоже понимается как 400.

Важно, что виноват именно запрос, а не страница. Если бы страницы не было, сервер ответил бы 404, если бы доступ был закрыт — 403.

Четыре вида 400 в nginx

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

Если вы посетитель

1. Проверьте адрес. Лишний символ, пробел или обрезанная ссылка из мессенджера — частые причины.
2. Откройте сайт в режиме инкогнито. Если там всё работает — дело в cookie: удалите cookie этого сайта в настройках браузера и обновите страницу. Это лечит и «Request Header Or Cookie Too Large».
3. Если ошибка «The plain HTTP request was sent to HTTPS port», уберите из адреса номер порта (например, :443) и откройте сайт через https://.
4. Не помогло ни в инкогнито, ни в другом браузере — проблема на стороне сайта. Напишите его владельцу, когда и на какой странице появилась ошибка.

Как найти причину на своём сервере

Сначала посмотрите заголовок страницы с ошибкой — по таблице выше. Потом журнал ошибок nginx; в пакетах Ubuntu и Debian он лежит в /var/log/nginx/error.log.

Подвох: nginx записывает ошибки клиентов на уровне info, а журнал по умолчанию пишет только уровень error и выше. Поэтому при настройках по умолчанию в журнале их не видно. Чтобы увидеть причину, временно включите подробный журнал для нужного сайта:

server {
    ...
    error_log /var/log/nginx/error.log info;
}

Проверьте настройки командой nginx -t, перечитайте их (systemctl reload nginx), повторите запрос и найдите строку, которая начинается с «client sent». Что она значит:

Найдя причину, верните прежний уровень журнала: на info он быстро растёт.

Как исправить

Большие заголовки и cookie. Размер задаёт директива large_client_header_buffers: по умолчанию четыре буфера по 8 КБ, и один заголовок не может быть больше одного буфера. Её можно увеличить в блоке http или server:

large_client_header_buffers 4 16k;

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

HTTP-запрос на порт HTTPS. Такие запросы можно отправлять на HTTPS-версию страницы — nginx позволяет перехватить код 497 директивой error_page:

error_page 497 =301 https://$host$request_uri;

Клиентские сертификаты. Коды 495 и 496 появляются, только если в настройках включена проверка сертификатов посетителей (ssl_verify_client). Если вы её не включали намеренно, ищите эту директиву в конфигурации.

Сайт за прокси или CDN. Ошибку 400 могла вернуть не ваша программа, а посредник. Посмотрите заголовок Server в ответе (curl -I адрес) — он подскажет, кто ответил.

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

Чем 400 отличается от соседних кодов

Источники

• RFC 9110, раздел 15.5.1 — определение кода 400.
• Документация nginx: large_client_header_buffers и error_page.
• Документация nginx: обработка ошибок SSL — коды 495–497.
• Документация nginx: error_log — уровни журнала.
• Исходный код nginx — тексты сообщений «client sent…».

Сверено 6 октября 2026 года.

Что почитать дальше

• Коды ответа HTTP — полный список с расшифровкой.
• Ошибка 431 Request Header Fields Too Large — та же проблема с заголовками у других серверов.
• Бесплатный SSL-сертификат — как перевести сайт на HTTPS без ошибок.
• Как разместить сайт на VPS — настройка nginx с нуля.