要排除缓存造成的假象,核心做法是:先确认你看到的页面内容到底是来自源站、CDN边缘节点、浏览器本地缓存,还是搜索引擎自己的快照,再用带随机参数的URL、强制刷新和源站直连三种方式交叉验证。只有源站返回的内容与缓存层不一致时,才能判定是缓存问题,而不是服务器邻居网站本身的内容变化。
“服务器邻居网站”通常指同一台服务器或同一IP段上的其他站点。排查假象时,容易把不同层级的缓存混为一谈:
这四类现象看起来都像“页面没更新”,但处理方式完全不同。判断顺序应从最靠近你的一端开始:浏览器→CDN→源站→搜索引擎快照。
最直接的办法是对同一个URL发起三次请求,比较响应内容:
?cachebust=20240101这类无意义参数,强制绕过部分缓存层。如果普通访问是旧内容,带随机参数和源站直连都是新内容,说明缓存层没有及时更新,问题在CDN或反向代理。如果三种方式都返回旧内容,说明源站本身没有更新,和缓存无关。
用浏览器开发者工具的Network面板或命令行查看响应头,重点关注:
Cache-Control:是否设置了较长的max-age或s-maxage。Age:大于0说明响应来自缓存层,数值是已缓存秒数。X-Cache或类似字段:常见取值为HIT或MISS,HIT表示命中缓存。Last-Modified和ETag:用于判断源站内容是否真的变化。注意,不同CDN厂商的响应头字段名不一样,没有统一标准。看到HIT只能说明这一层命中了缓存,不能直接推断是哪一层。需要结合请求路径和节点信息判断。
确认是缓存问题后,按以下顺序处理:
适用条件:这套流程适合已有页面更新后显示不一致的场景。如果源站内容本身没有改动,刷新缓存不会产生新内容,此时应检查发布流程或数据库写入是否成功。
搜索引擎结果里的快照或摘要滞后,属于搜索引擎自己的缓存,和CDN缓存是两回事。robots.txt的抓取限制不等于可靠的索引移除,站点地图也不保证收录。要推动快照更新,可以检查页面是否可正常抓取、是否有noindex误设、内链是否指向该URL,然后通过搜索平台的URL检查工具提交刷新请求。不同搜索引擎的支持情况须分别核查,不能假设一家生效另一家也同步生效。
下一步:挑一个你怀疑被缓存影响的URL,按“普通访问、随机参数、源站直连”三种方式各请求一次,记录响应头中的Age和缓存命中字段,再决定刷新哪一层。