301转向,怎样排除缓存造成的假象

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

301转向,怎样排除缓存造成的假象

排除缓存造成的假象，核心是让“你看到的响应”和“服务器实际返回的响应”分开验证。301转向最容易出现的假象是：浏览器或中间缓存仍返回旧的 301，让你误以为规则没生效；或者反向，缓存里存着旧的 200，让你误以为还没转向。判断方法是绕开缓存直接请求源站，再对比带缓存请求的结果，两者不一致就说明存在缓存层干扰。

先明确要交付的验证结果

多人协作时，返工往往来自“凭感觉说已生效”。交付物应当是一份可复核的记录，至少包含四项：请求的完整 URL、请求时使用的工具或命令、返回的状态码、返回的 Location 头。缺任何一项，别人都无法判断你看到的是真实响应还是缓存副本。

建议按下面的清单逐项确认：

用直连源站的方式拿到真实响应

最直接的做法是向源站 IP 发起请求，并带上 Host 头，这样请求不会经过 CDN 或反向代理缓存。命令示例：

curl -I -H "Host: example.com" http://源站IP/old-path

如果返回 301 且 Location 正确，说明源站规则本身是对的。此时若通过域名访问仍看到 200 或旧的跳转目标，问题大概率在缓存层，而不是转向规则。注意这里说的“大概率”，因为也可能是 DNS 尚未切换或负载均衡有多台源站配置不一致，需要继续区分。

逐层排查可能的缓存位置

同一个现象可能有多个解释，不要一上来就断定是浏览器缓存。按从近到远排查：

  1. 浏览器缓存：用无痕窗口或禁用缓存后重新请求，仍返回旧结果则排除这一层。
  2. CDN 或反向代理缓存：查看响应头中是否有缓存命中相关字段，或直接在 CDN 控制台对该 URL 执行刷新。
  3. 本地 DNS 缓存：域名解析到旧 IP 时，请求会打到旧服务器，返回的自然是旧响应。
  4. 应用层缓存：部分框架会缓存重定向规则，改配置后需要重启或清缓存才生效。

只有逐层排除后剩下的那一层，才是已经定位的原因。把“可能原因”直接写成“问题原因”是协作中最常见的误导。

用对比请求确认缓存是否在起作用

一个可执行的判断方法：对同一 URL 发两次请求，一次带缓存绕过参数，一次不带，比较响应头。

curl -I http://example.com/old-path curl -I "http://example.com/old-path?nocache=1"

如果带参数的请求返回 301，不带参数的返回 200，说明缓存层按完整 URL 存储了旧响应。此时需要清理该 URL 的缓存，而不是修改转向规则。如果两次都返回 200，则转向规则可能根本没生效，应回到源站配置检查。

验收时写清适用条件

验收结论要注明测试环境：是直连源站、经过 CDN，还是普通浏览器访问。不同路径的结果可能不同，只写“已生效”没有意义。建议在交付记录中写明：源站直连返回 301 到目标地址，CDN 刷新后返回一致，浏览器无痕模式返回一致。三者都一致，才能判定转向在缓存层面没有假象。

下一步：按上面的清单对目标 URL 做一次直连源站请求，把状态码、Location 和请求命令记录到交付文档中，再决定是否需要清理缓存。

图1 图2
nginx