421 Misdirected Request 4xx

What does 421 mean?

A 421 Misdirected Request response means the request reached a server that isn't configured to handle requests for the specific combination of scheme and host the client was asking for — even though the connection itself was successfully established. This code exists primarily because of a performance optimization in HTTP/2 (and later) called connection coalescing: a client might reuse an existing connection to a server for requests to a different hostname, if the server's TLS certificate covers both hostnames and the client believes the same server can handle both.

421 is the server's way of saying "you sent me this request over a connection you're reusing for a different host, but I — this particular server behind this connection — can't actually serve content for the host you specified, even though my certificate technically covers it." It tells the client "don't reuse this connection for that hostname; open a new one instead."

How a 421 behaves

• It's specific to connection-reuse scenarios, primarily in HTTP/2+ — it wouldn't typically arise in simpler HTTP/1.1 setups where each connection is more straightforwardly tied to one host
• It can carry a body explaining the issue, though it's primarily meant to be acted upon by the client's connection-management logic rather than displayed to users
• The expected client behavior is to retry on a new connection — specifically not reusing the connection that produced the 421, since that connection has been demonstrated not to work for this hostname
• It's a relatively new addition (associated with HTTP/2's connection-reuse capabilities) compared to most other 4xx codes

Common causes

If you're operating the server/infrastructure:

• Your TLS certificate covers multiple hostnames (e.g., a wildcard certificate, or a certificate with multiple SAN entries) that are actually served by different backend servers — a client, seeing the shared certificate, might attempt to reuse a connection across these hostnames, but the specific server behind that connection can only serve some of them
• Load balancer/routing configuration doesn't account for connection-reuse scenarios where a client expects one connection to serve multiple hostnames covered by the same certificate

If you're calling an API:

• You're unlikely to need to handle 421 manually — HTTP/2-aware client libraries that implement connection coalescing should handle 421 by retrying on a new connection automatically, as this is the documented expected behavior for this exact scenario

If you're a website visitor:

• Essentially invisible — browsers handle HTTP/2 connection management (including 421 responses, if encountered) transparently

How to fix it

As an API/website builder:

• If your infrastructure uses shared certificates across multiple hostnames served by different backend servers, ensure those servers correctly return 421 for hostnames they can't serve — this is the correct behavior, allowing clients to recover gracefully via a new connection
• This is largely an infrastructure/TLS-configuration concern rather than something application code typically needs to implement directly — most web servers and CDNs handle this correctly if configured properly

As an API consumer:

• If using a low-level HTTP/2 client implementation, ensure it correctly handles 421 by retrying on a new connection rather than treating it as a hard failure — most mainstream HTTP/2 libraries handle this automatically

As a website visitor:

• Not applicable — handled transparently by browsers

421 vs 400 vs 404

Real-world examples

CDNs and multi-tenant hosting platforms that serve many different customer domains, potentially behind shared certificates (e.g., wildcard certificates for a platform's subdomains), are the most likely context for 421 — if a client's connection-coalescing logic attempts to reuse a connection across domains that happen to share certificate coverage but are actually routed to different backend origins, 421 lets the specific server say "not me for that host, try again with a fresh connection."

SEO implications

421 is a connection-management-level detail in HTTP/2+ that should be handled transparently by clients (including crawlers using HTTP/2) — if implemented correctly by servers, it shouldn't cause crawling issues, since the expected recovery (retry on a new connection) happens automatically at the protocol level.

FAQ

What is "connection coalescing"?

An HTTP/2+ optimization where a client, having an existing connection to a server, may reuse that connection for requests to a different hostname — if the server's TLS certificate is valid for that hostname too — avoiding the overhead of establishing an additional connection.

Why would coalescing fail even if the certificate covers both hostnames?

A certificate covering multiple hostnames doesn't guarantee the same server actually serves content for all of them — different hostnames covered by the same certificate could be routed to entirely different backend origins. 421 is how a server signals "the certificate covers me for this name, but I don't actually have content for it."

Do I need to handle 421 in my application code?

Almost certainly not — this is handled at the HTTP/2 connection-management layer by client libraries/browsers, which should automatically retry on a new connection upon receiving 421, without surfacing this as an application-level error.

Is 421 related to virtual hosting?

Conceptually adjacent — virtual hosting (multiple hostnames served by one server based on the Host header) has existed since HTTP/1.1. 421 specifically addresses a new problem introduced by HTTP/2's connection reuse: when a client's assumption about which server can handle which hostnames (based on certificate coverage) turns out to be incorrect for a specific connection.

Is 421 likely to be common in typical web traffic?

Relatively rare from an application-developer's perspective — most scenarios where it could arise are handled transparently by HTTP/2 client and server implementations, making 421 more of a protocol-correctness mechanism operating "under the hood" than something developers typically interact with directly.

Fun fact

421 is one of the newest additions to the core 4xx range covered by this reference, existing specifically because HTTP/2 introduced a genuinely new kind of ambiguity (which server, behind a shared-certificate connection, actually owns a given hostname) that simply couldn't arise under HTTP/1.1's more one-connection-per-host-at-a-time model — a good example of how even the most "foundational" parts of HTTP (status codes) continue to evolve in direct response to changes in how the underlying protocol itself works.