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

死链查询：怎样排除缓存造成的假象

死链查询时遇到“链接打不开”或“返回404”的结果，先别急着把它记入待修清单。缓存造成的假象很常见：浏览器、CDN、代理服务器或搜索引擎快照都可能返回一份过期的旧响应。要排除它，核心动作是绕开缓存重新取一次源站响应，再对比状态码与响应头。下面用一个假设例子说明具体步骤和容易踩的坑。

一个假设例子：同一URL出现两种结果

假设你正在检查 https://example.com/old-page。浏览器打开显示404，但站点后台的编辑记录里这个页面并未删除，服务器上对应文件也存在。此时至少有三种可能：页面确实被移除但记录未同步；服务器路由配置错误；以及某个中间层缓存了旧的404响应。第三种就是我们要先排除的假象。

排除顺序建议从“最接近源站”的一层开始，逐层向外对比：

1. 用命令行直接请求源站，观察状态码与响应头：curl -I https://example.com/old-page。如果返回200，说明源站正常，问题出在缓存层。
2. 如果源站也返回404，再检查服务器上的文件或路由规则，此时缓存不是主因。
3. 若源站返回200但浏览器仍显示404，强制刷新并清除该站点缓存，或换一个未访问过该站的无痕窗口重试。
4. 若浏览器恢复200，而其他网络环境下仍是404，继续检查CDN或反向代理的缓存规则。

看响应头，而不是只看页面内容

页面显示什么内容会骗人，响应头相对可靠。重点看这几项：

• Cache-Control：出现 max-age 较大或 s-maxage 时，中间缓存可能长期保留旧响应。
• Age：数值大于0，说明这份响应来自缓存而非刚刚生成的源站响应。
• X-Cache、CF-Cache-Status 等自定义头：不同服务商命名不同，看到 HIT 一般表示命中缓存，MISS 表示回源。
• ETag 与 Last-Modified：可用来判断你拿到的是新版本还是旧版本。

判断结果很直接：如果源站请求返回200，而带缓存的一侧返回404且 Age 很大，基本可以判定为缓存假象，应优先清缓存而不是改页面。反之，如果源站本身就返回404，缓存只是如实转发了这个结果，就不属于假象。

死链查询中缓存假象的常见来源

按出现频率，容易制造假象的环节有：

• 浏览器本地缓存：用户端最常见，换设备或清缓存即可验证。
• CDN边缘节点：不同地区节点缓存状态不一致，同一URL可能一地正常一地404。
• 反向代理或服务器端页面缓存：常见于动态站点，更新内容后未主动失效缓存。
• 搜索引擎快照：快照显示旧页面，不代表当前线上状态，需以实时抓取为准。
• 抓取工具的本地缓存：部分工具会复用上次结果，需确认是否开启“忽略缓存”选项。

需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这两点和缓存假象不是同一类问题，不要混在一起判断。

时间和人手有限时的处理顺序

如果待查链接很多，按下面的优先级安排最省力：

1. 先用命令行或抓取工具对源站批量请求，得到一份“源站真实状态”清单。这一步能一次性排除大量缓存干扰。
2. 把源站返回404的链接单独列出，这些才是真正需要处理的死链。
3. 对源站返回200但外部报告404的链接，逐条检查缓存头，确认是缓存问题后走清缓存流程。
4. 最后再处理搜索引擎快照层面的差异，这类问题通常不影响实际访问，优先级最低。

常见错误是反过来做：先照着浏览器或第三方报告的结果改页面，结果把本来正常的页面改坏，或者反复提交删除请求，浪费人力。另一个错误是只清浏览器缓存，忽略CDN和代理层，导致换台电脑问题依旧。

可执行的核查清单

• 源站直连请求的状态码是多少？
• 响应头里 Age 是否大于0，是否存在 HIT 类标记？
• 换网络、换设备、无痕模式下结果是否一致？
• 清缓存后同一URL是否恢复？
• 该URL是否曾被规则屏蔽或做过跳转？

下一步：挑出你清单里“外部报告404但源站疑似正常”的链接，用一次带响应头的源站请求做验证，把确认属于缓存假象的条目从死链待修列表中移出，只保留源站真实返回错误的链接进入修复流程。