什么是 HTTP 421 Misdirected Request？连接目标与请求目标不一致的原因

关于本文
本文是通过利用生成式 AI 的自动化流程创建的。基于 RFC 9110 和 RFC 9113 的一手规范，梳理了 HTTP 421 的含义以及 HTTP/2 的连接复用。

验证状态：📘 已确认官方规范·尚未进行实际通信

当出现“421 Misdirected Request”时，人们往往会像看到 404 那样觉得页面不存在，或是像看到 503 那样觉得服务器宕机了。然而，421 却是一个表示接收请求的服务器无法针对该请求目标生成适当的响应，或未被配置为响应此请求的状态码。它是排查 HTTP/2 连接复用、TLS、CDN、反向代理以及虚拟主机的线索。

421 代表什么意思？

根据 RFC 9110 §15.5.20，421 表示接收请求的服务器无法针对请求的目标 URI 生成权威响应，或者未被配置为生成该响应。这里的“权威”与 DNS 的权威服务器不同，指的是能否正确处理该 Web 请求的目标。421 在 HTTP/2 中经常被讨论，但它并非 HTTP/2 专用的状态码。

首先操作：在开发者工具中检查 421

以您管理的网站或获准检查的网站为目标。

1. 从浏览器的开发者工具中打开“网络 (Network)”。

2. 重新加载目标页面，记录返回 421 的请求的 URL、状态以及协议（如果显示）。

3. 检查是哪个主机名的请求失败了，或者主机名是否因重定向而发生了变化。

4. 通过发生时间和安全请求标识符，核对 CDN、反向代理以及 Web 服务器的日志。

预期结果：您可以缩小返回 421 的请求主机以及接收该通信的服务器端路径的范围。如果没有复现，请记录为“未复现”。请勿将 Cookie、身份验证标头或带签名的 URL 粘贴到公共日志或咨询文本中。

使用 curl 比较 HTTP 版本

以下是供读者替换为自己管理的 URL 进行测试的示例。这些并非在编写时已确认执行成功的命令。

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

通过最初的版本信息确认 curl 对 HTTP/2 的支持。由于 HEAD 不会接收与 GET 相同的正文，因此即使 HEAD 正常，也不能断定 GET 没有问题。请同时通过浏览器的“网络”检查实际的 GET。

“只有 HTTP/2 返回 421”、“两者都返回 421”或“两者都正常”等对比是排查原因的线索，但仅分别启动 curl 并不能复现浏览器在多个源之间复用连接的情况。切记不要仅凭结果就断定是 TLS 证书或 CDN 出现故障。

原理：连接目标与请求目标源

在 HTTPS 中，TLS 连接时的 SNI 与 HTTP 请求的目标源（HTTP/2 的 :authority 等）息息相关。在 HTTP/2 中，如果满足条件，现有的连接也可以被复用到对其他源的请求中。但是，证书对多个主机名有效，与连接目标服务器能够分发所有主机的内容是两码事。

这是一个概念性的虚构示例。

1. 客户端与主机A建立TLS连接。

2. 判断该连接可复用，并使用同一连接发送针对主机B的请求。

3. 接收请求的服务器无法处理主机B，遂返回421状态码。

4. 客户端有时可以通过另一个连接重试。

此流程为RFC中的说明，并非在特定浏览器或CDN中的实际测得结果。

改变一个条件：如果是HTTP/1.1会正常吗？

如果出现HTTP/1.1正常、而HTTP/2返回421的差异，则可以将连接复用和源站处理方式列为调查候选。不过，协议的变更也可能会改变网络路径或中继设备的表现。在生产环境中禁用HTTP/2之前，请在测试环境中比对请求主机、连接目标和日志。

如果HTTP/1.1也会返回421，请不要将原因局限于HTTP/2独有的机制，而应检查Host、SNI、虚拟主机以及CDN的源站设置。

遇到问题时的排查方法

RFC 9110 允许在通过其他连接重试时使用 421。然而，并不意味着用户或运维脚本可以无限制地重新发送具有副作用的请求。关于实际的重试条件，请查阅客户端实现和 HTTP 规范。

运维安全措施

在变更之前，请核对目标主机、TLS 证书的目标名称、SNI、Host/:authority、反向代理的虚拟主机以及 CDN 转发目的地，并准备好配置备份和回滚步骤。切勿为了掩盖 421 而禁用证书验证，或者无条件接受所有主机。

图解：在主机 A 的连接中请求主机 B 会发生什么？

想象一下，将寄往目的地 B 的包裹交给了只处理目的地 A 的窗口。421 的本质并非“目的地不存在”，而是接收到该请求的连接端无法处理指定的请求目标这一问题。在 HTTP/2 中，由于在某些条件下可以将连接复用到多个源站，因此可能会出现此问题。

下图为虚拟通信，并非在特定浏览器或 CDN 中观察到的日志。实际能够复用连接的条件、生成 421 的位置以及是否会进行重试，均取决于具体环境。

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: 構成が正しければ応答する場合がある

这里需要区分的是，“TLS连接已成功建立”这一事实与“能够正确分发HTTP所请求的站点内容”这一事实之间的区别。即使持有对多个主机名有效的证书，接收方的虚拟主机设置或CDN的转发条件也未必能处理所有的请求目标。仅凭证书就判定没有问题未免为时过早。

将 SNI、Host 和 :authority 按层区分

在调查 421 时，会遇到 SNI、Host、:authority 等相似的名词。SNI 是与 TLS 连接时传递的服务器名相关的信息。HTTP/1.1 的 Host 和 HTTP/2 的 :authority 是表示请求目标的信息。如果将这些全都用“连接目标的主机名”这一个词来概括，就无法追踪究竟是在哪里出现了偏差。

特别是在使用 CDN 的情况下，从浏览器到 CDN 以及从 CDN 到源服务器的这段距离中，TLS 连接和发送的主机信息有时会被分开处理。仅凭返回 421 这一结果，无法断定是哪个区段引发的问题。需要通过时间戳和安全的标识符，对照浏览器的 Network、CDN 侧的记录以及源服务器的日志，来缩小问题发生的范围。

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["同条件で再現・改善を確認"]

该图展示了故障排除的顺序。切勿认为只要图中的某一项确认一致，该项目就绝对是根本原因。在调查时容易犯的错误是，一看到 421 就立刻停用 HTTP/2 或更换证书。由于这些操作也会影响其他用户的通信，因此请先从可读取的日志和简单的对比开始着手。

具体故障场景：只有图片返回421

设想这样一个架构：虚拟网站 A 从另一个主机 B 加载图片。有时会出现页面 A 可以正常显示，但只有图片返回 421，而单独打开图片 URL 则显示正常的情况。这种差异并不证明图片数据已损坏。因为作为页面的一部分请求图片时，与直接打开 URL 时，浏览器所选择的现有连接或路径可能有所不同。

首先，记录图片的请求 URL、失败时的状态码、HTTP 版本以及发生时间。接着重试相同的操作，即使成功也保留当时的条件。即使重试成功，也不能说明“修复已完成”。这可能只是选择了另一个连接，在重现相同条件时，可能再次出现 421。

使用 curl 比较 HTTP/1.1 和 HTTP/2 时也需要注意。分别启动 curl 的结果，并不能完全还原浏览器在多个源之间复用连接的情况。切勿盲目断言“如果只有 HTTP/2 出现 421，那原因就是连接复用”，应将其视为需要进一步确认的假设。同时注意不要混淆 HEAD 和 GET 的区别。

若要在工作中应用，请统一修改前后的比较条件

如果 Web 运维人员要交接调查结果，仅报告“出现了 421”是远远不够的。应同时记录请求 URL、发生时间、连接方式、受影响的主机、正常的比较条件，以及未实施的验证。在共享之前，请移除 Cookie、Authorization 或带签名的 URL 等机密信息，并注意访问日志中个人信息的处理。

即使查明原因并更改了配置，也应明确目标主机，并保存修改前的配置及回滚方法。修改后，需通过相同的浏览器操作、相同的 HTTP 版本以及相同的主机组合进行确认。切勿仅凭重启或暂时的重试成功就结束工作，确认用户的页面是否能实际正常显示至关重要。

总结

421 并不是指“页面不存在”，而是怀疑接收服务器与请求源不匹配的线索。HTTP/2 的连接复用是一个典型例子，但仅凭 421 无法确定原因。将请求 URL、协议、主机、TLS 以及中继路径并列进行调查，才能实现具备可复现性的排查。

官方第一手资料

• RFC 9110 §15.5.20 — 421 Misdirected Request

• RFC 9113 §9.1 — HTTP/2 Connection Management

• curl 官方手册

未实施： 421 实际通信复现、curl/浏览器/CDN/Web 服务器实机验证、WordPress 显示确认。