www域名配置，一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1e0a46495c86.html
📄
www域名配置，一次小流量灰度如何暴露全量发布的例外
灰度只覆盖主站入口时，www 域名配置看起来一切正常；一旦全量发布，例外往往来自灰度没有覆盖的路径：旧 www 主机名、带端口的内部调用、CDN 回源、证书 SAN 之外的子域。能否在上线前发现这些例外，取决于灰度样本是否包含真实的域名变体，而不是样本量大小。
假设情境：一次只改了主入口的灰度
假设某站点要把 www 版本从旧 IP 切到新集群，做法是先在负载均衡上放 5% 流量到新集群，观察一天后再全量。灰度期间监控显示正常，全量后却发现部分用户仍访问旧 IP，另有一批请求落到没有证书的新节点。原因是灰度只按主域名分流，没有覆盖带 www 前缀以外的入口形式，也没有覆盖回源路径。
这个情境说明：灰度样本的代表性由域名变体决定，不由百分比决定。配置改动影响的是域名解析、证书覆盖和回源链路，这三者都不在主入口的 5% 里。
两种做法取舍：按流量比例还是按域名变体灰度
第一种做法是按流量比例灰度，实现成本低，适合只改应用逻辑、不改域名与证书的场景。它的代价是：只要改动涉及解析记录、证书 SAN 或回源主机名，比例再低也可能漏掉未覆盖的变体。
第二种做法是按域名变体灰度，把每个需要验证的主机名单独列出来，逐个切换并观察。成本更高，需要维护一份变体清单，但能直接回答“哪些入口还没验证过”。
选择条件可以这样判断：如果本次改动只影响页面内容或接口逻辑，域名与证书不变，按比例灰度即可；如果改动涉及 DNS 记录、证书签发范围、CDN 回源地址或负载均衡监听规则，就应按域名变体灰度，并把每个变体当作独立发布单元。
灰度样本里必须包含哪些域名变体
把下面几类写进灰度清单，逐项确认是否被本次改动影响：
- 裸域与 www 域：两者是否指向同一组记录，是否存在只改其一的可能。
- 证书 SAN 覆盖范围：新证书是否包含所有实际使用的主机名，包括灰度期间未启用的。
- 回源主机名：CDN 或反向代理回源时使用的主机名，是否与用户访问的主机名一致。
- 内部调用与健康检查：带端口或内部域名的请求是否绕过了解析改动。
- 旧记录残留：灰度后旧 IP 或旧 CNAME 是否仍被部分解析器缓存。
这份清单的作用是让灰度覆盖“入口集合”，而不是覆盖“流量集合”。一个变体没被验证，全量时它就是一个未受控的例外。
发现例外后先做什么，再决定是否继续全量
假设灰度后发现某个旧 www 主机名仍解析到旧 IP。第一步不是立即回滚，而是确认这个主机名是否仍在被真实请求使用。可以查解析日志和回源日志，看该主机名的请求量、来源和响应状态。如果请求量已经归零，可能是缓存或爬虫残留，仍需确认是否有其他合理解释，比如监控采样窗口太短、日志只覆盖部分节点。
确认仍在被使用后，动作是把该主机名补进灰度清单，单独切换并观察，再决定全量。这个动作的结果会直接影响下一步：如果补测后没有新例外，全量可以继续；如果又暴露出新的变体，说明清单本身不完整，应先补齐清单而不是加快发布。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。灰度验证针对的是域名配置本身是否按预期生效，不是搜索引擎是否已处理旧地址。这两件事的验证方法不同，不要用抓取日志的归零来证明配置已经正确。
验证配置生效时，哪些证据算数
可复查的证据应来自配置生效链路本身：解析记录的实际返回值、证书实际覆盖的主机名、负载均衡实际转发的目标。这些证据能区分“配置已改”和“请求已按新配置处理”。
如果只看到请求量下降或某个统计归零，不能单独证明处理正确，因为缓存过期、监控口径变化、采样窗口调整都能产生同样现象。把配置侧证据和请求侧证据对照，才能判断例外是配置遗漏还是观测偏差。
HTTPS 不保证安全无漏洞或排名，证书覆盖只解决主机名匹配问题。不同搜索引擎对域名变体的处理方式须分别核查，不要用一套结论套用到所有入口。
把灰度清单、每个变体的切换记录和对应证据留成可复查的文档，全量发布时就有了判断例外是否受控的依据，而不是等到用户反馈才回头找原因。
