排除缓存造成的假象,核心方法是让同一个URL在“无缓存、无登录态、无本地历史”的环境下重新请求一次,再对比响应头与跳转链路。如果清缓存后跳转结果变了,说明之前看到的是缓存副本;如果结果不变,缓存就不是原因,应继续查服务器配置或中间层。这个判断适用于你已经设置了301跳转、但浏览器或工具显示的状态码、目标地址与预期不一致的情况。
301跳转本身是服务器返回的响应,但用户看到的“跳转结果”可能经过多层缓存。常见来源包括:浏览器本地缓存、CDN或反向代理缓存、服务器端页面缓存插件、以及搜索引擎自己的抓取缓存。不同层的表现不同,排查顺序也应不同。
不要只靠浏览器地址栏的变化判断。地址栏跳转成功,可能是浏览器自己记着上一次的301;地址栏没跳,也可能是缓存了旧的200响应。要看的是响应头里的状态码和Location字段。
curl -I -H "Cache-Control: no-cache" http://example.com/old-page,观察返回的是不是301,以及Location指向哪里。判断结果:如果命令行返回301且Location正确,而浏览器仍显示旧页面,问题在浏览器或本地缓存;如果命令行和浏览器都返回旧结果,但绕过CDN后正常,问题在CDN缓存;如果绕过CDN后仍是旧结果,问题在源站配置或服务端缓存。
301响应本身可以被缓存。查看响应头中的Cache-Control、Expires、Age等字段,能帮助判断缓存是否被允许、已存了多久。
Cache-Control: no-store或no-cache:表示不应直接复用缓存副本,出现旧结果更可能是其他层的问题。Cache-Control: max-age=...数值较大:浏览器或CDN可能在有效期内一直返回旧响应。Age大于0:说明响应来自缓存层,数值是已缓存的时间。这里要注意,修改Cache-Control只影响之后的请求,已经缓存的副本仍可能在有效期内继续被使用。所以验证时要同时做“清缓存”和“改配置”两步,不能只看配置改没改。
有些现象看起来像缓存,其实是配置本身的问题。可以用下面的对照来判断:
还要注意,robots.txt的抓取限制不等于可靠的索引移除,站点地图也不保证收录。这些手段不能用来替代对301响应本身的验证。
完成上述排查后,用以下信号确认缓存假象是否已排除:
Location指向预期目标。如果以上都满足,但某个特定工具或平台仍显示旧结果,应把该平台单独当作一个缓存层来核查,而不是继续修改301规则。下一步建议先固定一条测试命令和一组对比环境,把每次请求的状态码、Location和缓存相关响应头记录下来,再决定是清缓存、调缓存策略,还是修改跳转配置。