内链外链源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /92b5aa62463f.html
📄
内链外链源站正常而边缘节点异常时应保留哪些证据
结论先行：当源站返回正常、但边缘节点出现异常时，应优先保留能区分“源站内容”与“边缘交付结果”的对照证据，而不是只保留一份报错截图。最小可用证据集是：同一 URL 在同一时间窗口内，分别经源站直连与经边缘节点请求得到的响应头、状态码、响应体摘要，以及两者的时间戳与请求标识。只有这些证据能让后续判断落在“边缘层”而不是“源站层”，也才能决定是修缓存、改回源规则，还是先回滚边缘配置。
为什么单看源站正常不足以定位问题
源站正常说明的是回源链路末端的内容生成与响应是通的，它不能证明边缘节点上的缓存副本、回源路径、TLS 终止或重写规则也一致。边缘节点异常常见于几种互不相同的形态：缓存了旧版本、回源被拒绝、响应头被改写、部分节点超时。这几种形态在“源站直连”视角下可能完全看不出来。
因此证据要成对保留，而不是单点保留。判断标准很简单：如果一份证据无法回答“同一请求在源站和边缘分别得到什么”，它在定位阶段的价值就很低。
应保留的证据清单与各自作用
- 成对的响应头：源站直连与边缘节点各一份，重点看缓存状态、内容类型、内容长度、编码与自定义回源标识。差异本身就是线索。
- 状态码与重定向链：记录每一跳的状态码。边缘返回 200 但内容陈旧，和边缘返回 5xx，指向完全不同的处理方向。
- 响应体摘要：不必存全文，保留长度、哈希或首尾片段即可，用于证明“边缘给的是旧内容还是错误页”。
- 请求标识与时间戳：两边都要有，且尽量落在同一时间窗口。缺少时间对齐，后续无法排除“先后变化”造成的假差异。
- 请求所用的主机名与路径：边缘异常常与特定主机名或路径规则绑定，丢掉这一项就无法缩小范围。
- 边缘配置的当前版本标识：用于回答“异常是否与最近一次变更同时出现”。
一个实际动作：先用同一台机器、同一时间段，对同一 URL 分别做源站直连请求和经边缘请求，把两份响应头与状态码并列保存。这个动作的结果会直接决定下一步——如果两者响应头一致而仅内容陈旧，方向是缓存与刷新；如果边缘状态码异常而源站正常，方向是回源与边缘规则。
一个会让上述结论失效的反例
假设源站直连请求走的是内网地址、绕过了对外解析，而边缘回源走的是公网域名。此时“源站正常”并不能代表边缘回源路径正常，因为两者根本不是同一条链路。这种情况下，前面那份对照证据会把差异归因到边缘，而真实原因可能在解析或回源出口。
所以保留证据时必须同时记录请求实际连接的地址或解析结果。若两边目标地址不同，对照就失去意义，需要先补齐一条与边缘回源路径一致的源站请求，再重新比较。
退出旧内容或旧系统时如何取舍
当旧内容、旧系统或旧合作关系需要退出时，边缘异常的证据会直接影响“保留还是清理”的决定。可按下述条件区分：
- 若边缘异常只影响已计划下线的旧路径，且源站已不再生成该内容，可以保留异常记录后直接推进下线，不必先修边缘。
- 若异常波及仍在使用中的路径，即使源站正常，也应先冻结边缘配置变更，保留证据后再处理，避免修复动作覆盖现场。
- 若无法确认影响范围，先保留证据、暂不清理，因为清理会破坏可复查的现场。
这里要说明一个常见误判：某条路径的请求量或抓取量降到零，并不能单独证明该路径已无价值或处理正确。请求归零也可能来自边缘拦截、解析变化或外部链接失效，需要结合上面的成对证据一起看。
下一步动作与结果如何影响后续
收集完成后，先做一次差异归类：把源站与边缘的响应头、状态码、内容摘要逐项对比，凡是不一致的项都标注出来。若差异集中在缓存相关字段，下一步是核对边缘缓存规则与刷新记录；若差异集中在回源相关字段，下一步是核对回源地址、协议与主机头；若两边完全一致却仍表现为异常，则需要把观察点前移到客户端与解析层。
动作的结果会改变后续顺序：差异能稳定复现，就可以按单一方向深入；差异时有时无，则应先扩大采样窗口而不是急着改配置。无论走哪条路，保留的证据都应包含时间戳与请求标识，使后来者能复核而不是只能采信结论。这样，退出旧内容时才能只清掉确实无价值的部分，把仍有作用的部分连同判断依据一起留下。
