nginx故障转移靠精准控制实现“准”与“稳”：用max_fails+fail_timeout定义滑动窗口判定故障，proxy_next_upstream限定重试条件，backup节点提供降级出口，四类底层参数必须协同生效。
故障转移在 Nginx 中不是靠“快速失败”这个概念驱动的，而是通过精准控制失败判定窗口、限制重试行为、明确降级路径来实现响应快、不拖沓、不雪崩的效果。核心不在“快”，而在“准”和“稳”。
用 max_fails + fail_timeout 定义故障判定节奏
这两个参数共同构成一个滑动时间窗口，决定节点何时被临时隔离：
- max_fails=2 表示连续 2 次失败（连接拒绝、超时、502/504 等）就触发标记
- fail_timeout=10s 表示从第一次失败起算，10 秒内累计达 2 次即下线；该节点随后跳过 10 秒，到期后由首个新请求试探恢复
- 中间哪怕有一次成功，失败计数也不会清零——这是防止误判的关键设计
- 对强实时接口（如支付回调），推荐 max_fails=1 fail_timeout=5s；对慢服务（如报表导出），可设为 max_fails=2 fail_timeout=60s
靠 proxy_next_upstream 控制重试边界，避免无效等待
它不决定“要不要重试”，而是明确“什么错误才值得换节点再试一次”：
- 必须显式启用：proxy_next_upstream error timeout http_500 http_502 http_503 http_504
- 不要加 http_404：它是业务确定性结果，重试无意义
- 禁用 non_idempotent：除非你确认 POST 请求可安全重复（例如日志上报），否则绝不开启
- 搭配 proxy_next_upstream_tries 3（最多尝试 3 台，含首次）和 proxy_next_upstream_timeout 6s（整个重试过程不超过 6 秒）
设置 backup 节点与分层超时，提供可靠降级出口
当所有主节点都被标记为不可用时，流量必须有明确去向：
- 在 upstream 中添加带 backup 标志的 server：server 192.168.1.100:8080 backup max_fails=2 fail_timeout=20s;
- backup 节点本身也需健康检查，避免降级链路失效
- 为降级路径单独配置更宽松超时，例如在 location 块中针对 backup 流量设 proxy_read_timeout 60s，因为它可能指向缓存或静态页服务
- 若无需备用服务器，也可配置 error_page 502 503 504 /fallback.html 返回预置降级页面
确保底层参数协同，否则策略全部失效
以下四项缺一不可，常见故障多源于遗漏其中某项：
- proxy_connect_timeout 和 proxy_read_timeout 必须小于 fail_timeout，否则重试发不出去
- upstream 至少要有 2 台非 backup 节点，否则重试无目标
- proxy_next_upstream 必须出现在与 proxy_pass 同级的 location 块中，不能只写在 http 或 server 块顶层
- 避免 proxy_next_upstream_tries 设为 1——这等于关闭重试
