使用CDN时遇到回源失败如何排查

当CDN罢工时：我是如何揪出回源失败这个”老六”的

上周四凌晨2点，我被刺耳的手机警报声惊醒——公司官网的CDN监控疯狂报警。作为值班工程师，我顶着黑眼圈开始了一场与CDN回源失败的深夜搏斗。今天就把这次实战经历整理成排查指南，希望能帮到遇到同样问题的你。

一、现象确认：真的是回源问题吗？

首先别急着背锅，我习惯先做基础检查：

• 直接curl源站IP（绕过DNS）看是否存活
• 用dig +trace确认DNS解析正常
• 在CDN控制台查看回源状态码（502/504要特别关注）

那次事故中，源站其实响应正常，但CDN边缘节点日志里清一色的502，这就很诡异了。

二、网络层排查：TCP握手那些事儿

祭出我的网络排查三板斧：

# 1. 测试端口连通性
telnet origin-server.com 443
# 2. 检查MTU是否合理
ping -s 1472 -M do origin-server.com
# 3. 抓包看TCP握手
tcpdump -i eth0 host origin-server.com -w /tmp/debug.pcap

结果发现CDN节点到源站的SYN包有去无回。后来才知道，源站防火墙最近升级，把部分CDN厂商的IP段误杀了——这种隐蔽问题最容易让人抓狂。

三、应用层陷阱：Header和证书的坑

如果网络层没问题，就要深挖应用层：

• Host头检查：有些源站Nginx配置了严格域名校验
• SSL证书：CDN回源时用的可能是自签名证书
• 协议版本：遇到过CDN默认用HTTP/1.0回源导致的问题

建议用这个命令模拟CDN回源请求：

curl -H "Host: origin-server.com" 
  -H "X-Forwarded-For: 1.1.1.1" 
  -k https://源站IP/api/health

四、终极武器：CDN日志分析

各大CDN厂商都提供详细日志，关键字段包括：

那次事故最终就是通过日志发现，只有亚太区域的节点回源失败，这才锁定是地域性防火墙策略问题。

五、防患于未然的建议

血泪教训总结：

1. 在CDN配置多源站负载均衡
2. 设置回源超时时间（建议3-5秒）
3. 定期做CDN故障演练（直接禁用边缘节点测试）
4. 监控要区分边缘命中率和回源错误率

凌晨4点终于搞定问题后，我默默在运维手册上加了一条：”任何防火墙策略变更必须同步通知CDN团队”。大家如果有更好的排查技巧，欢迎在评论区交流~