CDN 的解析链路长什么样
接入 CDN 的域名通常不直接返回源站地址，而是先 CNAME 到厂商的调度域名，再由厂商的全局负载均衡按访问者的地域、运营商和节点健康度返回一台就近边缘节点的地址。链路上可能还有多级 CNAME，任何一跳异常或调度返回错误地域，现象都是「解析到不合适的节点」甚至超时。因此排查思路是逐跳验证整条链，而不是只看最终那个 A 记录。
基本信息
| 接入方式 | CNAME 接入最常见，NS 接入把整区交给厂商 |
|---|---|
| 链路特征 | 多级 CNAME，TTL 通常很短（几十秒），便于快速调度 |
| 调度依据 | 地域、运营商、节点负载与健康状态 |
| 影响调度的因素 | 递归位置与 EDNS 客户端子网信息 |
| 排查工具 | dig 的 +short、+trace 与指定服务器查询 |
典型使用场景
- 用户反馈访问到错误地域：确认调度结果与预期节点范围是否一致
- 切换 CDN 厂商后仍解析到旧节点：核对 CNAME 链与本地缓存
- 回源异常：先直连源站验证，再判断是回源配置还是边缘问题
- 对比不同解析器结果：观察是否存在调度差异与解析污染
- 验证证书与 SNI：确认回源域名与证书匹配
追踪 CNAME 链
追踪 CNAME 链
dig +short www.example.com CNAME # 一级别名
dig +short www.example.com # 完整链加最终 A 记录
dig +trace www.example.com | tail -30 # 看调度在哪一层发生变化
dig +short www.example.com @8.8.8.8 # 与本地结果对比，观察调度差异
dig +short www.example.com @223.5.5.5 # 换国内公共 DNS 再比一次
curl -sS -o /dev/null -w '%{remote_ip}\n' https://www.example.com/ # 实际连接到的节点排查点与判据
| 排查点 | 判据 | 处置 |
|---|---|---|
| CNAME 链是否完整 | 末端能解析出 A 或 AAAA | 修正别名配置或等待 TTL 生效 |
| 调度地域是否正确 | 返回节点归属与访问者地域一致 | 核对调度策略与源站分组 |
| 节点是否健康 | 连接成功率与首字节耗时正常 | 向 CDN 厂商提工单并附证据 |
| 源站是否可用 | 直连源站带 Host 头能正常响应 | 修源站，而不是继续查 DNS |
| 本地缓存是否陈旧 | 清缓存后结果变化 | 核对 TTL 与终端缓存策略 |
CDN 常见排查点：源站回源是否正常（用 curl 指定 Host 直连源站）、调度是否给到了错误地域、边缘节点本机缓存是否命中；用不同网段的递归服务器查询可以观察调度变化。
CDN 的 TTL 通常很短，切换后仍访问到旧节点，多半是本地或运营商递归的缓存未过期，也可能是长连接与连接池仍指向旧地址。