What is HTTP 421 Misdirected Request? Why connection destination and request destination mismatch

About this article
This article was created using an automated generation workflow utilizing generative AI. The meaning of HTTP 421 and HTTP/2 connection reuse are organized based on the primary specifications of RFC 9110 and RFC 9113.

Verification Status: 📘 Official Specification Verified / Actual Communication Not Performed

When "421 Misdirected Request" occurs, one might think it is a missing page like 404 or a server outage like 503. However, 421 is a status indicating thatthe server that received the request cannot generate an appropriate response for that request destination, or is not configured to respond. It serves as a clue for investigating HTTP/2 connection reuse, TLS, CDN, reverse proxies, and virtual hosts.

What does 421 mean?

According to RFC 9110 §15.5.20, 421 indicates that the receiving server is not able or configured to generate an authoritative response for the target URI of the request. "Authoritative" here is distinct from a DNS authoritative server, and refers towhether the web request destination can be handled appropriately.Although 421 is frequently discussed in the context of HTTP/2, it is not an HTTP/2-exclusive status code.

First action: Check for 421 in Developer Tools

Target sites that you manage or sites for which you have inspection permission.

1. Open the Network tab in the browser's developer tools.

2. Reload the target page and record the URL, status, and protocol (if displayed) of the request that resulted in a 421.

3. Investigate which hostname the failed request was sent to and whether the hostname changed due to a redirection.

4. Check CDN, reverse proxy, and web server logs using the occurrence time and a safe request identifier.

Expected Result:You can narrow down the request host that resulted in a 421 and the server-side routing that received that traffic. If it does not reproduce, record it as "Not reproducible". Do not paste cookies, authorization headers, or signed URLs into public logs or support inquiries.

Compare HTTP versions using curl

The following is an example to try by replacing it with a URL managed by the reader. This is not a command whose successful execution was verified at the time of writing.

curl --version
curl --http1.1 --head --show-error https://your-owned.example/
curl --http2 --head --show-error https://your-owned.example/

Check curl's HTTP/2 support in the initial version information. Since HEAD does not receive the same body as GET,a successful HEAD does not guarantee the absence of GET issues. Also verify the actual GET request in the browser's Network tab.

Comparisons such as "only HTTP/2 returns 421", "both return 421", or "both are normal" provide hints for troubleshooting, but simply running curl separately does not reproduce the connection reuse across multiple origins in a browser. It is important not to conclude that there is a TLS certificate or CDN issue based on the results alone.

Mechanism: Connection destination and request target origin

In HTTPS, the SNI during TLS connection and the target origin of the HTTP request (such as :authority in HTTP/2) are related. Under certain conditions, HTTP/2 can reuse an existing connection for requests to a different origin. However,the fact that a certificate is valid for multiple hostnames and the fact that the connected server can serve content for all hostnames are different things.

This is a conceptual, hypothetical example.

1. The client establishes a TLS connection to Host A.

2. Determining that the connection is reusable, it sends a request intended for Host B over the same connection.

3. The receiving server cannot handle Host B and returns a 421.

4. The client may be able to retry on a separate connection.

This sequence is based on the RFC specification and does not represent measured results from specific browsers or CDNs.

Changing one condition: Would it work normally with HTTP/1.1?

If there is a difference where HTTP/1.1 works normally and HTTP/2 returns a 421, connection reuse and origin handling can be candidates for investigation. However, changing the protocol may also alter the behavior of network paths and intermediaries.Before disabling HTTP/2 in productioncompare the requested host, connection destination, and logs in a staging environment.

If a 421 occurs even with HTTP/1.1, do not limit the cause solely to HTTP/2-specific mechanisms; check the Host header, SNI, virtual hosts, and CDN origin settings.

Troubleshooting when things do not work as expected

RFC 9110 permits retrying 421 responses over a different connection. However,this does not mean users or operational scripts are allowed to resend requests with side effects indefinitely. Please verify the actual retry conditions against client implementations and HTTP specifications.

Operational Safeguards

Before making changes, verify the target host, TLS certificate subject name, SNI, Host/:authority, reverse proxy virtual hosts, and CDN forwarding destination, and prepare configuration backups and rollback procedures. Do not disable certificate validation or unconditionally accept all hosts merely to hide 421 errors.

Diagram: What happens when a request for Host B is sent over a connection to Host A?

Imagine handing a package destined for B to a service counter that only handles destination A. The essence of a 421 error is not that the destination does not exist, but rather thatthe connection endpoint that received the request cannot process the specified target request. In HTTP/2, under certain conditions, connections can be reused for multiple origins, which can lead to this issue.

The following diagram illustrates a hypothetical communication and is not a log observed in any specific browser or CDN. The conditions under which connections can actually be reused, where 421 is generated, and whether retries are performed depend on the environment.

sequenceDiagram
    participant B as ブラウザ
    participant A as ホストAを扱う接続先
    participant H as ホストBを扱う接続先
    B->>A: ホストA向けに接続を確立
    A-->>B: 応答を返せる
    B->>A: 同じ接続でホストB宛ての要求
    A-->>B: 421 要求先Bは扱えない
    B->>H: 条件を確認して別接続で再試行
    H-->>B: 構成が正しければ応答する場合がある

What we want to distinguish here is the difference between the fact that "a TLS connection has been established" and the fact that "the content of the site requested via HTTP can be delivered correctly." Even if a certificate is valid for multiple host names, the receiving virtual host settings or CDN forwarding conditions may not be able to handle all requested destinations. It is premature to check only the certificate and assume everything is fine.

Separating SNI, Host, and :authority into Layers

When investigating 421 errors, similar terms such as SNI, Host, and :authority appear. SNI is information related to the server name transmitted during a TLS connection. HTTP/1.1 Host and HTTP/2 :authority are information indicating the request destination. If these are all lumped together under the single term "destination host name," it becomes impossible to track where the mismatch occurred.

Particularly when using a CDN, the TLS connection and transmitted host information may be handled separately between the browser and the CDN, and between the CDN and the origin server. The mere result that a 421 error was returned does not determine which segment caused the issue. Narrow down the occurrence point by cross-referencing browser network data, CDN logs, and origin server logs using timestamps and secure identifiers.

flowchart TD
    A["421の要求をNetworkで特定"] --> B["URL・時刻・HTTPバージョンを記録"]
    B --> C{"複数ホスト間の通信か"}
    C -->|"はい"| D["接続の再利用と受信先を調べる"]
    C -->|"不明・いいえ"| E["要求先Hostと仮想ホストを照合"]
    D --> F["TLS・SNI・CDN転送経路を比較"]
    E --> F
    F --> G["検証環境で条件を一つだけ変更"]
    G --> H["同条件で再現・改善を確認"]

This diagram illustrates the troubleshooting sequence. Just because one of the checks in the diagram matches does not necessarily mean that item is the root cause. A common pitfall during investigation is to disable HTTP/2 or replace certificates the moment a 421 error is seen. Because these actions affect communications for other users as well, start with readable logs and small-scale comparisons.

Specific failure scenario: Only images result in a 421 status code

Consider a configuration where a fictional site A loads images from a separate host B. There are cases where page A renders successfully, but only the images return a 421 error, whereas opening the image URL directly in the browser displays it normally. This discrepancy is not proof that the image data is corrupted, because the existing connection or routing selected by the browser may differ when requesting an image as part of a page versus opening the URL directly.

First, record the image request URL, the failure status code, the HTTP version, and the date and time of occurrence. Next, retry the same operation and document the conditions even if it succeeds. A successful retry does not mean the issue is resolved; it may simply mean a different connection was selected, and reproducing the same conditions could trigger a 421 error again.

Caution is also required when comparing HTTP/1.1 and HTTP/2 using curl. The results of launching curl commands separately do not accurately reproduce connection reuse across multiple origins in a browser. Do not jump to the conclusion that "connection reuse is the cause just because HTTP/2 returns a 421"; instead, treat this as a hypothesis that requires additional verification. Also, ensure that the differences between HEAD and GET requests are not confused.

In a professional environment, ensure comparison conditions are consistent before and after fixes

When a web operations engineer hands over investigation results, a simple report stating that a "421 occurred" is insufficient. Include the request URL, timestamp, connection method, affected host, normal comparison conditions, and unperformed verifications together. Remove sensitive information such as cookies, Authorization headers, and pre-signed URLs before sharing, and handle personal data in access logs with care.

Even if the cause is identified and settings are modified, clearly specify the target host, and save both the pre-change configuration and the rollback procedure. After applying the fix, verify using the same browser operations, the same HTTP version, and the same combination of multiple hosts. Do not mark the task as complete merely based on a reboot or a temporary retry success; it is crucial to confirm that users' pages actually render correctly.

Conclusion

A 421 status code does not mean "page not found", but rather serves asa clue indicating a mismatch between the receiving server and the requested origin.While HTTP/2 connection reuse is a typical example, a 421 error alone does not definitively determine the root cause. Investigating by correlating the request URL, protocol, host, TLS, and proxy paths leads to reproducible troubleshooting.

Official Primary Sources

• RFC 9110 §15.5.20 — 421 Misdirected Request

• RFC 9113 §9.1 — HTTP/2 Connection Management

• Official curl Manual

Not Performed: Real-traffic reproduction of 421 errors, physical verification using curl, browsers, CDNs, and web servers, and WordPress display verification.