nginx多版本共存核心是精准路由而非扩容，推荐路径前缀（如/v1/、/v2/）匹配不同upstream；支持请求头/cookie灰度、子域名隔离及后端版本感知，需注入x-service-version头确保兼容性。
在 Nginx 负载均衡环境下实现多版本服务共存，核心在于将请求按版本标识（如路径前缀、请求头、域名或参数）精准路由到对应后端集群，同时避免版本间相互干扰。关键不在于增加节点数量，而在于路由策略的明确性和配置的可维护性。
用路径前缀区分版本（推荐入门方案）
适用于 API 接口按版本号组织的场景（如 /v1/xxx、/v2/xxx）。Nginx 可通过 location 块精确匹配并代理至不同 upstream。
- 在
http块中定义多个 upstream，例如upstream backend_v1 { server 10.0.1.10:8080; }和upstream backend_v2 { server 10.0.1.11:8080; } - 在 server 块内配置带前缀的 location：
location ^~ /v1/ { proxy_pass http://backend_v1/; }（注意末尾斜杠，避免路径重复） - 对未带版本前缀的请求，可统一 fallback 到默认版本（如 v1），或返回 404/422 提示客户端指定版本
用请求头或 Cookie 实现灰度发布
当需对部分用户（如内测账号、特定设备）定向分发新版服务时，可结合 map 指令动态选择 upstream。
- 先定义 map 变量：
map $http_x_version $target_backend { default backend_v1; "v2" backend_v2; } - 在 location 中使用：
proxy_pass http://$target_backend; - 支持从
X-Version请求头、Cookie（如version=v2）甚至 IP 段提取判断依据，适合渐进式上线
用 Host 或子域名隔离版本环境
适合长期并行运行多个大版本（如正式版、预发版、实验版），运维清晰且无路径污染。
- 为各版本配置独立域名：
v1.example.com、v2.example.com、beta.example.com - 每个 server 块绑定对应 server_name，并指向专属 upstream，互不影响
- 配合 DNS 或本地 hosts 测试方便；生产环境建议搭配 Let’s Encrypt 自动证书管理
确保后端服务自身具备版本感知能力
Nginx 路由只是入口控制，后端服务仍需能识别并处理版本上下文，尤其涉及数据兼容性或降级逻辑时。
- 建议在转发请求时注入版本标识头，如
proxy_set_header X-Service-Version $target_backend; - 后端应用据此决定序列化格式、字段过滤策略或调用对应数据模型
- 避免仅靠 Nginx 路由却让 v2 接口错误调用 v1 的数据库 schema，造成隐性故障
