HTTP 421 Misdirected Request: почему возникает через CDN и как чинить SNI/Host на Nginx

HTTP 421 чаще всплывает в цепочке браузер → CDN → reverse proxy → origin при h2/h3 из‑за несовпадения TLS SNI и HTTP Host. В этой статье разберём, как воспроизвести проблему, диагностировать её с помощью curl и openssl и как настроить Nginx, CDN и апстрим, чтобы исключить misdirected request.

Инструкции
11 ноя, 2025
Время на чтение: ~14 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

HTTP 421 Misdirected Request: почему возникает через CDN и как чинить SNI/Host на Nginx

Если сайт иногда отвечает HTTP 421 Misdirected Request, чаще всего это связано с повторным использованием шифрованного соединения (connection coalescing) на уровнях HTTP/2 и HTTP/3, когда имя хоста в TLS SNI не совпадает с заголовком Host внутри HTTP‑запроса. Такое особенно проявляется в цепочке браузер → CDN → reverse proxy → origin, где каждый слой может переиспользовать соединения ради производительности. Разберёмся, почему сервер «прав» возвращать 421 и как настроить Nginx и инфраструктуру, чтобы все хосты обслуживались корректно.

Коротко: 421 — сигнал от сервера «вы обратились по этому соединению не к тому хосту». Клиент должен открыть новое соединение с корректным SNI/ALPN для данного домена.

Что такое HTTP 421 и откуда он берётся

Код 421 Misdirected Request возвращается, когда сервер не может безопасно ответить для указанного origin (scheme + host + port) по уже открытому транспортному соединению. В HTTP/2 и HTTP/3 допустимо мультиплексировать запросы разных origin по одному TLS/QUIC‑соединению, если клиент счёл их совместимыми. Если сервер видит, что выбранное при TLS‑рукопожатии имя (SNI) не соответствует пришедшему в HTTP Host, он вправе вернуть 421, попросив клиента переоткрыть соединение под правильный хост.

Это нужно для безопасности и корректной маршрутизации. В Nginx и других прокси виртуальный хост выбирается на этапе TLS по SNI; далее этот vhost обрабатывает HTTP‑запросы и сверяет Host. Несоответствие может вести к неверной выдаче сертификата, смешиванию контента доменов или утечке кэша между сайтами. Поэтому 421 — правильный, безопасный ответ, а не «сломанный сервер».

Как работает SNI и почему Host может не совпасть

SNI (Server Name Indication) — расширение TLS ClientHello: клиент сообщает домен, для которого открывает соединение. Сервер выбирает соответствующий сертификат и виртуальный хост ещё до чтения HTTP‑запроса. На слое HTTP клиент добавляет заголовок Host (или псевдозаголовок :authority для HTTP/2; аналогично для HTTP/3). В норме SNI и Host совпадают.

Где возникает рассинхрон:

Connection coalescing в браузере: открыто соединение для a.example.com, но оно переиспользуется и для b.example.com (совпадают IP, сертификат валиден для обоих и клиент это допустил). Тогда SNI остаётся a.example.com, а внутри запроса приходит Host: b.example.com.
CDN или reverse proxy к origin: прокси держит пул соединений к апстриму и может повторно использовать TLS‑канал с «чужим» SNI, либо отправлять неверный Host.
Групповые SAN/подстановочные сертификаты: один сертификат на множество доменов и один IP повышают шансы coalescing у клиента и риск 421 при несовпадении с конфигурацией виртуальных хостов.

HTTP/2 и HTTP/3: coalescing и ORIGIN

В HTTP/2 браузеры могут коалесцировать запросы разных origin по одному TLS‑соединению, если:

сертификат сервера валиден для обоих доменов (SAN/wildcard);
обе записи из DNS резолвятся в один адрес (на практике так делают многие клиенты);
ALPN согласован на h2.

Существует ORIGIN‑frame, позволяющий серверу явно объявить список origin, обслуживаемых по данному соединению, но реальная логика остаётся за клиентом. В гетерогенных сетях с CDN/прокси рассинхрон встречается регулярно. Если работаете с apex‑доменом на CDN, пригодится разбор ANAME/ALIAS для apex‑домена.

В HTTP/3 ситуация аналогична: QUIC‑соединение тоже может переиспользоваться для нескольких origin при валидном сертификате и разрешающей политике клиента. Поэтому 421 актуален и для h3.

Симптомы и типичные сценарии

Случайные 421 у части пользователей: чаще в современных браузерах при h2/h3, у мобильных клиентов и при активном кэшировании на CDN.
421 от origin в логах CDN: CDN отправил запрос, получил 421, ретраит на новом соединении — всплески «серо‑зелёных» метрик, без роста 5xx на стороне CDN.
421 за reverse proxy: фронтовый Nginx возвращает 421 клиенту; в логах видно, что Host не из его server_name, а SNI указывал на другой vhost.

Диагностика 421 с помощью curl и openssl

Быстрая диагностика (чек‑лист)

Проверьте, какие домены указывают на один IP (включая AAAA). Совпадения разных доменов на один адрес повышают шанс coalescing.
Убедитесь, что каждый виртуальный хост в Nginx имеет точный server_name, без «всеядных» пересечений.
Посмотрите, как CDN ходит на origin: какой Host шлёт и какой SNI использует при TLS к origin.
Проверьте сертификаты: SAN покрывает именно те домены, которые реально обслуживаются данным vhost.
Поймайте воспроизведение через curl с управлением SNI/Host.

Если используете gRPC‑стек, пригодится практический разбор gRPC через Envoy и gRPC‑Web.

Как воспроизвести 421 вручную

1) Откройте TLS к IP с SNI одного домена, а внутри запроса отправьте другой Host:

curl -v --http2 --resolve a.example.com:443:203.0.113.10 https://a.example.com/ -H "Host: b.example.com"

Если Nginx настроен корректно, вы получите 421 (или 400/403 в менее дружелюбных конфигурациях).

2) Посмотрите, какой сертификат выдаёт сервер под конкретным SNI и какой ALPN согласуется:

openssl s_client -connect 203.0.113.10:443 -servername a.example.com -alpn h2 -brief

3) Для HTTP/3 проверьте клиентом с поддержкой h3:

curl -v --http3 --resolve a.example.com:443:203.0.113.10 https://a.example.com/

Nginx: базовые принципы правильной маршрутизации

Ключевое правило: один vhost — один набор имён. Nginx выбирает vhost на этапе TLS по SNI, далее проверяет Host. Если Host не принадлежит этому vhost, корректно вернуть 421, чтобы клиент переоткрыл соединение под верное имя.

server {
    listen 443 ssl http2;
    # Для HTTP/3 (опционально):
    # listen 443 quic reuseport;
    server_name a.example.com www.a.example.com;
    ssl_certificate /etc/ssl/certs/a.bundle.pem;
    ssl_certificate_key /etc/ssl/private/a.key;
    # ... остальная конфигурация
}

server {
    listen 443 ssl http2;
    server_name b.example.com;
    ssl_certificate /etc/ssl/certs/b.bundle.pem;
    ssl_certificate_key /etc/ssl/private/b.key;
    # ...
}

# Явный default_server, который мягко отвергает неподходящие запросы кодом 421
server {
    listen 443 ssl http2 default_server;
    # listen 443 quic reuseport default_server; # для HTTP/3
    server_name _;
    return 421;
}

Даже при общем SAN/wildcard‑сертификате разделяйте vhost по именам — так Nginx сможет сравнить Host и вернуть 421 при несовпадении.

Reverse proxy к апстриму: SNI и Host к upstream

Частая причина 421 — неверные заголовки/параметры к upstream over TLS. Правильно:

upstream backend {
    server 192.0.2.20:443;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;

    location / {
        proxy_pass https://backend;
        proxy_http_version 1.1;
        proxy_set_header Host $host;            # Host, который ожидает апстрим
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;

        proxy_ssl_server_name on;               # включить SNI при коннекте к upstream
        proxy_ssl_name $host;                   # SNI совпадает с Host
    }
}

Если upstream — gRPC (требует HTTP/2), используйте grpc_pass и аналоги TLS‑настроек:

location /grpc {
    grpc_pass grpcs://backend;
    grpc_set_header Host $host;
    grpc_ssl_server_name on;
    grpc_ssl_name $host;
}

CDN → origin: где теряется соответствие

Для CDN обычно настраиваются две вещи: какой Host отправлять на origin и какой SNI использовать при TLS. В разных провайдерах это опции «Origin Host header» и «Origin SNI». Если CDN отправляет Host: origin.example.internal, а SNI выставляет как www.example.com (или наоборот), origin Nginx может выбрать «чужой» vhost и ответить 421.

Рекомендации:

Выберите консистентную пару «Host на origin» и «SNI к origin», которая соответствует server_name на origin.
Если origin использует внутренний домен, выпустите для него валидный сертификат и заведите отдельный vhost на origin именно под это имя.
Избегайте смешивания десятков публичных доменов на одном IP с одним SAN‑сертификатом, если у CDN включено агрессивное coalescing к origin.
Если возможно, временно отключите coalescing/HTTP/2/HTTP/3 к origin на время расследования.

Пример конфигурации Nginx для SNI и Host

Детали по сертификатам: SAN и wildcard

Идея «один сертификат на всё» повышает вероятность коалесцирования запросов для разных хостов на один транспорт. Это не ошибка, но требовательно к дисциплине конфигураций. Проверяйте, что SAN покрывает только нужные домены, внутренние origin‑имёна обслуживаются отдельными vhost и сертификатами, а цепочка валидна. При необходимости быстро оформить выпуск и установку помогут SSL-сертификаты.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Логи и метрики

В access_log Nginx 421 виден обычным статусом. Полезно добавить в формат имя хоста запроса и имя, выбранное по SNI:

log_format vhost '$remote_addr $host sni:$ssl_server_name $status "$request"';
access_log /var/log/nginx/access.log vhost;

Так вы увидите пары Host и sni: и быстро поймёте, когда они расходятся. В error_log при уровне info будет видно, какой серверный блок выбран при рукопожатии.

Безопасный дефолт: зачем возвращать именно 421

Альтернативы 421 — 400/403/404 — не сообщают клиенту, что проблема в выборе соединения. 421 корректно подсказывает: «открой новое соединение под правильное имя». Современные клиенты после 421 сразу ретраят на свежем соединении, и пользователь ничего не замечает.

Частые кейсы и решения

1) Один IP, много доменов, общий сертификат

Симптом: случайные 421 в браузерах. Решение: разнесите домены по явным server_name, добавьте default_server с 421, проверьте, что контент и кэш не смешиваются. При необходимости разделите IP по группам доменов или вынесите критичные проекты на выделенные адреса, например на VDS, чтобы клиенты реже коалесцировали.

2) CDN возвращает 5xx, в логах origin 421

Симптом: CDN ретраит на новый коннект после 421, иногда считает это ошибкой origin. Решение: выровнять «Origin Host header» и «Origin SNI» к одному имени, существующему в server_name на origin. Проверить сертификат для этого имени. Для диагностики временно отключить h2/h3 к origin.

3) Nginx как reverse proxy к TLS‑бэкенду

Симптом: 421 от апстрима. Решение: включить proxy_ssl_server_name on;, задать proxy_ssl_name $host; и передавать правильный Host. Для gRPC — grpc_pass, grpc_set_header Host, grpc_ssl_server_name on;, grpc_ssl_name.

4) Случайные 421 только при HTTP/3

Симптом: по h2 всё нормально, по h3 — есть 421. Решение: проверить, что HTTP/3 слушается тем же vhost и сертификатом, что и h2; заголовок Alt‑Svc у всех хостов выдан корректно; default_server по h3 также возвращает 421.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Проверки на стороне клиента и сети

DNS: у доменов, которые не должны коалесцироваться, разные адреса или хотя бы разные CDN‑пулы.
ALPN: фиксируйте, на каком протоколе была сессия (h2/h3), это поможет локализовать проблему.
Трассировка: снимите pcap на стороне origin и посмотрите ClientHello (SNI) и дальнейший HTTP Host. Любой анализатор TLS покажет SNI без расшифровки.

FAQ

Нужно ли «чинить» 421? Нет, если он редок и клиент успешно ретраит — это штатный механизм. Чинить нужно несовпадение SNI/Host и конфигурацию маршрутизации.

Поможет ли отключение HTTP/2/HTTP/3? Как временный обход для диагностики — да, отключит coalescing. Но лучше корректно настроить виртуальные хосты и заголовки к апстриму.

Можно ли сделать один vhost с подстановочным server_name и одним сертификатом? Можно, но вы потеряете возможность безопасно отвергать «чужие» Host и рискуете кэш‑изоляцией. Рекомендуется явное разнесение vhost плюс default_server с 421.

Итог

HTTP 421 — не баг, а защитный механизм, возникающий, когда реальный origin не соответствует параметрам уже открытого соединения. В цепочках с CDN и reverse proxy это часто следствие неверного соответствия SNI ↔ Host или агрессивного coalescing. Практически решается дисциплиной конфигурации: явные server_name в Nginx, аккуратная политика сертификатов, правильная передача Host и включение proxy_ssl_server_name к TLS‑апстриму, плюс безопасный default_server, возвращающий 421. Сделайте эти базовые шаги — и проблема уйдёт, не жертвуя преимуществами HTTP/2/HTTP/3.

Поделиться статьей