CDN 故障排查的流程是什么？有哪些常用工具？

直接回答

CDN 故障排查的核心流程：确认范围 → 检查DNS → 检查网络连通性 → 检查缓存状态 → 检查源站 → 定位修复。

第一步，确认故障范围。 问三个问题：是全量用户还是部分地域？是持续报错还是间歇性？是从什么时候开始的？范围判断决定后续排查方向——全局故障看CDN节点和DNS，局部故障看网络链路和缓存。

第二步，检查DNS解析。 CDN 依赖 DNS 将用户调度到最近的边缘节点，DNS 出问题一切白搭。用 dig 或 nslookup 确认域名是否正确解析到 CDN CNAME，检查不同地域 DNS 服务器的解析结果是否一致。常见坑：DNS 缓存未更新导致调度到已下线节点。

第三步，检查网络连通性。 ping 看延迟，traceroute 或 mtr 看链路丢包，curl -v 看 HTTP 握手各阶段耗时。重点关注 SSL 握手时间——如果证书链不完整或配置错误，握手会失败或变慢。

第四步，检查缓存状态。 看响应头里的 X-Cache 字段，HIT 还是 MISS。缓存命中率骤降是最常见的性能劣化原因。排查缓存键配置是否合理、TTL 是否过长导致内容不更新、是否有绕过缓存的请求头。

第五步，检查源站。 绕过 CDN 直接访问源站，如果源站也慢，问题在源站不在CDN。看源站负载、响应时间、错误日志。

核心工具速查

场景	工具	用法
DNS排查	dig/nslookup	dig @8.8.8.8 example.com
网络延迟	ping/mtr	mtr -r -c 10 cdn.example.com
HTTP调试	curl	curl -w "@format.txt" -o /dev/null -s URL
SSL检查	openssl	openssl s_client -connect host:443
缓存分析	日志+响应头	grep "X-Cache" access.log | sort | uniq -c
日志分析	ELK Stack	Kibana 看错误率趋势和地域分布

bash
# curl 计时模板 curl-format.txt
time_namelookup:  %{time_namelookup}

time_connect:  %{time_connect}

time_starttransfer:  %{time_starttransfer}

time_total:  %{time_total}

追问：缓存刷新后用户仍看到旧内容怎么办？

先确认刷新是否生效——用 curl -I 检查响应头的 X-Cache 和 Last-Modified。如果刷新成功但用户仍看到旧内容，三个可能：本地浏览器缓存、中间运营商缓存、多CDN节点同步延迟。对应措施：版本化URL（app.js?v=2）、缩短TTL、检查CDN供应商的刷新接口是否覆盖全部节点。

追问：如何预防CDN故障？

三件事：监控告警（节点可用性、缓存命中率、错误率）、健康检查（定时探测各节点）、容灾预案（多CDN切换、源站冗余、DNS快速切流量）。面试中能讲出"监控+容灾"两条线，基本过关。