死链检测工具：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /559f28bcc5ec.html
📄
死链检测工具：异常恢复后怎样区分缓存过期与真正修复
先看一个关键动作：用死链检测工具复测时，把请求头里的缓存控制字段临时改成强制回源，再对比同一 URL 在带缓存与不带缓存两种请求下的状态码。如果强制回源后仍返回 404 或 410，说明源站并未修复，之前看到的 200 只是缓存或 CDN 边缘节点在替你“圆场”；如果强制回源返回 200 且响应体与预期一致，才更接近真正修复。这个判断直接决定你下一步是继续改源站，还是可以转入观察阶段。
为什么样本正常、规模化后却冒出例外
小范围抽查时，你往往只测了少数几个 URL，恰好命中了已经回源的节点，于是得出“已恢复”的结论。等到用死链检测工具跑全量，才发现同一批链接里有的 200、有的 404。这不是工具不稳定，而是缓存层和源站状态不一致造成的分层现象。
常见矛盾现象是：单条复测返回 200，全量扫描却仍有大量 404。此时至少有两种解释成立，且它们指向完全不同的处理动作。
两种解释：缓存过期与真正修复
解释一：边缘缓存尚未过期
源站已经修好，但 CDN 或反向代理仍持有旧的 404 响应。缓存时长越长、节点越多，这种“表面异常”持续越久。它的特征是：带缓存请求返回 404，强制回源请求返回 200，且不同地理节点结果不一致。
解释二：源站并未真正修复
你看到的 200 来自缓存中的旧成功响应，或者来自一个兜底页面。源站本身仍在返回 404，只是被缓存或跳转掩盖了。它的特征是：强制回源后依然 404，或回源返回 200 但响应体是通用错误页、首页内容，而非原目标内容。
能区分两种解释的证据
不要只看状态码，要组合三类证据。
- 回源对比：带缓存与强制回源两次请求的状态码是否一致。不一致偏向缓存过期，一致且为错误码偏向未修复。
- 响应体指纹：回源 200 时，页面标题、正文长度、关键内容是否与预期目标一致。若只是通用页，不能算修复。
- 多节点一致性：换不同网络或节点复测。若结果随节点变化，缓存因素权重更高；若所有节点回源都失败，源站问题更确定。
这里要提醒一个边界：请求量归零或抓取量下降，并不能单独证明修复正确。它也可能来自抓取预算调整、robots 限制变化或站点整体流量波动。把这类统计当作唯一证据，容易误判。
一个注明假设的短例子
假设某站点有 500 条历史死链，修复后死链检测工具全量扫描仍报 120 条 404。你从中抽 10 条做强制回源复测：其中 7 条回源返回 200 且内容匹配，3 条回源仍是 404。据此可以推断，那 7 条属于缓存未过期，下一步是等待缓存自然过期或主动刷新；那 3 条属于源站未修复，下一步是回到内容或重定向配置继续处理。这个划分让两类问题不会混在同一张待办清单里。
需要说明的是，主动刷新缓存只影响你控制的缓存层，不能替代源站修复。若源站本身仍返回错误码，刷新只是让错误更快暴露。
规模化前先确认适用条件
上述对比方法在你能控制回源请求、能读取响应体、且缓存层可区分时成立。如果站点使用第三方托管、无法强制回源，或响应体被统一改写，这套证据链会打折。此时应退回到更保守的判断：以源站日志或直接访问源文件的结果为准，而不是以死链检测工具的单次状态码为准。
另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这些因素会干扰你对“是否修复”的观察，但不应被当作修复本身。把缓存判断和收录判断分开，才能避免把不同层面的现象混为一谈。
最终判断标准应落在源站的真实响应上：只有强制回源返回预期内容，才值得进入下一步的观察与复测安排。
