网站接入 CDN 后出现 421 Misdirected Request，可以从一次失败请求查起：请求访问哪个域名、TLS 握手用了哪个名字、最终交给哪个虚拟主机。域名解析正常、证书也没过期，仍可能在这几个名字的匹配关系上出错。

HTTP 标准把 421 用于拒绝目标 URI 与服务器所负责的源、或当前连接上下文不匹配的请求。它与普通页面不存在、TLS 握手直接失败的含义不同。RFC 9110 还区分源服务器、代表源站工作的网关与普通代理的职责，不能笼统地把所有中间层都当作 421 的生成者。[1]

下面按受影响的一跳定位问题。文中的域名、IP 和配置都是示例，需要替换为自己的环境；本文未对生产站点进行故障复现或性能测试。

先确定失败发生在哪一段连接

一次经过 CDN 的访问至少涉及浏览器到边缘节点、边缘节点到源站两段连接。源站前如果还有负载均衡或反向代理，应继续拆开观察。浏览器拿到 421，不足以判断是哪段配置不匹配。

保存失败时间、完整 URL、状态码、响应正文和可关联的请求 ID，再对照边缘日志与源站日志。分享记录时隐藏 Cookie、访问令牌和个人信息。

源站没有日志也可能是查错节点、日志延迟或请求在更前面的负载均衡处被拒绝。结合请求 ID 和时间窗口交叉核对，避免仅凭响应中的 Server 字段下结论。

将回源地址、Host 和 SNI 分别列出来

排查时可以给同一次回源做一张配置记录。

示例中的回源 IP 来自文档保留地址，不能用于真实访问。用户域名和回源域名也不要求在所有架构中完全相同；需要确认的是，这组域名、证书和虚拟主机能够按预期共同工作。

常见遗漏是只改了 HTTP Host，TLS SNI 仍使用旧域名或连接池名称。证书包含某个域名，也不等于源站应用已经允许该 Host。逐项查看 CDN 当前生效配置，并检查是否仍有旧节点或中间代理沿用旧值。

用正确的域名访问指定源站

从浏览器复制失败 URL 后，可以先通过 CDN 发起一次受控 GET，保存响应状态、头和正文。以下命令适用于安装 curl 的 Linux、macOS 或 WSL；Windows PowerShell 可使用 curl.exe 并调整换行写法。

curl --silent --show-error \
  --connect-timeout 5 --max-time 20 \
  --dump-header edge-headers.txt \
  --output edge-body.txt \
  --write-out 'status=%{http_code} ip=%{remote_ip}\n' \
  'https://www.example.com/health-check'

将路径替换为团队允许诊断的只读资源。这个命令不自动跟随跳转，也不自动重试。命令行与浏览器如果使用不同身份或请求头，结果需要分别解释。

为了检查指定源站，可以在已有授权和网络通路内使用 --resolve。假设源站按 origin.example.com 提供服务：

curl --silent --show-error \
  --connect-timeout 5 --max-time 20 \
  --resolve 'origin.example.com:443:192.0.2.20' \
  --dump-header origin-headers.txt \
  --output origin-body.txt \
  --write-out 'status=%{http_code} ip=%{remote_ip}\n' \
  'https://origin.example.com/health-check'

--resolve 把指定域名和端口映射到测试 IP，URL 仍保留域名。curl 官方手册也说明，--connect-to 只改变连接目标，不会相应改变 TLS SNI、证书校验或应用协议使用的名字。选择测试参数时应明确自己改变的是哪一项。[3]

不要用 https://源站IP/ 再补一个 Host 头来替代完整的域名测试，那样未必复现原来的 TLS 身份。也不要加入 -k 忽略证书校验。私有 CA 环境应通过 --cacert 指定团队认可的证书包。

源站有访问白名单、双向 TLS 或 CDN 专用鉴权时，应使用已有诊断入口。为了测试而临时公开源站，容易扩大暴露范围。

Nginx 反向代理中分别设置 Host 与 TLS 名称

如果自己管理的 Nginx 位于回源链路上，可以核对 proxy_set_header Host、proxy_ssl_server_name 和 proxy_ssl_name。官方文档分别规定了 HTTP Host 的设置、是否发送 SNI，以及证书校验和 SNI 使用的名称；其中发送 SNI 默认关闭，proxy_ssl_name 默认取 $proxy_host。[2]

下面示例用于支持这些指令的 Nginx HTTPS 反向代理。假设源站证书覆盖 origin.example.com，源站虚拟主机也接受该域名。upstream 放在已有 http 上下文，location 放在已有 server 中，两段内容并非完整配置文件。

# http 上下文
upstream origin_pool {
    server 192.0.2.20:443;
}

# 已有 server 内
location / {
    proxy_pass https://origin_pool;
    proxy_set_header Host origin.example.com;

    proxy_ssl_server_name on;
    proxy_ssl_name origin.example.com;
    proxy_ssl_verify on;
    proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
}

证书包路径示例按 Debian/Ubuntu 常见布局给出，其他发行版应使用实际存在的可信 CA 文件。私有 CA、验证链深度、上游端口及客户端证书按团队要求配置。修改前备份相关配置，运行 nginx -t，通过后再按现有服务管理流程重载；出现回归时恢复备份并重新验证。

此处把回源 Host 和 SNI 都固定为团队控制的源站域名，便于检查身份链。业务确实需要透传用户域名时，应让源站证书、站点绑定和路由一起支持该域名。不要把任意客户端输入直接当作新的回源目标。

托管 CDN 需要在厂商提供的回源设置中完成对应配置，不能把这段 Nginx 代码直接粘到控制台。不同服务的软件版本、域名校验和连接池行为可能不同，Host/SNI 不一致也不一定都返回 421；还可能表现为其他 HTTP 错误或握手失败。

检查边缘入口限制与连接复用

某些 421 发生在用户到边缘的入口。以 CloudFront 为例，官方文档说明它会检查 SNI 与 Host 的关系、证书所属账户及证书对请求 Host 的覆盖情况，并在不符合其跨账户域名前置保护条件时拒绝请求。具体判断规则应以该产品文档为准，不能简化为任何两个名字不同都被拦截。[4]

因此，排查边缘入口时要查看访问域名是否绑定到正确分配、证书是否覆盖域名，以及自定义客户端是否把 URL 域名和 Host 改成了不同目标。仅把域名解析到一个边缘 IP，不足以完成站点绑定。

如果故障只在复用连接时出现，可继续检查跨域连接复用和服务端限制。HTTP 标准允许客户端收到 421 后尝试另一条连接；重新建连后的结果可用作定位证据，但不能代替修复不匹配的配置。[1]

诊断时比较同一个 URL 在新连接和既有连接上的表现，记录协议和关联域名。只在受控客户端中临时对比 HTTP/1.1 与 HTTP/2，且要注意 curl 构建是否支持对应协议。浏览器与边缘之间的协议，与边缘回源协议应分别记录。一次 --http1.1 成功，不能证明永久关闭 HTTP/2 就是合适的解决方案。

修复后检查相同请求和其他虚拟主机

修改后，先验证原来失败的 URL，再检查同源的其他域名及必要资源。对照日志确认请求进入预期虚拟主机，证书校验通过，返回的正文也属于正确站点。

随后复测新连接和既有会话；如果有多个回源节点，检查各节点配置是否一致。回源 IP、Host 或 SNI 的变更还可能影响健康检查、应用跳转和 Cookie 域，应按业务路径一并验证。

如果团队确认边缘保留了旧错误响应，再按厂商支持的范围刷新受影响对象。缓存刷新无法修复持续存在的身份错配，全站清缓存也不应成为第一步。

保留故障请求 ID、访问域名、回源身份、实际命中的虚拟主机和修复结果。后续更换证书、回源地址或连接池配置时，用同一组检查项复核，能减少重复排查。

官方参考资料

资料核验日期：2026 年 10 月 19 日。

1. RFC 9110：421 Misdirected Request

2. Nginx：HTTP proxy 模块，Host 与上游 TLS 指令

3. curl 官方手册：--resolve 与 --connect-to

4. Amazon CloudFront：备用域名限制与 Domain fronting