404错误排查,怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /13f1cd5b3159.html
📄
404错误排查,怎样排除缓存造成的假象
遇到404时，先别急着改服务器或重发页面。缓存造成的假象很常见：浏览器、CDN、反向代理或DNS缓存里仍保留着旧响应，你看到的404可能并不是源站现在的状态。排查顺序应该是先确认“这个404来自哪一层”，再决定要不要清理缓存或修正配置。
第一步：用无缓存请求确认源站真实状态
在浏览器开发者工具打开Network面板，勾选Disable cache后刷新页面，记录状态码和响应头。也可以用命令行请求并强制不使用本地缓存：
curl -I -H "Cache-Control: no-cache" https://example.com/page
如果命令行返回200，而浏览器仍显示404，说明问题在浏览器缓存或本地网络层；如果两者都返回404，则要转向源站路由、文件路径或服务端配置排查。这里的判断依据是同一URL在不同请求路径下的状态码差异，而不是页面外观。
第二步：检查CDN与反向代理缓存
CDN和反向代理可能缓存了旧的404响应。要查的是：缓存命中状态、缓存键规则、TTL设置以及是否有强制刷新入口。
- 查什么：响应头中的缓存命中标识，例如Age、X-Cache、CF-Cache-Status等。
- 怎么查：用命令行请求同一URL，对比首次请求和再次请求的响应头变化。
- 结果说明什么：如果首次请求返回200、再次请求返回404，且Age增大，说明中间层缓存了错误状态。此时应在CDN或代理层对该URL执行刷新，并检查缓存规则是否把404也纳入了长期缓存。
注意，刷新缓存只能解决“缓存内容与源站不一致”的问题。如果源站本身已经返回404，刷新缓存不会让页面恢复。
第三步：确认DNS与本地hosts是否指向旧环境
DNS缓存或本地hosts文件可能把域名解析到旧服务器，旧服务器上已没有该页面，于是返回404。
- 查什么：当前域名解析到的IP，以及本机hosts文件是否有该域名的记录。
- 怎么查：使用
nslookup example.com或dig example.com查看解析结果；检查系统hosts文件。 - 结果说明什么：如果解析IP与当前源站IP不一致，或hosts里写死了旧IP，应清理DNS缓存或删除hosts记录后重试。若解析一致但仍404，则排除这一层。
第四步：区分服务端缓存与静态文件缓存
服务端缓存插件、框架路由缓存、OPcache或对象缓存也可能保留旧路由。判断方法是：临时停用缓存层后请求同一URL，观察状态码是否变化。
- 如果停用后返回200：说明是缓存层保留了旧路由或旧响应，需要清理对应缓存并检查缓存失效策略。
- 如果停用后仍返回404：说明问题不在缓存，应检查文件是否真实存在、路由规则是否匹配、重写规则是否正确。
这一步的适用条件是你能控制或临时调整缓存配置。生产环境操作前应确认影响范围，避免因停用缓存导致源站压力上升。
第五步：用带随机参数的请求做交叉验证
在URL后加一个无意义的查询参数，例如?v=20240601，可以绕过部分按完整URL缓存的层。如果带参数返回200、不带参数返回404，通常指向缓存键或缓存规则问题；如果两者都返回404，则更可能是源站路由或文件缺失。
这个方法的局限是：部分缓存层会忽略查询参数，因此不能作为唯一证据，只能与响应头、命令行请求结果一起判断。
可执行清单
- 用无缓存命令行请求记录状态码。
- 对比浏览器与命令行的结果差异。
- 检查CDN或代理的缓存命中标识与TTL。
- 核对DNS解析与hosts文件。
- 临时停用服务端缓存后重试。
- 用随机参数请求做交叉验证。
- 确认源站文件、路由与重写规则是否正常。
完成以上检查后，如果确认是缓存层保留了旧404，下一步应针对该URL执行缓存刷新，并复查缓存规则是否会把404长期缓存；如果源站本身返回404，则应转向文件路径、路由配置或重定向规则的处理。
