收录好的域名：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c1094e7817e1.html
📄
收录好的域名：异常恢复后怎样区分缓存过期与真正修复
先给有条件的结论：如果异常期间返回的错误状态、错误内容或屏蔽规则，在恢复后由同一请求路径、同一User-Agent、同一出口IP重新请求时，响应头中的缓存年龄、校验器或源站标记发生变化，那么更可能是真正修复；如果只有部分节点或部分工具恢复正常，而源站直连仍返回旧错误，则应优先怀疑缓存过期，而不是修复生效。
先看两个成立的判断条件
真正修复通常满足两个条件。第一，源站响应本身已经改变，例如原本返回<code>503</code>的URL现在返回<code>200</code>，且响应体不再是错误页。第二，这个改变不依赖特定CDN节点、特定DNS解析结果或特定爬虫出口。只要源站直连仍复现旧错误，缓存过期就足以解释外部观察到的恢复。
缓存过期则相反：源站可能仍然错误，但边缘节点上的旧副本到期或被清除，于是外部工具看到正常响应。此时恢复是局部的、暂时的，下一次回源可能再次把错误内容写进缓存。判断时不要只看一个工具或一个地点的结果，至少对比源站直连与经过缓存链路的两组响应。
一个会让结论失效的反例
假设你给某个目录配置了较长的边缘缓存时间，异常期间源站返回错误页，但错误页也被缓存。恢复后你只清除了部分节点缓存，另一些节点仍持有旧副本。此时外部观察到的“恢复”既不是缓存自然过期，也不是源站修复，而是人工清除不完整造成的混合状态。这个反例说明：只要缓存清除动作与源站修复动作同时发生，就不能用单次观察区分两者。
更隐蔽的情况是DNS或负载均衡把请求分到不同源站。一个源站已修复，另一个仍返回旧错误，外部工具随机命中，于是同一分钟内的结果互相矛盾。这种情况下，缓存过期和真正修复都不是主因，真正的问题是流量分配不均。需要先固定请求路径，再谈恢复判断。
用一组可区分原因的证据缩小范围
可以按以下顺序收集证据，每一步都记录请求时间、响应状态、响应头中的缓存相关字段和响应体摘要。
- 源站直连请求：绕过CDN或反向代理，直接请求源站IP并带上Host头。如果仍返回旧错误，缓存过期是更合理的解释。
- 带缓存链路请求：观察<code>Age</code>、<code>Cache-Control</code>、<code>ETag</code>或<code>Last-Modified</code>是否变化。年龄归零或校验器更新，只说明副本换了，不直接等于源站修好。
- 多出口对比：用不同网络或不同地区的请求出口重复同一URL。如果只有部分出口正常，优先查缓存节点和DNS解析，而不是宣布修复完成。
- 错误页特征比对：记录异常期间错误页的标题、状态码和关键片段。恢复后若这些特征仍出现在某些响应中，说明旧副本还在服务。
这些证据只能缩小范围，不能单独证明修复。抓取量或请求量归零也有多种解释：可能是爬虫降低了抓取频率，可能是robots.txt临时屏蔽，也可能是缓存命中让源站日志不再出现该请求。因此数量变化不能替代响应内容比对。
一个注明假设的短例子
假设某目录在异常期间对爬虫返回<code>503</code>，你在恢复后做了两件事：修改源站配置并清除CDN缓存。第二天外部工具显示<code>200</code>。此时不能直接归因于源站修复，因为清除缓存本身就会产生同样观察。可做的动作是：在源站直连上重复请求同一URL，并保留响应头。如果源站直连仍返回<code>503</code>，说明外部看到的正常只是缓存副本更新，下一步应继续修源站，而不是提交新的站点地图或等待收录恢复。如果源站直连返回<code>200</code>且响应体不再包含错误特征，才可以把下一步转向观察抓取与索引是否跟进。
这个例子的关键不是数字，而是动作顺序：先固定源站直连结果，再决定是否把恢复归因于修复。顺序颠倒会让缓存过期冒充修复。
下一步动作与判断代价
如果源站直连已正常，但带缓存链路仍返回旧错误，下一步是检查缓存规则和清除范围，而不是继续改源站。代价是可能多等一个缓存周期，但能避免把未修复的源站误判为已修复。如果源站直连仍异常，下一步是回到源站错误日志和配置变更记录，而不是反复清除缓存。清除缓存只能改变外部观察，不能改变源站行为。
需要提醒的是，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。恢复判断应基于响应内容和状态码，而不是基于提交动作或抓取数量。只有源站响应本身稳定正常，并且经过缓存链路重复请求不再复现旧错误，才可以把状态从异常恢复推进到观察收录变化。
