nginx 的 proxy_pass 本身不支持一次请求在多个 upstream 间自动切换或联动，只能指向一个明确的 upstream 名称或具体地址；所谓“多个 upstream 联动”实为通过 if、map、location 匹配等机制实现条件路由，而非 proxy_pass 自身能力。
Nginx 的 proxy_pass 本身不支持“一次请求自动在多个 upstream 间切换或联动”，它只能指向一个明确的 upstream 名称（如 http://api_backend）或具体地址（如 http://10.0.1.5:8080）。所谓“多个 upstream 的联动”，实际是指根据业务逻辑，在不同条件下将请求导向不同 upstream —— 这需要配合 if、map、location 匹配、变量赋值等机制来实现动态路由，而非 proxy_pass 自身具备多目标能力。
下面分几种典型联动场景说明配置要点：
根据域名或路径选择 upstream
这是最常用、最稳定的方式。每个 server 或 location 明确绑定一个 upstream：
upstream user_api { server 10.0.1.10:8080; server 10.0.1.11:8080; }
upstream order_api { server 10.0.2.20:8080; server 10.0.2.21:8080; }
server {
listen 80;
server_name api.example.com;
location /user/ {
proxy_pass http://user_api;
proxy_set_header Host $host;
}
location /order/ {
proxy_pass http://order_api;
proxy_set_header Host $host;
}
}
✅ 优点：配置清晰、无运行时开销、兼容所有 Nginx 版本
⚠️ 注意：proxy_pass后的斜杠要与location匹配一致（如location /user/对应proxy_pass http://user_api/才能正确重写路径）
根据请求头或参数动态选 upstream
用 map 预定义变量，再在 proxy_pass 中引用：
map $http_x_service $backend {
default user_api;
"order" order_api;
~^v2 user_api_v2;
}
upstream user_api { server 10.0.1.10:8080; }
upstream order_api { server 10.0.2.20:8080; }
upstream user_api_v2 { server 10.0.1.12:8080; }
server {
location /api/ {
proxy_pass http://$backend;
proxy_set_header Host $host;
}
}
✅ 适合灰度发布、AB 测试、多版本路由
⚠️ 注意：map必须在http{}级定义；变量值必须是已声明的 upstream 名称，不能拼接字符串
故障转移式联动（主备 fallback）
利用 proxy_next_upstream + 备用 upstream 的间接联动：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
upstream primary {
server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
}
upstream fallback {
server 10.0.2.20:8080 backup;
}
server {
location / {
proxy_pass http://primary;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 2;
# 注意：Nginx 不支持直接 fallback 到另一个 upstream，
# 但可把 fallback server 加进 primary 并标为 backup
}
}
✅ 真实可行，符合 Nginx 原生机制
⚠️ 不是“两个 upstream 切换”，而是同一 upstream 内部的主备调度；若真需跨组 fallback，需用 Lua（OpenResty）或外部网关
不推荐的做法：用 if + proxy_pass 动态拼接
# ❌ 错误示例（if 在 location 中限制多，且 proxy_pass 不支持变量拼接上游名）
if ($arg_env = "prod") {
set $upstream "prod_api";
}
proxy_pass http://$upstream; # 这会报错：“invalid URL prefix”
Nginx 官方明确不建议在 if 中使用 proxy_pass，且变量不能用于解析 upstream 名（除非启用 resolver + DNS 方式，见下文补充）。
补充：DNS 解析方式实现“软联动”
当多个服务注册到同一个域名（如 backend.service.consul），可通过 DNS 轮询+健康发现间接联动：
resolver 127.0.0.11 valid=5s;
upstream dynamic_group {
server backend.service.consul:8080 resolve;
}
server {
location / {
set $target "backend.service.consul:8080";
proxy_pass http://$target;
}
}
✅ 适用于 Consul/Eureka/CoreDNS 等服务发现场景
⚠️ 实际仍是单个 upstream，只是后端 IP 动态变化；不等于“多个 upstream 协同决策”
本质上，Nginx 的设计哲学是 静态配置 + 运行时高效转发，不是动态策略引擎。真正复杂的联动逻辑（如按用户 ID 分片到 A 组、按订单金额路由到 B 组、失败后重试 C 组），应交由上游网关（如 Kong、Traefik）、Sidecar（Istio）、或嵌入 Lua 脚本（OpenResty）来处理。
不复杂但容易忽略
