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

死链工具：异常恢复后怎样区分缓存过期与真正修复

先把结论说清楚：异常恢复后看到死链工具结果变好，不能直接当成修复成功。缺少完整日志或服务器权限时，最可靠的做法是选一个受影响页面，用带随机参数的请求绕过缓存，对比状态码、响应头和页面正文三者是否一致；只有三者都指向同一结果，才能把这次变化归为真正修复，否则更可能是缓存过期或中间层刷新。

先选一个页面，把“恢复”拆成三个可观测信号

不要一上来就重跑整站。挑一个此前被死链工具标记、现在又显示正常的页面，把它当作样本。你需要同时记录三样东西：

• HTTP 状态码，是否稳定返回 200，而不是 301、302 或 404。
• 响应头里的缓存相关字段，例如 Age、Cache-Control、X-Cache 这类能说明内容来自缓存还是源站的标记。
• 页面正文，是否已经包含修复后的目标内容，而不是旧快照或错误页模板。

如果状态码变好但正文仍是旧内容，或者响应头显示命中了缓存层，那么这次“恢复”更可能是缓存过期，而不是源站真的被修好。

用带随机参数的请求绕过缓存，观察源站真实响应

缓存最容易制造假象。你可以在样本 URL 后加一个不影响内容的随机查询参数，例如 ?probe=20240613a，再请求一次。这个动作的目的不是“刷新缓存”，而是让请求尽量落到源站或未命中的缓存节点上。

对比两次结果：

1. 带随机参数请求返回的状态码和正文，是否与不带参数时一致。
2. 带随机参数请求的响应头中，是否仍出现明显的缓存命中标记。
3. 如果不带参数时正常、带参数时仍异常，说明源站问题可能还在，只是缓存层暂时掩盖了它。

这个动作的结果会直接决定下一步：若带参数请求也恢复正常，才值得扩大检查范围；若带参数请求仍异常，就不要继续批量验证，先回到源站或上游处理。

区分三种常见原因，别把统计归零当成修复证据

死链工具结果恢复，至少有三种合理解释：

• 缓存过期：中间层或浏览器缓存到期后重新拉取，恰好拿到正常内容，但源站并未改动。
• 真正修复：源站已修正链接、重定向或内容，缓存和源站都返回一致结果。
• 抓取或统计波动：工具本轮抓取量下降、请求被限制，或数据延迟，导致异常数量看起来归零。

请求量、抓取量或某项统计归零，不能单独证明处理正确。它也可能来自抓取限制、超时、工具侧抽样或数据延迟。要排除这些解释，至少需要确认同一 URL 在不同时间、不同请求方式下返回一致结果。

缺少权限时，仍可执行的最小动作与不能推出的结论

如果你没有服务器日志、没有 CDN 配置权限，也不掌握源站改动记录，仍然可以做三件小事：

1. 对样本 URL 连续请求两次，一次带随机参数，一次不带，记录状态码和正文差异。
2. 检查响应头中是否出现缓存命中、代理层或过期时间相关字段。
3. 把两次结果与死链工具当前显示的结果并列，看它们是否指向同一状态。

做完这些，你能得到的结论仅限于：该样本在当前请求路径下是否仍异常、是否明显受缓存影响。你不能据此推出全站已修复，也不能推出所有搜索引擎都已重新抓取。站点地图不保证收录，robots.txt 的抓取限制也不等于可靠的索引移除；这些都需要分别核查。

一个假设例子：怎样用对比法做判断

假设某页面此前被死链工具标记为 404，今天工具显示正常。你不带参数请求，返回 200，正文是旧版错误页；带随机参数请求，返回 404，正文是源站错误页。此时更合理的判断是：缓存层存有旧的成功响应，源站问题仍在。下一步不应批量重跑全站，而应先处理源站或上游重定向，再重新用同样方法验证同一个样本。只有带参数和不带参数都返回一致的正确内容，才把这次变化视为真正修复。

把这个样本结论记录下来，再决定是否扩大验证范围，比直接相信工具面板上的“恢复”更稳妥。