404页面设置，异常恢复后怎样区分缓存过期与真正修复
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /b73f6b371d89.html
📄
404页面设置，异常恢复后怎样区分缓存过期与真正修复
先给有条件的结论：如果异常恢复后，同一URL在不同网络、不同设备或不同请求头下返回的状态码仍不一致，那么你看到的“恢复”多半是缓存过期或边缘节点刷新，而不是源站修复；只有当源站直接返回的响应稳定为预期状态，并且该状态在绕过缓存后依然一致，才算真正修复。这个判断的前提是你已经确认源站配置本身正确，且没有CDN或代理层在中间改写状态码。
先看响应头，不要只看页面内容
很多人判断404是否修复，靠的是浏览器里页面能不能打开。这个动作的结果只能说明“当前这次请求拿到了内容”，不能说明源站对缺失资源的真实态度。更可靠的动作是查看响应头里的Cache-Control、Age、X-Cache或类似字段。如果Age很大，说明你拿到的是缓存副本；如果X-Cache显示命中，那么这次恢复可能只是缓存还没过期。
假设一个场景：某页面之前返回404，你调整了规则后再次访问，页面正常显示。但响应头里Age: 86400，且Cache-Control允许缓存一天。此时不能判断源站已修复，只能判断缓存里存着旧的成功响应。下一步应当用带随机查询参数的URL或直接请求源站IP，观察源站返回什么。
绕过缓存后仍一致，才接近真正修复
真正修复的证据是：绕过CDN、代理和浏览器缓存后，源站对同一路径返回的状态码与预期一致，并且重复请求不跳变。具体动作可以是用curl -I直接请求源站地址，或在本地hosts里把域名指向源站IP，再发起请求。如果这时返回的状态码仍然异常，说明问题在源站规则，而不是缓存层。
反例也要说清楚：如果源站返回200，但内容其实是软404页面，或者状态码被应用层统一改写为200，那么绕过缓存后的“一致”也不能证明修复正确。此时需要看响应体是否包含错误提示，以及该URL是否应该存在。软404会让缓存和源站看起来一致，但索引结果仍然可能异常。
用两组请求对比缓存过期与源站修复
可以设计一组可区分的请求，帮助判断恢复来源：
- 第一组：直接访问原URL，记录状态码、
Age、X-Cache和响应时间。 - 第二组：在原URL后加一个无意义查询参数，例如
?test=404check，让缓存键发生变化，再记录同样字段。
如果第一组显示恢复，第二组仍返回404或异常状态，说明你之前看到的是缓存过期后的旧副本，源站并没有真正修复。如果两组都返回预期状态，且多次请求稳定，才更接近真正修复。这个对比不依赖具体平台界面，只依赖响应头是否暴露缓存命中信息；如果响应头被隐藏，就需要用源站直连来替代。
一个容易遗漏的条件：缓存过期不等于源站已改对
缓存过期只会让旧响应被清除，它不会自动修正源站规则。很多“恢复”发生在缓存TTL到期之后，于是看起来像修复，实际上源站仍然返回错误状态，只是新请求暂时没有命中旧缓存。要排除这种可能，必须在缓存过期后再次请求源站，并确认源站返回的状态码与预期一致。
另一个反例是：源站返回404，但CDN配置了自定义错误页并缓存了200。此时用户看到的是正常页面，缓存头也可能显示命中，但搜索引擎抓取到的仍是404。判断依据不是页面是否好看，而是源站对缺失资源的原始状态码。
下一步动作：先固定源站证据，再决定改哪里
如果绕过缓存后源站仍异常，下一步应检查源站的重写规则、应用路由和错误处理逻辑，而不是继续刷新CDN。如果绕过缓存后源站正常，但带缓存访问仍异常，下一步应检查CDN的缓存键、TTL和错误页缓存策略。这个动作顺序能避免在错误层面反复操作。
最后要说明一个适用条件：不同搜索引擎对404和软404的处理并不相同，robots.txt的抓取限制也不等于可靠的索引移除，站点地图不保证收录。因此，即使状态码修复正确，索引结果仍可能滞后或表现不同。判断修复是否完成，应以源站稳定返回预期状态码为准，而不是以某个页面能否打开或某次抓取是否恢复为准。真正修复后，缓存过期只是时间问题；缓存过期后仍异常，才是需要继续处理的问题。
