Ошибка 400: сервер не понял запрос

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

Мы проверили на сайтах Екатеринбурга, какие запросы на практике получают 400, а какие — другой код.

Что говорит стандарт

В RFC 9110, действующем стандарте HTTP, код описан так:

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error.

Сервер «не может или не будет» обрабатывать запрос из-за того, что «воспринимает как ошибку клиента». В примерах — неверный синтаксис, испорченная разметка сообщения, обманная маршрутизация. Ключевое слово «воспринимает»: сервер не обязан быть прав.

В справочнике кодов Вебмастера Яндекса про 400 сказано: «Запрос не может быть понят сервером из-за некорректного синтаксиса».

Наш замер: четыре испорченных запроса на 300 сайтов

Мы взяли сайты организаций Екатеринбурга из OpenStreetMap, которые отвечают на обычный запрос кодом 200, и выбрали из них случайные 300. 25 сентября 2026 года каждому отправили четыре вида запросов, которые встречаются в жизни.

Большие куки

Браузер отправляет все куки сайта одной строкой — заголовком Cookie. Мы добавили к запросу куки разного размера:

Граница — 8 КБ. С куки в 4 КБ открылись все, кто вообще ответил. С 8 КБ отказали шесть из десяти: 130 — кодом 400, ещё 47 — ошибкой шлюза 502 или 503, будто сломан сервер. Четыре ответили кодом 431, который придуман специально для слишком больших заголовков.

Причина видна в тексте ответа: 50 адресов с кодом 400 прямо написали «400 Request Header Or Cookie Too Large». Это nginx. В его документации сказано: поле заголовка не может превышать размер одного буфера, «or the 400 (Bad Request) error is returned», а размер буфера по умолчанию — 8 КБ.

Длинная ссылка

Тот же объём мы положили в адрес страницы:

Здесь почти никто не ответил 400. За длинную ссылку положен свой код — 414, «адрес слишком длинный». Та же документация nginx: строка запроса не может превышать буфер, «or the 414 (Request-URI Too Large) error is returned».

Испорченный адрес

Адрес с неверной кодировкой — /%zz, где после знака процента должны стоять две шестнадцатеричные цифры. Кодом 400 ответили 290 из 300. Так бывает, когда ссылку обрезали посередине кода символа или вставили в письмо с лишним %.

Обычный http на порт https

Запрос без шифрования на порт 443 получил 400 у 210 адресов. У 99 из проверенных 150 текст был «The plain HTTP request was sent to HTTPS port». Посетитель видит это, если в ссылке написано http://сайт.ru:443.

Откуда у посетителя столько куки

Одна кука в Chrome не бывает больше 4 КБ: в коде Chromium предел имени и значения — kMaxCookieNamePlusValueSize = 4096. Но на один домен браузер хранит до 180 куки (kDomainMaxCookies = 180) и все отправляет вместе. Счётчики, чаты, виджеты, рекламные метки и сам сайт добавляют свои. Когда вместе они переросли 8 КБ, сайт перестаёт открываться только у этого посетителя.

Отсюда характерный признак: у вас 400, а с телефона и в режиме инкогнито сайт работает. В инкогнито куки пустые.

Что чинит посетитель

1. Удалите куки этого сайта. В Chrome это делается в настройках сайта — значок слева от адреса. Остальные трогать не нужно.
2. Проверьте ссылку. Обрезанный хвост, лишний %, пробел или :443 после имени сайта — частые причины. Наберите адрес главной вручную.
3. Откройте в режиме инкогнито. Открылось — дело в куки или расширении.
4. Выключите расширения. Некоторые из них добавляют заголовки к каждому запросу.

Что чинит владелец

• Следите за объёмом куки. Посмотрите в инструментах разработчика, сколько весит заголовок Cookie у постоянного посетителя. Если он близок к 8 КБ, кто-то из виджетов пишет лишнее.
• Поднимите буфер сервера, если большие куки нужны делу. У nginx это large_client_header_buffers. Проверьте и сервер за ним: в нашем замере 47 адресов на большой запрос отвечали 502 или 503 — судя по коду, ломалось звено за посредником.
• Не передавайте данные в ссылке. Длинные фильтры и формы лучше отправлять методом POST, а не складывать в адрес.
• Проверьте формы. Если форма отправляет поля не в том формате, что ждёт обработчик, программа сайта тоже отвечает 400. Такую ошибку видно в журнале сервера по адресу обработчика.

Если после входа сайт просит пароль и отвечает 401, это другая история — в статье ошибка 401. Если сервер понял запрос, но отказал, — ошибка 403.

Как проверить самому

Повторите наш опыт на своём сайте:

curl -s -o /dev/null -w '%{http_code}\n' \
  -H "Cookie: t=$(head -c 8192 /dev/zero | tr '\0' a)" https://сайт.ru/

Ответ 200 значит, что сервер переживёт разросшиеся куки; 400, 431 или 502 — что посетитель с большим набором куки его не откроет.

Границы замера

• Выборка: 300 случайных сайтов организаций Екатеринбурга из OpenStreetMap, только главные страницы.
• Куки — одна большая кука, а не много мелких. Для сервера это один заголовок того же размера.
• Запросы шли программой curl, а не браузером.
• Тексты ответов мы разбирали для большой куки на всех 130 сайтах с кодом 400, для остальных опытов — на 150 сайтах.
• Данные сняты 25.09.2026.

Коротко

• 400 — сервер счёл запрос испорченным и не стал его разбирать.
• Самая частая причина у посетителя — разросшиеся куки: с 8 КБ сайт не открылся у шести из десяти проверенных.
• Длинная ссылка чаще даёт не 400, а 414.
• Испорченный адрес вроде /%zz получил 400 почти везде.
• Посетитель лечит удалением куки сайта; владелец — объёмом куки и настройкой сервера.