421 - Misdirected Request
HTTP 421 Misdirected Request means the request reached a server that is not able to produce a response for the target authority.
Last reviewed: February 3, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Misdirected Request Mean?
The request arrived over a connection bound to a different authority, so the receiving server cannot safely serve this target name.
Common Causes
- -HTTP/2 connection coalescing reuses TLS session for different authority not valid under certificate SAN set.
- -CDN forwards Host header for tenant B over origin connection established for tenant A and origin rejects.
- -Service mesh routes by mismatched SNI, sending request to backend that is not authoritative for requested host.
How to Fix Misdirected Request
- 1Retry the request on a fresh connection scoped to the correct authority.
- 2Align
Hostheader, TLS SNI, certificate SAN coverage, and virtual-host routing tables. - 3Disable or tune unsafe connection coalescing that reuses one connection across incompatible authorities.
Step-by-Step Diagnosis for Misdirected Request
- 1Capture request authority details (
Host, SNI, resolved target, connection ID) for 421 events. - 2Inspect ingress and origin virtual-host mappings for authority-to-backend mismatch.
- 3Trace HTTP connection reuse/coalescing behavior in clients and intermediaries.
- 4Retest with isolated per-authority connections and confirm routing consistency.
Authority and TLS Identity Alignment
- -Verify certificate SAN and SNI coverage for requested authority (example: wildcard cert missing specific subdomain routed on shared edge).
- -Check Host-to-backend mapping rules (example: one Host alias mapped to wrong upstream cluster).
Connection Reuse and Coalescing Controls
- -Inspect HTTP/2 or shared-connection coalescing decisions (example: client reuses connection for different authority not accepted by origin).
- -Audit proxy connection pool keying (example: pool keyed by IP only, not authority, causing misdirected requests).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 421 Misdirected Request
# {"error":"Misdirected Request","code":"421"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 421) {
console.error('Handle 421 Misdirected Request');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 421:
print('Handle 421 Misdirected Request')Seen in Production
HTTP connection reuse sends request to wrong virtual host backend
Frequency: common
Example: Client reuses pooled connection for api-b.example.com while it was established for api-a.example.com, producing 421.
Fix: Scope connection pools by authority and enforce strict host validation in client transport layer.
SNI mismatch after certificate/ingress change
Frequency: rare
Example: One ingress node presents cert/mapping set that does not cover requested host and responds 421.
Fix: Reconcile certificate SANs and ingress host mapping, then validate with multi-node canary probes.
Debugging Tools
- -TLS/SNI handshake inspection tools
- -Ingress virtual-host mapping logs
- -Connection pool reuse telemetry
- -Authority-scoped synthetic probes
How to Verify the Fix
- -Re-run affected requests and confirm 421 is eliminated on fresh authority-correct connections.
- -Validate Host/SNI routing parity across all regions and ingress tiers.
- -Confirm connection pools no longer cross authorities incorrectly.
How to Prevent Recurrence
- -Standardize authority routing and certificate management across environments.
- -Add pre-deploy tests for Host/SNI alignment and per-authority connection behavior.
- -Continuously audit proxy/load-balancer pool keying and virtual-host configuration drift.
Pro Tip
- -key every connection pool cache entry by authority to prevent accidental cross-host reuse under load.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.