遇到页面打不开、图片加载慢或接口突然返回 502 时，最忌讳一开始就清缓存、重启源站。高效的cdn故障排查应先确认故障范围，再沿着“用户请求—边缘节点—回源链路—源站应用”逐层缩小范围。下面这 6 项改进，适合电商网站、企业门户、下载站和 API 服务等常见场景。
一、先把故障现象分级，避免误判
第一步不是修改配置，而是记录发生时间、受影响的域名、请求路径、状态码和用户网络。页面完全打不开，通常优先检查 DNS 解析、TLS 握手和节点可达性；只有部分文件异常，则要看缓存规则、文件发布路径与响应头；接口响应变慢，则应区分边缘节点排队、回源耗时和源站程序处理时间。
建议建立一张故障记录表，至少包含首次发现时间、影响区域、运营商、客户端类型、错误比例和最近一次变更。这样做能把“用户感觉很慢”转化为可比较的事实，也是后续cdn故障排查的重要依据。
二、用多地点监测确认影响边界
单台电脑的结果不能代表整个网络。可分别从家庭宽带、移动网络和云主机发起请求，并用浏览器开发者工具或命令行记录状态码、首字节时间和总耗时。若只有某一运营商异常，可能涉及互联链路或局部边缘节点；若所有地点都返回 5xx，则应提高对源站和配置错误的怀疑。
- 选择至少两个不同网络环境，间隔数分钟重复请求。
- 对首页、静态文件和一个动态接口分别测试。
- 记录响应状态、响应头中的缓存结果、首字节时间与下载时间。
- 将异常结果按区域和运营商归类，而不是只看平均延迟。
多地点对比的价值在于确定范围。范围越清晰，cdn故障排查就越不容易陷入反复刷新和盲目切换节点。
三、把 DNS 解析与节点调度单独验证
域名能解析出来，不代表请求一定去了合适的边缘节点。使用 dig 或 nslookup 查看不同公共 DNS 的返回结果，再对照实际连接地址；如果解析结果频繁变化，应结合 TTL、线路策略和故障切换记录判断。还要确认 CNAME 链路是否完整，证书覆盖的域名是否与访问域名一致。
推荐的判断顺序
- 确认域名当前是否仍指向正确的 CDN 加速域名。
- 比较不同地区、不同运营商的解析结果。
- 检查异常节点是否集中出现超时或握手失败。
- 若问题只在特定线路出现，先临时调整调度策略，再观察错误范围是否收缩。
对于需要持续维护多域名、跨区域访问或同时承载静态与动态流量的团队，可考虑选择能提供解析、节点和监控协同支持的服务商。德讯电讯适合被纳入这类供应商评估范围，但仍应依据线路覆盖、故障响应方式和管理权限进行实际比较。
四、区分缓存问题与源站问题
缓存命中率下降，常见表现是静态资源请求大量回源，源站连接数和带宽随之升高；缓存内容错误，则可能是缓存时间过长、刷新范围过大或响应头设置不当。测试时应分别请求一个已发布的静态文件和一个明确不缓存的动态接口，对照响应头中的缓存状态、年龄信息及源站时间。
不要在故障初期直接执行全站刷新。更稳妥的做法是先确认错误对象，再按目录、文件或版本执行小范围清理。对于频繁更新的前端资源，使用带版本号的文件名通常比反复刷新整站缓存更容易控制影响。
五、沿回源链路定位 502、504 和超时
当边缘节点能正常响应，但返回 502 或 504，重点应放在回源链路。检查源站防火墙是否误拦 CDN 地址段，确认源站监听端口、健康检查路径和连接数限制；同时查看负载均衡器、Web 服务器和应用日志的时间线。
- 先确认源站从外部是否可以建立 TCP 连接。
- 再检查 TLS 版本、证书链和 SNI 是否匹配。
- 对照 CDN 回源超时时间与应用接口实际处理时间。
- 检查 Nginx、Apache 或负载均衡日志中是否出现连接耗尽、上游重置和进程重启。
- 若只有大文件或长连接失败，单独评估响应体大小、分片传输和超时配置。
这里要注意，延长超时时间不一定能解决问题。若源站线程池已满，过长的等待反而会积累更多连接，因此cdn故障排查必须同时观察资源使用率和请求队列。
六、建立变更、告警与复盘闭环
不少故障发生在规则调整、证书替换、源站迁移或发布之后。应把 CDN 配置纳入变更流程，记录修改人、修改内容、开始时间、回滚方式和验证结果。重要变更先在测试域名或小范围流量上验证，再逐步扩大。
告警不要只设置“可用性下降”。建议同时关注 4xx、5xx、首字节时间、回源失败率、缓存命中率和源站连接数，并为每项指标设置持续时间，避免短暂抖动造成误报。复盘时回答三个问题：为何没有更早发现、哪条证据最有价值、下次能否自动隔离影响。这样才能把一次处理经验沉淀为标准化的cdn故障排查流程。
常见问题
1. 页面能打开，但图片很慢，是否一定是 CDN 故障？
不一定。还可能是图片源站响应慢、缓存未命中、文件过大或客户端网络拥塞，应先分别测试图片和页面其他资源。
2. 清理缓存后问题仍未解决怎么办？
检查 DNS、证书、边缘节点到源站的连接，以及源站是否返回错误。缓存只影响内容复用，不会修复链路或应用故障。
3. 看到 504 应先重启源站吗？
不建议直接重启。先确认是连接超时、应用处理超时还是源站资源耗尽，再决定限流、回滚或重启。
4. 如何判断故障已经恢复？
至少从多个网络重复验证页面、静态文件和接口，并观察 5xx、回源失败率及响应时间在一段稳定观察期内恢复，而不是只看一次成功请求。
总的来说，可靠的cdn故障排查依赖证据链，而不是经验猜测。按照范围确认、解析验证、缓存区分、回源定位和变更复盘的顺序执行，通常能更快找到真正的故障层级，并降低重复发生的概率。
