死链检查工具：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0bd1253966a9.html
📄
死链检查工具：多层缓存返回不同版本时怎样定位一致性问题
当同一批URL在不同节点、不同工具或不同时刻得到不一致的404/410/200结果时，先不要改页面，也不要直接判定死链。更可靠的做法是固定请求路径，逐层剥离缓存，确认每个缓存层实际返回的版本；只有当某一层持续返回与源站不同的状态码时，才把问题归到该层，并决定保留、改写还是退出当前检查方案。
先区分三类不一致：请求差异、缓存差异、源站差异
多层缓存下的不一致，通常不是单一原因。可以用三个可观察信号分流：
- 请求差异：带与不带Cookie、User-Agent、Accept-Encoding或查询参数时结果不同。这类不一致往往在剥离缓存后仍存在，说明源站或CDN按请求头分流。
- 缓存差异：同一请求在边缘节点返回旧状态码，回源后返回新状态码。典型证据是响应头里出现年龄、缓存命中或缓存状态字段，且回源请求结果与边缘不同。
- 源站差异：多个源站实例返回不同状态码。常见于发布未同步、配置未收敛或灰度环境混用。
如果只看到“工具A报404、工具B报200”，还不足以归因。需要补一次带缓存绕过标记的回源请求，以及一次固定请求头的边缘请求，比较两者是否收敛。这个动作的结果决定下一步：收敛到边缘，说明缓存层需要处理；收敛到源站，说明发布或配置需要处理；两边都不收敛，说明请求条件本身在制造差异。
保留、改写还是退出：按缓存层是否可控来取舍
定位到具体层之后，决策取决于你对那一层是否有控制权，以及不一致是否影响真实用户和抓取。
保留当前工具与流程的前提
如果边缘与源站在固定请求条件下返回一致，只是不同工具默认请求头不同，那么保留现有死链检查工具和流程是成立的。此时要做的是统一检查条件：固定User-Agent、固定是否携带Cookie、固定是否跟随重定向，并把回源结果作为基准。这样后续报告才有可比性。
改写检查方案的前提
如果边缘节点持续返回旧状态码，而源站已经更新，且你能修改缓存策略或触发刷新，那么改写方案比换工具更有效。具体动作是：对问题URL单独发起一次回源校验，记录源站状态；再触发该路径的缓存刷新；刷新后重新用同一请求条件检查边缘。若刷新后边缘与源站收敛，说明问题在缓存过期或刷新覆盖；若刷新后仍不收敛，说明还有中间层或规则在改写响应。这个结果直接影响下一步是继续刷新还是转向排查规则。
退出的前提
如果多层缓存由你无法控制的外部方管理，且不一致长期存在、无法通过请求条件固定，那么继续用当前工具做全站死链判定会持续产生噪声。此时退出“用统一报告下结论”的做法，改为只对源站可验证的URL做判断，把边缘结果单独记录为待确认项。这不是放弃检查，而是把不可控层从结论里剥离。
一个注明假设的短例子：同一URL三种结果
假设某URL在源站返回410，边缘节点A返回200，边缘节点B返回404。按以下顺序处理：
- 用同一请求头分别请求源站、节点A、节点B，记录状态码和响应头中的缓存相关字段。
- 若节点A返回200且带较长缓存年龄，触发该路径刷新，再请求节点A。若变为410，说明是缓存未过期；若仍为200，检查节点A是否有独立重写规则。
- 若节点B返回404且回源也是404，但源站实际为410，说明源站不同实例状态不一致，需要先收敛源站配置。
这个例子的关键不是数字，而是顺序：先固定请求，再比较层，再决定改哪一层。跳步直接改页面，可能把源站正确状态覆盖掉。
把结论落到可复查的证据上
多层缓存问题容易在复测时“自己好了”，因此每次判断都要留下可复查记录：请求URL、请求头、响应状态码、响应头中的缓存字段、请求时间、请求出口。至少保留源站与边缘两组对照。这样当结果再次变化时，能判断是缓存自然过期、刷新生效，还是源站又发生了发布。
需要提醒的是，抓取量或某次检查结果归零，并不能单独证明处理正确。它也可能是请求被限流、工具出口变化或目标暂时不可达。只有把请求条件、源站结果和边缘结果放在一起对照，才能把“看起来一致”与“实际一致”区分开。对robots.txt的限制、站点地图提交和HTTPS状态，也应分别核查其实际作用范围，不要用其中一项替代对缓存版本的验证。最终，是否保留、改写或退出当前检查方式，取决于你能否稳定复现某一层与源站的差异，以及你是否有权限修正那一层。
