404错误排查,怎样排除缓存造成的假象

📍 WDQWDWQD987AAAAA:216.73.217.78
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5c6e51a94165.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设置以及是否有强制刷新入口。

注意，刷新缓存只能解决“缓存内容与源站不一致”的问题。如果源站本身已经返回404，刷新缓存不会让页面恢复。

第三步：确认DNS与本地hosts是否指向旧环境

DNS缓存或本地hosts文件可能把域名解析到旧服务器，旧服务器上已没有该页面，于是返回404。

  1. 查什么：当前域名解析到的IP，以及本机hosts文件是否有该域名的记录。
  2. 怎么查：使用nslookup example.com或dig example.com查看解析结果；检查系统hosts文件。
  3. 结果说明什么：如果解析IP与当前源站IP不一致，或hosts里写死了旧IP，应清理DNS缓存或删除hosts记录后重试。若解析一致但仍404，则排除这一层。

第四步：区分服务端缓存与静态文件缓存

服务端缓存插件、框架路由缓存、OPcache或对象缓存也可能保留旧路由。判断方法是：临时停用缓存层后请求同一URL，观察状态码是否变化。

这一步的适用条件是你能控制或临时调整缓存配置。生产环境操作前应确认影响范围，避免因停用缓存导致源站压力上升。

第五步：用带随机参数的请求做交叉验证

在URL后加一个无意义的查询参数，例如?v=20240601，可以绕过部分按完整URL缓存的层。如果带参数返回200、不带参数返回404，通常指向缓存键或缓存规则问题；如果两者都返回404，则更可能是源站路由或文件缺失。

这个方法的局限是：部分缓存层会忽略查询参数，因此不能作为唯一证据，只能与响应头、命令行请求结果一起判断。

可执行清单

  1. 用无缓存命令行请求记录状态码。
  2. 对比浏览器与命令行的结果差异。
  3. 检查CDN或代理的缓存命中标识与TTL。
  4. 核对DNS解析与hosts文件。
  5. 临时停用服务端缓存后重试。
  6. 用随机参数请求做交叉验证。
  7. 确认源站文件、路由与重写规则是否正常。

完成以上检查后，如果确认是缓存层保留了旧404，下一步应针对该URL执行缓存刷新，并复查缓存规则是否会把404长期缓存；如果源站本身返回404，则应转向文件路径、路由配置或重定向规则的处理。

图1 图2
nginx