摘要

  • HTTP/2 允许客户端在满足解析和证书校验条件时，用一条持久、多路复用的连接承载不同 URI 权威部分的请求；这些证据足以支持一次复用尝试，却无法证明最初握手选中的服务上下文已经配置了所有被证书覆盖的源。
  • 421 Misdirected Request 否定的是“这个源应由这条连接来承载”这一配对，而不是宣布 URI 已迁移、请求语法错误或 TLS 必然失败。客户端可以在另一条连接上重试同一请求，方法即使不是幂等的也可以；普通代理不得自行生成 421。
  • RFC 8336 后来用 HTTP/2 的 ORIGIN 帧提前声明一条连接的 Origin Set，并要求支持该扩展的客户端在收到 421 后，从这条连接的集合中删除相应源。HTTP/3 改用 QUIC 后仍保留 421，说明真正需要治理的是共享连接上的权威边界，而非 TCP 的某个偶然细节。

一张证书给了客户端理由，却没有给服务端义务

客户端已经为站点甲建立了一条加密连接。连接工作正常，握手顺利完成，服务端证书的身份范围同时覆盖站点乙。客户端查询站点乙的名称，又发现它指向同一个服务端地址。

从客户端能看到的证据出发，复用几乎是最合理的选择。重新建连意味着新的握手、新的传输状态和额外等待；已有连接已经认证，并且能够并发承载多个流。HTTP/2 的性能收益，正来自把许多原本要排队或分别建立的请求放进一条持久连接。

但服务端看到的是另一半事实。建立连接时的 SNI 可能已经选定一个租户、一组端口策略、一个 TLS 终止环境或一套后端池。证书可以覆盖甲和乙，最初握手建立的内部路径却可能只接通甲。站点乙在另一条以乙为 SNI 的连接上完全可用，但并不愿意让甲的连接上下文代它回答。

客户端没有无理猜测，服务端也没有义务接受这个猜测。HTTP 需要一种精确的说法，承认连接本身有效，同时拒绝它对某个源的代表资格。421 就是这句话。

Host 说明“你在问谁”，没有替服务端决定“谁来回答”

HTTP 早已遇到过地址与名称分离的问题。多个网站开始共享同一个 IP 地址后，TCP 目的地址无法说明客户端想访问哪个命名空间。HTTP/1.1 因而要求请求携带 Host；在 HTTP/2 与 HTTP/3 中，:authority 通常承担相同职责。

这个字段解决的是目标识别：请求指向哪个源、哪个主机与端口。它没有消除接收方的路由判断：这个源是否配置在当前服务上，这条连接的上下文是否适合处理它。

现行的 RFC 9110 同时保留两项纪律。请求中的主机与端口把一个源的资源空间同其他命名空间分开；服务端在解析出目标 URI 后，仍要决定自己处理、转发、重定向、拒绝还是断开，并核验方案、目标与连接上下文的要求。

因此，Host 表达的是客户端意图，不是对套接字背后所有进程的授权书。把目标说清楚，与找到有权回答该目标的上下文，是相邻但不同的工作。

多路复用把一次合理推断变成了常见路径

2015 年 5 月发布的 RFC 7540 首次标准化 HTTP/2。它鼓励保持连接，并允许在源站看似具有权威时，让一条连接承载具有不同 URI 权威部分的请求。

对于未加密的 TCP 连接，另一个主机需要解析到同一 IP 地址。对于 HTTPS，服务端证书还必须对新主机有效，而且要通过客户端新建连接时原本会执行的检查。一张含有多个 subjectAltName 的证书，或一张适用的通配符证书，可以给多个源提供身份覆盖。

这不是盲目合并。客户端同时使用名称解析与证书校验，才把请求放进现有连接。然而，这些检查描述的是客户端可以观察到的外部边界，无法完整描述端点之后的部署结构。

RFC 7540 举出的典型情形是：一个中间设备终止 TLS，并依据连接建立时的 SNI 选择源站。客户端随后在同一连接上发送另一个同样被证书覆盖的源请求，请求便可能落入不对应的服务上下文。此时 DNS 未必错误，证书未必伪造，HTTP 消息也未必畸形。缺少的只是接收方掌握的那项局部知识：这个目标不能由这条连接来回答。

421 否定一条边，不抹掉边的两端

RFC 7540 为上述情形引入 421 Misdirected Request。2022 年，421 的现行定义被放入通用 HTTP 语义 RFC 9110，不再只属于 HTTP/2。

它表示请求抵达的服务端无法或不愿意为目标 URI 产生权威响应。原因可以是目标不匹配服务端配置的任何源，也可以是目标不符合接收请求的连接上下文。

这个范围非常窄。421 没有说资源不存在，没有说源已经搬家，也没有要求客户端换一个 URI。它只说：由“这个目标”与“这条连接”组成的配对不能在这里得到权威回答。

因此，源站可以发出 421，代表源站行事的网关也可以，因为它们处在源的服务边界内。普通代理服务器则被明确禁止生成 421。若任意转发节点都能制造这个判断，客户端就无法区分究竟是源拒绝了连接上下文，还是某个中途节点单方面偏好另一条路。

421 把否定性证据留在掌握配置事实的一方，并把作用域限制在一条具体关系上。连接仍然存在，目标源仍然存在；失效的是它们在这一刻的组合。

可达、凭证覆盖与上下文接受，是三个命题

理解 421 的最好方法，是拒绝把三类证据揉成一个结论。

第一是可达性：这条连接确实通向一个端点。第二是凭证覆盖：该端点拿出的证书，在客户端的校验规则下可以认证目标源。第三是连接上下文接受：接收方的部署已经配置好，并愿意在这条具体连接上为目标源作出权威响应。

前两项足以让复用成为有依据的尝试，却不能强迫第三项成立。一张证书证明对私钥和所列身份的控制，不会自动证明所有名称在每个端口、租户、后端池与握手上下文中都共享同一服务图。

如果把证书当成完整的服务清单，安全团队一次扩大名称范围，就可能无意中扩大连接复用的推断范围；应用团队却未必同步了后端。反过来，如果服务端只能用模糊错误拒绝，客户端又难以知道该换连接、换目标还是停止操作。

421 让双方各自在证据最充分的边界上作决定：客户端负责尝试复用，接收方负责否决它无法代表的源。

重试保留请求含义，只改变承载上下文

RFC 9110 对恢复方式写得很明确：收到 421 的客户端可以在另一条连接上重试，无论请求方法是否幂等。另一条连接可以是专门为目标源新建的连接，也可以通向合适的替代服务。

允许非幂等方法重试，是这项机制最容易被误读的部分。HTTP 并不是宣布所有网络失败之后都可以安全重放一次写操作。它针对的是一个具有明确语义的拒绝：响应方已经表明自己没有在当前连接上下文中为目标源产生权威响应。改变连接，是纠正投递上下文，而不是在未知执行结果后随意重复业务动作。

即使如此，规范使用的仍是“可以”，不是“必须”。客户端可以因为本地策略、请求体不可重放、凭证绑定、用户确认要求或风险偏好而拒绝重试。协议提供恢复根据，不替应用承担后果。

真正不可少的是条件变化。若客户端在同一条已被拒绝的共享连接上无限重发，421 就从纠错信号变成循环。正常恢复保持 URI、方法与意图不变，同时更换连接上下文。

即便新连接最终仍通往同一 IP，并看到同一张证书，它仍可能携带目标源自己的 SNI，从而选择不同的前端规则或后端服务。这正说明“另一条连接”不是形式主义，而是可能改变权威落点的操作。

421 不是换了名字的重定向

重定向让客户端考虑另一个目标，通常用 Location 提供新的 URI。421 不这样做。它没有声明内容在别处，也没有把选择新资源的权力交给响应方。

客户端要做的是把同一目标交给另一个连接上下文，而不是改变请求想表达的对象。这个区分保护了缓存键、凭证范围、审计记录和应用语义。如果运营者用重定向掩盖连接路由不一致，可能暴露内部名称，跨越凭证边界，或让一个配置错误看起来像正常迁移。

421 也不是 400 Bad Request：消息完全可能语法正确。它不是 403 Forbidden：核心事实不是用户对资源缺少权限。它更不是 TLS 告警：TLS 可能恰好已经按证书规则成功。

窄状态码的价值，在于不让某一层的错误词汇越权解释另一层的问题。

ORIGIN 把部分否定从事后移到事前

421 的纠错要付出一个往返：先发送请求，得到拒绝，再选另一条连接。2018 年 3 月发布的 RFC 8336 因此为 HTTP/2 定义 ORIGIN 帧，让服务端提前说明一条连接可以用于哪些源。

该扩展把一条连接对应的源集合称为 Origin Set。集合一旦初始化，支持扩展的客户端不得再把集合之外的源视为该连接的权威对象。条目必须写出具体源，不支持通配符；因此，一张通配符证书不会自动变成一份无限扩张的连接声明。

ORIGIN 描述的是一条连接的属性，所以按跳处理。中间节点不得转发该帧，配置为使用代理的客户端也要忽略从代理收到的 ORIGIN。服务端可以用后续帧增添源，但证书校验依然不可省略。ORIGIN 是部署意图信号，不是新凭证。

RFC 8336 还规定：支持该机制的客户端收到 421 后，必须把相应源从这条连接的 Origin Set 中删除。一次否定由此改变后续连接选择，而不是作为孤立错误被遗忘。

正确的记忆键是“源加连接”。全局屏蔽该源会从局部错误中学得过多；完全不记忆则会不断重复同一次失败。

替代服务提供另一条路，但不自行创造权威

Alt-Svc 允许一个源声明可由另一个主机、端口或协议端点提供等价服务。它给客户端新的路由选择，却不意味着普通权威检查失效。

RFC 8336 明确指出，替代服务广告不会改变 Origin Set。RFC 9110 虽允许客户端在 421 后经替代服务重试，但新连接仍要满足目标源所需的身份、配置和连接上下文要求。

这一限制防止便利信号彼此循环作证。证书支持身份认证，DNS 支持端点判断，Alt-Svc 提名替代端点，ORIGIN 描述一条连接预期服务的源；没有任何一个信号可以单独证明其余全部结论。若组合后的实际上下文仍然不合适，421 保留最后的窄否决。

互联网的互操作性并不要求所有参与者服从一个总判断。它要求每项证据只承担自己能够证明的那部分。

HTTP/3 换了传输，仍然留下 421

现行的 RFC 9113 取代 RFC 7540，继续保留 HTTP/2 的跨源连接复用与 421。RFC 9114 则把 HTTP 带到 QUIC 上，并继续使用同一状态。

HTTP/3 不再建立 TCP 连接，但仍保持持久连接，也允许一条连接承载不同 URI 权威部分的请求。客户端要为新源复用现有连接，必须校验服务端证书是否适用于该源；证书不合格时，复用被禁止。即使证书合格，服务端若不愿让某个源使用这条 HTTP/3 连接，仍可返回 421。

这段延续说明了机制的历史价值。421 最初诞生于 HTTP/2，后来进入与版本无关的 HTTP 语义，又被 HTTP/3 采用。真正的难题不是 TCP，也不是某一种帧格式；只要多个命名权威可以共享高效连接，而接收方持有发送方看不到的服务上下文，边界就会再次出现。

传输可以更换，谁有权替某个源回答的问题不会因此消失。

观测对象应是失败的关系，而不只是错误总数

单独统计 421 次数，无法解释系统发生了什么。运维证据必须沿着那条被拒绝的边展开：目标的 scheme、host 与 port，请求方法，连接与流标识，HTTP 版本，远端端点，SNI、ALPN、证书身份集合，用于复用决策的 DNS 结果，Alt-Svc 来源，Origin Set，所选前端与后端，发出 421 的角色，以及重试是否换了连接。

新旧路径的比较尤其重要。若共享连接返回 421，而以目标源单独建立的连接成功，连接上下文选择就是首要解释。若两者都返回 421，问题更可能是源整体未配置或配置错误。若只在某个区域或某次发布后出现，则证书、DNS、ORIGIN、替代服务与后端部署之间可能发生了不同步。

健康系统不一定从不出现 421。一次 421 可能恰恰表示服务端正确拒绝了客户端的乐观推断。真正的危险是拒绝不能收敛：客户端在原连接上重试，多个层互相指责，或共享证书长期掩盖服务图分裂。

否定一项优化，不等于反对共享

连接合并减少握手、状态与调度成本，是有真实价值的工程选择。421 没有要求每个源永远独占连接，也没有把任何暂时差异都解释为安全事件。

它做的是更薄的工作：允许客户端依据现有证据作一次可撤回的性能决策；允许掌握内部配置事实的接收方拒绝某个源与连接的组合；允许客户端保持请求含义，再选择一个可重新核验的上下文。

没有这个否定能力，成功握手很容易被升级为永久授权。一条首先为甲建立的连接，会因为证书也包含乙而逐渐被当作乙的当然入口；共享基础设施从节省成本的手段，变成替多个源决定服务边界的中心。

现行的 IANA HTTP 状态码注册表 将 421 登记为 Misdirected Request，并指向 RFC 9110。登记固定了可互操作的名称与规范来源，却不证明它在现实中的出现频率、所有客户端都会重试，也不替任何具体部署证明源边界配置正确。

421 防止这项优化硬化为统治关系。连接可以共享，判断权仍然分布在各自掌握事实的边界。

连接是真的，它的委任不是

收到 421 时，最容易做出的错误判断是“这条连接坏了”或“这个源坏了”。两者都可能仍然正常。

同一条连接可以继续为青色的第一个源服务。被拒绝的第二个源也可以经专用连接正常回答。失败的，是把第二个源委托给第一条连接这一命题。

HTTP 通过一个状态码，把对象、路径和权威拆开记录。它没有让性能推断消失，而是让推断在遇到更接近事实的一方时可以撤回。

这正是 421 留下的历史教训：抵达一个能够展示正确凭证的端点，还不等于获得了代表每个名称发言的授权。共享通道可以很宽，权威声明仍应当很窄。