Nginx实现后端高可用容灾切换，关键在于组合权重策略、主动健康探测、proxy_next_upstream重试与backup兜底机制：按实测QPS设weight（如北京3/台、广州1/台），配置max_fails=3 fail_timeout=20s、proxy_next_upstream error timeout http_500-504及独立/health?site=xx探测路径，确保秒级故障感知与自动接管。
Nginx 代理实现后端服务高可用容灾切换，关键不在“转发”本身，而在于它能否主动感知故障、合理分配流量、并在毫秒到秒级完成自动接管。单纯用 upstream 轮询或加个 backup 标签远远不够，必须组合权重策略、健康探测、重试机制与兜底逻辑。
用 upstream 定义带权重与状态感知的后端组
不同服务器性能、延迟、带宽差异大，平均分流量容易导致弱节点过载。需按实测吞吐设置 weight：
- 对北京集群单台压测得 QPS=1200，广州集群单台仅 400，则 weight 比例可设为 1200:400 = 3:1，即
server bj1:80 weight=3、server gz1:80 weight=1 - 每台 server 显式配置
max_fails=3 fail_timeout=20s，让 Nginx 在连续失败 3 次后，20 秒内不发新请求过去 - 灾备节点可加
backup标记，确保日常完全不参与调度，只在所有非 backup 节点被标记为不可用时才启用
靠 proxy_next_upstream 主动触发重试与降级
仅等连接超时太被动。必须让 Nginx 在收到异常响应时立即换节点：
- 在
location块中启用：proxy_next_upstream error timeout http_500 http_502 http_503 http_504 - 限制重试行为：
proxy_next_upstream_tries 3（最多换 3 次节点），proxy_next_upstream_timeout 15s（总耗时超 15 秒即返回错误） - 配合 upstream 中的
max_fails，形成“失败→临时剔除→超时恢复”的闭环，避免反复试探已故障节点
独立健康探测路径，避免业务接口误判
用 /health 这类接口做健康检查很常见，但如果和主业务共用同一路径，可能因慢查询、锁表、GC 导致误下线：
- 为每个中心单独定义探测路径，如
/health?site=bj、/health?site=gz - 该路径应绕过数据库、缓存等复杂依赖，只检查进程存活、端口可达、基础依赖连通性
- 若用商业版 Nginx Plus 或 OpenResty，还可配置
health_check指令实现更细粒度探测（如 HTTP 状态码、响应体关键字）
补充会话一致性与灰度验证机制
高可用不只是“不断”，还要“不乱”。尤其在未完全无状态的业务中：
- 优先推动改造：会话存 Redis、身份凭证用 JWT，彻底解除对路由节点的依赖
- 短期缓解可用 cookie-based sticky（需第三方模块），比
ip_hash更可靠，不受 NAT 影响 - 上线前务必压测验证：停掉一个节点，看日志中
X-Data-Center头是否 10 秒内全部切到备用组；用stub_status查看各 upstream 的requests分布是否符合权重预期
