Мониторинг сайтов · 4 мин · обновлено 2026-10-01

Ошибка 421 Misdirected Request: почему запрос попал не к тому origin

HTTP 421 появляется, когда сервер не принимает целевой URI в текущем соединении или маршруте. Разбираем HTTP/2, SNI, виртуальные хосты, CDN и порядок проверки.

Ошибка 421 Misdirected Request означает, что сервер получил запрос, но считает соединение или маршрут неподходящим для указанного адреса. Обычно страница существует, а несогласованность находится между HTTP/2, TLS/SNI, виртуальным хостом, reverse proxy, балансировщиком или CDN.

Сначала сравните тот же URL в новом соединении по HTTP/2 и HTTP/1.1. Если 421 появляется только по HTTP/2 или после обращения к другому домену, исследуйте повторное использование соединения; если код стабилен в обоих протоколах, проверяйте маршрутизацию домена на всей цепочке.

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

По RFC 9110 сервер или действующий от его имени шлюз возвращает 421, когда не может или не хочет дать авторитетный ответ для целевого URI. Запрос пришёл не в тот контекст: имя в адресе не совпало с настроенным origin или с соединением, по которому запрос был получен.

Origin — это сочетание схемы, имени хоста и порта. Два домена на одном IP, за одним CDN или в одном сертификате всё равно могут быть разными origin.

421 важно отличать от соседних ошибок:

404 означает, что на выбранном сервере не найден ресурс;
502 указывает на неудачный ответ upstream-сервера;
ошибка сертификата возникает на этапе TLS и может не дать получить HTTP-ответ;
421 означает отказ обслуживать URI в текущем маршруте или соединении.

Почему 421 часто связан с HTTP/2

Повторное использование соединения

HTTP/2 поддерживает длительные соединения. Клиент может использовать одно соединение для разных origin, если выполняются условия авторитетности сервера и проверки сертификата. Это экономит подключения, но выявляет ошибки конфигурации.

Типичный сценарий:

Два имени обслуживаются через общий IP, балансировщик или CDN, а сертификат подходит для обоих.
TLS-соединение создаётся с SNI первого имени.
Браузер отправляет запрос ко второму имени по уже открытому HTTP/2-соединению.
Узел, выбранный по первому SNI, не обслуживает второй origin и отвечает 421.

Общий сертификат не доказывает, что маршруты настроены одинаково. Он лишь может сделать повторное использование соединения возможным.

Несогласованные виртуальные хосты и proxy-маршруты

Ошибка возникает и тогда, когда уровни по-разному понимают имя сайта: TLS-терминатор принимает домен, но в reverse proxy нет нужного virtual host; балансировщик передаёт неверный Host; правило CDN знает публичный домен, а origin — нет.

При нескольких узлах сбой бывает плавающим: один edge или backend настроен правильно, другой возвращает 421. Результат зависит от сети, DNS-ответа или уже открытого соединения.

Порядок диагностики

1. Зафиксируйте точный запрос

Запишите публичный URL, время и часовой пояс, сеть, браузер, код и безопасные заголовки ответа. Отметьте, какое обращение к другому домену было перед ошибкой. Не передавайте Cookie, Authorization, токены и приватные адреса.

2. Сравните HTTP/2 и HTTP/1.1

Выполните запросы из отдельных процессов, чтобы каждый начинался с нового соединения:

curl -I --http2 https://example.ru/path
curl -I --http1.1 https://example.ru/path

Если curl не поддерживает HTTP/2, посмотрите Protocol в Network браузера или используйте другой клиент с выбором протокола. Свежий curl не воспроизводит пул соединений браузера: успешный ответ curl при 421 в браузере — признак, но не доказательство исправности.

3. Проверьте сценарий в браузере

В DevTools найдите запрос со статусом 421 и посмотрите домен, инициатор и протокол. Повторите сценарий в новой приватной сессии. Если сначала всё работает, а ошибка появляется после загрузки соседнего домена, сохраните последовательность: она помогает воспроизвести coalescing — объединение соединений.

Очистка кэша или перезапуск браузера могут скрыть симптом, но не исправляют маршрутизацию.

4. Сопоставьте DNS, SNI и сертификат

Для каждого затронутого имени проверьте:

адреса из DNS;
сертификат при правильном SNI и наличие имени в SAN;
virtual host на TLS-терминаторе;
привязку домена в CDN, балансировщике и origin.

Посмотреть сертификат для конкретного SNI можно командой:

openssl s_client -connect example.ru:443 -servername example.ru </dev/null

Если TLS завершается ошибкой, это отдельная проблема, а не подтверждение 421.

5. Сравните узлы без подмены имени

Когда подозрение падает на один адрес, сохраните hostname для TLS и HTTP:

curl -I --http2 --resolve example.ru:443:<IP> https://example.ru/path

Проверяйте только известные публичные адреса своей инфраструктуры. Открытие сайта по IP меняет Host и SNI, поэтому не является равнозначным тестом.

6. Проверьте reverse proxy и CDN

На каждом уровне подтвердите, что:

домен привязан к нужному virtual host;
SNI выбирает правильный сертификат и tenant;
:authority или Host доходит до нужного upstream;
default host не перехватывает чужое имя;
конфигурация одинакова на активных узлах.

Если браузер показывает общий ERR_HTTP2_PROTOCOL_ERROR, используйте отдельную схему диагностики HTTP/2: это более широкий класс сбоев.

Как читать результаты

421 есть в браузере, но исчезает в новом HTTP/2-соединении — вероятен конфликт повторного использования соединения.
HTTP/2 стабильно возвращает 421, а HTTP/1.1 работает — ищите различия в HTTP/2 frontend, SNI и маршрутах.
Оба протокола возвращают 421 — проверяйте привязку домена и origin, а не только coalescing.
Ошибка приходит лишь с одного адреса — сравнивайте конфигурацию узлов.

Это ориентиры, а не автоматический диагноз. Вывод должен подтверждаться конфигурацией и воспроизводимым запросом.

Что исправлять

Согласуйте списки допустимых имён в CDN, балансировщике, TLS-терминаторе, reverse proxy и origin. Для каждого имени должен выбираться правильный virtual host и upstream, а исходное имя запроса должно сохраняться там, где от него зависит маршрут.

Если origin не должны совместно использовать соединение, разделите их на уровне адресов, сертификатов или политики frontend по документации платформы. Не расширяйте сертификат только ради исчезновения ошибки: сертификат и право сервера отвечать за URI — разные проверки.

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

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

Повторите сценарий, который давал 421. Каждый домен должен отвечать ожидаемым кодом, а активные узлы — вести на правильный origin. Одного успешного открытия мало, если сбой зависел от сети или порядка запросов.

Web-Puls может регулярно проверять публичный URL и сообщать об изменении доступности, но проверка одного адреса не воспроизводит объединение соединений между доменами и не видит конфигурацию proxy. Критичный URL контролируйте регулярно, а сценарий с несколькими origin — отдельным техническим тестом.

Когда нужна помощь

Если 421 зависит от CDN, балансировщика или нескольких virtual host и причина не видна снаружи, подготовьте URL, время с часовым поясом, протокол, шаги, безопасные заголовки и список изменений. С этими данными можно отправить заявку на профессиональную диагностику; доступы, Cookie и токены в форму добавлять не нужно.

Техническая основа: описание 421 в RFC 9110 и правила повторного использования HTTP/2-соединений в RFC 9113.