网站死链检查工具：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /40e085e69f56.html
📄
网站死链检查工具：源站正常而边缘节点异常时应保留哪些证据
当源站返回 200 而边缘节点返回 404 或 5xx 时，先不要急着改内容或提交删除。应保留三类证据：同一 URL 的源站直连响应、边缘节点响应、以及两者之间的时间与请求头差异。这三类证据能帮你判断问题出在缓存、回源配置还是节点同步，而不是误判为页面已死。
先分清两种做法：改源站还是等节点恢复
假设一个场景：某栏目页在源站直连时返回 200，但通过 CDN 访问时返回 404，且只发生在部分地区。此时有两种看似合理的做法。第一种是立即在源站删除该页面或改链接，第二种是暂不动源站，先收集证据再判断。选择条件在于异常是否可复现、是否与节点相关。如果只有个别节点异常，改源站会掩盖问题，还可能让正常节点也失去内容。如果所有节点都异常且源站正常，才需要检查回源路径和缓存规则。代价是：等待证据会延迟处理，但能避免误删正常页面。
必须保留的四类证据
证据不是截图越多越好，而是要能区分源站与边缘节点的行为差异。以下四类按优先级排列。
- 源站直连响应：用绑定源站 IP 或绕过 CDN 的方式请求同一 URL，记录状态码、响应头和响应体前几行。这能证明源站本身是否正常。
- 边缘节点响应：通过 CDN 域名请求同一 URL，记录状态码、响应头中的缓存命中字段、节点标识和请求时间。这能证明异常发生在哪一层。
- 请求头差异：对比两次请求的 Host、User-Agent、Accept-Encoding 和 Cookie。有些节点异常只在对特定请求头组合时出现。
- 时间与复现记录：记录每次请求的 UTC 时间、来源 IP 和复现次数。如果异常只在某个时间段出现，可能与节点同步或缓存刷新有关。
这四类证据合在一起，才能回答“是源站问题还是节点问题”。缺少源站直连响应，就无法排除源站本身间歇性异常；缺少边缘节点响应，就无法判断异常范围。
用一次假设的对比来定位差异
假设某页面在源站直连时返回 200，响应头包含 Cache-Control: max-age=600；通过边缘节点请求时返回 404，响应头显示缓存命中。此时可以做一个动作：在边缘节点请求中加一个随机查询参数，例如 ?v=20250101，强制回源。如果加参数后返回 200，说明异常出在缓存层，而不是源站内容。这个动作的结果会直接影响下一步：若强制回源正常，应检查缓存键规则和刷新策略；若强制回源仍返回 404，则应检查回源 Host 和路径重写规则。
这个对比的价值在于，它把“源站正常”和“节点异常”拆成了可验证的步骤，而不是靠猜测。注意，加查询参数只是诊断手段，不是修复方案；它可能暂时绕过缓存，但不会改变缓存规则本身。
哪些现象不能单独作为判断依据
请求量归零、抓取量下降或某个节点连续报错，都不能单独证明问题出在边缘节点。请求量归零还可能是因为统计口径变化、日志延迟或爬虫主动降低频率。抓取量下降也可能与站点整体更新节奏有关。要结合源站直连响应和边缘节点响应一起看，才能排除其他解释。
另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。这些原则在排查死链时同样适用：不要因为某个 URL 在工具中显示异常，就立即断定它需要被删除或屏蔽。
交接给开发或运维时的最小证据包
如果你需要把问题交给开发或运维，不要只发一张截图。最小证据包应包含：同一 URL 的源站直连请求与响应、边缘节点请求与响应、两次请求的时间戳、以及你已尝试过的诊断动作及其结果。这样对方能直接判断是缓存、回源还是节点同步问题，而不需要重新复现。
如果异常只出现在部分节点，还应注明节点地区或标识；如果异常与特定请求头有关，应保留完整请求头。证据越能区分“源站正常”和“节点异常”，后续处理就越不容易走错方向。最后，记录你决定暂不改源站的理由，以及下一次复查的时间点，这样即使问题自行消失，也有依据判断是节点恢复还是缓存过期。
