301重定向：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f37c1f316132.html
📄
301重定向：多层缓存返回不同版本时怎样定位一致性问题
当同一URL在CDN边缘、反向代理和浏览器本地分别返回不同结果时，问题通常不在301规则本身，而在各层缓存对旧响应的保留策略不同。判断顺序应当是：先确认哪一层仍在返回旧版本，再决定是等待缓存过期、主动失效，还是从源头修正301目标。缺少完整日志和刷新权限时，最小可执行动作是用带唯一查询参数的请求绕过缓存，比对同一路径的响应差异，但这只能证明某一层是否命中缓存，不能据此断定301规则已正确或错误。
先区分两种条件：你能控制缓存失效，还是只能观察
能控制缓存失效时，排查可以主动推进。对疑似不一致的URL，分别向源站、反向代理和CDN边缘发起请求，记录每层返回的状态码、Location头和缓存相关响应头，例如 Age、Cache-Control、X-Cache 一类由各层自行添加的标记。若源站已返回新目标，而边缘仍返回旧目标，说明问题集中在边缘缓存未失效，而不是301规则写错。
只能观察、没有刷新权限时，选择完全不同。此时不要反复修改301规则来“试”，因为规则变更可能让新请求走新逻辑，而旧缓存继续服务另一批用户，反而扩大版本分裂。更稳妥的动作是固定一组测试URL，按固定时间间隔记录各层响应，观察旧版本是否随缓存寿命自然消退。若旧版本在超过该层声明的缓存时间后仍存在，才值得把证据交给有权限的一方处理。
两种条件的分界不是“有没有日志”，而是“能否让某一层立即停止返回旧响应”。不能做到这一点时，任何结论都只是相关性，不能当成因果。
用唯一参数请求做最小定位，并明确它证明不了什么
在URL后附加一个此前未出现过的查询参数，例如 ?cache_probe=日期时间，通常会让多数缓存层把它视为新对象，从而回源获取最新响应。把带参数与不带参数的响应并排比较，可以得到一个有用信号：
- 带参数请求返回新目标，不带参数返回旧目标，倾向于说明缓存层保留了旧版本；
- 两者都返回旧目标，倾向于说明源站或应用层仍在输出旧301；
- 两者都返回新目标，但部分用户仍报告旧版本，倾向于说明问题在更靠近用户的层，例如浏览器本地缓存或中间网络缓存。
这个动作的结果会直接决定下一步：若差异出现在边缘层，下一步是核对缓存键和失效机制；若差异出现在源站，下一步才是检查301规则、目标页和重定向链。需要说明的是，带参数请求返回新版本，不能证明不带参数的普通用户也会很快拿到新版本，因为缓存键、缓存寿命和失效范围可能不同。查询参数归零或抓取量下降，也不能单独证明缓存问题已解决，它还可能来自请求样本变化、日志延迟或测试方式改变。
检查缓存键：同一URL为何被当成多个对象
多层缓存不一致，常见原因是各层对“同一个资源”的定义不同。有的层把主机名、路径、查询参数、请求头中的 Accept-Encoding 或 Vary 响应头纳入缓存键，有的层只认路径。结果是同一路径被存成多个版本，用户命中哪一个取决于请求特征，看起来就像301时好时坏。
可执行动作是：对同一路径分别发送带与不带常见请求头的请求，比较返回的 Vary 和缓存标记。如果不同请求头组合返回不同目标，就要把缓存键规则和301规则放在一起看，而不是只改其中一处。例外是：若该层明确不缓存301响应，或缓存寿命极短，那么缓存键差异通常不是主因，应把注意力转回源站规则和重定向链。
从源头修正还是等待过期：按影响面选择
若旧版本只影响少量测试路径，且缓存寿命已知，等待自然过期是成本较低的选择。若旧版本影响的是应当统一跳转的核心路径，且各层缓存寿命不一致，等待会让不一致持续更久，此时应优先从源头修正301目标，再推动各层失效。
需要强调一个边界：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。因此，即使301在源站已正确，也不能用“已提交站点地图”或“已限制抓取”推断旧版本一定不再出现。HTTPS 同样不保证安全无漏洞或排名，它和缓存版本一致性是不同层面的问题。不同搜索引擎对301和缓存的处理须分别核查，不能把一处的观察结果直接套用到另一处。
假设例子：三层返回三个目标时怎么收敛
假设某路径在源站返回目标A，反向代理返回目标B，CDN边缘返回目标C。先不修改任何规则，而是对三层分别记录响应头和缓存寿命。若源站是A且规则文件确实指向A，则B和C属于下游缓存旧版本；此时动作是推动反向代理和CDN失效，而不是改源站。若源站本身返回B，则先修正源站301，再处理下游。这个例子的数字和层数只为说明比较方法，不代表任何真实项目的观测结果。
最终判断标准是：同一路径在明确绕过缓存的请求下返回什么，以及各层声明的缓存寿命是否已经过去。只有这两点都清楚，才能决定是改规则、刷缓存，还是继续观察。
