死链检查工具：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /797eb0993d88.html
📄
死链检查工具：异常恢复后怎样区分缓存过期与真正修复
先给结论：异常恢复后，单看死链检查工具返回的“正常”状态码，无法区分缓存过期与真正修复。真正修复意味着源站对同一 URL 稳定返回预期内容；缓存过期只说明某一层缓存里的旧结果被替换了，源站可能仍然异常。可靠做法是绕过缓存直连源站复核一次，再决定是否把该 URL 从待修清单中移除。
假设情境：一次状态码集体转好的复核
以下为假设示例，用于说明判断方法，不代表任何真实项目。假设某站点做了一轮批量改版，死链检查工具在周一报告约 200 个 URL 返回 404。团队修改了部分跳转规则后，周三再跑一次，工具显示其中 150 个已返回 200。此时不能直接把这 150 个标记为“已修复”，因为两次检查之间隔了时间，中间可能有多层缓存参与了响应。
要区分两种情况，需要把“工具看到的结果”拆成两个问题：这个 200 是谁返回的？它是否来自源站当前的真实处理逻辑？只有第二个问题得到肯定答案，才算真正修复。
用绕过缓存的一次直连请求做分界
最小可执行动作是：对同一 URL 追加一个不会命中已有缓存的查询串，或从源站服务器本机发起请求，观察响应是否与工具结果一致。例如把 /old-page 改为请求 /old-page?v=check1，或在服务器上用 curl -I 直接请求源站地址。注意查询串只是规避缓存的常见手段，是否有效取决于缓存键的配置，并非绝对可靠。
动作的结果直接决定下一步：
- 直连源站同样返回 200 且正文正确，说明修复已落到源站，可以把该 URL 移出待修清单，转入抽样复查。
- 直连源站仍返回 404 或 5xx，而工具显示 200，说明工具命中了缓存或中间层返回的旧结果，该 URL 必须保留在待修清单中。
- 直连源站返回 200 但正文是错误页或占位内容，属于“软 404”，同样不能算修复，需要继续跟进。
如果缺少服务器权限、拿不到源站直连能力，仍可执行的最小动作是：用工具对同一 URL 连续检查两次，第二次附加随机参数，对比两次结果是否一致。两次结果不一致，倾向于缓存因素；两次一致也不能直接下“已修复”结论，只能说明当前观测稳定。
哪些证据支持“缓存过期”，哪些支持“真正修复”
把可观察到的现象按证据强度排列，有助于减少误判。
- 支持缓存过期的证据：附加随机参数后结果变回异常；响应头里带有较长的缓存有效期；同一 URL 在不同检查节点结果不一致；恢复时间点与缓存刷新周期吻合。
- 支持真正修复的证据：源站直连稳定返回预期状态码与正确正文；多次检查结果一致；修改记录能对应到具体规则变更；异常 URL 数量在后续检查中持续下降而非反弹。
需要提醒的是，请求量或抓取量在某个时间点归零，不能单独证明处理正确。它也可能是检查任务未运行、权限变更、robots.txt 限制了抓取，或工具本身配置改动造成的。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些现象都需要另行核查，不能当作修复完成的依据。
把结论写进清单时保留不确定性
建议在待修清单里给每个 URL 增加一列“复核方式”，记录是源站直连确认还是仅工具复查。只有前者可以作为关闭依据。对于只能做工具复查的 URL，标注“待源站确认”，避免后续把缓存假象当成已完成项。
一个可操作的收尾动作是：从 150 个“转好”的 URL 中抽取一部分做源站直连，若抽样中仍出现异常，则把整批标记为“疑似缓存恢复”，重新全量复核。抽样比例没有固定标准，应根据站点缓存层数和变更范围自行确定。这样做的价值在于，用少量复核成本换掉一次可能全错的批量关闭。
什么时候可以停止追查
当同一 URL 在源站直连、工具检查、不同时间点三次观测下都返回预期结果，且正文内容正确，就可以认为修复成立，不必继续追查缓存。反之，只要存在一次源站直连异常，就应保留在清单中。缺少完整数据和权限时，能给出的最稳妥结论是“当前观测正常，但未排除缓存”，而不是“已修复”。
