421 Misdirected Request
4xx client error
The request went to a server that can't produce a response for that hostname.
421 shows up with HTTP/2 and HTTP/3 connection reuse. Browsers reuse one TLS connection for several hostnames when the certificate covers them all and they resolve to the same IP. If the server on that connection isn't actually configured for one of those hostnames, it answers 421, and the browser retries on a fresh connection.
| Class | 4xx Client Error |
|---|---|
| Retry? | Yes — safe to retry |
| Cacheable by default | No — only with explicit Cache-Control |
| Response body | Allowed |
| Defined in | RFC 9110 §15.5.20 — 421 Misdirected Request |
Example response
HTTP/1.1 421 Misdirected Request
Content-Type: application/json
Content-Length: 31
{"error":"Misdirected Request"}Common causes
- A wildcard or multi-domain certificate shared by virtual hosts with different TLS settings.
- Reverse proxies where the SNI from the TLS handshake doesn't match the
Hostheader.
How to fix it
- Usually nothing — browsers retry on a new connection automatically.
- If users do see it, give virtual hosts that share a certificate identical TLS settings, or a certificate each.
Check what a URL returns
Print just the status line from the command line, or check a whole list of URLs at once, with their response headers, in the HTTP Status Checker.
curl -sI https://example.com/your-path | head -n 1
Frequently asked questions
Why do only some browsers hit 421?
It depends on connection coalescing. Browsers that reuse HTTP/2 connections across hostnames reach the misconfigured host; others open a new connection per host and never notice.
Headers used with 421
Related status codes