灰度发布应避免依赖DNS轮询，而需在网关/Nginx层基于请求特征（如Header、Cookie、IP哈希）实现一致性分流，并配套降TTL、双环境验证与可观测性保障。
灰度发布中的域名解析切换，核心是让部分用户流量精准、稳定地导向新版本服务，而不是靠随机轮询“碰运气”。DNS 层虽能参与，但有天然限制——它不识别用户身份、不维护会话、缓存不可控。所以真正可靠的灰度，得在更靠近用户的层（如网关、CDN、反向代理）做，DNS 更适合作为辅助或粗粒度分流手段。
用 DNS 做粗粒度灰度：按线路/地域切流
这是小团队在资源有限时最务实的做法。比如把电信用户全切到新版本，联通和移动仍走老版本：
- 在 DNS 控制台中，选择“线路划分”或“智能解析”功能（阿里云、腾讯云、Cloudflare 等均支持）
- 新增一条 A 记录，线路类型设为“中国电信”，记录值填新服务器 IP
- 再配一条默认线路（或“未匹配线路”）的 A 记录，指向老服务器 IP
- TTL 建议设为 300 秒（5 分钟），确保策略变更后较快生效
这种方式避免了同一用户反复跳变，也无需改造应用，适合初期验证区域兼容性或运营商适配问题。
避免踩坑：别用纯权重轮询做灰度
把同一域名配两条 A 记录、设不同权重，看似能分流，实则不可控：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- DNS 解析结果由 LocalDNS 决定，客户端每次请求可能拿到不同 IP，甚至同一浏览器刷新就变版本
- 新老版本若共享 Cookie 或 Session，极易出现状态错乱、登录失效、页面渲染异常等问题
- 无法按用户 ID、设备、AB 测试参数等做一致性分流，违背灰度基本要求
这种做法本质是“伪灰度”，只适合临时测试，绝不该用于线上用户。
推荐主路径：Nginx / 网关层动态 proxy_pass
真正可控的灰度，应基于请求特征做判断，并保证同一用户始终路由到同一版本：
- 用 map 指令根据 Header（如
X-Release: canary）或 Cookie（如abtest=1）映射 upstream 名称 - 用 split_clients 模块按 IP 或用户 ID 哈希分流，例如固定 5% 用户走新版本，且长期不变
- proxy_pass 直接指向变量（
http://$upstream_backend），配合 resolver 或直接写 IP+端口提升可靠性 - TTL 设为 300 秒即可，因灰度逻辑不在 DNS，它只负责把域名稳定解析到网关入口
配套关键动作不能少
无论在哪一层做灰度，以下三点直接影响成败：
- 提前降 TTL：切换前 24 小时，把相关域名的 TTL 从默认 86400 逐步调低至 300，确保后续变更快速生效
- 双环境并行验证：新版本上线前，必须通过 hosts 或内网 DNS 提前完成全链路测试，确认接口、静态资源、第三方依赖全部就绪
-
可观测性兜底：在网关或日志中打标灰度标识（如
release=canary），结合监控看板实时观察错误率、响应时间、分流比例是否符合预期
