SEO

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

14.10.2026 · 8 мин чтения

Некорректный запрос остановлен перед веб-сервером

Ошибка 400 означает, что сервер получил запрос, но не смог или не захотел обработать его из-за неверного формата. Причина бывает в адресе, cookies, заголовках, данных формы, прокси или серверных ограничениях.

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

400 Bad Request относится к клиентским ошибкам HTTP. Это не значит, что пользователь обязательно сделал что-то неправильно. Сервер, CDN или защитный фильтр видит запрос как некорректный: например, URL обрезан, заголовок слишком большой, JSON сломан или порт не соответствует протоколу. Повторять тот же запрос без изменений обычно бесполезно.

С кодом 404 разница принципиальная. При 404 сервер понял запрос, но не нашёл ресурс. При 400 он не смог нормально разобрать само обращение. Ошибка 401 относится к авторизации, 403 — к запрету доступа, 413 — к слишком большому телу, 414 — к слишком длинному URL. На практике серверы иногда используют общий 400 вместо более точного кода, поэтому я всегда смотрю детали ответа и лог.

Быстрая диагностика

Симптом	Вероятная причина	Что проверить
Ошибка только в одном браузере	Cookies, кэш или расширение	Приватное окно, другой браузер, данные сайта
Ошибка только по одной ссылке	Обрезанный или неверно закодированный URL	Пробелы, проценты, параметры, протокол и порт
Не работает форма или API	Неверный метод, Content-Type или тело	Network, curl или Postman, схема данных
Ошибка у всех посетителей	Конфигурация сервера, CDN, WAF или приложения	access.log, error.log и журналы защиты
Сбой после авторизации	Разросшиеся cookies или неверный токен	Размер Cookie и Authorization, срок токена
Сбой при загрузке файла	Лимит тела запроса	Размер файла и ограничения на каждом прокси
Запрос HTTP отправлен на HTTPS-порт	Неверная схема или порт	Начало URL, номер порта и настройки прокси

Я начинаю с вопроса: ошибка повторяется у одного человека или у всех? Это быстро делит поиск причины на две ветки. Если страница открывается в другом браузере и с другого устройства, сервер, скорее всего, исправен. Если одинаковый 400 получают все, чистка кэша у посетителя ничего не решит.

Проверка браузера, cookies и кэша при ошибке запроса

Если сбой только в одном профиле, сначала проверяю данные конкретного сайта.

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

Перечитать URL. Проверить лишние пробелы, двойной протокол, обрезанные параметры, странные символы и порт.
Открыть сайт с главной и дойти до страницы через меню. Ссылка из письма или мессенджера могла скопироваться не полностью.
Повторить действие в приватном окне. Если всё работает, причина обычно в cookies, расширении или сохранённой сессии.
Удалить cookies и кэш только для проблемного домена, а не стирать всю историю браузера.
Временно отключить VPN, прокси и расширения, которые меняют трафик: блокировщики, антивирусные фильтры, корпоративные агенты.
Проверить другой браузер, устройство или сеть. Результат важно сообщить владельцу сайта вместе с точным временем ошибки.

Я не начинаю с переустановки браузера, драйверов или системы. Для единичной ошибки на одном домене это слишком широкий шаг. Также не стоит отключать защиту компьютера насовсем: краткая проверка нужна только для локализации причины, после неё настройки возвращают.

Если ошибка возникает в форме или API

У формы запрос часто ломается незаметно для посетителя: пустое обязательное поле, неправильная кодировка, неверный Content-Type или JSON с лишней запятой. В инструментах разработчика открываю вкладку Network, повторяю действие и смотрю URL, метод, заголовки, тело запроса и ответ. Пароли и токены перед отправкой кому-либо удаляю.

Запрос разбираю по частям: адрес, метод, заголовки и тело.

Сверяю метод GET, POST, PUT или PATCH с документацией.
Проверяю Content-Type: JSON, форма и загрузка файла отправляются по-разному.
Сравниваю Content-Length с реальным телом и лимитами промежуточных узлов.
Валидирую JSON или XML до отправки, включая кавычки и экранирование.
Проверяю обязательные параметры и ожидаемые типы значений.
Повторяю минимальный запрос через curl или Postman без браузерных cookies и скриптов.

Если минимальный запрос проходит, возвращаю поля по одному. Так быстрее найти конкретный параметр, чем перечитывать весь код. Если он тоже получает 400, сравниваю его с рабочим примером и перехожу к серверным журналам.

Что проверять владельцу сайта

Страница с сообщением Bad Request почти не объясняет причину. Полезные данные находятся в access.log, error.log, журнале приложения, CDN и WAF. Я фиксирую время, URL, метод, IP или идентификатор запроса — так одну запись можно провести через все уровни инфраструктуры.

Лимиты Nginx и Apache

Большие cookies и заголовки упираются в буферы, а загрузки — в лимит тела. На Nginx смотрю client_header_buffer_size, large_client_header_buffers и client_max_body_size, но не увеличиваю их вслепую. Сначала измеряю реальный запрос и выясняю, почему он разросся. Лимит может существовать и на CDN, и на балансировщике, и в приложении.

CDN, прокси и WAF

Защитный фильтр способен принять обычное поле формы за атаку. В его журнале обычно видно сработавшее правило. Правильное решение — точечное исключение или корректировка приложения, а не полное отключение защиты. За обратным прокси также проверяю Host, схему, порт и доверенные заголовки.

Серверные логи, защитный фильтр и ограничения запросов

На стороне сайта проверяю всю цепочку: прокси, веб-сервер, защиту и приложение.

Обновления и код приложения

Если ошибка появилась после релиза, проверяю изменения маршрутов, формы, авторизации и сериализации данных. Откат выполняю только управляемо, с резервной копией и пониманием миграций. Случайное отключение модулей на рабочем сайте может создать больше проблем, чем исходный 400.

Как не допустить повторения

Собирать URL штатными библиотеками и кодировать параметры, а не склеивать сырой текст.
Проверять входные данные и возвращать человеку понятное сообщение о конкретном поле.
Разделять ошибки формата, авторизации, размера и частоты запросов точными HTTP-кодами.
Не хранить крупные данные в cookies и регулярно удалять устаревшие значения.
Тестировать формы, API и загрузки через CDN до релиза.
Связывать логи единым идентификатором запроса и не записывать в них секреты.
Настроить мониторинг всплеска ответов 400 по маршрутам.

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

SEO

Разберу ошибку на сайте

Проверю проблемный запрос, ответ сервера и логи, чтобы отделить ошибку браузера от настройки сайта.

Леонид Стрельцов

Интернет-маркетолог и автор материала

Обо мне VK Telegram Max