421 Misdirected Request

RFC 9110, section 15.5.20, says an origin server sends 421 when the target URI does not match an origin it is configured for, or does not match the connection context. The client may retry on a fresh connection, even if the method is not idempotent, because nothing was processed. Proxies must not generate 421.

The code was introduced with HTTP/2, where browsers reuse one TLS connection for several hostnames when the certificate covers them and DNS points to the same IP. If the server behind that IP does not actually host one of those names, 421 tells the browser to open a dedicated connection.

A second wave came in July 2025 with Apache httpd 2.4.64, which tightened SNI checks. Setups with nginx in front of Apache over HTTPS (common on cPanel, Plesk and DirectAdmin) started returning 421 because nginx did not send SNI to the backend. The Apache error log shows AH02032 for this case.

If you are visiting the site

• Your browser reused an HTTP/2 connection for a second subdomain that shares the certificate and IP but is served by a different backend.
• The site has a proxy misconfiguration; every visitor sees the same 421.

If you run the server

• nginx proxies to an HTTPS backend without proxy_ssl_server_name on, so the backend sees no SNI, or the wrong one, and rejects the Host.
• A wildcard or multi-domain certificate lets browsers coalesce connections across hosts that live on different virtual hosts or servers.
• Apache mod_ssl finds that the SNI name and the Host header map to virtual hosts with incompatible TLS settings (AH02032).

If you are visiting the site

• Reload the page; browsers retry on a new connection. If it persists, close the browser to drop pooled connections, or try another browser.

If you run the server

• In nginx, forward SNI to HTTPS upstreams: proxy_ssl_server_name on; and proxy_ssl_name $host;. Hosting panels added this after the Apache 2.4.64 change.
• Give hosts that live on different servers separate certificates, or separate IPs, so browsers do not coalesce their connections.
• Check the Apache error log for AH02032 to confirm an SNI and Host mismatch.

Most of the time you are fixing a 421, not sending one. The nginx block is the fix for the reverse-proxy case; the Express and Go examples show an origin rejecting hostnames it does not serve.

const HOSTS = new Set(['example.com', 'www.example.com']);

app.use((req, res, next) => {
  if (!HOSTS.has(req.hostname)) {
    return res.status(421).send('Misdirected Request');
  }
  next();
});

func onlyHosts(next http.Handler, hosts ...string) http.Handler {
	allowed := map[string]bool{}
	for _, h := range hosts {
		allowed[h] = true
	}
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if !allowed[r.Host] {
			http.Error(w, "misdirected request", http.StatusMisdirectedRequest) // 421
			return
		}
		next.ServeHTTP(w, r)
	})
}

# Fix: send SNI to an HTTPS backend (avoids 421 from Apache 2.4.64+)
location / {
  proxy_pass https://backend;
  proxy_set_header Host $host;
  proxy_ssl_server_name on;
  proxy_ssl_name $host;
}

421 vs 400

400 fits a missing or malformed Host header; 421 means the Host is valid but not served on this connection.

421 vs 502

502 is a proxy reporting a bad upstream answer; a 421 comes from the origin itself, and proxies must not generate it.

How do I fix 421 Misdirected Request behind nginx?

If nginx proxies to an HTTPS backend, add proxy_ssl_server_name on; and proxy_ssl_name $host; to the location block so the backend receives the right SNI, then reload nginx.

Why did 421 errors appear after an Apache update?

Apache httpd 2.4.64 (July 2025) enforced stricter matching between the TLS SNI name and the Host header. Front proxies that did not send SNI to Apache started getting 421, logged as AH02032.

Is it safe for a browser to retry after 421?

Yes. RFC 9110 lets the client retry on a different connection whether or not the method is idempotent, because the server did not process the request.