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

死链处理方法_怎样排除缓存造成的假象

遇到死链时，第一件容易踩坑的事，是把缓存返回的旧页面当成“链接还活着”。排除缓存假象的核心方法，是让请求带上明确的禁缓存头，并对比“带缓存请求”和“强制回源请求”两次结果。如果两次状态码、响应体或跳转目标不一致，说明你看到的很可能是缓存副本，不能据此判断死链是否已修复。

先分清你查的是哪种“缓存”

同一个URL出现“有时404、有时200”，可能来自不同层：浏览器本地缓存、CDN边缘节点缓存、服务器端页面缓存，以及搜索引擎自己的快照或索引缓存。它们的排查方式不同，判断结论也不同。

• 浏览器缓存：只影响你自己的设备，换设备或隐私窗口即可验证。
• CDN或反向代理缓存：影响所有访客，需要用禁缓存请求头回源验证。
• 服务器页面缓存：同一URL被程序缓存成静态结果，需要清理缓存后重测。
• 搜索引擎快照：那是搜索引擎已抓取的历史版本，不代表你服务器当前状态。

注意：搜索引擎的索引缓存和你的服务器缓存是两回事。即使服务器已经返回404，搜索结果里仍可能短暂显示旧标题或旧快照，这属于索引更新滞后，不是服务器缓存假象。

可执行清单：每项查什么、怎么查、结果说明什么

1. 查浏览器层。用无痕窗口或另一台设备打开同一个URL。如果无痕窗口返回404、普通窗口返回200，说明你本地缓存了旧页面，问题不在服务器。
2. 查响应头。用命令行请求该URL，观察 Cache-Control、Age、X-Cache、CF-Cache-Status 一类字段。出现 HIT 或较大的 Age，说明响应来自缓存节点，不能直接当作源站状态。
3. 强制回源。在请求中加 Cache-Control: no-cache，或给URL临时加一个无意义查询参数（如 ?v=20240101）再请求。如果这时返回404、而原URL返回200，基本可确认是缓存层在返回旧内容。
4. 查跳转链。用 curl -I 或浏览器网络面板查看完整跳转。如果缓存返回301到新地址、回源却返回404，说明链接目标已经失效，缓存掩盖了真实状态。
5. 查 robots.txt 与站点地图。确认死链URL是否被 robots.txt 屏蔽。屏蔽只阻止抓取，不等于移除索引；站点地图里保留该URL也不保证它被收录或及时删除。这两项都不能替代对HTTP状态码的判断。
6. 查搜索引擎侧。在搜索结果中查看该页快照日期，并与服务器当前响应对比。快照旧、服务器新，属于索引滞后；两者都指向404，才是真死链。

时间和人手有限时，先处理哪几项

按“影响面 × 排查成本”排序，优先做这三步：

• 先做第2、3项（响应头 + 强制回源）。这两步几分钟内就能区分“缓存假象”和“真死链”，决定后续是否要改链接。
• 再做第6项（搜索引擎侧抽查）。只抽查流量最高或外链最多的几个死链URL，不必全站铺开。
• 最后才处理第5项（robots.txt、站点地图）。这些属于辅助配置，不能作为判断死链是否存在的依据。

如果强制回源后仍返回404，就按真死链处理：设置301跳转到最相关的有效页面，或恢复内容。如果回源返回200而缓存返回404，则清理对应缓存节点并调整缓存规则，而不是去改链接。

一个假设例子

假设某商品页 /p/123 在浏览器里显示正常，但用 curl -I 加禁缓存头请求时返回404。带缓存请求返回 X-Cache: HIT，回源请求返回 X-Cache: MISS 且状态码404。结论：该页在源站已删除，你之前看到的是CDN缓存的旧副本。此时应清理该URL缓存，并决定是恢复页面还是做301跳转，而不是继续等待缓存自然过期。

下一步：挑出你手上流量最高的3个疑似死链URL，分别做一次带缓存请求和一次强制回源请求，记录两次的状态码与跳转目标。两次结果一致，按真死链处理；不一致，先清缓存再复测。