404 not found - 怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /750de676c81b.html
📄
404 not found - 怎样排除缓存造成的假象
遇到404 not found时，先别急着改服务器或删页面。缓存造成的假象很常见：浏览器、CDN、反向代理都可能保存旧的错误响应，让你看到的404并不代表源站当前状态。判断起点是：用不同网络、不同设备、带随机查询参数直接请求源站，对比响应是否一致。如果源站返回200而缓存层返回404，问题就在缓存，不在页面本身。
先分清是浏览器缓存还是服务端缓存
浏览器缓存只影响你自己的设备，换一台设备或开无痕窗口就能验证。服务端缓存影响所有访客，必须从响应头判断。重点看这几个字段：Cache-Control、Age、X-Cache、CF-Cache-Status（不同CDN名称不同）。如果Age大于0，说明响应来自缓存；如果X-Cache显示HIT，说明命中了中间缓存层。
- 浏览器缓存假象：本机看到404，手机流量访问正常。
- CDN缓存假象：多地访问都404，但源站IP直接请求返回200。
- 应用层缓存假象：源站日志显示没有收到请求，说明请求被前置缓存拦截。
这三种情况的处理入口完全不同，先定位层级再动手。
用带随机参数的请求绕过缓存
在URL后面加一个无意义的查询参数，例如?v=20240611a，让缓存键发生变化。如果加了参数后返回200，去掉参数又变回404，基本可以确认是缓存按原URL存了错误结果。这个方法的适用条件是：页面本身确实存在，且源站能正常响应。如果加参数后仍然404，就要转向检查源站路由、文件是否存在或重写规则。
注意：有些缓存会忽略查询参数，或者只按路径缓存。这时需要改用curl直接请求源站IP并带上Host头，例如：curl -I -H "Host: example.com" http://源站IP/路径。返回200说明源站正常，返回404说明源站本身就没有这个资源。
检查缓存规则是否把404也缓存了
不少CDN和反向代理默认会缓存404响应，尤其是设置了较长的TTL时。你需要确认两件事：一是404响应是否被纳入缓存；二是缓存过期时间有多长。如果404被缓存且TTL很长，即使源站已经恢复，访客仍会持续看到404。
处理方式是：在缓存配置中排除404状态码，或者对404设置很短的缓存时间。已经缓存的错误响应需要主动清除，不同平台操作不同，但判断依据一致——清除后再次请求，看响应头中的Age是否归零、X-Cache是否变为MISS。
从交付结果倒推需要准备什么
假设目标是“让这个URL对所有访客恢复正常”，你需要准备：源站正确的响应证据、缓存层配置的查看权限、清除缓存的执行权限，以及验证用的多个网络出口。任务分工上，确认源站状态通常由开发或运维负责，缓存规则调整由CDN或运维负责，最终验收由提出问题的角色完成。
验收标准可以写成三条：第一，不带参数的原始URL返回200；第二，响应头中不再出现异常的缓存命中标记；第三，至少两个不同网络环境访问结果一致。满足这三条，才能认为缓存假象已经排除。
下一步做什么
先做一次最小验证：用无痕窗口和手机流量分别访问同一URL，记录状态码和响应头中的缓存字段。如果两者结果不同，优先排查浏览器缓存；如果结果相同且都404，用带随机参数的URL请求源站。根据返回结果，你就能确定是继续清缓存，还是转向检查源站路由和文件是否存在。
