死链查询：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /52063743a22f.html
📄
死链查询：多层缓存返回不同版本时怎样定位一致性问题
先给结论：出现“同一 URL 在不同环境返回不同结果”时，不要急着判定死链或修复死链，而应先把请求路径拆成浏览器缓存、CDN 或反向代理缓存、应用层缓存、源站四层，逐层记录状态码和响应头，找出第一个出现分歧的层。死链查询在这个场景里只是手段，真正要定位的是哪一层缓存保留了旧版本、哪一层已经拿到新版本，以及这种分歧是否会误导后续的死链判断。
矛盾现象：清理过的 URL 为何仍被报为死链
一个常见情形是：内容下架或迁移后，源站已经返回 410 或 301，但通过不同网络、不同工具、不同时间查询，结果并不一致。有的返回 200 的旧页面，有的返回 404，有的返回 301。此时如果直接把这些 URL 全部归入死链清单，后续处理动作就会建立在错误前提上。
这类分歧通常不是随机噪声，而是各层缓存的新旧版本不同步。旧内容退出时，往往只更新了源站，没有同步清理中间层；或者中间层 TTL 很长，仍按旧规则继续提供响应。死链查询要做的第一件事不是扩大扫描范围，而是固定几个已确认变更的 URL 作为对照样本。
两个解释：源站配置未生效，还是中间层缓存未过期
解释一：源站配置没有真正生效。规则写入了，但未部署到全部节点，或只对部分路径生效，导致不同节点返回不同结果。这种情况下，分歧出现在最靠近源站的一层，缓存只是如实转发了源站的差异。
解释二：源站已经一致，但中间层缓存仍持有旧版本。CDN、反向代理或应用缓存按旧 TTL 继续响应，尚未回源。这种情况下，直接回源查询会得到新结果，而经过缓存的查询仍是旧结果。
两个解释对应完全不同的修复动作。若是解释一，清理缓存无效，必须回到配置和发布流程；若是解释二，修改源站也不会立刻改变外部看到的结果，需要处理缓存失效或等待过期。
能区分两个解释的证据
关键证据是“绕过缓存后结果是否一致”。具体动作：对同一个 URL，分别发起直接回源请求和经过完整缓存链路的请求，记录状态码、响应头中的缓存标识、时间戳和返回内容摘要。如果回源结果一致、经过缓存的结果不一致，支持解释二；如果回源结果本身就不一致，支持解释一。
第二步证据是响应头中的年龄字段和缓存命中标识。年龄明显大于零且接近 TTL，说明该层仍在提供旧版本；年龄很小或标记为未命中，却仍返回旧内容，则要怀疑源站或更上游的层。这个动作的结果直接决定下一步：先清缓存，还是先查配置发布。
第三步证据是变更时间线。把源站变更时间、缓存 TTL、首次观察到新版本的时间并列。如果新版本出现时间与 TTL 到期时间吻合，缓存解释更可信；如果新版本在部分节点立刻出现、部分节点始终不出现，配置或节点差异解释更可信。
一个假设例子：用对照样本缩小范围
假设某站点下架了 50 个旧页面，源站规则改为返回 410。死链查询发现其中 12 个仍返回 200。此时不要扫描全站，而是从这 12 个里选 3 个，加上 3 个已正确返回 410 的页面，组成 6 个对照样本。
对每个样本分别记录：直接回源状态码、经过 CDN 状态码、响应头年龄、缓存命中标识。若 3 个异常样本回源均为 410、经过 CDN 为 200，且年龄接近 TTL，则可先按缓存未过期处理，推动缓存失效或等待过期，再复测这 3 个样本。若复测后仍不一致，才扩大范围。这个顺序能避免在错误层反复操作。
与死链查询清单衔接时的取舍
定位到分歧层之后，再决定哪些 URL 进入死链清单。已经确认源站返回 410 或 404、且缓存已同步的，按真实死链处理；源站已变更但缓存未同步的，先标记为待复测，不进入修复批次；源站本身仍返回 200 的，说明变更未生效，回到配置流程。
还需要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。缓存层返回的旧版本可能让外部观察者长期看到旧状态，但这与索引状态是两件事，判断时要分开记录，分别复测。只有当缓存、源站和外部观察结果一致后，死链查询的结论才适合作为下一步动作的依据。
