nginx后端切换由upstream机制实现，server块仅通过proxy_pass指定目标组；按域名、路径或请求头路由至不同upstream，结合max_fails、backup、weight及proxy_next_upstream实现故障转移与流量调度。
server 块本身不直接“切换”后端，而是通过 proxy_pass 指向不同 upstream 名称，把路由决策交给 upstream 的定义与状态。真正的后端切换能力，来自 upstream 内部的节点管理、健康状态和 fallback 机制，server 块只负责发起请求并指定目标组。
用 server 块选择不同的 upstream 组
这是最基础也最常用的切换方式：按域名、路径或请求头，把流量导向预定义的 upstream。
- 按域名区分主备中心：
server_name app-beijing.example.com → proxy_pass http://beijing_cluster;
server_name app-guangzhou.example.com → proxy_pass http://guangzhou_cluster; - 按请求头灰度分流（推荐用 map）：
定义 map $http_x_env $target_upstream { default beijing; "dr" guangzhou; }
在 location 中 proxy_pass http://$target_upstream; - 按 URL 路径隔离版本：
location /v1/ { proxy_pass http://backend-v1; }
location /v2/ { proxy_pass http://backend-v2; }
靠 upstream 内部机制实现自动故障切换
server 块只是出口，真正发生“节点级”或“组级”切换，依赖 upstream 的配置细节：
- 用 max_fails + fail_timeout 实现被动摘除：某节点返回超时或连接失败达阈值，Nginx 暂时跳过它，后续请求自动落到其他存活节点
- 用 backup 标记灾备节点：只有当所有非 backup 节点都被标记为不可用时，backup 才参与调度，适合冷备中心
- 用 weight 控制多中心流量比例：北京节点 weight=5，广州节点 weight=2，既避免平均分配导致灾备中心过载，又保留一定常态化流量验证能力
配合 proxy_next_upstream 主动重试
仅靠 upstream 列表静态变化不够及时，需在 server 或 location 块中启用重试逻辑：
- 设置 proxy_next_upstream error timeout http_502 http_503 http_504，让 Nginx 在收到这些响应或网络异常时，立即尝试下一个 upstream 节点
- 限制重试次数和总耗时：
proxy_next_upstream_tries 3（最多再发 2 次，共 3 次请求）
proxy_next_upstream_timeout 12s（从首次请求开始计时，超时即返回错误） - 该机制必须配合 upstream 中各 server 的 max_fails 参数，否则重试可能打到已知故障节点
进阶：server 块内嵌逻辑触发组间切换（无 Lua 场景）
若需在多个 upstream 组之间自动降级（如 primary → backup1 → backup2），可在 server 块中借助 try_files + named location 模拟 fallback 链：
- 定义三个 named location：
@primary { proxy_pass http://upstream-primary; }
@backup1 { proxy_pass http://upstream-backup1; }
@backup2 { proxy_pass http://upstream-backup2; } - 主 location 使用 try_files @primary @backup1 @backup2 =503；
配合 error_page 404 = @backup1 等，可进一步细化失败条件 - 注意：这种 fallback 依赖 Nginx 对 upstream 返回错误的捕获能力，对 5xx 响应需显式配置 proxy_next_upstream 才能触发跳转
