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

死链检查工具，怎样排除缓存造成的假象

用死链检查工具扫出大量404或超时，先别急着改链接或删页面。缓存造成的假象很常见：工具拿到的是CDN边缘节点、浏览器、代理服务器或搜索引擎快照里的旧响应，而源站当前状态已经恢复或从未出错。排除办法是按“先确认源站、再逐层绕过缓存、最后对照多源结果”的顺序复核。

先判断哪些结果最可能是缓存假象

缓存假象有几个可观察特征，命中越多越值得怀疑：

• 同一URL短时间内重复扫描，状态码在200和404之间跳变。
• 报错集中在某个路径前缀或某个子域，其他路径正常。
• 工具显示超时或5xx，但用浏览器直接访问源站IP或加随机查询参数后正常。
• 报错URL的响应头里带有较长的Cache-Control、Age或CDN标识。
• 只有部分节点报错，换一个出口地区或网络环境结果不同。

这些只是“可能原因”的信号，不能据此断定就是缓存。真正定位需要下面几步实测。

绕过缓存直接验证源站

这一步的目标是拿到源站的真实响应，而不是CDN或中间层返回的旧副本。

1. 用curl -I请求目标URL，观察状态码和响应头。命令示例（假设域名为example.com，仅作格式演示）：curl -I https://example.com/page。
2. 在URL后加一个无意义查询参数，例如?cachebust=20240101。多数缓存按完整URL做键，加参数通常能穿透旧缓存，拿到源站响应。
3. 如果站点有源站IP，用--resolve把域名指向源站IP再请求：curl -I --resolve example.com:443:源站IP https://example.com/page。这样请求不经过CDN。
4. 对比带参数和不带参数的响应头。如果带参数返回200、不带参数返回404，且两者Age差异明显，缓存嫌疑很大。

适用条件：你能拿到源站IP或可控的测试入口。若站点完全托管在CDN后面、没有独立源站入口，就跳到下一步用多源对照。

用多个出口和多种工具交叉对照

单一工具的结果不足以定论，因为每个工具的出口节点、User-Agent和超时设置不同。

• 换网络出口：同一URL分别从办公室网络、移动网络、境外节点请求，结果一致才更可信。
• 换工具：命令行curl、在线HTTP状态检查、浏览器开发者工具的Network面板各跑一次，比较状态码。
• 看响应头时间戳：Date、Age、Last-Modified能帮助判断返回的是新内容还是旧副本。
• 区分搜索引擎快照：搜索引擎结果里的“快照”是历史存档，不等于当前页面状态，不能作为死链判断依据。

判断结果：如果多个独立出口都返回404，缓存假象基本可以排除，问题在源站本身；如果只有部分出口报错，优先怀疑该出口对应的缓存节点。

清理缓存后重新扫描的正确顺序

确认是缓存问题后，按从内到外的顺序处理，避免反复：

1. 先刷新源站或应用层缓存（如对象缓存、页面缓存插件）。
2. 再刷新CDN缓存，只针对报错的那批URL，不要整站清空。
3. 等待缓存刷新生效后，用加随机参数的URL复测源站，确认源站正常。
4. 最后用死链检查工具重扫，并把扫描出口固定为与之前相同，便于对比。

注意：robots.txt的抓取限制不等于可靠的索引移除，它只影响抓取，不保证页面从索引消失；站点地图提交也不保证收录。这些机制与缓存假象是不同层面的问题，不要混用。

把复核固化成检查项

为了避免每次都被缓存误导，可以在死链检查流程里固定几个检查项：扫描前记录工具出口和User-Agent；对报错URL先加参数复测一次；对批量报错先抽样验证源站；把“源站确认”和“缓存确认”分成两个独立结论。这样得到的死链清单才可用于后续修复，而不是把时间花在并不存在的坏链接上。

下一步：挑出本次扫描中报错最集中的一批URL，按上面的顺序做一次源站与缓存对照，只把源站确认返回404的URL列入修复清单。