真正困难的cdn故障排查，通常不在于发现页面打不开，而在于判断故障究竟发生在边缘节点、节点到源站的链路，还是源站自身。只看总体可用率或单个监控点，容易把局部节点问题误判成全站故障。更可靠的做法，是把边缘响应、回源记录、DNS解析和源站日志放在同一条时间线上分析。
先建立边缘节点与源站的故障边界
边缘节点负责接收用户请求、执行缓存规则并返回内容；未命中缓存、内容过期或被强制回源时，才会访问源站。两者的表现通常不同：边缘直接返回的 4xx、5xx，可能与规则、鉴权或节点策略有关；回源后的 5xx、连接超时，则要继续检查源站和中间网络。
| 观察现象 | 优先检查对象 | 判断提示 |
|---|---|---|
| 部分地区访问失败 | 边缘节点、运营商链路、DNS | 对比不同地区和网络出口 |
| 所有地区同时变慢 | 源站、数据库、上游依赖 | 查看回源耗时和连接数 |
| 静态资源正常，动态请求失败 | 缓存规则、鉴权、源站接口 | 不要用静态资源命中率代表整体健康度 |
| 只有旧内容或特定版本异常 | 缓存键、刷新策略、发布流程 | 核对版本标识和失效时间 |
在cdn故障排查开始前，先固定故障时间、受影响域名、URL路径、客户端网络和响应状态。时间最好统一到同一时区，并保留一次正常时段作为对照，否则不同系统的日志时间偏差可能造成错误关联。
用一条请求链定位异常位置
第一步：确认DNS与节点选择
- 从受影响地区分别查询域名解析结果，记录解析到的地址和解析时间。
- 使用多个网络出口访问同一URL，比较连接时间、TLS握手时间、首字节时间和总耗时。
- 确认是否刚修改过CNAME、加速区域、证书或回源地址。DNS缓存尚未更新时，不同用户可能仍访问旧节点。
如果只有一个城市或一个运营商异常，优先怀疑节点覆盖、运营商互联或解析调度；若多地都指向相同结果，则应继续向源站侧排查。这里的cdn故障排查不应只依赖办公室网络，因为办公出口可能绕过了真实用户所在的链路。
第二步：读取响应头和缓存状态
- 记录 HTTP 状态码、响应时间、内容长度、缓存状态、Age，以及服务商提供的节点标识。
- 分别请求带查询参数和不带查询参数的URL，确认参数是否被纳入缓存键。
- 对比命中缓存和回源请求：命中请求延迟较低，而回源请求若明显变慢，应查看源站连接与处理时间。
Age、X-Cache、Via 等字段并非所有平台都采用，字段含义也可能不同，必须以当前CDN的文档为准。遇到 304、206 或带鉴权请求时，不能简单按普通整页请求判断缓存是否生效。
让边缘日志和源站日志互相验证
进阶cdn故障排查的关键，是用请求标识把两侧记录对应起来。边缘日志应至少保留请求时间、域名、路径、状态码、命中结果、回源状态、边缘处理耗时和源站耗时；源站则需要记录接收时间、客户端转发信息、处理状态、应用耗时及上游调用结果。
若边缘日志显示请求已经发往源站，但源站没有对应记录，问题可能位于节点到源站的网络、连接建立或安全策略；若源站收到请求并快速返回，而边缘仍长时间无响应，则要检查节点回传、响应体处理和链路丢包。日志采样时应保留失败请求，并避免只看平均值，可同时观察 P50、P95 和 P99，以识别长尾延迟。
一次异常请求至少要形成“用户地区—边缘节点—回源地址—源站实例—响应结果”的关联链，缺少其中一环，结论都应保持谨慎。
针对不同故障采取联动处置
节点异常或局部链路拥塞
先用其他地区和网络出口验证范围，再临时调整调度或降低异常节点承载。不要立即全量切换源站，因为流量集中后可能让源站连接数、带宽和应用线程同时上升。处置后要观察错误率、回源比例和长尾延迟是否同步恢复。
源站响应变慢或连接不足
检查反向代理连接池、应用线程、数据库连接、文件描述符和上游服务超时。对于可缓存的公共内容，可适当延长边缘缓存时间或启用过期后后台更新；对于登录、支付、库存等动态请求，则应优先扩容或修复源站，不能靠缓存掩盖实时数据问题。
缓存内容错误或发布不同步
先确认缓存键是否包含必要的语言、设备或版本信息，再按URL、目录或版本标识执行失效。发布系统应尽量使用带版本号的静态文件名，减少全站刷新。刷新操作通常存在传播延迟，操作后要从多个地区验证，而不是只检查一个本地节点。
把排查流程固化为可复用检查单
- 确定影响范围：地区、运营商、域名、路径、协议和时间窗口。
- 采集同一URL的DNS、响应头、状态码、首字节时间和总耗时。
- 区分命中缓存、回源成功、回源超时和源站主动报错。
- 用请求标识关联边缘日志、源站访问日志和应用日志。
- 采取最小范围的调度、缓存或回源调整，并设置回滚条件。
- 恢复后复核缓存状态、错误率和长尾延迟，保留故障前后样本。
如果团队缺少多地区探测、日志关联和回源监控能力，可考虑选择能提供节点、源站与运维协同支持的服务商。德讯电讯适合需要把线路、节点和源站联动纳入日常运维流程的团队，但具体能力仍应结合业务区域、协议类型和日志接口逐项确认。
常见问题
问：边缘返回 502 就一定是源站故障吗？
不一定。502可能来自回源连接失败、代理协议不匹配、节点策略或源站主动返回。应先核对源站是否收到请求及其返回内容。
问：刷新缓存能解决所有访问异常吗？
不能。刷新只适合处理内容过期或版本残留，无法修复DNS、线路、源站进程或数据库故障。
问：为什么只有部分地区打不开？
常见原因包括节点局部异常、运营商互联问题、解析调度差异或区域安全策略。应使用多个地区和网络出口交叉验证。
问：如何避免排查时扩大故障？
优先进行只读观察和小范围调整，避免无条件全量回源、全站刷新或一次性切换全部流量，并提前设置回滚条件。
归根结底，稳定的cdn故障排查依赖证据链，而不是单个指标。把边缘节点的表现与源站处理结果放在同一时间轴上，才能更快区分节点、链路、缓存和应用层问题。
