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

301重定向 - 如何排除缓存造成的假象

排除缓存假象的核心做法是：不要只看浏览器当前显示的结果，而要用带缓存规避参数的请求、不同网络环境以及服务器响应头三方面交叉验证。如果带随机参数的请求返回301，而普通访问仍显示旧页面，基本可以判断是缓存层在起作用，而不是重定向本身失效。

先分清三类缓存，判断问题出在哪一层

301重定向出现“假象”，通常来自三个位置，排查顺序应从近到远：

• 浏览器缓存：浏览器会长期记住301。你之前访问过旧地址，之后即使服务器改了规则，浏览器仍可能直接跳转或直接显示旧内容，不向服务器发请求。
• 中间缓存：CDN、反向代理、公司网关可能缓存了旧的301响应。此时换浏览器没用，因为缓存不在你本机。
• 搜索引擎缓存：搜索结果里仍显示旧标题、旧链接，这属于索引层面的滞后，和服务器是否已经返回301是两件事。

判断方法：用无痕窗口加随机查询参数访问，例如 https://example.com/old-page?cachebust=20240101。如果带参数时正确跳转，不带参数时显示旧页面，问题多半在缓存层；如果两者都不跳转，问题在服务器配置本身。

用响应头确认服务器到底返回了什么

浏览器地址栏会隐藏中间过程，必须看响应头。可以用命令行工具执行：

curl -I https://example.com/old-page

重点看第一行状态码和 Location 字段：

• 返回 301 且 Location 指向新地址，说明服务器规则正确。
• 返回 200，说明旧地址仍在正常输出内容，重定向没有生效。
• 返回 302 或 307，说明用的是临时跳转，长期看与301效果不同。
• 返回 301 但 Location 指向错误地址，说明规则写错，与缓存无关。

如果 curl 返回301，而浏览器仍显示旧内容，可以确定是浏览器或中间缓存的问题，而不是服务器没配好。这一步能把“缓存假象”和“配置错误”彻底分开。

清除与绕过缓存的执行步骤

时间和人手有限时，按下面顺序做，先做代价最低的：

1. 用无痕窗口访问旧地址，排除本机浏览器缓存。
2. 在旧地址后加一个从未用过的查询参数，强制绕过缓存键。
3. 换一个网络环境，例如从公司网络切到手机热点，排除网关或CDN缓存。
4. 用 curl -I 直接看响应头，确认状态码和跳转目标。
5. 如果以上都正常，只剩搜索结果仍显示旧页面，那属于索引更新滞后，不是缓存假象，继续等待或通过站点工具提交新地址即可。

适用条件：这套流程针对的是“服务器已配置301，但看到的結果不一致”的情况。如果服务器根本没配301，第一步就会暴露，无需继续排查缓存。

容易被误判成缓存的情况

有几种现象看起来像缓存，实际原因不同：

• 跳转链过长：A跳B、B再跳C，浏览器可能停在中间页面。用 curl -IL 跟踪完整跳转链可以看清。
• 页面内嵌了旧资源：主文档已跳转，但页面里的图片、脚本仍是旧地址，看起来像没生效。
• robots.txt 限制抓取：这会影响搜索引擎抓取，但不等于能从索引中移除已有页面，也不等于重定向失效，两者要分开看。
• HTTPS 与 HTTP 混用：旧地址是 HTTP、新地址是 HTTPS 时，可能先发生协议跳转再发生路径跳转，中间状态容易被误读。

这些情况的共同点是：响应头往往已经正确，问题出在跳转链、页面内容或索引层面。先看响应头，再决定是否继续查缓存，能省下大量时间。

下一步该做什么

拿一个你正在处理的旧地址，执行 curl -I 并记录状态码与 Location；再在无痕窗口加随机参数访问同一地址。两组结果一致，说明配置和缓存都没问题，剩下的只是索引更新；两组结果不一致，优先清理CDN或中间层缓存，而不是反复修改301规则。