网站死链：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /510a127fb66b.html
📄
网站死链：多层缓存返回不同版本时怎样定位一致性问题
先确认一件事：多层缓存返回不同版本，不一定意味着死链处理逻辑错了，更常见的原因是各层缓存对同一URL的存储键、过期时间和失效通知没有对齐。定位时应先固定一个可复现的请求路径，再逐层对比响应，而不是直接改规则。
先判断该统一缓存键，还是该分层放行
两种做法都成立，取决于死链状态是否会在短时间内反复变化。
- 统一缓存键：适合死链判定稳定、状态长期不变的站点。把查询参数、协议、语言变体等归一到同一键，能减少同一URL出现多种缓存版本。代价是牺牲部分细粒度控制，某些带参数的合法页面可能被误合并。
- 分层放行：适合死链状态频繁变动、需要按地区或设备返回不同结果的站点。让边缘层、反向代理层和源站各自保留独立判断。代价是一致性更难保证，需要额外的失效通知机制。
选择依据不是哪种更先进，而是死链状态的变化频率。如果同一URL在一小时内可能从410变为301，统一缓存键会把过期状态锁死；如果状态几周不变，分层放行只会增加排查成本。
用一条可复现路径逐层取证
假设某URL在边缘节点返回410，在反向代理返回200，在源站返回404。先不要下结论，按下面顺序取一次完整证据：
- 用固定请求头（相同User-Agent、Accept-Language、Cookie）分别请求边缘、代理和源站，记录状态码、响应头和响应体摘要。
- 对比各层的缓存键字段，例如
Vary、Cache-Control、Age和自定义缓存标签。 - 检查失效通知是否到达每一层。常见做法是源站变更后向代理发purge请求，但边缘层可能只订阅了部分标签。
- 在源站临时关闭缓存，重复同一请求。如果此时各层一致，问题在缓存同步；如果不一致，问题在源站判定逻辑。
这个动作的结果直接决定下一步：若关闭源站缓存后仍不一致，应优先检查源站对死链的判定条件，而不是继续调缓存过期时间。
区分“缓存未失效”和“判定条件不同”
两者表现相似，但证据不同。
- 缓存未失效：各层返回的响应体内容相同，只是状态码或
Age不同；强制purge后短时间一致，随后再次分叉。 - 判定条件不同：各层返回的响应体本身不同，例如一层返回自定义410页面，另一层返回源站默认404页面；purge后仍不一致。
如果属于前者，应检查失效链路是否覆盖所有层，尤其是边缘层是否收到代理层的失效事件。如果属于后者，应检查各层是否使用了不同的死链判定规则，例如一层按链接检查结果判定，另一层按HTTP状态码判定。
一个注明假设的短例子
假设某站点有三层缓存：CDN边缘、Nginx反向代理、应用层缓存。某URL在源站被标记为死链并返回410。
操作：在源站变更后，只向Nginx发送purge，未向CDN边缘发送。结果：CDN边缘仍返回旧200，Nginx返回410，应用层返回410。
下一步：不应直接改死链规则，而应补齐CDN边缘的失效通知，或在CDN边缘设置更短的TTL作为过渡。补齐后再次逐层请求，确认三层状态码一致，再观察一个缓存周期。
这个例子的数字仅用于说明比较方法，不代表任何真实站点的实际表现。
例外与适用条件
有些情况不适合强行统一。例如站点按地区返回不同语言版本的410页面，各层缓存键本就应包含地区字段，此时“不一致”是设计结果，不是故障。又如某些搜索引擎对410和404的处理周期不同，缓存层保留不同状态码可能是有意为之，需要先确认业务意图再决定是否合并。
另外，robots.txt的抓取限制不等于可靠的索引移除，站点地图不保证收录。定位缓存一致性时，不要把这些信号当作死链状态已正确处理的证据。请求量或抓取量归零也不能单独证明处理正确，它还可能来自抓取预算调整、外部链接减少或统计口径变化。
最后，如果各层缓存由不同团队维护，先约定一个共同的缓存键规范和失效通知格式，再逐层验证。验证通过后，把该URL加入监控列表，观察它在至少一个完整缓存周期内是否保持状态一致，再决定是否推广到其他死链。
