Is a 421 error a problem with my site or with the visitor?

Almost always the server or its TLS and virtual host setup. The client did nothing unusual; it reused a connection that the server, or the proxy in front of it, then refused to serve for that hostname.

Can a CDN or reverse proxy send 421?

RFC 9110 says a proxy must not generate 421. It comes from an origin server or a gateway acting for the origin, such as a load balancer that terminates TLS and routes by hostname.

Will browsers retry a 421 automatically?

RFC 9110 allows a client to retry the request over a different connection, even for non-idempotent methods, and major browsers generally do so. Users may still see the error if the fresh connection also lands on the wrong backend.

421 Misdirected Request — HTTP Status Code

What 421 means

421 Misdirected Request tells the client: "you sent this to me, but I am not the right server to answer for this URL." It is defined in RFC 9110, Section 15.5.20. An origin server, or a gateway acting for it, sends 421 when the target URI does not match any origin it is configured for, or does not match the connection the request came in on.

The second case is the interesting one. Under HTTP/2, a client may reuse a single TLS connection for several hostnames, a technique usually called connection coalescing. RFC 9113, Section 9.1.1, allows this when the hostnames resolve to the same IP address and the server's certificate is valid for all of them. If the server behind that connection cannot actually serve one of those hostnames, 421 is how it says so. RFC 9110 lets the client retry on a new connection, even for a POST.

When you see it

You usually see 421 in a browser, not in a terminal, because browsers are the clients that coalesce connections. A typical pattern: www.example.com loads fine, but a request to api.example.com or static.example.com fails with 421 on the same page load. Refreshing may work, because the browser then opens a dedicated connection.

The response comes from your web server or from a TLS-terminating load balancer in front of it. It is not sent by forward proxies.

Common causes

Wildcard or multi-name certificate, separate virtual hosts. A certificate covers *.example.com, so the browser reuses the connection for api.example.com, but the server picks its virtual host by the TLS SNI name from the first handshake. Requests for the second hostname arrive on a connection set up for the first.
Strict SNI and Host checks. Some servers reject any request whose Host header (or :authority in HTTP/2) differs from the SNI name of the connection. Apache's mod_ssl and mod_http2 combination is a well-known source of 421 when TLS settings differ between virtual hosts that share an IP and certificate.
Different TLS settings per virtual host. If two hosts on one IP have different protocols, ciphers or client-certificate requirements, the server may refuse to serve one over a connection negotiated for the other.
DNS or load balancer pointing at the wrong backend. A hostname that resolves to a server with no matching virtual host can produce 421 instead of the default site.

How to fix it

List which hostnames share an IP and certificate. Those are the ones browsers may coalesce.
Make shared virtual hosts compatible. Give hosts that share an IP and certificate the same TLS protocol and cipher configuration, so the server can serve any of them on any connection.
Or stop advertising shared authority. Use separate certificates, or separate IP addresses, for hosts that must stay isolated. Browsers only coalesce when the certificate covers both names.
Check the load balancer's routing. Make sure routing uses the Host or :authority header of each request, not only the SNI name of the connection.
Confirm every hostname has a matching server block or virtual host, including www and bare-domain variants.

How to check it

Force a request for one hostname over a connection made to another, which mimics coalescing:

curl -sv --http2 https://api.example.com/ \
  --connect-to api.example.com:443:www.example.com:443 -o /dev/null

Then compare with a TLS handshake where SNI and the requested host disagree:

curl -sv https://www.example.com/ -H "Host: api.example.com" -o /dev/null

If the second command returns 421 while a plain curl -sI https://api.example.com/ returns 200, the server is enforcing SNI and Host consistency, and browsers that reuse connections will hit it.

What it means for uptime monitoring

PingRobot's checker sends a GET with the user agent PingRobot/1.0 (+https://pingrobot.io/bot), follows redirects, and counts the final response as up only if its status is between 200 and 399. A 421 therefore counts as down, and the failure is re-checked from a second region before any alert is sent.

Because a monitor makes one request per check rather than loading a page full of resources, it rarely triggers connection coalescing. A 421 seen by a monitor more often points to a real configuration problem: the hostname reaches a server, or a backend behind a load balancer, that has no virtual host for it. Treat it as an outage for that hostname. If the monitor is green but users report 421, the cause is almost certainly coalescing in browsers, and the fix is in your TLS and virtual host setup.

400 Bad Request – the request itself is malformed.
403 Forbidden – the server understood but refuses.
404 Not Found – the right server, but nothing at that path.
505 HTTP Version Not Supported – another protocol-level rejection.
502 Bad Gateway – a proxy got a bad answer from the backend.

Start monitoring free — 10 monitors, no credit card.