Код 400 Bad Request означает, что сервер получил запрос, но отказался его обрабатывать: запрос сформирован с ошибкой. Формально это ошибка клиента — проблема в самом запросе, а не в работе сервера. Но когда 400 видят мониторинг или обычные посетители, причина почти всегда в настройках сервера, CDN или защитных фильтров. Владельцу сайта важно выяснить, кто именно и почему отклоняет запросы.
Что означает код 400
400 — базовый код группы клиентских ошибок 4xx, описанный в стандарте RFC 9110. Сервер возвращает его, когда не может или не хочет обработать запрос из-за ошибки на стороне клиента: неверный синтаксис строки запроса, некорректные заголовки, повреждённое тело. Это универсальный ответ «запрос некорректен» — его отдают и веб-серверы, и приложения, и CDN.
От смежных кодов 400 отличается степенью конкретности. Ошибка 422 Unprocessable Content значит, что синтаксис запроса верен, но данные не прошли проверку логики приложения. Ошибка 415 Unsupported Media Type указывает на неподдерживаемый формат тела. А ошибка 500 Internal Server Error — противоположность: запрос корректен, сломался сам сервер. Место 400 среди остальных кодов — в полном списке кодов ответа HTTP.
Считает ли Tracker.ru 400 падением
Да. Успешной Tracker.ru считает только проверку с кодом 2xx. Ответ 400 помечает сайт недоступным, тип ошибки — «HTTP-ошибка», и вы получаете уведомление на email, в Telegram или по webhook. Проверки идут из нескольких регионов. Мониторинг отправляет корректный HTTP-запрос без cookie и лишних заголовков. Если сервер стабильно отвечает 400 даже на такой чистый запрос — ошибку почти наверняка видят и живые посетители. Периоды недоступности отражаются в статистике аптайма.
Типичные причины
- Слишком большие заголовки или cookie. nginx отвечает «400 Bad Request — Request Header Or Cookie Too Large», когда суммарный размер заголовков превышает лимит буферов (директива large_client_header_buffers). Обычно cookie раздувает само приложение или скрипты аналитики.
- HTTP-запрос пришёл на HTTPS-порт. Классическое сообщение nginx «The plain HTTP request was sent to HTTPS port»: ссылка или редирект ведут на порт 443 по протоколу http.
- Некорректный заголовок Host. Сервер настроен на конкретные домены, а запрос пришёл по IP-адресу или с посторонним доменом — часть конфигураций отвечает 400 вместо ответа по умолчанию.
- Ошибки в URL. Неэкранированные пробелы, спецсимволы или кириллица в адресе, который вы поставили на мониторинг или указали в ссылках.
- Строгая валидация в приложении. API и формы часто возвращают 400 на некорректный JSON, отсутствующие обязательные параметры или неверный Content-Length.
- WAF, CDN или анти-бот фильтр. Защитный слой считает запрос сформированным неправильно или подозрительным и отклоняет его с кодом 400 ещё до вашего сервера.
Что проверить владельцу сайта
- Откройте онлайн-проверку кода ответа своего сайта — она покажет реальный ответ сервера без кэша и cookie браузера, регистрация не нужна.
- Повторите запрос вручную:
curl -I https://ваш-домен/. Такой лёгкий запрос без cookie похож на проверку мониторинга: если даже он получает 400 — проблема в конфигурации сервера, а не у посетителей. - Загляните в журнал ошибок веб-сервера (error.log в nginx или Apache): там указана конкретная причина — превышен размер заголовков, неверный Host и так далее.
- Проверьте адрес, который стоит на мониторинге: протокол, порт, экранирование спецсимволов. Ошибка в одном символе даёт стабильный 400.
- Если перед сайтом стоит CDN или WAF — просмотрите его журнал событий: не отклоняет ли фильтр корректные запросы, включая проверки мониторинга.
- Когда на 400 жалуются отдельные посетители, а проверки зелёные, — попросите их очистить cookie для вашего домена и увеличьте лимиты заголовков на сервере.
Как часто встречается 400 на практике
Код 400 — редкий гость в мониторинге: за десять с лишним миллионов проверок Tracker.ru он встретился лишь несколько сотен раз, то есть примерно в четырёх проверках из ста тысяч (по данным на июль 2026). Это логично: мониторинг отправляет корректный HTTP-запрос, и отклонить его сервер может только из-за ошибки конфигурации или чрезмерно строгого фильтра.
Частые вопросы
Почему мониторинг показывает 400, а в браузере сайт открывается?
Скорее всего, запросы фильтрует WAF или анти-бот защита: она отклоняет обращения с IP-адресов дата-центров или запросы без привычного браузерного набора заголовков. Проверьте журнал защитного сервиса и ослабьте правило — корректный HTTP-запрос от мониторинга не должен получать 400. Иначе мониторинг будет фиксировать ложные падения.
Почему у посетителя ошибка 400, а мониторинг показывает, что сайт работает?
Типичный случай — переполненные cookie в браузере посетителя: сервер отвергает запрос с раздутыми заголовками, а проверка мониторинга приходит без cookie и проходит успешно. Быстрое решение для посетителя — очистить cookie. Системное решение для вас — увеличить лимиты заголовков и найти скрипт, который раздувает cookie.
Чем 400 отличается от 422?
400 означает, что сервер не смог корректно разобрать запрос: сломан синтаксис, заголовки или тело. 422 — запрос разобран успешно, но данные не проходят проверку бизнес-логики приложения. Для мониторинга разницы нет: оба кода не входят в группу 2xx, поэтому сайт в обоих случаях помечается недоступным.