📍 WDQWDWQD987AAAAA:216.73.216.250
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d3274908a0fb.html
📄

404错误页面怎样排除缓存造成的假象：交付前先分清真404与缓存旧页

要排除缓存造成的假象，核心做法是：先用带随机查询参数的网址、无痕窗口和强制刷新请求一次，再看服务器实际返回的状态码与响应头。如果源站返回200而浏览器仍显示404，问题多半在浏览器、CDN或反向代理缓存；如果源站本身就返回404，那就是内容或路由问题，与缓存无关。多人协作时，把“谁在什么条件下看到404”写清楚，比反复截图更省返工。

先确认你看到的404来自哪一层

404可能由浏览器缓存、CDN边缘节点、反向代理、应用路由或源站文件缺失分别产生。判断顺序应从离你最近的一层开始，逐层向外验证，不要一上来就改服务器配置。

• 要查什么：浏览器是否用了旧缓存。在无痕窗口打开同一网址，或按 Ctrl+F5（Mac 用 Cmd+Shift+R）强制刷新。
• 怎么查：打开开发者工具的 Network 面板，勾选 Disable cache，重新加载，记录该请求的 Status Code 和 Response Headers。
• 结果说明什么：无痕下正常、普通窗口404，说明是本地浏览器缓存；两者都404，继续查下一层。

用查询参数绕过缓存做一次干净请求

在网址末尾加一个无意义的查询参数，例如 ?cachebust=20240601，多数缓存会把带不同参数的网址当作不同资源，从而回源。这是判断“缓存旧页”还是“源站真404”的最快手段。

• 要查什么：带参数请求是否仍返回404。
• 怎么查：用 curl -I "https://你的域名/路径?cachebust=1" 只看响应头，或用浏览器无痕访问同一带参网址。
• 结果说明什么：带参正常、不带参404，基本可判定为缓存层持有旧结果；带参也404，则源站或路由确实没有该资源。

注意：查询参数绕过缓存只是诊断手段，不要把它当作长期修复方案，也不要把带参网址当作正式链接对外发布。

检查响应头里的缓存线索

响应头能告诉你缓存是谁、缓存了多久。重点看 Cache-Control、Age、X-Cache、CF-Cache-Status 等字段，不同服务商字段名不同，以实际返回为准。

• 要查什么：当前返回是命中缓存还是回源。
• 怎么查：在开发者工具或 curl -I 输出中找上述字段。
• 结果说明什么：出现 Age 大于0或缓存命中标识，说明内容来自缓存节点；此时源站状态需另发一次绕过缓存的请求确认。

如果 Cache-Control 设置了较长的 max-age 或 s-maxage，旧404可能在整个缓存周期内持续出现。修改源站后，需要按缓存服务商提供的刷新方式清理对应网址，而不是只等它自然过期。

多人协作时的交付清单

协作场景下，返工往往来自“我看到404、你看到正常”却没人记录条件。建议每个404问题都按下面清单留痕：

1. 记录原始网址：完整路径，含或不含查询参数分别写明。
2. 记录访问环境：浏览器、是否无痕、是否登录、所在网络或地区。
3. 记录状态码与响应头：截图或粘贴关键字段，不只写“打不开”。
4. 记录复现步骤：第一步做什么、第二步做什么，让别人能重复出同样结果。
5. 记录处理动作：是否清过缓存、是否改过源站、改后谁再验证一次。

这份清单的价值在于：当问题再次出现时，能直接判断是同一缓存节点未刷新，还是源站配置被回滚，减少重复排查。

确认源站状态后再决定修复方向

如果绕过缓存后源站返回404，就不要继续在缓存上花时间。此时应检查文件是否存在、路由规则是否匹配、大小写是否一致、是否被重写规则误导向404。反过来，如果源站返回200而用户仍看到404，就集中处理缓存刷新与缓存策略，例如缩短静态资源的缓存时间、对HTML设置更短的 max-age，或对已删除页面主动下发清理。

需要区分的是：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些与缓存假象是不同层面的问题，排查时不要混在一起改。

下一步：选一个当前被报告为404的网址，按上面的顺序做一次带参请求、无痕访问和响应头记录，把三项结果填进协作清单，再决定是清缓存还是改源站。