CDN监控里状态码分布是排查回源失败的第一入口，绝大多数回源故障都会先在状态码占比突变上露出痕迹，学会读状态码分布，等于拿到了回源问题的诊断地图。
CDN的监控面板每天跳出大量数据,很多人盯着“总请求量”“带宽峰值”看半天，唯独忽略了状态码分布，状态码分布不是给你欣赏的，它是回源链路的体检报告，请求到了CDN节点，回源失败，节点会替源站返回一个错误码，这个错误码是节点替你写的“病历本”，每一行都指向病因。
状态码分布到底怎么读才有意义
只看总状态码占比没有价值,因为这相当于用平均体温掩盖了正在发烧的那根手指，正确的读法是把状态码分布放在三个维度里拆开看。
第一个维度：按节点聚合。 同一个源站，有的节点回源正常，有的节点大面积报错，问题往往出在节点与源站之间的网络链路或节点本身，如果所有节点同时报错，那问题基本锁定在源站或源站的上游出口。
第二个维度：按时间切片。 把状态码分布图切成5分钟一个粒度，观察异常码是从哪个时间点开始抬头的，是流量高峰压垮了源站，还是源站发布新版本之后开始报错，时间点和变更记录一对就能确认方向。
第三个维度：和命中率叠加对比。 业内专家指出，回源失败和缓存命中率是一对因果链，某一状态码激增的同时命中率同步跳水，说明大量请求穿透到源站，源站已经承受不住或正在拒绝服务，先看命中率再判断状态码，能少走一半弯路。
把监控粒度细化到省份和运营商同样关键,某省的回源链路质量差，会导致该省的请求长时间拿不到资源，反映在高比例的超时类状态码上，而其他省份状态码平滑如常，这种情况不该动源站，该找的是那条线路的运营商或CDN厂商做链路调优。
回源失败会伪装成哪几种状态码
很多人一看到502就慌,一看到504就以为是源站挂了，实际上两者代表的是完全不同的故障环节。
502和504的真实区别
502 Bad Gateway的意思是CDN节点作为网关已经和源站建立了连接，但源站返回了非法响应，或者连接建立后源站主动断掉，通俗点说，门敲开了，对面递出来一个空箱子。
504 Gateway Timeout的意思是CDN节点在规定时间内没等到源站的响应，源站可能活着，但处理太慢，一个请求卡在数据库查询或慢接口上，节点等到不耐烦就替源站宣布超时。
| 常见状态码 | 节点与源站连接 | 故障偏向 |
|---|---|---|
| 502 | 已建立 | 源站应用异常、请求头异常、源站主动断开 |
| 504 | 建立中/已建立但超时 | 源站慢、负载高、网络丢包 |
| 521 | 连接被拒绝 | 源站端口未监听、防火墙拦截 |
| 523 | 无法建立连接 | 源站宕机、DNS解析失败、路由不通 |
| 524 | 连接超时 | 源站处理请求超过节点等待上限 |
很多CDN厂商还有自定义状态码,比如521是Cloudflare特定的“源站拒连”，523是“源站不可达”，524是“源站超时”，这些码虽然不是标准HTTP定义，但在CDN监控里出现频率极高，排查逻辑和502、504一脉相承。
4xx也可能是回源惹的祸
回源失败不只有5xx一种形态,源站返回403，CDN节点原样透传，监控面板上就出现了403的比例突增，有人天真地以为是访问者触发了源站WAF规则，其实可能是回源IP被源站的安全策略封了，源站限流、防盗链校验、鉴权参数过期，都会让节点背回来一个4xx，行业共识认为，凡是涉及回源链路的状态码异常，排查顺序永远是先验证源站直接访问是否复现，再谈CDN策略调整。
一套可落地的回源失败排查路径
第一步，锁死时间窗和范围。
状态码分布的横坐标是时间，纵坐标是占比，先看异常持续时间跨了多久，再看分布范围是某个单节点还是全国节点，在CDN控制台的“节点监控”或“边缘日志”里筛选异常节点，能直接拿到节点IP、源站IP和请求域名。
第二步，验证源站当前状态。 绕过CDN，直接请求源站域名，用curl加上源站HOST头，模拟CDN回源时的请求格式，如果直接请求源站同样报错，问题基本不在CDN侧，先处理源站自身的应用或网络故障。
curl -I http://源站IP -H "Host: www.example.com"
第三步，把回源链路拆成三段查。 第一段是源站本地健康状态，用ss -lntp查端口监听，用top看负载，第二段是源站到公网的出口质量，从源站上ping一下CDN节点的IP或对端PoP，第三段是网络路由，用traceroute看经过的每一跳，重点观察是否有较高的延迟跳变或大比例丢包点。
第四步，翻回源日志的响应时间。 很多CDN厂商的日志里有回源耗时这个字段，它记录了节点发出回源请求到收到源站响应头的时间差，正常情况这个耗时在几十到几百毫秒，如果回源耗时从300毫秒突然飙升到5秒，不管状态码有没有变化，源站的处理能力已经出现瓶颈。
第五步，检查回源HOST配置。 回源HOST错了，会导致源站返回403或404，源站接收请求时靠HOST字段识别域名，虚拟主机要匹配对应的ServerName，稍微折腾一下，把回源HOST改成镜像站域名或默认站点，故障瞬间消失的情况每年都在发生。
哪些日常操作能降低回源失败频率
源站健康检查一定要开着,CDN厂商的监控告警里一般有源站探活功能，用HEAD请求定期探测源站存活，频率不要设太低，建议15秒到30秒探测一次，当源站异常时，CDN节点自动把请求切到备用源站或临时缓存，用户侧无感。
备用源站不是摆设,主备切换的时间越短，状态码分布里的异常占比就越低，自己搭不了备源站的，可以配对象存储当兜底，主要静态资源提前同步一份，动态请求回主源站，分流效果明显。
监控告警别只盯总量,单节点状态码占比超过整体均值太多时，也需要单独拉出告警，这类告警不需要通知值班同学深夜爬起来，但要在第二天早上出现在汇报列表里。
关于CDN状态码和回源失败最常见的三个疑问
Q1：监控里502突然增多，怎么排查？
先看502增长范围,全国节点同时涨，直接检查源站应用日志、连接数、请求处理线程，大概率是源站扛不住，单节点或单区域涨，先联系CDN厂商确认是否节点升级或网络割接，同步检查源站防火墙和解封策略，确认没有把CDN回源IP段封掉，查找节点IP、源站连通性、回源HOST，这三步做完基本可以定位。
Q2：回源失败会影响网站打开速度吗？
分情况,节点有缓存时，用户请求直接命中边缘缓存，回源失败对用户无感知，缓存过期后恰好回源失败，用户会收到5xx错误页，感知速度从“秒开”直接变成“打不开”，如果只是部分请求回源失败，站点还能打开，但TTFB会明显变长，因为这部分请求经历了连接重建、超时等待等一连串补救动作。
Q3：502、504、523同时出现要不要一起处理？
三个码同时出现说明源站整体处于不可用或半不可用状态,521和523指向源站网络和端口层，502指向应用层，504指向响应慢，看起来码多，动作就一个：按顺序排查源站网络的连通性、端口监听状态、应用进程健康度，这三个码同时出现的情况下，CDN侧能做的抵抗非常有限，最多靠缓存扛一阵，源站恢复才是根治办法。
状态码分布不会说谎,回源失败也从不随机发生，每一次异常都对应一个明确的故障环节，要么源站委了，要么链路断了，要么配置错了，顺着状态码的变化方向一路追，回源问题总会现出原形。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/644039.html
