Nginx weight灰度发布需满足三硬条件：新旧实例IP/域名可区分、启用upstream加权轮询、权重为正整数且看相对大小；起步用小基数、加健康检查、注意keepalive影响；上线须热更新验证、响应头标识版本、预设回滚路径。
直接用 Nginx 的 weight 参数做灰度发布，本质是让新旧服务按固定比例承接流量，不依赖用户身份或请求内容，适合验证基础稳定性。关键不在“设多少”，而在于权重能否真实生效、是否便于随时调、出了问题能不能秒切回。
权重配置必须满足三个硬条件
光写个数字没用，实际流量不会自动对齐预期：
-
新旧实例必须可区分：不能共用同一个 IP+端口或服务名。比如 v1 部署在
192.168.1.10:8080，v2 就得另起地址如192.168.1.11:8080；若走域名，也要确保v1.example.com和v2.example.com解析到不同后端 -
必须启用 upstream + weighted round-robin：不能直接
proxy_pass http://xxx，得先定义upstream块，并在里面写server ... weight=；Nginx 默认就是加权轮询，不用额外声明策略 -
权重值要是正整数，且只看相对大小：设
v1 weight=95, v2 weight=5和v1 weight=19, v2 weight=1效果一样，都是 95% : 5%。避免用小数（如 0.5）或负数，部分版本不支持
怎么设才不容易出偏差
大流量下，权重看似简单，实则容易因连接复用、节点健康状态等导致实际分流不准：
-
起步用小基数：比如灰度初期想导 5% 流量，建议设
v1 weight=20, v2 weight=1，而不是95/5。数值越小，Nginx 内部计算时四舍五入误差越小 -
加上基础健康检查：在
server行里补上max_fails=1 fail_timeout=10s，避免某台机器卡住后持续转发失败请求 -
留意 keepalive 影响：客户端长连接会复用 TCP 连接，导致单个用户始终打到同一台后端。若需更均匀的随机效果，可在 upstream 里加
least_conn或配合应用层短连接控制
上线后必须能随时调、快速验、一键退
灰度不是配完就完事，得有闭环能力：
-
热更新要可靠：改完配置必须执行
nginx -t && nginx -s reload，确认无语法错误且进程已刷新；别只跑-t就以为生效了 -
验证方式要直接：让新旧服务在响应头里返回不同版本标识，例如
X-App-Version: v1.2.0和X-App-Version: v2.0.0，再用脚本批量请求统计分布 -
回滚路径要预设好：最稳妥的是把新版本权重直接改为 0（部分版本支持），或临时注释掉对应
server行再 reload；别等出问题才翻配置文件找哪一行
不复杂但容易忽略细节。只要实例分得清、配置写得对、上线看得见、出事退得快，权重灰度就能稳得住。
