死链处理方法：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f1cdcec283c1.html
📄
死链处理方法：多层缓存返回不同版本时怎样定位一致性问题
先给结论：当同一批死链在不同层缓存里表现不一致时，不要从最外层开始逐层清缓存，而要先判断“哪一层拥有最终解释权”。如果站点有可控的源站响应或边缘回源日志，就以源站状态为基准，逐层比对缓存键与缓存时长；如果缺少回源日志和刷新权限，只能做最小动作——固定一个带随机参数的探测路径，记录各层返回的状态码、响应头和缓存命中标识，先确认分歧是否稳定复现。这个动作能区分“缓存版本漂移”与“源站本身就在摇摆”，但推不出哪一层配置一定错误。
有源站日志或回源权限时：以源站为基准逐层比对
这种条件下，定位的关键不是清缓存，而是找到“同一资源、同一缓存键、不同层返回不同状态”的最小复现路径。死链处理中最常见的分歧是：源站已返回 404 或 410，中间层仍返回 200 的旧页面；或者源站已做 301，某一层仍返回 404。
实施动作可以按这个顺序：
- 选一条已知死链，记录它在源站的当前状态码、响应头和最后修改时间。
- 用同一路径分别请求各层缓存节点，保留每层返回的状态码、
Age、Cache-Control、ETag或等价标识。 - 对比缓存键：确认各层是否把查询参数、协议、主机名、
Vary头纳入键。键不同，返回不同版本就是预期行为，不是故障。 - 对比缓存时长：如果某层
max-age明显长于源站变更周期，旧版本会继续存活。
这一步的结果会直接决定下一步：若各层缓存键一致、时长一致，但只有一层返回旧版本，问题更可能在那一层的刷新机制或存储副本；若各层键不一致，则应先统一缓存键策略，而不是继续追死链本身。注意，源站返回 404 并不自动等于所有层都会立即同步，缓存过期前旧响应仍可能被继续提供。
缺少回源日志或刷新权限时：用固定探测路径做最小验证
没有完整数据和权限时，仍然可以执行一个最小动作：构造一条带唯一随机参数的探测 URL，指向同一死链资源，连续请求多次并记录每层返回。随机参数的作用是绕过部分缓存键，帮助你观察“不带参数”和“带参数”是否返回不同版本。
可区分的原因至少有三类：
- 缓存版本漂移：带参数请求返回新状态，不带参数返回旧状态，说明旧版本被按无参数键缓存。
- 源站摇摆：同一路径多次请求状态码本身就不稳定，说明问题在源站或上游，不在缓存层。
- 探测路径被干扰：随机参数触发了不同的路由、重定向或防护规则，返回差异不能代表真实死链状态。
这个动作的边界要写清楚：请求量归零、抓取量下降或某层突然不再返回旧版本，都不能单独证明处理正确。它们也可能来自探测频率变化、缓存自然过期或上游限流。缺少权限时，你能得到的是“分歧是否稳定、是否与缓存键相关”，不能得到“某一层配置一定错误”的结论。
两种条件下的选择依据
有源站日志时，优先做逐层比对，因为你能把源站状态当作基准，分歧点可以直接定位到某一层。缺少日志和权限时，优先做固定探测路径的最小验证，因为它的成本低、可重复，且不需要改动生产配置。
选择时看两个信号：第一，分歧是否只在特定查询参数或特定主机名下出现；第二，旧版本是否在超过预期缓存时长后仍然存在。前者指向缓存键问题，后者指向缓存时长或刷新机制问题。若两者都不成立，应把注意力转回源站响应本身。
一个假设例子：三层缓存返回三种状态
假设某条死链在源站返回 410，边缘层返回 410，中间层返回 200 旧页面，最外层返回 404。此时不要先清最外层。先检查中间层的缓存键是否忽略了某个查询参数，再检查它的 max-age 是否长于源站变更周期。若中间层键与源站一致但仍是 200，则问题在中间层的刷新或存储；若键不一致，则先统一键策略。这个例子的数字仅用于说明比较方法，不代表任何真实站点。
把上述动作做完后，下一步取决于分歧是否可稳定复现：可复现就继续缩小到具体层和具体缓存键；不可复现就记录时间窗口，等待下一次复现再比对，避免在证据不足时批量清缓存掩盖真实原因。
