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

如何检查网站死链怎样排除缓存造成的假象

结论先说：缓存造成的死链假象，通常来自浏览器本地缓存、CDN边缘缓存、中间代理缓存或搜索引擎快照。排查时不要直接改链接，而要先做“无缓存对照请求”，确认同一个URL在不同缓存层下是否返回不同状态。如果无缓存请求返回200，而普通访问返回404或旧页面，问题大概率在缓存层，不在链接本身。

先区分四种缓存假象

同一个链接“看起来死了”，可能对应不同层次：

• 浏览器缓存：你看到的是旧页面或旧404，强制刷新后恢复正常。
• CDN缓存：源站已修复，边缘节点仍返回旧状态码或旧内容。
• 代理或企业网关缓存：公司网络、运营商缓存返回过期响应。
• 搜索引擎快照：搜索结果里的标题、摘要或缓存页仍是旧版本，实际URL已可访问。

这四类的验证方法不同。把搜索引擎快照当成死链，是最常见的误判。

用无缓存请求做第一轮对照

先拿到URL，然后在命令行执行一次带随机参数的请求，绕过大部分中间缓存：

curl -I "https://example.com/page?cachebust=20240601"

再执行一次不带参数的普通请求：

curl -I "https://example.com/page"

比较两次返回的HTTP状态码和响应头。重点看：

• HTTP/1.1 200 与 404 是否不一致。
• Cache-Control、Age、X-Cache、CF-Cache-Status等头部是否显示命中缓存。
• Last-Modified或ETag是否停留在修复前的时间。

判断规则：带随机参数返回200、不带参数返回404，说明源站正常，缓存层在返回旧状态。反过来，两者都404，才更可能是真实死链。

检查CDN与源站是否一致

如果使用了CDN，需要分别请求源站和CDN节点。假设源站IP是203.0.113.10，可以这样指定解析：

curl -I --resolve example.com:443:203.0.113.10 "https://example.com/page"

然后把结果与直接访问域名的结果对比。若源站返回200、CDN返回404，问题在CDN缓存或回源配置。此时可以执行缓存刷新，但刷新后要再次用无缓存请求验证，而不是只看控制台提示成功。

适用条件：只有当你确认源站内容已正确发布、且CDN确实参与该URL的响应时，才把问题归因到CDN。若源站本身也返回404，应先修源站。

用日志和抓取工具收集证据

命令行只能看到单次响应，要判断是否普遍存在缓存假象，需要看服务器访问日志。查找该URL最近的记录，关注：

• 状态码分布：是否同一URL交替出现200和404。
• 请求来源：是搜索引擎爬虫、真实用户还是监控工具。
• 时间点：404是否集中在某次发布或缓存刷新之后。

也可以用站点爬虫工具重新抓取，但要把“爬虫结果”和“浏览器结果”分开记录。爬虫通常不带浏览器缓存，若爬虫返回200而你的浏览器返回404，基本可以确认是本地或中间缓存。

验收信号与下一步

修复完成的验收信号不是“我刷新后正常了”，而是：

1. 无缓存请求与普通请求返回相同状态码。
2. CDN响应头中不再出现旧的Age或缓存命中标记。
3. 源站日志中该URL不再出现404。
4. 搜索引擎快照更新需要单独等待，不能作为死链是否修复的唯一依据。

下一步：挑一个你怀疑是缓存假象的URL，先跑一次带随机参数的curl -I，把两次状态码和响应头记下来。若结果不一致，再按CDN、代理、浏览器三层逐项排除；若结果一致且都是404，就回到链接本身和源站配置去查。