📍 WDQWDWQD987AAAAA:216.73.217.37
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d1190543f3ee.html
📄

URL重定向技术：怎样排除缓存造成的假象

要排除缓存造成的假象，核心方法是把“你看到的响应”与“服务器实际发出的响应”分开验证。也就是在浏览器之外，用不带本地缓存、能显示完整响应头的工具重新请求一次，再对比状态码、Location 头和最终 URL 是否一致。下面从一个假设的协作场景展开，说明具体步骤和常见错误。

一个假设的协作返工场景

假设团队把 /old-page 重定向到 /new-page，A 同事在浏览器里访问 /old-page，看到地址栏停在 /old-page，页面却显示新内容，于是判断“重定向没生效”。B 同事在另一台机器上看到地址栏跳到了 /new-page。两人结论相反，交付卡住。

这种分歧最常见的原因就是缓存：浏览器可能缓存了旧的 301 响应，或者缓存了旧页面本身，导致地址栏、页面内容和服务器当前配置对不上。注意这里说的是“可能原因”，不是已经定位的原因；必须用下面的方法逐项确认。

用无缓存请求看真实响应

先绕开浏览器缓存，直接观察服务器返回什么。可以用命令行工具发起请求并只看响应头：

curl -I -H "Cache-Control: no-cache" https://example.com/old-page

判断要点：

• 状态码是 301、302、307、308 还是 200。若为 200，说明服务器当前没有对该路径做重定向。
• 响应头里是否有 Location，它的值是否指向预期的目标 URL。
• 再加 -L 跟随跳转，观察最终落到哪个地址，以及中间经过几次跳转。

如果命令行结果与浏览器结果不同，基本可以判断浏览器侧存在缓存或旧状态；如果两者相同，问题就不在缓存，而在重定向配置本身，例如规则顺序、匹配条件或目标地址写错。

区分几种容易被误判为缓存的情况

不是所有“看起来没跳”都是缓存。需要分开判断：

• 重定向被缓存：浏览器或中间层保存了旧的 301，之后不再回源查询。此时命令行看到的是新配置，浏览器看到的是旧结果。
• 页面内容被缓存：跳转其实已发生，但目标页返回的是旧版本内容，让人误以为没更新。
• 重定向链未走完：A 跳到 B、B 又跳回 A，或跳到第三个地址，地址栏表现会与预期不符。
• 规则未匹配：请求路径大小写、结尾斜杠、查询参数不同，导致规则没触发，与缓存无关。

逐项排除时，先固定一个完全相同的请求 URL，再改变缓存条件，才能把变量控制住。

多人协作时的交付检查清单

为了减少返工，交付前把下面几项写成可复现的记录，而不是只写“已生效”：

1. 记录测试用的完整 URL，包含协议、路径、结尾斜杠和查询参数。
2. 记录命令行请求返回的状态码与 Location 值。
3. 记录浏览器无痕窗口或清除缓存后的结果，并注明使用的浏览器。
4. 若涉及搜索引擎表现，分别核查不同搜索引擎的抓取与索引情况，不要用一次结果推断全部。
5. 说明 robots.txt 只限制抓取，不等于可靠的索引移除；站点地图也不保证收录。

这样交付后，其他人能按同样条件复现，出现分歧时可以直接对比数据，而不是争论“我这边是好的”。

验证缓存假设的下一步

下一步是固定一个 URL，先用无缓存命令行请求拿到状态码和 Location，再在无痕窗口访问同一 URL，把两组结果并列记录。若两者不一致，继续检查浏览器缓存、CDN 或反向代理层的缓存策略；若两者一致但仍不符合预期，就回到重定向规则本身，检查匹配条件与跳转目标。