404页面设置 - 怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5224d0f52da1.html
📄
404页面设置 - 怎样排除缓存造成的假象
404页面设置改完后，如果访问旧地址仍返回200或仍显示旧内容，先不要判定设置失败。最常见的情况是中间缓存或本地缓存仍在提供旧响应。判断的关键是看响应头与缓存层，而不是只看浏览器画面。只要绕开缓存后状态码和页面内容都符合预期，就可以确认设置本身已经生效，剩下的工作是清理缓存或等待缓存过期。
先分清三种“看起来没生效”
多人协作时，返工往往来自把不同问题混在一起。下面三种现象的处理方式完全不同：
- 浏览器本地缓存：你一个人看到旧页面，其他同事或无痕窗口看到的是新404页。问题在客户端，不在服务器。
- CDN或反向代理缓存：所有访问者都看到旧响应，响应头里带有缓存命中标识，源站日志甚至没有收到这次请求。
- 设置确实没生效：绕开所有缓存后，旧地址仍返回200，说明规则、路由或发布流程有问题。
只有先定位到哪一层，才能决定是清缓存、改配置还是改代码。
用响应头替代肉眼判断
浏览器地址栏显示什么并不可靠，状态码和缓存头才是依据。在命令行执行一次带完整响应头的请求：
curl -I https://example.com/old-page
重点看三行：
HTTP/1.1 404或200：这是源站或缓存返回的状态码。Cache-Control、Age、X-Cache：出现Age大于0或命中标识，说明响应来自缓存。Last-Modified、ETag：与上次记录对比，可以判断内容是否真的更新过。
如果加上绕过缓存的参数后状态码变成404，而直接请求仍是200，基本可以确认是缓存层在提供旧响应。这里要区分“可能是缓存”和“已经定位到缓存”：只有响应头明确显示命中，才算定位成功。
分层绕开缓存做对比
按从近到远的顺序逐层排除，每一步都记录结果，避免多人重复劳动：
- 用无痕窗口或换一个浏览器访问，排除本地缓存与登录态干扰。
- 在URL后加一个随机查询参数，例如
?v=20240101，多数缓存会把它当作新资源，从而回源。 - 直接请求源站IP或内部测试域名，跳过CDN，观察源站返回的状态码。
- 在CDN控制台执行缓存刷新，只刷新该路径，再重新请求并记录响应头。
适用条件：站点确实经过CDN或反向代理。如果请求直接打到源站，第3步和第4步可以省略。判断结果：绕开后为404、直连为200，说明缓存是唯一变量；两者都是200，则问题在源站设置。
缓存策略决定清理代价
404页面的缓存时间越长，修正后生效越慢，这是需要提前权衡的代价：
- 设置较长缓存时间：回源压力小、访问快，但改错后需要手动刷新，协作中容易产生“改了没用”的误会。
- 设置较短缓存时间：修改后很快生效，但回源请求增多，源站负载上升。
对还在调整的404页面，建议先用较短缓存时间，确认稳定后再延长。不要依赖“等一会儿就好”，因为不同缓存层过期时间不同，等待期间团队成员看到的结果可能不一致。
交付时留下可核对的信息
为减少返工，改动404页面设置时，在交付说明里写清三件事：改动的具体路径、请求后应返回的状态码、执行过的缓存刷新操作。接收方按同样的命令核对，而不是凭截图判断。若多人同时改缓存和页面内容，先约定谁负责刷新、刷新哪一层，避免互相覆盖。
下一步：挑一个已改过的旧地址，用上面的命令分别记录直连和绕开缓存的结果，把两组响应头放进交付记录，再决定是否需要刷新缓存或修改源站规则。
