永久重定向方法：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a5a709209547.html
📄
永久重定向方法：多层缓存返回不同版本时怎样定位一致性问题
先给结论：多层缓存下不同地区、不同设备看到不同跳转结果，通常不是永久重定向本身写错了，而是某一层缓存保存了旧响应或缓存键划分不一致。要定位它，不能反复刷新同一个地址，而要用带缓存标识的请求逐层比对响应头，找出第一层开始出现分歧的位置。
为什么同一规则会返回两个版本
假设源站已经把旧路径 /old-a 永久重定向到 /new-a，但边缘节点、反向代理和浏览器三层缓存中，只有部分层更新了规则。此时你会看到一种矛盾现象：同一台电脑换浏览器结果一致，换网络环境却落到另一个地址；或者桌面端正常，移动端仍停在旧路径。
这种矛盾往往不是规则冲突，而是缓存副本的生命周期不同步。永久重定向的响应通常允许被较长时间缓存，一旦某层缓存把它当作可长期保存的响应，后续即使源站改了目标地址，这一层仍会返回旧版本。
两个主要解释：旧缓存副本，还是缓存键不一致
第一种解释是旧缓存副本尚未过期。源站已经更新，但某一层缓存仍持有旧的 301 响应，直到该副本被清除或自然过期。它的特征是：同一层缓存对所有请求都返回旧版本，且响应头里能看到较旧的缓存时间或命中标记。
第二种解释是缓存键划分不一致。不同层可能把 Host、协议、路径大小写、查询串或设备类型纳入缓存键，而源站规则只按路径匹配。结果是同一路径在不同缓存键下被存成多个副本，一部分指向新地址，一部分仍指向旧地址。它的特征是：结果随请求特征变化，而不是随缓存层固定不变。
用哪些证据区分这两种解释
可以按下面的顺序收集证据，每一步的结果都会决定下一步该查哪里。
- 先固定一个请求特征，只改变缓存层。用同一路径、同一协议、同一 Host 发起请求，记录每一层返回的状态码和 Location。如果只有某一层始终返回旧目标，倾向旧缓存副本。
- 再固定缓存层，只改变请求特征。分别用带与不带查询串、不同大小写路径、不同协议发起请求。如果结果随特征变化，倾向缓存键不一致。
- 检查响应头中的缓存年龄、命中状态和变体标记。如果同一路径出现多个不同的缓存年龄，说明存在多个副本；如果年龄一致但目标不同，说明缓存键把请求分到了不同副本。
- 回到源站直接请求，确认源站只返回一个目标。如果源站本身返回两个目标，问题不在缓存，而在规则匹配顺序或路径归一化。
假设一个短例子：源站把 /old-a 指向 /new-a，但边缘缓存把 /old-a?from=nav 和 /old-a 存成两个副本，其中一个尚未更新。此时直接请求路径得到新地址，带查询串请求得到旧地址。这个结果说明分歧来自缓存键，而不是源站规则，下一步应统一缓存键或让源站对带查询串的请求也返回同一目标，而不是先清空所有缓存。
定位后该先动哪一层
如果证据指向旧缓存副本，优先处理持有旧副本的那一层，清除或等待其过期，然后再验证其他层是否同步。如果证据指向缓存键不一致，先统一各层对路径、协议和查询串的处理方式，再清除受影响的副本，否则清完仍会重新生成两个版本。
需要提醒的是，抓取限制或站点地图提交都不能替代对缓存响应的直接比对，也不能证明索引已经一致。HTTPS 只解决传输层问题，不保证缓存层返回同一版本。不同缓存产品对变体和过期时间的处理不同，具体行为要按实际部署逐层核查。
最后，把每次请求的路径、请求特征、命中的缓存层和目标地址记录下来。只要记录足够细，就能看出分歧是从哪一层、哪一个请求特征开始的，而不是靠反复刷新碰运气。
