Linux下Nginx灰度发布核心是proxy_pass动态解析目标，通过map基于请求特征路由，配合upstream、split_clients或weight实现版本分流，变量代理需resolver或直用IP。
Linux 下用 Nginx 的 proxy_pass 实现灰度发布，核心不是改后端地址本身，而是让 proxy_pass 指向一个**动态解析的目标**——这个目标根据请求特征（如 Header、Cookie、IP）实时决定是旧版还是新版服务。
用 map 做安全可靠的条件路由
不推荐在 location 里用 if 判断再 set 变量，容易出错且有执行限制。正确做法是在 http 块顶部用 map 预定义映射规则：
- 定义两个 upstream：一个指向稳定版，一个指向灰度版
- 写 map 规则，把请求头、Cookie 或参数值映射成 upstream 名称
- 在 location 中直接
proxy_pass http://$upstream_backend
例如识别 X-Release: v2 或 Cookie: gray=1 走新版本：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
map $http_x_release $upstream_backend {
default "backend-stable";
"v2" "backend-canary";
}
<p>map $cookie_gray $upstream_backend {
~^1$ "backend-canary";
default "backend-stable";
}按用户或 IP 做一致性哈希分流
适合需要“同一个用户始终走同一版本”的场景，比如便于问题复现或会话保持：
- 用
split_clients模块，基于$remote_addr或$cookie_uid哈希 - 相同输入永远得到相同结果，天然支持会话粘性
- 可配置百分比，如 5% 流量进灰度，其余走稳定版
split_clients "${remote_addr}ABC" $backend_group {
5% "backend-canary";
* "backend-stable";
}按权重做整体流量比例控制
适用于初期验证阶段，不区分用户，只控制新版本接收的总流量占比：
- 在 upstream 块中为不同后端设置 weight 值
- weight 总和不重要，关键看相对大小，比如 95 和 5 相当于 95% vs 5%
- 注意：这是轮询式随机分配，无法保证某类用户固定走新版本
upstream backend {
server 192.168.1.10:8080 weight=95; # 老版本
server 192.168.1.11:8080 weight=5; # 新版本
}必须配 resolver 才能用变量名做 proxy_pass
如果 proxy_pass http://$upstream_backend 中的变量是 upstream 名（而非 IP），Nginx 默认无法解析——它启动时就需知道后端地址。解决办法只有两个：
- 给 upstream 配置 DNS 解析器：
resolver 114.114.114.114 valid=30s;（放在 http/server/location 均可） - 更简单稳妥的做法：upstream 全用 IP+端口，避免域名；或者干脆不用 upstream，直接
proxy_pass http://$ip:$port（需提前在 map 中拼好）
