< HTTP/1.1 421 Misdirected Request

TL;DR: 421 means “you sent this request to the wrong connection”. The server will not answer for that hostname on the TLS connection in use. It is most often HTTP/2 connection coalescing meeting a server whose per-host TLS or routing config differs; the fix is consistent config per IP, or non-overlapping certificates.

What it means

RFC 9110 §15.5.20: the request was directed at a server that is not able or willing to produce an authoritative response for the target URI. The client may retry on a different connection.

GET /dashboard HTTP/2
:authority: admin.example.com

HTTP/2 421
content-type: text/html

Misdirected Request
The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.

That body is Apache httpd’s wording. The error log carries the key:

[ssl:error] [pid 2217] AH02032: Hostname admin.example.com provided via SNI and hostname www.example.com provided via HTTP have no compatible SSL setup

Why it happens: connection coalescing

With HTTP/1.1, one connection serves one hostname. HTTP/2 (RFC 9113 §9.1.1) allows a client to reuse a connection for another origin when:

1. the second hostname resolves to an IP the connection already uses, and
2. the certificate on that connection is valid for the second hostname (a wildcard or multi-SAN cert).

The browser then sends www.example.com and admin.example.com requests down one TCP+TLS connection that was set up with SNI www.example.com. The server saw only the first SNI during the handshake. If the second hostname is meant to have different TLS parameters, a different client-certificate policy, or is routed by a different virtual host, the server cannot honour it safely and answers 421.

Real triggers:

• Apache vhosts with different SSL settings on the same IP (one requires client certificates or restricts protocols, another does not).
• nginx with ssl_verify_client on one server block and not on another that shares the address: when the Host header selects a different server block than the SNI did, and client-certificate settings differ, nginx answers 421 rather than serve a client-certificate-protected host on a connection that never asked for a certificate.
• Envoy/Istio gateways, Traefik, HAProxy, Kubernetes ingress where a wildcard certificate and shared IP let the browser coalesce hosts, but filter chains or routes are selected by SNI. In Istio the symptom is more often an intermittent 404 than a 421.
• CDNs and multi-tenant frontends that place unrelated customers on one IP with an overlapping SAN set.
• mTLS endpoints next to ordinary endpoints on the same IP.

Symptoms are intermittent and order-dependent: it works when the first page visited is admin., fails when www. was visited first. Incognito windows or a second browser behave differently because they have different live connections.

Diagnose

1. Check whether it only happens on HTTP/2 with a reused connection. curl --http1.1 https://admin.example.com/ will succeed because each hostname gets its own connection. Give curl two URLs in one invocation so it can reuse the connection:

curl --http2 -v https://www.example.com/ https://admin.example.com/ 2>&1 | grep -E 'Re-using|HTTP/2 |< HTTP'
# Re-using existing connection with host www.example.com   <- coalescing

curl only reuses the connection when its own checks (IP and certificate) allow it, so a clean run does not prove the server is fine; the browser’s decision can differ.

2. Compare the certificates and SNI behaviour of both names on the IP:

echo | openssl s_client -connect 203.0.113.10:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
echo | openssl s_client -connect 203.0.113.10:443 -servername admin.example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

If both return the same wildcard or SAN list, coalescing is allowed. 3. In Chrome, chrome://net-export or the DevTools Network panel with the Connection ID column shows two hostnames sharing one connection. 4. Read the server error log (Apache AH02032) or the Envoy access log, where response_flags of NR (no route configured) with a 404 or 421 points at a coalesced request.

Fix it

Pick whichever fits the architecture:

1. Make configuration consistent across all vhosts that share an IP and certificate (same SSLProtocol, SSLCipherSuite, SSLVerifyClient). Coalescing then is harmless.
2. Stop the certificate overlap. Issue separate certificates whose SANs do not cover each other’s names, so the browser has no basis to coalesce. For example, an mTLS admin.example.com gets its own cert and does not sit under *.example.com. This is the usual answer for mTLS.
3. Separate IPs for hosts that need different TLS policy. Browsers only coalesce if DNS returns an overlapping address.
4. Route correctly at the gateway. In Istio, use one Gateway server with a wildcard host and one credential so both hosts share a filter chain, or have the gateway return 421 for the unmatched host (an EnvoyFilter) so the browser retries on a fresh connection.
5. As a last resort, disable HTTP/2 on the affected listener. This costs you multiplexing everywhere on it, so it is a workaround.

If you build the server, return 421 only when the TLS context and the request authority conflict, not for unknown hosts (that is 404, or nothing at all as in 444).

RFC 8336 defines an HTTP/2 ORIGIN frame that lets a server tell clients exactly which hostnames it will answer for on a connection, which reduces both over- and under-coalescing; support is not universal.

Related

• 400 Bad Request: malformed request rather than a wrong connection.
• 403 Forbidden
• 404 Not Found
• HTTPS and TLS: SNI and certificates.
• Host