要实现秒级灾备切换，需配置被动健康检查（max_fails=1、fail_timeout=3s）、proxy_next_upstream重试策略（含HTTP错误码）、backup节点同样设健康参数，并用error_page实现跨协议兜底。
要实现核心连接链路的秒级灾备切换，仅在 upstream 中加 backup 关键字远远不够。它本身不探测、不判断、不触发——真正决定“切不切得快、准不准”的，是健康检查机制与重试策略的协同。
必须配被动健康检查参数
默认情况下，Nginx 不会主动探活节点。只有配置了 max_fails 和 fail_timeout，它才能根据请求失败情况动态标记节点状态：
- max_fails=1：只要一次连接超时、502/503/504 或被拒绝，就立即标为 down
- fail_timeout=3s：该节点被标记后，3 秒内不再发请求；超时后自动试探一次，成功即恢复
- 参数需写在每个 server 行末尾，例如：
server 192.168.1.10:8080 max_fails=1 fail_timeout=3s;
启用 proxy_next_upstream 控制重试行为
默认只对网络层错误（如 connect timeout）重试，HTTP 层错误（如后端返回 500）会直接返回给用户。要让 Nginx 把常见服务异常也纳入重试范围：
- proxy_next_upstream error timeout http_500 http_502 http_503 http_504：覆盖主要故障类型
- proxy_next_upstream_tries 2：最多尝试 2 次（含首次），防卡死
- proxy_next_upstream_timeout 5s：整个重试过程总耗时上限，控长尾
backup 节点也要设健康参数，防自身雪崩
很多人忽略：backup 一旦启用，它自己也可能出问题。若不加保护，Nginx 会持续往一个已失效的 backup 上转发请求，导致彻底不可用：
- 同样给 backup 节点加上 max_fails=1 fail_timeout=3s
- 多个 backup 节点之间按轮询或权重调度，提升备用链路自身可用性
- 若所有节点（含 backup）都不可达，Nginx 会直接返回 502/503，不会无限重试
跨协议或跨源场景用 error_page 做兜底出口
当 backup 不是同个 upstream（比如主是 HTTP，backup 是 HTTPS、本地文件或轻量降级服务），就不能只靠 backup 标记：
- 在主 location 中写：
error_page 502 503 504 = @backup_origin; - 另起一个
location @backup_origin，里面用proxy_pass或return指向真实备用地址或静态响应 - 这种写法可实现接口级降级，毫秒级响应，不依赖后端
不复杂但容易忽略。
