📍 WDQWDWQD987AAAAA:216.73.216.123
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /93bd78f7dedd.html
📄

网站死链检测，源站正常而边缘节点异常时应保留哪些证据

先把结论说清：源站返回正常，只证明回源这一层没问题，不能证明用户拿到的响应正常。此时要保留的证据必须能同时覆盖“源站响应”“边缘节点响应”“两者之间的差异”三部分，并且带上时间、请求 URL、节点标识和响应头。没有节点标识的截图，事后几乎无法复查。

先分清两种异常，证据要求不同

边缘节点异常大致分两类，处理路径不一样。

• 边缘返回了错误状态：比如源站给 200，边缘给 404、410 或 5xx。这类要保留边缘的完整响应头与响应体，重点是确认错误由哪一层生成。
• 边缘返回正常但内容被替换：比如状态码仍是 200，但页面变成节点默认页、缓存旧版本或跳转页。这类只看状态码会漏判，必须保留响应体片段和缓存相关响应头。

两种情况的共同点是：源站日志干净，边缘日志才有价值。如果只留源站日志，等于只证明了没问题的那一半。

一条请求至少要留下哪些字段

对每个可疑 URL，按下面这组字段记录，缺一项都会让后续判断变模糊：

1. 完整请求 URL，含协议、主机名、路径和查询串；查询串不同可能命中不同缓存键。
2. 请求时间，精确到秒，并注明时区。跨时区团队最容易在这里对不上。
3. 边缘节点标识。可能是响应头里的节点编号、机房代码，或 CDN 日志中的节点字段，具体字段名随服务商而异，需按实际响应确认。
4. 完整响应头，尤其缓存命中状态、缓存键、回源状态、内容类型。
5. 响应体片段。错误页保留前若干行即可，但被替换的正常页要保留能看出差异的那段文本。
6. 同一时刻的源站响应，用相同 URL 和相同请求头再取一次，作为对照。

这里的关键动作是同 URL、同请求头、同时间窗做两次取样。如果只取边缘一次、源站一次却相隔数小时，缓存已经过期或配置已变更，两组数据就不能直接对比。

假设例子：一次可复查的取样

假设某页面在边缘返回 404，源站返回 200。可以这样记录：

• 边缘取样：URL 为 https://example.com/a?x=1，时间 10:00:00，响应头显示命中缓存且回源状态为 200，但最终状态码为 404。
• 源站取样：同一 URL，绕过边缘直连源站，时间 10:00:30，状态码 200，内容类型与预期一致。
• 差异点：边缘的最终状态码与回源状态不一致，说明错误发生在边缘处理环节，而非源站。

这个例子的数字只用于说明比较方法，不代表任何真实项目结果。它的价值在于：当边缘的“回源状态”是 200 而“最终状态”是 404 时，排查方向应转向边缘的规则、缓存或改写逻辑，而不是继续查源站文件是否存在。

证据到手后，下一步怎么走

拿到上述字段后，先做一次可重复验证：在另一个时间点、另一个节点再取一次同样的 URL。

• 如果只有个别节点异常，问题更可能在节点缓存或局部配置，处理动作是清理该 URL 的缓存并复测同一节点。
• 如果多个节点同时异常，更可能是全局规则或缓存键设计问题，处理动作是检查缓存键是否把不该区分的参数纳入，或规则是否误匹配了该路径。
• 如果复测后恢复正常且无法再现，仍要保留首次取样记录，并注明未能复现，避免把偶发问题当成已修复。

清理缓存或调整规则后，用同一组字段再记录一次，形成前后对照。只有边缘最终状态与源站一致、且响应体内容一致，才算这一轮验证完成。

容易误判的几种情况

边缘异常时，有几类现象不能单独作为结论依据：

• 边缘请求量或错误量归零，可能只是日志延迟、采样变化或监控口径调整，不等于问题已解决。
• 源站访问日志里没有该请求，可能是边缘直接命中缓存未回源，也可能是日志未采集，需要结合缓存命中状态判断。
• robots.txt 的抓取限制只影响爬虫抓取，不等于可靠的索引移除；它与边缘返回错误是两回事，不要混在一份证据里。
• 站点地图提交正常、页面使用 HTTPS，都不能证明边缘响应正确，也不能保证收录或排名，这些只能作为独立事实分别核查。

把这几类现象和真正的边缘响应证据分开记录，后续复盘时才不会把“没看到错误”误当成“没有错误”。