# 421 Misdirected Request: HTTP/2 Connection Coalescing

> 421 Misdirected Request means the server cannot answer for the host on this connection. Fix SNI and certificate mismatches caused by HTTP/2 connection reuse.

Source: https://howhttpworks.com/status-codes/421
Last reviewed: 2026-10-04

> **TL;DR:** 421 means "you sent this request to the wrong connection". The server will not answer for that hostname on the TLS connection in use. It is most often HTTP/2 connection coalescing meeting a server whose per-host TLS or routing config differs; the fix is consistent config per IP, or non-overlapping certificates.

## What it means

RFC 9110 §15.5.20: the request was directed at a server that is not able or willing to produce an authoritative response for the target URI. The client may retry on a different connection.

```http
GET /dashboard HTTP/2
:authority: admin.example.com

HTTP/2 421
content-type: text/html

Misdirected Request
The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
```

That body is Apache httpd's wording. The error log carries the key:

```text
[ssl:error] [pid 2217] AH02032: Hostname admin.example.com provided via SNI and hostname www.example.com provided via HTTP have no compatible SSL setup
```

## Why it happens: connection coalescing

With HTTP/1.1, one connection serves one hostname. HTTP/2 (RFC 9113 §9.1.1) allows a client to reuse a connection for another origin when:

1. the second hostname resolves to an IP the connection already uses, and
2. the certificate on that connection is valid for the second hostname (a wildcard or multi-SAN cert).

The browser then sends `www.example.com` and `admin.example.com` requests down one TCP+TLS connection that was set up with SNI `www.example.com`. The server saw only the first SNI during the handshake. If the second hostname is meant to have different TLS parameters, a different client-certificate policy, or is routed by a different virtual host, the server cannot honour it safely and answers 421.

Real triggers:

- **Apache vhosts with different SSL settings** on the same IP (one requires client certificates or restricts protocols, another does not).
- **nginx** with `ssl_verify_client` on one `server` block and not on another that shares the address: when the `Host` header selects a different server block than the SNI did, and client-certificate settings differ, nginx answers 421 rather than serve a client-certificate-protected host on a connection that never asked for a certificate.
- **Envoy/Istio gateways, Traefik, HAProxy, Kubernetes ingress** where a wildcard certificate and shared IP let the browser coalesce hosts, but filter chains or routes are selected by SNI. In Istio the symptom is more often an intermittent 404 than a 421.
- **CDNs and multi-tenant frontends** that place unrelated customers on one IP with an overlapping SAN set.
- **mTLS endpoints** next to ordinary endpoints on the same IP.

Symptoms are intermittent and order-dependent: it works when the first page visited is `admin.`, fails when `www.` was visited first. Incognito windows or a second browser behave differently because they have different live connections.

## Diagnose

1. Check whether it only happens on HTTP/2 with a reused connection. `curl --http1.1 https://admin.example.com/` will succeed because each hostname gets its own connection. Give curl two URLs in one invocation so it can reuse the connection:

```bash
curl --http2 -v https://www.example.com/ https://admin.example.com/ 2>&1 | grep -E 'Re-using|HTTP/2 |< HTTP'
# Re-using existing connection with host www.example.com   <- coalescing
```

curl only reuses the connection when its own checks (IP and certificate) allow it, so a clean run does not prove the server is fine; the browser's decision can differ.

2. Compare the certificates and SNI behaviour of both names on the IP:

```bash
echo | openssl s_client -connect 203.0.113.10:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
echo | openssl s_client -connect 203.0.113.10:443 -servername admin.example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
```

If both return the same wildcard or SAN list, coalescing is allowed.
3. In Chrome, `chrome://net-export` or the DevTools Network panel with the Connection ID column shows two hostnames sharing one connection.
4. Read the server error log (Apache AH02032) or the Envoy access log, where `response_flags` of `NR` (no route configured) with a 404 or 421 points at a coalesced request.

## Fix it

Pick whichever fits the architecture:

1. **Make configuration consistent** across all vhosts that share an IP and certificate (same `SSLProtocol`, `SSLCipherSuite`, `SSLVerifyClient`). Coalescing then is harmless.
2. **Stop the certificate overlap.** Issue separate certificates whose SANs do not cover each other's names, so the browser has no basis to coalesce. For example, an mTLS `admin.example.com` gets its own cert and does not sit under `*.example.com`. This is the usual answer for mTLS.
3. **Separate IPs** for hosts that need different TLS policy. Browsers only coalesce if DNS returns an overlapping address.
4. **Route correctly at the gateway.** In Istio, use one Gateway server with a wildcard host and one credential so both hosts share a filter chain, or have the gateway return 421 for the unmatched host (an EnvoyFilter) so the browser retries on a fresh connection.
5. **As a last resort,** disable HTTP/2 on the affected listener. This costs you multiplexing everywhere on it, so it is a workaround.

If you build the server, return 421 only when the TLS context and the request authority conflict, not for unknown hosts (that is [404](https://howhttpworks.com/status-codes/404), or nothing at all as in [444](https://howhttpworks.com/status-codes/444)).

RFC 8336 defines an HTTP/2 `ORIGIN` frame that lets a server tell clients exactly which hostnames it will answer for on a connection, which reduces both over- and under-coalescing; support is not universal.

## Related

- [400 Bad Request](https://howhttpworks.com/status-codes/400): malformed request rather than a wrong connection.
- [403 Forbidden](https://howhttpworks.com/status-codes/403)
- [404 Not Found](https://howhttpworks.com/status-codes/404)
- [HTTPS and TLS](https://howhttpworks.com/guides/https-and-tls): SNI and certificates.
- [Host](https://howhttpworks.com/headers/host)