backup节点需激进配置max_fails=1/fail_timeout=2s、精准重试（tries=1/timeout=1.5s）、长连接复用及error_page降级，方能在高压下实现秒级故障感知与稳定容灾切换。
要让 upstream 的 backup 节点在极致压力下真正扛住容灾切换，不能只靠“标个 backup”就完事。它本质是被动兜底机制，必须在高并发、低延迟、节点频繁抖动的场景下，把健康探测、重试控制、连接复用和降级兜底全部拧成一股绳——否则容易切不及时、切错、切了回不来，甚至引发雪崩。
短时故障秒级摘除：max_fails 和 fail_timeout 必须激进
压力大时，节点可能不是宕机，而是响应慢、超时多、503 突增。默认保守配置（如 max_fails=3 fail_timeout=30s）会导致 Nginx 还在往“半死”节点发请求，backup 始终不启用。
- 主节点统一设为 max_fails=1 fail_timeout=2s：只要一次失败（连接超时、502/503/504 或 proxy_next_upstream 定义的错误），立刻标记 down，2 秒后自动试探恢复
- 避免“连续失败”逻辑拖慢感知：Nginx 被动检查依赖请求失败计数，单次失败即摘，才能匹配毫秒级抖动
- backup 节点也建议加 max_fails=1 fail_timeout=2s：防止它自己因压测或网络抖动失效后，仍被持续轮询
重试策略必须精准可控，防长尾放大
高压下一次重试可能就是 300ms+，盲目重试会加剧下游压力、拉高 P99 延迟，甚至触发级联超时。
- 只对安全可重试的方法开启重试：proxy_next_upstream error timeout http_502 http_503 http_504（慎加 http_500，除非确认业务幂等）
- 严格限制重试次数：proxy_next_upstream_tries 1（即最多再试 1 次，含首请求共 2 次）
- 全局重试耗时封顶：proxy_next_upstream_timeout 1.5s：哪怕 backup 节点响应慢，超时也立即放弃，返回 502 或走 error_page
连接层优化：减少建连开销，加速故障感知
短连接场景下，TCP 握手失败本身就会被计入失败，但建连耗时波动大，易误判；长连接复用则能更快暴露真实服务状态。
- upstream 块中启用连接池：keepalive 64;
- location 中复用连接：proxy_http_version 1.1; proxy_set_header Connection '';
- 调低传输超时：proxy_connect_timeout 500ms; proxy_send_timeout 1s; proxy_read_timeout 1s;（配合业务 SLA 调整）
兜底不止 backup：error_page + 独立 fallback location 是压舱石
当所有 upstream（含 backup）都不可达，或 backup 自身也抖动时，单纯依赖 backup 会直接返回 502，用户体验断崖式下跌。
- 在主 location 中声明：error_page 502 503 504 = @degraded_origin;
- 另起 location @degraded_origin，指向轻量 fallback 服务（如本地静态页、降级 API、CDN 缓存、或另一套独立备份集群）
- 该 fallback 可完全跨协议、跨域名，甚至返回预生成 JSON 或 HTML，不依赖 upstream 机制
不复杂但容易忽略：backup 不是热备，而是最后一道闸门；极致压力下的容灾，拼的是感知快、决策准、切得稳、退得清。每一步配置都要贴着业务水位和故障特征来调，而不是照搬模板。
