www域名配置：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /38c7ba838754.html
📄
www域名配置：异常恢复后怎样区分缓存过期与真正修复
先给结论：把“恢复”拆成两层证据——响应层是否已经返回修复后的内容，以及该内容是否来自你刚刚部署的源站。只有源站响应、边缘缓存和不同网络位置的观测结果互相印证，才能把一次观察到的正常视为真正修复；如果只是某个节点或某个时刻变正常，更可能是缓存过期或局部回源。下面以你手里一个具体页面为对象，给出可执行的处理顺序。
先固定一个可复查的观测对象
不要用首页或整站作为判断对象，选一个在异常期间确实返回过错误状态的 URL，并记录三样东西：完整请求 URL、请求时携带的 Host 与协议、以及首次发现异常的时间点。这个时间点是后面区分“缓存过期”与“修复生效”的基准，没有它就无法判断变化发生在部署之前还是之后。
接着做一次带响应头的请求，重点看 Age、Cache-Control、ETag、Last-Modified 以及任何由 CDN 注入的命中标识。假设你看到 Age: 3600 且状态已恢复正常，这只能说明该副本在缓存中已存放一小时，不能说明源站已经修好——它同样可能是修复前的旧正常副本被重新命中。
用源站直连和边缘请求做对照
真正修复的第一个硬证据，是绕过缓存直接请求源站时返回的就是修复后的内容。做法是临时把请求指向源站地址并带上正确的 Host 头，观察状态码与正文特征。如果源站仍返回错误，而边缘节点返回正常，那这次“恢复”几乎可以判定为缓存层在起作用，而不是修复完成。
反过来，如果源站正常但边缘仍异常，说明修复已生效但缓存尚未更新，此时需要主动清理对应 URL 的缓存，而不是等待。清理后再从多个网络位置分别请求，确认返回一致。这里要注意一个边界：不同网络位置可能命中不同边缘节点，单点正常不足以证明全局一致。
区分三种容易混淆的“变正常”
- 缓存自然过期：
Age接近Cache-Control设定的生存时间，且源站直连仍为异常。这种情况下恢复是暂时的，缓存再次被填充后可能回到异常。 - 缓存被主动清理：清理后立即正常，且源站直连也正常，属于修复与缓存更新同时成立，可信度最高。
- 局部回源或节点差异：部分位置正常、部分位置异常，通常说明并非全量修复，需要继续定位是哪个节点或哪条回源链路的问题。
还有一种情况要单独排除：异常期间返回的错误本身可能被缓存。如果错误响应带有较长的缓存时间，那么“恢复”可能只是错误副本过期，而源站从未真正修好。检查错误响应当时的缓存头，能帮你判断这一点。
把观察转成下一步动作
根据上面的对照结果分两条路走。若源站直连正常、边缘清理后也正常，就把该 URL 加入一段时间的复查清单，在缓存生存时间过后再请求一次，确认没有回退。若源站直连仍异常，则不要继续在缓存层操作，回到配置本身排查，例如 www 主机名与裸域的解析指向、证书覆盖的域名、以及回源地址是否正确。
这里给出一个注明假设的短例子：假设某页面在缓存生存时间设为 600 秒的情况下，异常出现后第 12 分钟自行恢复，源站直连却仍返回错误。此时最合理的解释是缓存过期后重新回源拿到了另一份副本，而不是修复完成；下一步应直接检查源站配置，而不是重复清理缓存。
规模化时不能照搬的边界
单 URL 的验证方法在样本变多后会失效，因为不同 URL 的缓存生存时间、回源路径和节点分布可能不同。个别样本正常不能推出整站恢复，反之亦然。规模化验证需要按 URL 分组，用相同的请求条件批量比对源站与边缘结果，并记录每组的差异比例，而不是只看总体是否“看起来正常”。
另外，抓取限制类配置与索引状态是两回事：限制抓取不等于移除已有索引，站点地图也不保证收录，这两点不能用来判断修复是否生效。验证 www 域名配置的恢复，始终以响应层和源站层的一致性为准，再决定是否进入下一步的抓取与索引观察。
