CDN 源站路由

CDN 路由包含两个独立决策：客户端连接到哪里，以及边缘节点联系哪个源站。 DNS 和任播选择边缘位置；该边缘位置的配置选择源站并构造上游请求。 将这两个决策分开，可以更容易诊断故障。

边缘节点的请求身份 #

客户端从类似 https://www.example.com/docs 的 URL 开始。DNS 返回边缘地址， TLS SNI 在握手期间标识 www.example.com，HTTP 请求携带 Host: www.example.com（HTTP/2 和 HTTP/3 中则携带等价的 :authority 字段）。 CDN 使用该主机名和路径选择分发配置及缓存行为。

单独的 IP 地址不是源站身份。共享反向代理会在一个地址上托管多个域名，因此直接测试必须包含 预期的主机名：

curl --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/health

--resolve 在选择特定地址的同时保留 URL 主机名，以供 SNI 和 HTTP 使用。 相比只手动提供标头并发送原始 IP URL，这种方式更安全，也更接近实际情况。

转发正确的上游主机 #

源站可能使用传入主机选择虚拟主机、生成重定向或应用租户策略。 CDN 可以保留访问者主机、将其替换为源站主机名，或转发配置的值。应有意选择一种方案：

viewer:  https://www.example.com/account
edge:    GET /account  Host: origin.internal.example.net
origin:  routes by Host and returns a response

如果源站 TLS 证书包含 origin.internal.example.net，CDN 应使用该名称进行上游 SNI 和证书验证。源站需要时仍可将 www.example.com 作为 HTTP Host 转发， 但不应因此削弱 TLS 验证。

避免路由和缓存意外 #

保持缓存键、源站选择规则和转发标头一致。如果 /api/* 发送到 API 源站而 /* 发送到对象存储， 应让更具体的规则优先。只有当租户或区域改变响应时，才将其加入缓存键；更清晰时可使用独立主机名 或行为。

保护源站免受直接流量影响，记录访问者和上游请求 ID，并通过 CDN 测试重定向、WebSocket、 健康检查和错误路径。内部网络中可用的源站仍可能在边缘失败，因为 DNS、SNI、防火墙或转发主机存在差异。