演练中遇到回源异常，第一时间要固定现场证据链，记录完整的请求链路信息、异常特征、时间线与操作痕迹，而不是急着重启或切换。 这份清单帮你把每一层该记什么、怎么记、记到什么程度,全都梳理清楚。
回源异常演练，为什么记录比修复更重要
演练的目的不是真的把系统修好，而是验证你面对故障时能不能快速定位、准确判断，大多数演练团队的问题不是不会修，而是修完了复盘时发现关键信息缺失，没法还原当时的真实状态，尤其是回源异常这种涉及客户端、CDN节点、源站三层链路的问题，少记一个请求头,可能就得重新演练一遍。
业内专家指出，回源异常演练中，超过一半的无效复盘源于记录要素不完整，这不是态度问题，是方法问题，你看到的回源失败，往往只是表象，真正的原因可能藏在DNS解析、SSL握手、源站防火墙、超时配置等某个细节里。
回源异常记录清单的六个核心层级
把记录拆成六个维度，每个维度对应一条独立的链路环节，演练时按顺序采集,缺一个都不完整。
请求入口层：客户端与访问特征
先从最外层开始，你要记录发起请求的客户端类型、IP地址、访问的具体URL，以及请求方法（GET还是POST），别小看这些信息，它决定了异常是全局性的还是特定用户、特定区域触发的。
- 客户端IP与所属运营商（电信、联通、移动等）
- 访问的完整URL，包括Query参数
- 请求方法、请求头（重点关注User-Agent、Referer、Accept-Encoding）
- 发起时间点（精确到秒）
- 客户端侧观察到的错误码（比如502、504、Connection Reset）
CDN节点层：命中与回源行为
CDN节点是回源异常的直接观察点，你需要记录节点是否缓存了该资源、缓存的TLL状态、回源的触发原因。
- 节点ID或节点所在区域（比如华东、华北、海外节点）
- 命中状态：HIT、MISS还是EXPIRED
- 回源URL（协议、域名、路径）
- 回源时携带的Host头、SNI信息
- 节点上看到的回源TCP连接耗时、SSL握手耗时、首字节时间
- 节点日志中的状态码，比如502、503、504，以及更细的子状态码
网络链路层：DNS解析与连通性
很多回源异常根本到不了源站，卡在DNS解析或网络连通阶段,这一层最容易漏记。
- DNS解析的CNAME记录和A记录结果
- 解析耗时、是否走了本地DNS缓存
- 从CDN节点到源站IP的TCP连通性测试结果（telnet或nc）
- 中间经过的路由跳数、丢包率（可以用traceroute记录）
- 是否出现源站IP变更导致节点仍指向旧IP的情况
源站响应层：服务状态与配置
如果请求成功到达源站，那么源站自身的状态就是核心，记录源站的负载、进程、端口监听情况,以及Web服务器和应用服务的具体表现。
- 源站公网IP、内网IP、服务端口
- 源站服务器CPU、内存、磁盘IO使用率（记录时间点）
- Web服务（Nginx/Apache）和PHP-FPM/Tomcat等进程状态
- 源站访问日志中对应请求的时间戳、上游响应时间、upstream_status
- 防火墙规则、安全组、WAF是否拦截了来自CDN节点的请求
- 源站是否配置了回源鉴权、IP白名单等额外限制
时间线层：每个关键动作的精确时刻
异常永远是动态演变的,你需要把从发现异常到演练结束的每一个关键节点都标出来。
- 首次发现异常的时间（用户报障或监控告警）
- 各环节排查的起止时间
- 修改配置或重启服务的时间点
- 异常恢复的时间点
- 每次操作前后的状态对比（比如清缓存前后、改超时前后）
操作痕迹层：谁在什么时间做了什么
回源异常演练常常不止一个人参与，记录每个人的操作，是为了复盘时能区分是演练脚本触发的问题,还是选手的误操作扩大了故障。
- 操作人角色（观察员、执行者、决策者）
- 具体执行了哪些命令（命令行内容可以截图或复制）
- 执行后的输出结果
- 是否回滚、回滚时间点
- 沟通记录（关键口头决策也建议同步记录）
演练中回源异常的常见场景与记录侧重
不同异常场景下，记录的优先级不一样,提前区分能帮你减少无效记录。
CDN回源失败是什么意思：源站不可达场景
这时重点记录CDN节点的状态码和TCP层结果，如果从节点telnet源站IP超时，基本可以判定网络不通，要记录是全部节点不通还是部分节点不通,以及源站是否对特定区域IP做了限制。
缓存穿透导致的回源突发
节点没有缓存，所有请求都打到源站，源站扛不住直接超时，记录重点在于节点缓存命中率的下降趋势,以及源站并发连接数的激增曲线。
回源协议不一致
源站只支持HTTP，但CDN配置的回源协议是HTTPS，导致握手失败，记录请求是HTTP还是HTTPS，回源端口是80还是443,SSL证书是否匹配。
制作回源异常记录表模板的四个要点
有了记录清单，你还需要一个能落地使用的模板，别用脑子记,演练现场就要打开表格填。
- 每一行对应一个时间点的具体观察，不要合并单元格
- 预设好下拉选项（比如异常类型：连接超时、SSL失败、源站响应慢）
- 留出原始日志粘贴区，方便后续分析
- 模板要支持多人同时编辑，线上文档比本地Excel更适合演练场景
实际演练中，建议把模板提前打印出来或放到共享位置，你可以搜索“CDN回源异常记录表模板”找到很多参考，但最好根据自己业务的实际链路改一版,因为模板里的字段未必覆盖你的源站架构。
如何让记录真正服务于复盘
记录不是目的，复盘才是，演练结束后，把记录清单里的数据跟监控图表、日志文件对齐,验证每个时间点是否吻合。
- 用记录里的时间点去查对应时段的监控曲线，确认异常持续时长
- 对比CDN日志和源站日志，找出时间戳差异
- 检查有没有记录之外的操作发生（比如自动恢复脚本是否触发）
- 把记录中的状态码、错误信息归档，形成异常特征库
如果复盘时发现记录缺失，那没关系，下次演练前更新模板，把本次漏掉的字段加进去,这就是记录清单不断进化的过程。
回源异常演练记录常见问题Q&A
回源异常演练时，记录响应头里的Server字段有什么用
Server字段可以快速识别回复请求的到底是不是你预期的源站软件，比如你配置的是Nginx，但返回的Server是Apache，说明请求可能被转发到了其他服务或负载均衡器，部分源站会通过Server字段隐藏真实版本号,记录它可以帮你判断是否存在版本相关兼容问题。
日志里没有记录到CDN节点的请求，该怎么继续排查
这种情况通常说明请求没有成功到达CDN节点，或者节点在入口处做了拦截，先确认客户端的DNS解析结果指向的CNAME是否正确，再检查客户端本地是否使用了代理或hosts文件，如果客户端直连源站IP能正常访问,那问题就集中在CDN接入层配置上。
演练中把源站配置改乱了，记录要素还能用来回滚吗
可以，记录时间线层中的每一次配置修改、命令执行、输出结果，就能精确还原到改动前的状态，优先查看备份文件的时间戳和操作人记录，找到最后一次成功状态对应的配置，如果记录里包含了命令原文，可以直接逆向执行反向操作，但前提是你确认命令是可逆的，这就是为什么操作痕迹层要保留完整命令行，而不是只写一句“改了超时时间”。
回到核心：演练中遇到回源异常，完整记录就是你的逃生地图，按照请求入口、CDN节点、网络链路、源站响应、时间线、操作痕迹六个层级去收集，你就能从一团乱麻里精准揪出根因,让每一次演练都有实际产出。