nginx upstream需同时配置被动健康检查（max_fails/fail_timeout + proxy_next_upstream）与backup节点，二者协同实现容灾：backup仅在所有非backup节点被标记为不可用时启用，且须确保其能独立承载全量流量。
要让 Nginx 的 upstream 同时具备健康检查和备用机（backup）能力，需分两层配置：一是用被动或主动方式判断节点是否健康，二是通过 backup 参数定义故障兜底路径。两者不是互斥，而是协同工作的关键组合。
被动健康检查 + backup 节点（原生支持，无需编译）
这是最常用、最稳妥的生产配置方式。Nginx 不发心跳，而是在真实请求中识别失败，并自动摘除异常节点，等所有非 backup 节点都不可用时，才启用 backup。
-
在 upstream 中为每个主节点设置
max_fails和fail_timeout：例如server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;，表示连续 3 次失败后，该节点被标记为 down，30 秒内不参与调度 -
显式声明哪些错误触发重试：在
location块中必须配置proxy_next_upstream error timeout http_500 http_502 http_503 http_504;，否则 5xx 错误不会触发切换 -
backup 节点仅写
backup，不加max_fails或权重：它默认不参与轮询，也不受健康检查影响；只有当其他节点全被标记为不可用时，才会启用 -
注意调度策略限制：backup 只在默认的
round-robin模式下生效；若用了ip_hash或least_conn，backup 将被忽略
主动健康检查 + backup（需第三方模块）
如果需要定时探测（比如每 3 秒发一次 HTTP 请求），就必须引入 nginx_upstream_check_module。它和 backup 并存时，backup 依然只作为最终兜底，但主动检查能让节点状态更及时、更准确。
-
upstream 内启用 check 指令：例如
check interval=3000 rise=2 fall=5 timeout=1000 type=http;，其中fall=5表示连续 5 次探测失败才标记为 down -
HTTP 类型检查可定制探针：加
check_http_send "GET /health HTTP/1.1\r\nHost: example.com\r\n\r\n";和check_http_expect_alive http_2xx;，确保只认健康接口返回 2xx -
backup 节点不参与 check：模块默认不对带
backup标记的 server 执行探测，它始终处于“待命”状态，只在全部非 backup 被主动标记为 down 后启用 -
不能混用官方 health_check 指令：Nginx Plus 有内置
health_check，但开源版不支持；若看到类似配置，说明用的是商业版，非社区版 Nginx
backup 节点本身也要能独立承载流量
很多人忽略这点：backup 不是“修好再切回来”的临时通道，而是故障期间的主力服务。它必须和主节点一样部署完整应用、配置相同超时、能处理全量并发。
- 避免 backup 因资源不足、连接池过小或未启用 keepalive 导致雪崩
- 建议对 backup 节点也配置
max_conns和keepalive，例如server 192.168.1.12:8080 backup max_conns=2048; - 上线前务必模拟主节点全挂场景，验证 backup 是否真能响应、日志是否有错误、监控指标是否正常
验证配置是否生效的关键动作
光写对配置不够，必须实测闭环：
- 停掉一台主 server，观察 Nginx
error.log是否出现upstream server temporarily disabled - 用
curl -I http://your-domain/多次请求，确认状态码始终是 200，且响应头中Server字段指向 backup IP - 查看
access.log，确认流量已完全切换到 backup 地址，无 502 日志 - 恢复主节点后，等待
fail_timeout时间过去，确认流量自动回切（被动检查）或探测成功后恢复（主动检查）
