Nginx灰度发布需版本隔离、动态路由与逐步放量：为v1/v2分别定义upstream，用map按Header/Cookie/IP映射目标组，proxy_pass统一转发，配合健康检查和会话粘性，再通过权重调整与监控验证实现可控上线与回滚。
在 Nginx 中用 upstream 实现多台服务器间的平滑灰度发布，关键不是平均分发流量，而是让新旧版本服务共存、可识别、可控制、可回滚。核心是“版本隔离 + 动态路由 + 逐步放量”，避免直接轮询或硬编码切换。
定义独立的 upstream 分组，按版本隔离
每个 API 版本必须有专属 upstream，不能混用同一组后端：
-
v1 稳定版：单独定义
upstream backend-v1，指向旧版实例（如10.0.1.10:8080、10.0.1.11:8080），可设weight=90控制初始流量占比 -
v2 灰度版：单独定义
upstream backend-v2，指向新版实例（如10.0.1.20:8081、10.0.1.21:8081），初期设weight=10或仅单节点 - 两个 upstream 内都建议启用健康检查（如
max_fails=2 fail_timeout=30s），确保异常节点自动剔除
用 map 指令实现请求特征驱动的动态路由
不推荐在 location 中频繁使用 if，应提前通过 map 提取灰度标识并映射目标 upstream：
- 从请求头提取：
map $http_x_release $upstream_group { "v2" "backend-v2"; default "backend-v1"; } - 从 Cookie 提取：
map $cookie_version $upstream_group { ~*v2 "backend-v2"; default "backend-v1"; } - 从 IP 段识别内网灰度用户：
geo $is_internal { default 0; 192.168.0.0/16 1; } map $is_internal $upstream_group { 1 "backend-v2"; 0 "backend-v1"; }
之后在 location 中统一写 proxy_pass http://$upstream_group;，逻辑清晰且兼容变量转发。
配合一致性哈希或 session 粘性保障体验稳定
灰度期间若涉及状态保持（如登录态、临时缓存），需避免用户在新旧版本间跳变：
- 对
backend-v1和backend-v2分别启用ip_hash或hash $remote_addr consistent - 不建议跨版本共享哈希，否则会破坏灰度边界；应保证同一用户始终落在同一版本内
- 若新版已支持无状态设计，也可关闭粘性，靠业务层兜底
上线与验证阶段的操作要点
灰度不是配完就生效，必须闭环验证：
- 先小范围测试：只对指定 Header、Cookie 或内网 IP 开放 v2，确认响应正确、延迟正常、错误率不升
- 逐步扩大比例：修改
map规则或调整weight，按 5% → 20% → 50% → 全量节奏推进 - 监控分流效果：检查
nginx_upstream_requests_total{upstream="backend-v2"}是否符合预期，同时比对成功率与 P95 延迟 - 一键回滚准备：保留旧版配置备份，切换只需改
map默认值或set $active_version "v1"并执行nginx -s reload
