必须显式配置proxy_next_upstream error timeout http_502，配合proxy_next_upstream_tries 3、proxy_next_upstream_timeout 10s及upstream中max_fails=2 fail_timeout=30s，且仅对get/head等幂等请求生效。
要让 Nginx 在轮询模式下遇到后端返回 502 时立即尝试下一个节点，不能只依赖默认行为——502 默认不触发重试，必须显式启用并精确配置。
必须开启并限定重试范围
proxy_next_upstream 是核心指令，但默认对 http_502 不生效。需在 location 或 upstream 块中明确列出：
- 保留基础错误类型：error（连接失败、reset）和 timeout（超时）是兜底必需项
-
显式加入 502/503/504：加上
http_502 http_503 http_504，这样后端真实返回这些状态码才会触发切换 - 避免加入 http_404 或 http_500：前者是路径问题，后者多属业务异常，重试无意义且可能引发副作用
限制重试次数与总耗时
不加约束的重试会放大延迟，甚至让用户卡住几十秒。关键参数要配齐：
- proxy_next_upstream_tries 3：最多总共尝试 3 次（含首次），即最多换 2 个节点
- proxy_next_upstream_timeout 10s：从第一次请求发出起计时，所有重试加起来不能超过该值
- 若单次 proxy_read_timeout 设为 5s，10s 总时限可覆盖一次慢响应 + 一次网络抖动，兼顾容错与体验
配套被动健康检查，防止反复打挂节点
仅靠重试解决不了“下次还打不打它”的问题。每个 upstream server 必须带故障隔离机制：
- server 192.168.1.10:8080 max_fails=2 fail_timeout=30s;：连续 2 次失败（包括重试失败）后，该节点 30 秒内不再参与轮询
- 注意：只有被 proxy_next_upstream 列出的状态码（如 http_502）失败，才会计入 max_fails 计数
- 可选加
backup节点，作为全主节点不可用时的最后一道备用链路
确认请求方法是否支持重试
Nginx 默认只对幂等方法（GET/HEAD）自动重试。如果是 POST/PUT 等非幂等请求：
- 即使配置了 proxy_next_upstream，也不会自动切换——这是安全保护机制
- 不建议强行开启 non_idempotent，否则可能造成重复提交、扣款等严重后果
- 业务层应尽量将关键写操作设计为可重试或幂等，而非依赖 Nginx 层兜底
