nginx 中 split_clients 实现平滑分流的核心是确保同一用户始终命中同一版本，需选用稳定唯一变量（如 $cookie_ab_id）、动态绑定 upstream、透传分组信息，并通过 reload 机制实现零中断变更与毫秒级回滚。
在 Nginx 中用 split_clients 实现平滑分流，关键不是“随机切流”，而是让同一用户始终命中同一版本，同时支持按需调整比例、快速回滚、不扰动现有连接。它本身不负责“平滑”，但配合 upstream 管理、健康检查和 reload 机制，就能达成真正的平滑效果。
选对分流依据，保证用户稳定性
分流变量必须具备稳定性和唯一性，否则同一用户反复切换分组，就谈不上“平滑”：
- 优先用 $cookie_ab_id：前端在首次访问时写入唯一 ID（如 UUID），Nginx 读取后哈希，确保登录态/设备级一致性；比 IP 更可靠，规避 NAT 和代理干扰
- 慎用 $remote_addr：在 CDN 或反向代理后可能全是同一个 IP（如 10.0.0.1），需改用 $http_x_forwarded_for 并做清洗（防伪造）
- 可用 $http_user_agent + salt（如 "${http_user_agent}v2"）：适合浏览器兼容性测试，但同设备换浏览器会变组，不适合功能灰度
配置 split_clients 变量并绑定 upstream
在 http 块中定义分组变量，再通过 proxy_pass 动态指向不同 upstream —— 这样增删后端、调整权重都不影响分流逻辑：
split_clients "$cookie_ab_id" $upstream_group {
5% grey_v2;
20% canary_v2;
* stable_v1;
}
对应 upstream 定义（每个组独立管理）：
upstream stable_v1 {
server 10.0.1.10:8080 max_fails=2 fail_timeout=10s weight=100;
keepalive 32;
}
upstream canary_v2 {
server 10.0.1.20:8081 max_fails=2 fail_timeout=10s weight=100 slow_start=30s;
keepalive 32;
}
upstream grey_v2 {
server 10.0.1.30:8082 max_fails=1 fail_timeout=5s weight=50;
keepalive 32;
}
注意：slow_start=30s 让新节点流量线性上升，避免冷启动打满；keepalive 复用连接，减少后端抖动。
把版本信息透传给后端与监控
仅分流不够，还要让后端知道“谁来了、从哪来”，便于日志归因、行为分析和快速止血：
- 用
proxy_set_header X-AB-Group $upstream_group把分组名传给后端 - 在 access_log 中加入
$upstream_group字段，方便按组统计成功率、延迟、错误率 - 结合
map指令补充业务标签（如是否登录、地域）：可叠加决策，但不要在location中嵌套多层if
上线与调整过程保持零中断
真正的“平滑”体现在变更时刻：
- 修改
split_clients比例或 upstream 配置后，执行nginx -t && nginx -s reload：旧 worker 继续处理存量请求，新 worker 按新规则分发新请求 - 若要下线某组（如 grey_v2），先将比例调为 0%，reload，确认无新流量后再停对应后端服务
- 紧急回滚？改回原配置 reload 即可，整个过程毫秒级生效，无需重启进程
