HTTP 421 Misdirected Request

What’s actually happening

Pages load intermittently — sometimes fine, sometimes a hard 421 — and it's maddening to reproduce because it depends on connection reuse. It shows up after a cert change, an Apache/nginx upgrade, or moving behind a new proxy. Curl with --http1.1 often succeeds while the browser (HTTP/2) fails, which is the tell.

Common causes

• Browser HTTP/2 connection coalescing: two hostnames share one cert (overlapping SAN) and the same IP, so Chrome reuses one TLS connection but sends a Host the server's vhost won't serve.
• A reverse proxy terminates/re-originates TLS without forwarding SNI, so the origin's SNI doesn't match the forwarded Host header.
• Apache 2.4.64+ tightened SNI/Host enforcement (RewriteRule / SSLStrictSNIVHostCheck), rejecting requests that older versions accepted.
• Wrong or default certificate served for the vhost, so the name in SNI doesn't line up with the configured ServerName.
• A wildcard or multi-domain cert spanning hosts that live on different backends behind the same edge IP.

How to fix it

1. Forward SNI from your proxy to the originIn nginx upstream-TLS, set proxy_ssl_server_name on; and proxy_ssl_name $host; so the origin receives an SNI that matches the Host header. Without this, nginx sends no SNI and Apache rejects with 421.
2. Reproduce by pinning the protocolRun curl -v --http1.1 https://host/ and curl -v --http2 https://host/. If HTTP/1.1 works and HTTP/2 doesn't, it's connection coalescing — confirmed.
3. Stop unwanted coalescingGive the affected hosts distinct certificates (no shared SAN) or distinct IPs so browsers can't reuse one connection across them. Splitting the cert is the cleanest fix when two domains must hit different backends.
4. Loosen Apache's strict check if it's the triggerAfter upgrading to Apache 2.4.64+, if legitimate traffic breaks, review SSLStrictSNIVHostCheck and the new SNI/Host matching, and ensure each vhost has an explicit, correct ServerName/ServerAlias and its own SSLCertificateFile.
5. Verify the right cert is servedCheck with openssl s_client -connect host:443 -servername host and confirm the returned certificate's CN/SAN actually covers that hostname.