Misdirected Request

Active

RFC 9110 §15.5.20•Since 2015•HTTP/2 servers, CDNs, reverse proxies, multi-tenant TLS termination

HTTP 421 Misdirected Request indicates the server cannot produce a response for the combination of scheme and authority in the request URI. Defined in RFC 9110 §15.5.20. Most common with HTTP/2 connection coalescing where the client reuses a connection for a different hostname. The client SHOULD retry on a different connection.

Description

The 421 Misdirected Request status code indicates that the request was directed at a server that is not able to produce a response for the combination of scheme and authority included in the request URI. This can happen when a client reuses an existing connection for a request that the server is unwilling or unable to serve on that particular connection.

The most common trigger is HTTP/2 connection coalescing. When a TLS certificate covers multiple hostnames (e.g., a wildcard cert for *.example.com), HTTP/2 clients are allowed to reuse an existing connection for any hostname that the cert covers. However, the server may not be configured to serve all those hostnames on the same connection — perhaps different hostnames route to different backend services, or virtual hosting rules require separate connections.

When the server receives a request it cannot serve on the current connection, it responds with 421. This is not an error in the traditional sense — the request itself is valid, and the resource exists. The problem is the routing: this request arrived on the wrong connection. The client SHOULD retry the request on a different connection, typically by opening a new TCP/TLS connection directly to the target authority.

421 is also relevant to reverse proxy configurations and SNI (Server Name Indication) mismatches. A reverse proxy that terminates TLS for multiple backends may receive a request intended for a backend it cannot reach on the current connection. Similarly, when SNI and the Host header disagree, some servers respond with 421 rather than serving potentially incorrect content.

Unlike most 4xx errors which indicate client fault, 421 is more of a routing signal. The client did nothing wrong — it followed HTTP/2 connection reuse rules correctly. The server is simply saying 'I can't handle this particular request on this particular connection, please try elsewhere.'

Examples

HTTP/2 request reusing connection for different host

http

GET /assets/logo.png HTTP/2
Host: cdn.example.com
:authority: cdn.example.com
:scheme: https
Connection: (reused from api.example.com)

421 response — misdirected request

http

HTTP/2 421 Misdirected Request
Content-Type: application/json

{"error": "misdirected_request", "message": "This server cannot produce a response for cdn.example.com on this connection. Please retry on a new connection.", "retry": true}

SNI mismatch — Host header differs from TLS SNI

http

GET /api/users HTTP/2
Host: app.example.com
:authority: app.example.com
:scheme: https

# TLS was negotiated with SNI = api.example.com
# but :authority = app.example.com → mismatch

421 response — SNI mismatch

http

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

The request authority (app.example.com) does not match the TLS SNI (api.example.com). Please establish a new connection with the correct SNI.

Client retry after 421 — new connection

http

# Client opens NEW TCP+TLS connection directly to cdn.example.com
# TLS SNI: cdn.example.com
# ALPN: h2

GET /assets/logo.png HTTP/2
Host: cdn.example.com
:authority: cdn.example.com
:scheme: https

Reverse proxy cannot route to backend

http

GET /dashboard HTTP/2
Host: internal.example.com
:authority: internal.example.com
:scheme: https

# Proxy terminates TLS for *.example.com but
# internal.example.com backend is not reachable
# from this proxy instance

Edge Cases

•421 is NOT a permanent error — the same request will succeed if sent on a different connection. Clients must retry, not give up.
•A client that receives 421 MUST NOT retry the request on the same connection. It must open a new connection to the target authority.
•HTTP/1.1 connections rarely produce 421 because connection coalescing is an HTTP/2+ feature. If you see 421 on HTTP/1.1, it's likely a misconfigured virtual host or reverse proxy.
•Wildcard certificates (*.example.com) are the primary enabler of connection coalescing — and therefore the primary trigger for 421 when the server can't actually serve all subdomains on one connection.
•Some CDNs (Cloudflare, Fastly) may return 421 when a client's TLS session ticket was issued for a different origin server than the one handling the request.
•Infinite retry loops: if a client keeps getting 421 after opening new connections, the issue is likely DNS-level (all IPs route to the same server that can't serve the host) — not a connection reuse problem.
•GOAWAY frame vs 421: HTTP/2 servers can also refuse connections via GOAWAY with ENHANCE_YOUR_CALM or other error codes, but 421 is the correct application-layer signal for 'wrong connection for this authority'.

When You'll See This

→Client reuses HTTP/2 connection to api.example.com for cdn.example.com because the wildcard cert covers both, but the server only handles API traffic
→Reverse proxy receives request for a hostname it cannot route to on the current backend connection pool
→SNI value from TLS handshake does not match the :authority pseudo-header in the HTTP/2 request
→Load balancer routes connection to a node that doesn't serve the requested virtual host
→CDN edge server receives request for an origin it hasn't cached and can't reach on this connection
→Multi-tenant platform where different tenants map to different backends despite sharing a TLS certificate
→Client sends request after server has decided to deprecate a hostname from a shared connection but before GOAWAY is processed

Implementation References

Language	Constant
Go	http.StatusMisdirectedRequest
Rust	http::StatusCode::MISDIRECTED_REQUEST
Python	http.HTTPStatus.MISDIRECTED_REQUEST
Node.js	http.STATUS_CODES[421]
.NET	HttpStatusCode.MisdirectedRequest
Java	421 (no built-in constant, use literal)
PHP	Response::HTTP_MISDIRECTED_REQUEST (Symfony)
Ruby	:misdirected_request (Rack)

History

Introduced in RFC 7540 (HTTP/2, 2015) specifically to address connection coalescing issues that did not exist in HTTP/1.1. When HTTP/2 allowed multiplexing multiple streams over a single TCP connection, and clients began reusing connections for different hostnames covered by the same TLS certificate, servers needed a way to signal 'I can't serve this hostname on this connection.' The status code was later incorporated into RFC 9110 (HTTP Semantics, 2022) as §15.5.20, making it part of the core HTTP specification rather than an HTTP/2-specific extension. Its existence is a direct consequence of the connection model change in HTTP/2 — without connection coalescing, there would be no need for 421.

Related Status Codes

400 Bad Request 403 Forbidden 404 Not Found 502 Bad Gateway

Related Headers

Host Alt-Svc

FAQ

What causes HTTP 421 Misdirected Request?

The most common cause is HTTP/2 connection coalescing. When a TLS certificate covers multiple hostnames (e.g., a wildcard cert for *.example.com), HTTP/2 allows clients to reuse an existing connection for any hostname the cert covers. If the server can't actually serve the requested hostname on that connection — because different hostnames route to different backends, or virtual hosting rules require separate connections — it returns 421. The client should then open a new, dedicated connection to the target hostname and retry.

How should a client handle a 421 response?

The client MUST NOT retry the request on the same connection. Instead, it should open a new TCP+TLS connection directly to the authority (hostname) specified in the request URI, perform a fresh TLS handshake with the correct SNI, and resend the request on this new connection. Most HTTP/2 client libraries handle this automatically — they mark the connection as unable to serve that particular authority and establish a new one. If the retry also returns 421, there's likely a server misconfiguration rather than a connection reuse issue.

What is HTTP/2 connection coalescing and why does it cause 421 errors?

Connection coalescing is an HTTP/2 optimization where a client reuses an existing TCP+TLS connection for requests to a different hostname, provided the TLS certificate is valid for both hostnames and the IP address resolves to the same server. For example, if a client has a connection to api.example.com and the cert is *.example.com, it may reuse that connection for cdn.example.com. The problem arises when the server handles these hostnames differently — different backend routing, different application logic, or different virtual host configurations. The server responds 421 to tell the client: 'this request is valid, but I can't serve it on this connection. Open a new one.'

Source: RFC 9110 §15.5.20