1. 题目与适用场景
一个多租户 HTTPS API 通过 HTTP/2 连接复用多个域名。某些请求偶发收到 421，团队想在应用控制器中统一改成 503。请判断 421 的语义，解释 SNI 与 Host 的关系，并设计网关、源站、客户端和可观测性方案。假设请求可能经过 CDN、反向代理和服务网格。
2. 面试官考察点
- 是否知道 421 表示请求到达了无法或不愿为目标 URI 提供权威响应的源站。
- 是否能把连接复用、TLS SNI、请求 Host、scheme 与 authority 放进同一条诊断链。
- 是否理解代理不能凭自身判断生成 421，以及客户端应换连接后再谨慎重试。
- 是否能区分 421、421 上游故障、404、503 与证书配置错误，避免只改状态码。
3. 回答前需要澄清的问题
- 421 是由源站、网关、CDN 还是应用直接生成的？
- 请求使用 HTTP/2 或 HTTP/3 吗？同一连接是否承载多个 authority？
- TLS 握手中的 SNI、HTTP Host 和最终路由到的虚拟主机分别是什么？
- 客户端是否能建立目标域名专用的新连接，方法是否幂等，是否已经产生副作用？
4. 30 秒回答框架
421 表示源站认为请求被错误地导向了当前连接或虚拟主机，例如连接证书与目标 authority 的组合不适用。先在 TLS、连接池、代理路由和源站虚拟主机层定位 SNI、Host、scheme 与 authority 的不一致，不要把它改写成 503。源站可以返回 421，代理不能凭自身生成它；客户端可在新连接上重试，但要遵守方法幂等性、请求体重放和退避规则。日志要关联连接 ID、SNI、authority、路由和重试结果。
5. 分步骤深入解答
第一步：界定 421 的责任边界
RFC 9110 将 421 定义为源站拒绝请求，因为目标 URI 看起来被错误导向。它可能是不匹配的源站配置，也可能是不适合当前连接上下文的请求。应用层不应把任意上游超时、DNS 错误或证书过期映射成 421；这些问题要保留各自的错误语义。
第二步：重建一次请求的连接上下文
TLS 握手阶段的 SNI 用于选择证书和虚拟主机；加密连接建立后，请求携带的 Host 或 authority 决定目标。HTTP/2 允许一条连接承载多个请求，但连接只有在证书、协议和服务器配置都允许时才能安全复用。诊断时记录 SNI、Host、scheme、authority、ALPN、连接建立时间和选中的后端，比较“连接属于谁”和“请求要去哪里”。
TLS SNI: api-a.example
HTTP authority: api-b.example
ALPN: h2
selected virtual host: api-a.example
result: 421 from origin第三步：处理代理、CDN 与服务网格
边缘代理应保留原始 authority、TLS 终止信息和上游连接状态，并避免把不同租户错误地复用到同一上游连接。代理可以转发源站 421，但不能仅因为自身认为路由失败就生成 421；代理应使用自己的 502、503 或路由错误契约。服务网格的连接池键必须包含会影响证书和虚拟主机选择的字段，而不是只按 IP 和端口复用。
第四步：设计客户端重试
规范允许客户端在不同连接上重试 421，包括针对目标 origin 的新连接。重试前要判断方法是否幂等、请求体是否可重放、认证令牌是否仍有效，以及是否已收到部分响应。对 POST 等可能产生副作用的方法，优先使用幂等键或让服务端确认没有执行，再决定是否重试。重试只允许有限次数并记录原因，不能用固定循环掩盖错误配置。
第五步：观测、修复与回归验证
指标应按 SNI、authority、虚拟主机、协议版本和边缘节点统计 421，而不是只看总量。日志保存脱敏后的连接 ID、路由决策、证书指纹、源站响应和客户端是否换连接。修复后用多个域名、同一连接复用和新连接三组测试验证：合法复用不应返回 421；错误连接应稳定返回 421；新连接重试应得到目标服务的最终响应。
6. 高质量示范回答
我会把 421 视为连接上下文或源站权威性不匹配，而不是通用的暂时故障。先关联 TLS SNI、HTTP authority、证书、ALPN、连接池和虚拟主机路由，确认请求是否复用了不适用的连接。源站可以返回 421，代理应转发它而不是凭自身生成。客户端可针对目标 origin 建立新连接后重试，但要检查方法幂等性、请求体重放和幂等键。观测上按域名、协议、节点和连接池维度统计，并用同连接复用与新连接回归测试证明修复有效。
7. 常见错误
- 把 421 统一改成 503 → 丢失连接上下文线索 → 保留 421，并在网关日志中记录 SNI 与 authority。
- 只检查 Host 不看 SNI → 无法解释证书和虚拟主机复用问题 → 同时记录 TLS 和 HTTP 两层目标。
- 让代理随意生成 421 → 违反状态码责任边界 → 代理转发源站 421，自己的路由故障使用明确的 5xx 契约。
- 收到 421 后无条件重试 POST → 可能重复写入 → 先用幂等键或确认未执行，再限制次数和退避。
- 只在单域名单连接测试 → 遗漏 HTTP/2 复用路径 → 加入跨域复用、错误复用和新连接三组回归。
8. 追问及应对
追问一：421 与 503 的区别是什么？
421 指向请求与当前连接或源站权威性的错配，换到目标专用连接可能恢复；503 表示服务暂时无法处理请求，通常与容量、维护或依赖有关。两者的修复路径、重试条件和告警维度不同。
追问二：客户端可以复用旧连接重试吗？
不应继续使用被判定不适用的连接。客户端应针对目标 origin 建立新连接，重新完成 TLS 和协议协商；同时遵守退避、请求体可重放和认证状态要求。
追问三：代理看到 Host 与 SNI 不一致时能否直接返回 421？
不能仅凭代理自身判断生成 421。它应按自身路由契约返回合适错误，或把请求转给源站由源站决定；若确实转发了源站 421，应保留来源信息供排查。
追问四：如何验证连接池修复没有降低性能？
分别测量合法复用、按 authority 分池和错误复用被拒绝三种场景，比较 421 率、握手次数、尾延迟、连接数与 CPU。目标是消除错误复用，同时把新增握手成本控制在可接受的预算内。