死链处理：怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e6de443276a1.html
📄
死链处理：怎样排除缓存造成的假象
排除缓存造成的假象，核心是绕过浏览器、CDN、代理和搜索引擎四层缓存，用带随机参数的请求或强制回源方式重新验证同一个URL。如果清缓存后状态码从404变为200，说明原判断是缓存假象；如果多次绕过缓存仍返回404，才能把它计入真实死链清单，再进入处理流程。
先分清四层缓存各自会伪造什么现象
浏览器缓存会把旧的404或200页面留在本地，刷新未必生效；CDN和反向代理缓存会返回上一次回源的响应，尤其是配置了较长TTL的静态资源；代理或公司网关缓存可能让同一办公网内所有人看到同一份旧结果；搜索引擎结果页的缓存快照与索引状态又是另一回事，快照显示404不代表当前线上仍404，反之亦然。
判断时不要只看一次请求的结果。同一URL在不同网络、不同工具、不同时间返回不一致，基本可以判定存在缓存层干扰，而不是链接本身时好时坏。
用可执行步骤绕开缓存重新验证
- 用命令行发请求并附加随机查询参数，例如
curl -I "https://example.com/page?cb=20240101a"，让缓存键变化，观察返回的状态码与响应头。 - 检查响应头中的
Age、X-Cache、CF-Cache-Status一类字段。存在这些字段且值表明命中缓存时，当前结果不能作为死链证据。 - 对CDN或反向代理执行一次回源刷新（purge），再重复第1步。若状态码改变，原现象属于缓存假象。
- 换一条网络路径复测，例如从办公网切到手机热点，排除本地代理缓存。
- 把每次请求的时间、工具、状态码、关键响应头记进同一张表，作为交付依据。
适用条件是你能控制或至少能观察到缓存层。如果站点由外部团队托管、无法purge，只能靠随机参数和换网络复测，此时结论要标注“未排除缓存”，不能直接判为死链。
多人协作时把验证资料固定下来
要减少返工，交付物应包含：待验证URL清单、每条的复测命令与结果、响应头截图或文本、判定结论（真实死链／缓存假象／待确认）、判定人和时间。责任划分上，谁发起死链报告，谁就负责附上首次证据；谁执行复测，谁负责标注是否已绕开缓存。
验收标准可以写成三条：每条URL至少有一次带随机参数的请求记录；命中缓存的记录不得单独作为死链结论；结论为“真实死链”的条目必须能重复复现。满足这三条，后续的跳转设置或删除处理才有可靠输入。
容易混淆的几种情况
- robots.txt 禁止抓取会阻止爬虫访问，但它不是可靠的索引移除手段，也不能用来判断某个URL是否真的404。
- 站点地图里保留着某个URL，不代表它已被收录，更不代表它当前可访问。
- 页面返回200也不等于内容正确，缓存可能返回旧版200页面，需要比对正文关键内容或时间戳。
- HTTPS 只说明传输加密，与链接是否失效、是否被缓存无关。
这些情况都要分别核查，不能用一个现象推断另一个结论。
确认是缓存假象之后怎么处理
如果复测证明是缓存假象，处理对象就不是链接，而是缓存策略：检查该路径的TTL设置、回源规则和刷新流程，并把这次误判记录进协作文档，避免同一URL被重复报告。如果绕开缓存后仍稳定返回404或410，才把它转入真实死链处理，按内链、外链、站点地图分别安排修复或跳转。
下一步建议先挑出最近一次死链报告中状态码前后不一致的条目，用带随机参数的请求逐条复测，把结果补进同一张表，再决定哪些需要真正修改。
