死链优化：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /88b2414f0d92.html
📄
死链优化：多层缓存返回不同版本时怎样定位一致性问题
先给结论：不要从“哪个版本才是对的”开始查，而要先固定一个可复现的请求标识，再逐层记录同一标识在各层缓存与源站上的返回。缺少完整日志或权限时，最小动作是选一条已知死链，用同一 URL、同一 UA、同一 Cookie 状态分别请求边缘、代理和源站，记录状态码、响应头中的缓存标识与正文特征。能对齐到某一层，问题就归那一层；对不齐，说明请求没有真正走到你假设的那一层。
假设情境：一条死链在三层返回三个结果
假设某站把 /old-page 设为 410，同时保留一条指向它的内链。运营在浏览器看到 410，在 CDN 边缘节点看到 200 且正文是旧版页面，源站直连又返回 404。三个结果同时存在，且刷新后偶尔互换。这个情境只用于说明排查顺序，不代表任何真实站点。
此时最容易犯的错，是拿“浏览器看到 410”当作全局事实，然后去改源站。真正需要先确认的是：这三个结果分别由哪一层产生，以及它们是否共享同一个缓存键。如果边缘按 URL 缓存，而代理按 URL 加语言头缓存，那么两者本就不该被当成同一个对象比较。
先固定请求标识，再逐层对照
把变量压到最少，才能让差异有意义。建议固定以下字段，并在每一层记录同一组值：
- 完整 URL，包含查询串与结尾斜杠
- 请求方法与请求头中会影响缓存的内容，例如 Accept-Language、Cookie、设备标识
- 响应状态码与响应头中的缓存状态字段、年龄字段、命中标识
- 正文中一个稳定特征，例如标题或某个只出现在旧版的字符串
动作上，先直连源站拿一次基准，再按由外到内的顺序请求边缘、中间代理，最后回到源站复测。若边缘返回 200 而源站返回 410，且响应头显示边缘命中，说明边缘持有一份旧副本；若边缘未命中却仍返回 200，则要怀疑中间层或回源路径被改写。下一步不是立刻清缓存，而是确认这份旧副本的缓存键与过期时间，否则清完还会被同一路径重新写入。
区分三种常见原因，别急着归因于缓存
多层返回不一致，通常落在三类原因上，证据形态不同：
- 缓存键不一致。不同层把不同请求头纳入键，导致同一 URL 被当成多个对象。证据是改变某个请求头后结果稳定切换。
- 过期与回源策略不一致。某层仍在使用旧副本，另一层已回源。证据是响应头中的年龄接近该层设定的上限，或命中标识在多次请求间跳变。
- 源站本身按条件返回不同结果。例如按 UA、登录态或灰度标识返回不同状态。证据是直连源站时，仅改变这些条件就能复现差异。
需要提醒的是，抓取量或某层请求量降到零，并不能单独证明某层已被正确清理。它也可能是抓取被限制、请求被合并、或监控点选错位置造成的。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，因此不要用“爬虫不来了”当作死链已处理完的证据。
缺少权限时的最小动作与不能推出的结论
没有边缘配置权限、也拿不到完整访问日志时，仍可执行一个最小动作：对同一条死链连续请求多次，逐次记录状态码、缓存命中标识与正文特征，并把请求按固定间隔分散开。若结果在少数几个值之间稳定轮换，可初步判断存在多个缓存对象；若结果始终一致，则说明当前观测点看不到分层差异，需要换观测点，而不是断定只有一层。
这个动作能支持的结论有限。它能说明“从当前观测点看，返回是否稳定”，不能说明哪一层持有旧副本，也不能说明清理是否彻底。要推进到修复，至少还需要一层可区分的证据：要么是某层响应头中的命中与年龄信息，要么是能改变结果的那个请求头。拿到其中之一，才能把下一步动作落到具体层，例如统一缓存键、缩短某层过期时间，或让源站在死链上返回不可缓存的响应。
最后，把验证标准提前写清楚：同一请求标识在边缘、代理和源站返回一致，且连续多次请求不再跳变，才算这一轮定位结束；在此之前，任何单点结果都只是线索。
