网站空间域名：一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c9ec2c679f9c.html
📄
网站空间域名：一次小流量灰度如何暴露全量发布的例外
小流量灰度能暴露全量发布的例外，通常不是因为灰度样本太小，而是因为灰度路径和全量路径在域名解析、空间入口或重定向规则上并不一致。换句话说，灰度验证的是“被切到的那部分流量”，全量发布验证的是“所有入口的并集”。两者之间只要存在一个未被覆盖的入口，例外就会在全量时出现。
先分清灰度与全量到底差在哪一层
网站空间域名相关的发布，至少涉及三层：域名解析层、空间入口层、应用路由层。灰度往往只动其中一层，比如只把某个子域指向新空间，而全量会同时改动主域、带 www 的域、旧域名跳转和 CDN 回源。判断例外是否会发生，先问一句：灰度覆盖了哪几个入口，全量又会新增哪几个入口。
- 如果灰度只覆盖主域，全量却要同时启用旧域名跳转，那么旧域名上的重定向链就是例外高发区。
- 如果灰度只覆盖新空间，全量却要保留旧空间做兜底，那么两个空间对同一路径的响应差异会暴露出来。
- 如果灰度只覆盖 HTTPS，全量却还要处理 HTTP 入口，那么协议切换时的跳转目标就是需要单独确认的点。
这里的关键动作是：在灰度阶段就把“全量入口清单”列出来，并逐个用同一请求去比对响应。这个动作的结果会直接决定下一步——如果清单里存在灰度从未触达的入口，就不要直接全量，而应先对这些入口做一次定向验证。
保留、改写还是退出：三种取舍的前提
当灰度暴露出例外时，常见的取舍有三种，但各自成立的前提不同，不能混用。
保留现有配置，只补例外入口
适用前提是：例外只出现在少数入口，且这些入口的请求量占比低、不影响主流程。此时保留主配置，只对例外入口单独修正，风险最小。动作是记录例外入口的请求特征，修正后再次用相同请求验证，确认响应与主入口一致。如果修正后例外入口仍返回不同状态码或不同跳转目标，说明问题不在入口本身，而在应用路由，需要进入下一层排查。
改写规则，统一入口行为
适用前提是：例外入口数量多，或例外与主入口的差异来自同一类规则冲突。此时逐个补丁会越补越乱，应改写规则让所有入口走同一条路径。动作是先在灰度环境模拟全量入口，观察改写后是否引入新的例外。若改写后灰度环境本身出现新异常，说明规则改动影响了原本正常的入口，此时应退回保留策略，而不是继续扩大改写范围。
退出本次发布，回到变更前状态
适用前提是：例外影响了核心入口，或无法在可接受时间内定位原因。退出不是失败，而是避免把不确定状态扩散到全量。动作是回滚域名解析和空间指向，并确认回滚后各入口响应与变更前一致。如果回滚后仍有入口异常，说明问题可能不在本次变更，需要单独核查空间本身的可用性。
用一组可区分原因的证据来定位例外
例外出现后，不要只盯着“页面打不开”这一个现象。以下证据可以帮助区分原因：
- 同一路径在不同域名下返回的状态码是否一致。若不一致，问题在域名解析或跳转规则。
- 同一域名下不同路径的响应是否一致。若只有部分路径异常，问题在应用路由或空间目录配置。
- 直接请求空间入口地址与通过域名请求的响应是否一致。若不一致，问题在域名到空间的映射层。
- HTTP 与 HTTPS 入口的跳转目标是否指向同一最终地址。若不同，问题在协议跳转配置。
这些证据的作用是缩小范围，而不是证明某个结论。比如请求量归零，可能是入口被切断，也可能是缓存命中或监测点失效，不能单独作为判断依据。只有多个证据指向同一层时，才适合在该层做修改。
一个假设的短例子
假设某站点灰度时只把 new.example.com 指向新空间，主域仍指向旧空间。灰度期间访问正常。全量时把主域也指向新空间，同时保留旧域名跳转。结果旧域名跳转后落到新空间的一个不存在的路径，返回 404。这个例外的原因不是新空间不可用，而是灰度从未验证过“旧域名跳转 + 新空间路径”这个组合。
此时若选择保留策略，动作是单独修正旧域名的跳转目标，并再次用旧域名请求验证；若修正后仍 404，则说明新空间缺少对应路径，需要回到应用路由层处理，而不是继续改跳转规则。
灰度之后、全量之前必须确认的一件事
灰度通过不等于全量安全。全量之前，至少要用全量入口清单中的每一个入口发一次相同请求，并记录响应状态和最终地址。这个动作的结果决定下一步：所有入口响应一致，才可以进入全量；存在不一致，就先处理不一致的入口，而不是靠增加灰度流量来“覆盖”它。小流量灰度的价值不在于流量小，而在于它逼你提前列出全量入口清单；例外暴露的，正是清单里被漏掉的那一项。
