ErrorBase
Independent technical referenceOfficial site
  • Software and digital services
  • HTTP service

421

HTTP 421 Misdirected Request: non-authoritative origin host

Verified with sources2 sourcesReviewed Oct 19, 2026
Technician coming? See the 2 steps they must show you

Risk level

Low

Usually safe to check without specialist tools.

Urgency

Medium

Quick answer

HTTP 421 Misdirected Request means the server or gateway cannot or will not answer authoritatively for the target URI. Check HTTP/2 connection reuse by retrying on a fresh connection, and ask the administrator to verify TLS certificates and virtual hosts.

Safety first

Stop and check this first

  • Never silence HTTP 421 by configuring an origin server to accept arbitrary unverified Host headers or mismatched TLS contexts; RFC 9110 Section 7.4 warns that Host/connection inconsistencies outside a trusted gateway can indicate attempts to bypass security filters, deliver non-public content, or poison a cache.

Safe checks you can perform

  • Repeat the request over an isolated fresh connection to the target origin
  • Compare the TLS certificate SAN list against the target URI host and SNI
  • Verify origin server and gateway virtual-host configuration for scheme, host, and port

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Register the missing URI origin triple on the authoritative server
  • Do not attempt this professional task: Align TLS SNI termination, certificate scopes, and HTTP/2 origin routing

What a technician must be able to justify

Technician visit

These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.

These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.

  1. Register the missing URI origin triple on the authoritative server

    What they doHave the web server or hosting administrator configure the target scheme, host, and port virtual host and attach a valid TLS certificate for that origin before pointing DNS or gateway traffic to the server.

    They must show youthe active virtual-host configuration entry and a fresh https request returning a 2xx or 3xx authoritative response.

    In writingthe exact scheme, host, and port registered, the certificate thumbprint bound to the listener, and the change ticket ID.

  2. Align TLS SNI termination, certificate scopes, and HTTP/2 origin routing

    What they doHave the CDN, load-balancer, or infrastructure engineer either route coalesced HTTP/2 requests by the HTTP Host/:authority header to the matching backend, split multi-domain certificates across distinct backends, or ensure non-authoritative backends return 421 cleanly so clients open a dedicated connection.

    They must show youa test trace where sequential HTTP/2 requests to the domains on the certificate either route to their authoritative backends or cleanly retry over a separate connection without failing user traffic.

    In writingthe updated TLS certificate scope or SNI/Host routing rule, the affected origin triples, and the verification timestamp.

Before accepting a part or repair

Nothing has been shown yet. Do not accept a part swap based on the code alone.

Follow these steps

Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.

  1. Repeat the request over an isolated fresh connection to the target origin

    Tools required

    Who:
    Your developer or site administrator runs a single-connection check from the command line.
    How:
    Send one request to the failing target URI over a brand-new TCP/TLS connection without prior requests to sibling domains, and note the negotiated HTTP version and status code.
    Result that matters:
    RFC 9110 Section 15.5.20 permits a client receiving 421 to retry the request, whether or not the method is idempotent, over a fresh connection specific to the target resource's origin.
    If the fresh connection succeeds with a normal response, that confirms HTTP/2 connection coalescing across shared-certificate domains triggered the 421 on the reused connection.
    If the fresh connection still returns 421, that rules out connection reuse and points to missing virtual-host routing or a certificate mismatch for that origin.
    Evidence to keep:
    Save the command output showing the TLS SNI server_name, HTTP version, Host or :authority value, and response status.

    Do not attempt to bypass TLS certificate verification flags when testing https origins.

    Evidence: RFC 9110 section 15.5.20 - 421 Misdirected Request · RFC 9113 section 9.1.1 - Connection Reuse

  2. Compare the TLS certificate SAN list against the target URI host and SNI

    No special tools

    Who:
    Your site administrator or CDN operator inspects the active TLS certificate on the endpoint.
    How:
    Check the Subject Alternative Name (SAN) entries presented during a TLS handshake to the target host and see which other domains share that certificate.
    Result that matters:
    Under RFC 9113 Section 9.1.1, a single certificate can establish authority for multiple origins, prompting HTTP/2 clients to reuse one connection across those hosts.
    If the certificate does not cover the requested host at all, that confirms why RFC 9110 Section 7.4 requires the server to reject the https request.
    If the certificate covers multiple domains that route to different origin servers via SNI, that explains why coalesced HTTP/2 requests arrive at a backend that must return 421.
    Evidence to keep:
    Record the certificate serial number, SAN host list, issuer, and expiration date.

    Evidence: RFC 9110 section 7.4 - Rejecting Misdirected Requests · RFC 9113 section 9.1.1 - Connection Reuse

  3. Verify origin server and gateway virtual-host configuration for scheme, host, and port

    No special tools

    Who:
    Your hosting or reverse-proxy administrator reviews the server routing configuration.
    How:
    Inspect the origin server and gateway listeners to confirm whether the normalized triple of scheme, host, and port (RFC 9110 Section 4.3.1) is registered and note which hop emits 421.
    Result that matters:
    RFC 9110 Section 15.5.20 specifies that an origin server or gateway acting on its behalf sends 421, whereas a forward proxy must never generate a 421 response.
    If the Host header or :
    authority pseudo-header differs from the configured origin on that backend, that confirms a gateway routing or DNS assignment mismatch.
    If a forward proxy is generating 421 on its own, that identifies a standards violation under RFC 9110 Section 15.5.20.
    Evidence to keep:
    Keep the relevant virtual-host configuration block and the access log line showing the received Host/:authority and 421 status.

    Evidence: RFC 9110 section 15.5.20 - 421 Misdirected Request · RFC 9110 section 7.4 - Rejecting Misdirected Requests · RFC 9110 section 4.3.1 - URI Origin

Still not solved

If the error persists, stop here. See what the technician must do and show you.

Where this code applies

A code is meaningful only inside the right product and version context.

Primary scope

System
Software and digital services
Brand
HTTP
Product type
HTTP service

Known code variants

  • 421 Fehlgeleitete Anfrage
  • 421 Misdirected Request
  • 421 Requête mal acheminée
  • 421 Richiesta indirizzata male
  • 421 Solicitud mal dirigida
  • HTTP 421
  • HTTP status 421

What it means

RFC 9110 Sections 15.5.20 and 7.4 define 421 as rejection of a target URI that does not match a configured origin triple (scheme, host, port) or the connection context. An https request requires a connection secured with a certificate valid for that URI's origin. RFC 9113 Section 9.1.1 describes how HTTP/2 reuse across domains sharing a wildcard or SAN certificate can route requests through an SNI middlebox to a backend that is not authoritative for the second host. The 421 response alone does not establish the root cause or prove an application bug.

Warnings and stop conditions

  • Mediumsource verified

    Never silence HTTP 421 by configuring an origin server to accept arbitrary unverified Host headers or mismatched TLS contexts; RFC 9110 Section 7.4 warns that Host/connection inconsistencies outside a trusted gateway can indicate attempts to bypass security filters, deliver non-public content, or poison a cache.

    Evidence: RFC 9110 section 7.4 - Rejecting Misdirected Requests

Symptoms and causes

Probable causes · in order

  • HTTP/2 connection reuse across origins behind SNI-based TLS routingCommon

    RFC 9113 Section 9.1.1 allows clients to reuse an HTTP/2 connection for multiple URI authorities covered by the same certificate, but if a TLS terminator selects backends by Server Name Indication (SNI), requests for a second host land on a non-authoritative origin server that replies 421.

    Evidence: RFC 9110 section 15.5.20 - 421 Misdirected Request · RFC 9113 section 9.1.1 - Connection Reuse

  • Target URI origin not configured on the receiving server or gatewayPossible

    Under RFC 9110 Section 15.5.20 and Section 4.3.1, an origin server or gateway sends 421 when the scheme, host, and port of the target URI do not match any origin namespace configured on that listener.

    Evidence: RFC 9110 section 15.5.20 - 421 Misdirected Request · RFC 9110 section 4.3.1 - URI Origin

  • Connection TLS certificate not valid for the target https originPossible

    RFC 9110 Section 7.4 requires an origin server (unless behind a trusted gateway) to reject any https request received over a connection whose certificate is not valid for that target URI's origin.

    Evidence: RFC 9110 section 7.4 - Rejecting Misdirected Requests · RFC 9113 section 9.1.1 - Connection Reuse

Virtual technician

Does 421 still appear after these checks?

Answer a few questions to narrow down the likely cause and the safest next action. Guidance only - it never replaces a professional.

Start diagnosis

Sources and technical references

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Sources: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsreviewed 2026-10-19 · verified

Was this entry useful?