URL重定向，多层缓存返回不同版本时怎样定位一致性问题
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /314541eef7fe.html
📄
URL重定向，多层缓存返回不同版本时怎样定位一致性问题
先接受一个前提：当CDN、反向代理、应用层缓存和浏览器缓存同时存在时，同一请求在不同层看到不同响应，通常是各层缓存键、缓存时长或重定向状态码被分别处理的结果，而不一定是重定向规则本身写错。要定位一致性，最有效的做法不是逐层刷新，而是固定一个测试URL，记录每层返回的状态码、Location和缓存命中标记，再比较差异出现在哪一跳。
先确定比较对象：一条重定向链在四层缓存中的实际表现
假设手头有一个从旧地址跳转到新地址的页面：https://example.com/old 应返回301，Location指向 https://example.com/new。你可以在同一时刻分别从四个位置请求它：浏览器开发者工具的Network面板、命令行直接访问源站、带CDN调试头访问边缘节点、以及通过代理查看反向代理层。关键不是看“有没有跳”，而是记录四项：HTTP状态码、Location值、响应头中的缓存相关字段、以及响应是否来自缓存。
如果浏览器看到302，而源站返回301，差异就集中在浏览器或中间层对301的缓存策略上。如果CDN边缘返回301但源站返回302，说明CDN缓存了旧响应，或者缓存键把不同版本混在一起。如果所有层状态码一致但Location不同，问题更可能出在应用层根据请求头生成目标地址，而不是缓存层。这个记录动作会直接决定下一步：状态码不同去查缓存时长和缓存键，Location不同去查应用逻辑和请求头。
两种处理顺序的取舍：先清缓存还是先固定缓存键
面对多层缓存不一致，常见两种做法。第一种是逐层清除缓存，然后重新验证。第二种是先固定缓存键和缓存时长，再决定是否清除。两者成立的条件不同。
- 先清缓存适合：你已经确认规则本身正确，只是旧响应残留；且各层缓存可以分别清除，清除后能立即回源验证。代价是，如果缓存键本身有问题，清完很快又会出现不一致，你需要反复操作。
- 先固定缓存键适合：同一URL在不同设备、不同协议或不同查询参数下返回不同重定向目标。此时清缓存只能暂时掩盖问题，必须先统一缓存键的组成，例如是否包含Host、协议、Accept-Language或特定查询参数。代价是需要改动CDN或代理配置，验证周期更长。
判断依据可以很具体：如果清除某一层缓存后，该层返回与源站一致，但过一段时间又变回旧版本，说明问题在缓存键或缓存时长，不在残留。如果清除后一直保持一致，才说明是残留。这个判断动作会决定你是否继续追缓存键，而不是反复清缓存。
用一组可区分原因的证据缩小范围
不要只凭“刷新后好了”下结论。以下证据可以帮助区分原因：
- 同一URL加一个不会影响应用的查询参数，例如
?cachebust=1，如果返回正确，说明原URL被缓存了旧响应；如果仍返回错误，说明规则或应用逻辑有问题。 - 直接请求源站IP并带上Host头，如果源站返回正确，而CDN边缘返回错误，问题在CDN缓存或回源配置。
- 检查响应头中的缓存时长字段。如果CDN缓存时长长于源站设置，边缘可能继续提供旧重定向。
- 对比HTTP和HTTPS。如果只有HTTPS返回错误重定向，问题可能在协议判断或跳转规则，而不是缓存。
- 对比带尾斜杠和不带尾斜杠。如果只有一种形式错误，问题在规范化规则，不在缓存层。
这些证据不需要全部收集，但至少应记录两项：加随机参数后的结果，以及直接回源的结果。两者结合，通常能把问题锁定在缓存层或规则层。
一个假设例子：从一条错误Location倒推处理方案
假设某页面应301到 https://example.com/new，但CDN边缘返回301到 http://example.com/new，源站返回301到 https://example.com/new。此时可以按以下顺序处理：
第一步，直接回源确认源站Location正确。第二步，在CDN边缘请求同一URL，确认边缘Location错误。第三步，检查CDN缓存键是否包含协议，以及回源请求是否携带了 X-Forwarded-Proto。如果回源请求没有携带正确的协议信息，应用层可能生成HTTP目标，CDN再把该响应缓存下来。第四步，修正回源协议头或缓存键后，再清除该URL的边缘缓存。这个动作的结果是：边缘返回与源站一致。如果修正后仍不一致，下一步应检查CDN是否还有上层缓存或浏览器缓存未更新，而不是继续改重定向规则。
这个例子是假设的，数字和字段仅用于说明比较方法。实际环境中，缓存键和回源头的名称可能不同，需要按你使用的CDN或代理文档核查。
把处理方案落到一个可重复的验证动作
无论最终选择先清缓存还是先固定缓存键，都需要一个可重复的验证动作：固定同一个测试URL，在源站、边缘、代理和浏览器四个位置各请求一次，记录状态码、Location和缓存命中标记。每次修改配置后重复这个动作，而不是只在一个位置刷新。只有当四个位置返回一致，并且连续两次请求都一致，才能认为该URL的重定向一致性问题已经收敛。如果只有部分位置一致，下一步应继续追该位置对应的缓存层，而不是扩大范围改规则。
需要留意的是，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些与缓存一致性不是同一类问题，不要用它们来解释重定向版本差异。把验证动作固定下来，比反复清除所有缓存更能帮助你判断问题是否真正解决。
