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

死链检测方法 - 排除缓存造成的假象

缓存造成的假象，指的是你检测到某个链接返回404或无法访问，但源站实际已恢复、或返回的是旧页面。要排除它，核心动作是让检测请求绕过各级缓存，并对比“带缓存请求”和“绕缓存请求”的结果差异，而不是直接相信第一次检测的返回码。

先分清缓存可能出现在哪一层

死链检测中的“假死链”通常来自三个位置，需要分别对待：

• 浏览器缓存：你本地访问过旧页面，浏览器直接返回历史结果。
• CDN或反向代理缓存：边缘节点保存了旧的404或旧页面，源站已修复但边缘未刷新。
• 检测工具自身缓存：爬虫或监控平台对同一URL做了结果缓存，短时间内不重新请求。

这三种情况的共同特征是：同一URL在不同时间、不同网络、不同工具下返回不一致。判断时优先找“不一致”，而不是急着改链接。

用绕缓存请求做一次对照检测

最直接的可执行步骤，是对可疑URL发两次请求并对比：

1. 第一次用普通方式请求，记录返回的状态码和响应内容。
2. 第二次在请求头中加 Cache-Control: no-cache 和 Pragma: no-cache，并附加一个随机查询参数，例如 ?t=时间戳，强制回源。
3. 如果第一次返回404、第二次返回200，说明之前的结果很可能来自缓存，属于假象；如果两次都返回404，才更接近真实死链。

适用条件是你能控制或模拟请求头。判断结果是：两次状态码一致，缓存嫌疑基本排除；不一致，则要追查缓存层。注意随机参数只用于检测，不要留在正式链接里，否则会制造大量重复URL。

检查缓存相关响应头

响应头能直接暴露缓存行为，重点看几个字段：

• Age：大于0说明响应来自缓存，值越大缓存越旧。
• X-Cache 或类似字段：常见取值为 HIT/MISS，HIT 表示命中缓存。
• Cache-Control：max-age 决定缓存存活时长，no-store 表示不应缓存。
• ETag 与 Last-Modified：用于判断返回的是否为旧版本。

如果普通请求显示 Age 很大且状态码异常，而绕缓存请求正常，就应把结论写成“疑似缓存导致”，并记录两组响应头作为证据，而不是直接判定链接已死。

把检测流程固化为可验收的步骤

要稳定排除缓存假象，检测任务本身需要明确交付物：

• 每个可疑URL至少保留两次请求的状态码、响应头和请求时间。
• 标注请求是否绕缓存，以及使用的网络出口或节点。
• 对同一URL在不同工具下结果不一致的，单独列出，不并入死链清单。
• 验收标准：只有绕缓存请求仍返回4xx/5xx，才标记为确认死链。

这样做的意义是：缓存假象会随节点和时间变化，单次结果无法定论，必须靠对照数据定位。

容易混淆的几种情况

有些现象看起来像缓存，实际是别的原因，需要区分：

• robots.txt 限制抓取：这会导致工具无法访问，但不等于链接失效，也不能靠它做索引移除。
• 站点地图中的URL：出现在站点地图里不保证被收录，也不代表链接一定可访问。
• HTTPS 证书问题：可能让请求失败，但这不是缓存造成的假死链，应按证书或协议错误单独排查。

判断方法是先看失败发生在请求阶段还是响应阶段：连不上、证书报错属于连接问题；能连上但返回旧状态码，才优先怀疑缓存。

下一步：挑出你清单里状态码反复变化的URL，对每个URL按上面的方法做一次绕缓存对照请求，把两次结果和响应头并排记录，再决定哪些才是真正需要修复的死链。