死链检测工具，怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /feb5aa134da0.html
📄
死链检测工具，怎样排除缓存造成的假象
用死链检测工具扫出大量404，先不要急着改链接。第一步应当把“缓存返回的旧结果”和“服务器真实响应”分开：对可疑URL绕过本地缓存、CDN缓存和工具自身缓存重新请求，再对比状态码与响应内容。只有服务器源站持续返回404或410，才算真实死链；若源站返回200，而工具仍报404，基本可判断是缓存或中间层造成的假象。
准备：先分清三层缓存
死链检测工具的结果可能被三类缓存干扰：浏览器或本地DNS缓存、CDN或反向代理缓存、工具服务端的结果缓存。排查前先记录可疑URL的完整地址、检测时间、工具显示的状态码，以及是否带参数或做了跳转。带参数的URL更容易被缓存策略区别对待，需要单独列出。
同时准备一个能直接查看源站响应的方式，例如命令行请求或源站日志。没有源站视角，就只能看到缓存层返回的结果，无法判断真假。
实施：用绕过缓存的方式复核
最关键的一步是向源站发起一次不经过缓存的请求，并核对响应头。可以按下面的顺序执行：
- 对可疑URL追加一个无意义的查询参数，例如
?cachebust=20240101，让缓存键发生变化。这只是排查手段，不要把它写进正式链接。 - 在请求头中加入
Cache-Control: no-cache和Pragma: no-cache，要求中间层回源校验。 - 查看响应中的
X-Cache、Age、CF-Cache-Status等字段。若显示命中缓存且Age较大，说明这次结果可能来自缓存。 - 把工具报出的状态码与源站日志中的状态码逐条对照。两者不一致时，以源站记录为准继续追查。
如果工具支持自定义请求头或关闭缓存，优先在工具内直接设置。若工具没有该选项，就用命令行或源站日志做交叉验证。注意：robots.txt的抓取限制只影响爬虫能否访问，不等于可靠的索引移除，也不能用来解释状态码差异。
验证：判断是假象还是真实死链
复核后会出现几种结果，判断方式不同：
- 源站返回200，工具返回404：属于缓存假象。应检查CDN缓存规则、工具的结果缓存周期，以及是否命中了旧版本页面。
- 源站返回404或410，工具也返回404：属于真实死链。需要进一步确认是内容被删除、URL规则变更，还是链接拼写错误。
- 源站返回301或302，工具未跟随：属于跳转未被正确处理。应检查工具是否开启跟随重定向，以及跳转链是否过长。
- 源站间歇性返回5xx：不属于死链，而是服务端不稳定。应结合服务器日志和监控判断，不要直接当作404处理。
验证时至少重复请求两次，间隔几分钟，排除瞬时故障。若两次结果不同，说明存在缓存或负载均衡层面的差异，需要继续定位。
维护：把复核变成常规检查
确认是缓存假象后，处理重点不是删链接，而是调整缓存策略：缩短可疑资源的缓存时间、在发布新页面时主动刷新CDN缓存、避免让检测工具长期复用同一份结果。对真实死链，则设置301跳转到最相关的新页面，或返回410表示已永久移除。
把死链检测纳入固定周期，例如每次内容改版后和每月各扫一次。每次扫描后先抽样复核，再批量处理。站点地图不保证收录，HTTPS也不保证安全无漏洞或排名，它们都不能替代对状态码本身的核对。
下一步：挑出本次扫描中状态码最集中的10个URL，按上面的方法逐个回源复核，先确认哪些是缓存假象，再决定是否修改链接或缓存规则。
