Why does 421 only show up on some browsers or after a while?

421 is almost always an HTTP/2 side effect. A browser opens one connection for domain A, notices the certificate also covers domain B on the same IP, and reuses that connection for B. If the server won't serve B over that connection, it answers 421. curl on HTTP/1.1 opens a fresh connection per host, so it often never sees the error.

Is 421 a client bug or a server bug?

Neither, usually. The client did something the spec explicitly allows (reuse a connection), and the server did something the spec explicitly allows (refuse to answer for a host it isn't authoritative for on that connection). It's a configuration mismatch between a shared certificate and per-host server config.

Can a proxy or CDN return 421 to my users?

RFC 9110 says a proxy MUST NOT generate 421. But a CDN acting as the origin's gateway can, and commonly does when it re-encrypts to your origin with the wrong SNI. Check what hostname the edge presents to the backend in its TLS handshake.

Views: 116

421 Misdirected Request Checklist

421 Misdirected Request? Separate HTTP/2 connection reuse from an origin SNI or certificate mismatch in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The final response code for the request is 421 Misdirected Request, often with a message like “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.”

Symptoms

HTTP Check shows a final status code of 421.
It’s intermittent — the same URL works on reload, or works in one browser and fails in another.
It appears only over HTTP/2 (or HTTP/3). Forcing HTTP/1.1 makes it disappear.
It hits sites where several hostnames share one IP and one certificate.

What 421 Actually Means

RFC 9110 (§15.5.20) defines 421 as the request being “directed at a server that is unable or unwilling to produce an authoritative response for the target URI.” The origin server sends it to reject a target URI that doesn’t match a host it’s configured for, or doesn’t match the connection context the request arrived on.

The interesting clause is the retry rule. A client that gets a 421 MAY retry the request over a different connection — and, unusually, it may do so “whether or not the request method is idempotent.” Normally a browser won’t silently retry a POST, because the server might have already acted on it. 421 is the one status that explicitly says: this request never reached an authoritative server, so retrying it on a fresh connection is safe.

That single clause tells you the whole story. 421 doesn’t mean your request was bad. It means it arrived on the wrong pipe.

Top 3 Causes

HTTP/2 connection coalescing - This is the common one. A browser opens a TLS connection to an IP for a.example.com, sees the certificate’s SAN list also covers b.example.com on that same IP, and reuses the existing connection for b.example.com instead of opening a new one. If the origin’s virtual host for b is on a different backend or expects its own SNI, it answers 421 rather than serve a request it isn’t authoritative for.
A CDN or proxy sends the wrong SNI to the origin - When an edge re-encrypts traffic to your origin, it performs its own TLS handshake. If it presents the wrong hostname (or no SNI) the origin routes to the wrong virtual host — or a strict origin refuses with 421.
Strict SNI enforcement with a shared certificate - A wildcard or multi-SAN certificate makes the browser believe one connection is valid for many hosts, but the server is configured to require an exact SNI match per request. The certificate says “these hosts are the same”; the server config says “they are not.”

Diagnose with DechoNet

HTTP Check to confirm the final code is 421 and see which host is failing.
SSL Check to inspect the certificate’s Subject Alternative Names — coalescing only happens when the cert covers more than one of the hostnames sharing an IP.

Resolution Checklist

Reproduce with curl --http1.1 https://host/ and then curl --http2 https://host/. If only HTTP/2 fails, it’s coalescing.
List the certificate’s SAN entries and note which of them share the same IP — those are the hosts a browser may coalesce.
On the origin, decide the intended behavior: either serve every SAN host on that connection, or disable coalescing by giving each host its own certificate/IP.
If a CDN or load balancer fronts the origin, verify the SNI it sends upstream matches the requested Host header.
For Apache/nginx, check that the virtual host for the failing hostname exists and isn’t set to reject non-matching SNI.
Re-run HTTP Check and confirm the response is no longer 421.

When to Escalate

Escalate to whoever manages the shared certificate and virtual-host config — 421 is a mismatch between the two, and fixing one without the other just moves the failure.
If the 421 comes from a managed CDN, review the origin SNI / host-header forwarding settings with the edge provider; the certificate on your origin is not the one the browser sees.