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

自定义404错误页，怎样排除缓存造成的假象

排查自定义404错误页是否真的生效时，最容易遇到的假象是：浏览器、CDN或反向代理返回的仍是旧页面或旧状态码，让你误以为配置失败或成功。要排除缓存干扰，核心方法是让请求绕过缓存层，或强制缓存层回源，再对比不同来源的响应。判断顺序建议先看响应头，再用无缓存请求验证，最后才去改配置。

先分清是哪一层在“骗”你

自定义404错误页涉及至少三层缓存：浏览器本地缓存、CDN或反向代理缓存、服务端应用缓存。任何一层返回旧内容，都会造成假象。判断依据是响应头中的Age、Cache-Control、X-Cache、CF-Cache-Status等字段，不同厂商字段名不一样，需要按实际服务商文档核对。

• 浏览器缓存假象：换无痕窗口或禁用缓存后结果变化，说明之前看到的是本地副本。
• CDN缓存假象：同一URL在不同地区或不同节点返回不同状态码，可能是节点缓存未刷新。
• 应用缓存假象：服务端模板或页面片段被缓存，导致404页面内容更新但状态码仍是旧的。

用带随机参数的请求强制绕过缓存

最直接的一步是在URL后加一个无意义的查询参数，例如?cachebust=20240101。多数缓存策略把带不同查询串的URL视为不同资源，从而回源。执行后观察两点：返回的状态码是否为404，页面内容是否为最新版本。

适用条件：仅用于验证，不要把这个参数写进站内链接或站点地图。判断结果：如果加参数后状态码正确、内容正确，去掉参数又变回旧结果，基本可以定位为缓存层问题，而不是自定义404配置本身错误。

对比命令行与浏览器的响应差异

浏览器会带入本地缓存和Cookie，命令行工具更接近爬虫看到的原始响应。用curl -I查看响应头，用curl -s查看正文，再与浏览器结果对比。若命令行返回404且正文正确，浏览器仍显示旧页，优先怀疑浏览器缓存或Service Worker。

检查项：

1. 请求一个确定不存在的路径，例如/this-page-should-not-exist-123。
2. 记录状态码、Content-Type、响应体前几行。
3. 更换网络或使用不同出口IP重复一次，观察CDN节点差异。
4. 若使用Service Worker，在开发者工具中勾选绕过网络或注销后再测。

刷新缓存前先确认代价

刷新CDN缓存通常按URL或目录提交，量大时耗时且可能产生费用；刷新浏览器缓存只需用户端操作，但无法影响其他访客。时间和人手有限时，优先做只读验证，确认问题确实在缓存层，再决定是否提交刷新。

选择步骤：先加随机参数验证，再用命令行对比，最后检查响应头中的缓存指令。只有当响应头明确显示Age较大或命中缓存，且回源结果正确时，才值得提交缓存刷新。若回源结果本身就错误，刷新缓存只会把错误内容再缓存一遍。

把验证动作固定成检查清单

每次修改自定义404页面后，按同一顺序执行，能减少误判：

• 用无痕窗口访问一个不存在的URL，记录状态码和页面标题。
• 用curl -I请求同一URL，对比状态码。
• 加随机查询参数再请求一次，确认回源结果。
• 查看响应头缓存字段，判断是哪一层命中。
• 确认无误后，再决定是否刷新CDN或通知团队。

下一步：挑一个当前被缓存的自定义404 URL，按上面的清单跑一遍，把每一步的状态码和缓存头记下来，再决定是改配置还是刷缓存。