An HTTP/2 client can reuse one secured connection for requests to more than one origin when the server is authoritative for those origins. A request can still reach a server instance whose connection context does not fit the target URI. 421 Misdirected Request exists for that boundary: the server rejects the routing context rather than treating the target resource itself as missing.
This distinction separates resource semantics from connection authority. A 421 response says that this server, on this path or connection context, is unable or unwilling to produce an authoritative response for the target URI. It does not say that the resource has been deleted, that its method is forbidden, or that the request representation is invalid.
Connection reuse can span URI authorities
HTTP/2 permits a connection to an origin server to be reused for requests carrying different URI authority components when the server is authoritative for them. For HTTPS, reuse also depends on certificate validity for the host in the new URI.
A certificate can cover several host names. If a.example.test and b.example.test resolve compatibly and the certificate presented on the connection is valid for both, a client can have a protocol basis for sending requests for both origins over one HTTP/2 connection.
TLS connection
certificate valid for:
a.example.test
b.example.test
HTTP/2 stream 1 -> https://a.example.test/orders
HTTP/2 stream 3 -> https://b.example.test/profileThe transport connection is shared, but the origins remain distinct. HTTP authority rules decide whether the peer can act for each target URI; multiplexing does not merge the resources into one origin.
This is a key constraint in connection coalescing. Reuse reduces connection setup and can consolidate traffic, but every additional origin still needs a valid authority basis.
TLS authority and backend routing can disagree
A deployment can satisfy certificate checks at the connection edge while routing requests internally according to information established during connection setup.
Consider a TLS terminator that selects a backend from Server Name Indication. The client opens a connection using a.example.test. The certificate is also valid for b.example.test, so the client later reuses that connection for a request whose target authority is b.example.test.
client
|
| TLS SNI: a.example.test
v
edge terminator
|
| selected backend A
v
backend A
later on the same connection:
:authority = b.example.testThe client can have a valid certificate basis for reuse while the edge has already bound the connection to backend A. If backend A is not configured to serve b.example.test, blindly processing the request would cross an application routing boundary.
A 421 response gives the receiving server a precise rejection path. The target might be valid on another connection even though it is not valid in the current connection context.
421 is not a substitute for 404
404 Not Found concerns the target resource: the origin server did not find a current representation or is not willing to disclose one. 421 Misdirected Request concerns the server or connection context used to reach the target URI.
The difference becomes visible when a fresh connection changes the result.
request for https://b.example.test/profile
|
v
coalesced connection selected via a.example.test
|
v
421 Misdirected Request
same target over a connection specific to b.example.test
|
v
200 OKReturning 404 in the first exchange would misstate the failure. The resource lookup is not necessarily the problem; the request arrived through a context that cannot authoritatively serve it.
The same separation applies to 403 Forbidden. Authorization can be perfectly valid while connection authority is not. A server should not collapse a routing-context rejection into an application permission result.
The retry exception is tied to a different connection
HTTP permits a client receiving 421 to retry the request over a different connection, including a fresh connection specific to the target origin or an appropriate alternative service. The specification permits this even when the request method is not idempotent.
That exception is narrow. It is based on the 421 meaning that the first server rejected the request as misdirected rather than performing the target operation. The useful change is not merely another attempt; it is another connection context.
Repeating the same request on the same unsuitable coalesced connection can reproduce the same rejection. A client needs to avoid selecting the connection that caused the authority failure for the retry.
This behavior differs from generic transient-error retry logic. The response supplies structural information about routing. A connection pool that treats 421 as an ordinary application error can keep assigning the target origin to a connection the server has already rejected for that origin.
A proxy cannot generate 421
HTTP explicitly prohibits a proxy from generating a 421 response. The status code belongs to an origin server, or a gateway acting on behalf of an origin server, rejecting a target URI that does not fit its configured origin set or connection context.
That restriction keeps the signal tied to origin authority rather than generic forwarding trouble. A conventional proxy has other status codes for failures encountered while forwarding requests.
The distinction matters in layered deployments because the word “server” can describe several roles. A reverse proxy acting as the origin-facing endpoint can participate in origin authority decisions. A forwarding proxy does not gain permission to emit 421 merely because its route selection failed.
Host coverage is necessary but not sufficient
For HTTPS connection reuse, certificate validity for the new origin is mandatory, but certificate coverage alone does not force a server to accept requests for every covered host on every eligible connection.
A certificate proves a cryptographic authority relationship under the client’s validation rules. Server configuration can impose a narrower operational boundary. Virtual-host mappings, tenant isolation, client-certificate selection, or connection-specific routing can make one connection unsuitable for an origin that the certificate otherwise covers.
This is the gap that 421 can expose. The client has enough evidence to consider reuse, but the receiving endpoint has deployment information showing that the request should not be served in that context.
Treating certificate subject names as a complete backend-routing map can therefore produce false assumptions. Certificate authority and application routing are related constraints, not identical configuration objects.
HTTP/3 preserves the same authority problem
HTTP/3 also permits connection reuse across different URI authorities when the certificate is valid for the new origin and the other authority requirements are met. Its transport changes from TCP-based HTTP/2 to QUIC, but the multi-origin authority boundary remains.
A server that does not want an HTTP/3 connection reused for a particular origin can likewise respond with 421. The status code is part of HTTP semantics rather than a TCP-specific repair mechanism.
This portability is significant. The observable failure is not “wrong TCP socket.” It is “this request arrived through a connection context that the server rejects for this target URI.” That formulation survives a change in transport protocol.
Alternative services add another authority path
An origin can advertise an alternative service so that clients access the origin through another network endpoint. The alternative endpoint still acts on behalf of the original origin; using it does not change the target origin named by the request semantics.
If an alternative service returns 421, the alternative-service specification requires the client to remove the corresponding cached alternative for that origin. It can then retry at another alternative or at the origin, subject to the applicable protocol rules.
This is another case where 421 carries routing information rather than resource state. Keeping a rejected alternative cached would preserve the path that the server has declared unsuitable.
The response therefore has consequences for connection and route selection state. Application code above the HTTP stack might only observe a retry or final failure, while the protocol implementation updates which endpoint is considered valid for that origin.
421 exposes a deployment boundary that certificates can hide
Multi-origin connection reuse works because one secured connection can establish authority for more than one origin under defined conditions. Deployment routing can be narrower than that externally visible authority set.
421 Misdirected Request is the protocol escape hatch for that mismatch. It lets the server reject the current route without asserting that the target resource itself is absent or forbidden. A compliant client can react by selecting a different connection context instead of changing the request’s application meaning.
That makes 421 a useful diagnostic signal as well as a protocol result. Repeated 421 responses can point to disagreement among certificate coverage, DNS placement, connection coalescing, SNI-based routing, alternative-service state, and virtual-host configuration.
The status code does not repair those layers. It preserves their boundary: authority sufficient to attempt connection reuse does not guarantee that every server instance reached through that connection is configured to serve every eligible origin.