HTTP 421 Misdirected Request

Quick reference

HTTP/2 connection coalescing

HTTP/2 allows a single TCP+TLS connection to carry requests for multiple origins if two conditions are met: both origins resolve to the same IP address, and the TLS certificate covers both hostnames (via SAN entries or a wildcard). When a browser sees that api.example.com and static.example.com share the same IP and the certificate covers both, it may reuse a single HTTP/2 connection for requests to both — this is connection coalescing.

The problem: the server at that IP may not be configured to serve all coalesced origins. It handles api.example.com but has no virtual host for static.example.com. When the browser sends a request for static.example.com over the coalesced connection, the server returns 421: “I cannot serve this origin on this connection.”

The browser must then open a separate connection directly to static.example.com and retry. RFC 9110 §15.5.20 explicitly requires this: a client that receives 421 should retry on a new connection.

# HTTP/2 coalescing scenario:
# DNS: api.example.com → 203.0.113.50
# DNS: static.example.com → 203.0.113.50
# TLS cert: *.example.com (covers both)
# Browser coalesces both to single HTTP/2 connection

# Browser sends on coalesced connection:
:method GET
:scheme https
:authority static.example.com
:path /styles/main.css

# Server at api.example.com returns:
:status 421   (configured for api., not for static.)

TLS SNI mismatch

TLS Server Name Indication (SNI) is the mechanism by which a TLS client tells the server which hostname it is connecting to during the handshake, before the HTTP request is sent. The server uses the SNI value to select the correct TLS certificate. If the server receives a TLS handshake with an SNI value it does not have a certificate for, it may return 421 after the handshake completes on a fallback certificate that does not cover the requested hostname.

This can occur when: a wildcard certificate covers the domain but the server does not have a virtual host for the specific subdomain, a load balancer terminates TLS and forwards to a backend that has no virtual host for that hostname, or a certificate was updated to remove a SAN without updating the corresponding virtual host configuration.

Reverse proxy misconfiguration

A reverse proxy (nginx, HAProxy, Traefik, Envoy) that receives requests for multiple virtual hosts and routes them to different backends may misroute a request if its routing configuration is incomplete or incorrect. If the backend receives a request for a hostname it does not serve, it returns 421.

Common nginx misconfiguration causing 421:

# nginx receiving requests for multiple hosts
server {
    listen 443 ssl;
    server_name api.example.com;
    # only configured for api.example.com
    # requests for static.example.com arrive here via coalescing
    # and trigger 421 because server_name does not match
}

Fix: Add explicit virtual host blocks for each hostname, or use a catch-all server block with appropriate routing:

server {
    listen 443 ssl;
    server_name api.example.com;
    location / { proxy_pass http://api_backend; }
}

server {
    listen 443 ssl;
    server_name static.example.com;
    location / { proxy_pass http://static_backend; }
}

Diagnosing 421

Step 1: Confirm the DNS resolution. Both the requested hostname and the server’s configured hostname should resolve to the same IP for coalescing to occur. Use dig api.example.com A and dig static.example.com A to compare.

dig +short api.example.com
dig +short static.example.com
# If both return the same IP, coalescing is possible

Step 2: Check the TLS certificate SANs:

openssl s_client -connect static.example.com:443 -servername static.example.com 2>/dev/null   | openssl x509 -noout -text | grep -A2 "Subject Alternative Name"

Step 3: Verify server virtual host configuration. On nginx: nginx -T | grep server_name. Confirm every hostname in the TLS certificate has a corresponding server_name directive in the server config.

Step 4: Test directly without HTTP/2:

curl --http1.1 -v https://static.example.com/test
# If this succeeds but HTTP/2 fails, coalescing is confirmed as the cause

421 vs 503 vs 404

Frequently asked questions

What does HTTP 421 mean?

The server received the request but is not configured to serve the requested origin (hostname + scheme). Most commonly caused by HTTP/2 connection coalescing sending a request for one hostname to a server only configured for a different hostname. The client should retry on a fresh connection.

How should a client handle 421?

Open a new TCP+TLS connection directly to the requested origin without reusing any existing coalesced connection. Do not retry on the same connection. Browsers do this automatically; programmatic HTTP/2 clients may need explicit handling.

Can 421 be caused by a CDN?

Yes. A CDN that coalesces connections for multiple customer domains sharing an IP can trigger 421 if the edge node handling the connection is not configured for the requested customer domain. CDN 421 errors often resolve automatically as the CDN retries on a correct edge node.

Is 421 ever a server-side misconfiguration?

Yes. If a server returns 421 consistently (not just occasionally due to coalescing), the server configuration is missing a virtual host for the requested hostname. Add the hostname to the server’s virtual host configuration and ensure the TLS certificate covers it.

Related guides

HTTP 400 Bad Request · HTTP 503 Service Unavailable · SSL Handshake Failed

Standards reference

Definitions from the IANA HTTP Status Code Registry and RFC 9110 §15.5.20. Human-readable guidance by ErrorLookup. · HTTP 421 quick reference →