421 Misdirected Request

The request was sent to a server that is not configured to produce a response for the combination of scheme and authority in the request URI.

Defined in RFC 7540 §9.1.2

What 421 means

RFC 7540, the original HTTP/2 specification, defines 421 for the case where a request arrives over a connection that the server cannot or should not use to answer it, because the request's target authority does not match what that connection is actually configured to serve. RFC 9110 later folded the same semantics into the core HTTP status registry.

The classic trigger is HTTP/2 connection coalescing: a browser that already has an open, secure connection to one hostname will reuse it for a second hostname if both resolve to the same IP address and the connection's TLS certificate covers both names (via Subject Alternative Names), avoiding a costly new handshake. If the server behind that shared connection cannot actually serve the second hostname's content, it must return 421 rather than silently answering with the wrong site.

This is closely tied to TLS SNI: a load balancer or CDN edge that terminates TLS with one wildcard or multi-SAN certificate may present a single connection for several distinct origins. When the specific vhost requested does not match the backend routing configured for that connection, 421 tells the client the mismatch is real and it must not trust this connection for that authority.

Unlike most 4xx responses, 421 is explicitly safe to retry: RFC 7540 states the client may retry the exact same request on a different connection. This makes it a signal to reconnect, not a signal that the request itself was wrong.

Common causes

HTTP/2 connection coalescing routes a request for one hostname onto a connection actually established for a different, unrelated hostname sharing the same IP and certificate.
A TLS SNI mismatch exists between the connection that was negotiated and the Host header of this particular request.
A CDN edge or reverse proxy serves multiple origins behind one shared certificate but cannot route this specific virtual host over the reused connection.
Load balancer configuration does not match the origin's virtual host setup for the coalesced hostname.
A client reuses a persistent connection for a new authority without verifying the connection actually covers it, per RFC 7540's coalescing rules.

How to fix a 421

If you are the client (browser user or API caller)

On receiving 421, retry the exact same request over a fresh connection rather than reusing the current one.
Only coalesce connections for origins that share both the same IP address and a certificate covering every relevant SAN.
Disable aggressive connection coalescing for origin sets that consistently trigger 421 responses.

If you run the server

Make sure every hostname that shares a TLS certificate and IP address is actually served correctly by whichever backend answers that shared connection.
Configure CDN or edge routing to dispatch by SNI and Host header consistently, so coalesced connections land on the right origin.
Return 421 explicitly when a coalesced request cannot be honored, instead of silently serving the wrong virtual host's content.
Keep virtual host configuration aligned across every IP address and certificate used for a given domain to minimize coalescing mismatches.

Example

# Connection already open to 203.0.113.10 for a.example.com,
# certificate also covers b.example.com (coalescing candidate)

GET / HTTP/2
Host: b.example.com

HTTP/2 421 Misdirected Request
Content-Type: text/plain

This connection cannot serve requests for b.example.com; reconnect.

The client reused a connection to a.example.com for b.example.com and must retry on a new connection.

Try it live

Our free status responder returns a real HTTP 421 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/421