重试阈值由proxy_next_upstream触发条件、proxy_next_upstream_tries和upstream的max_fails/fail_timeout共同决定；需显式配置error、timeout及http_502/503/504等触发条件，设tries≤2、timeout≤8s，并配合max_fails=2/fail_timeout=5s实现灵敏故障隔离与快速恢复。
重试阈值不是独立配置项，而是由 proxy_next_upstream 触发条件、proxy_next_upstream_tries 和 upstream 中的 max_fails/fail_timeout 共同决定的。关键在于控制“失败后重试几次”和“什么算失败”。
明确重试触发条件
仅靠默认的 error timeout 不够，很多 HTTP 错误（如 502、504）不会自动触发重试，必须显式声明：
- error：连接被拒、断连等底层网络错误
- timeout：连接、发送或读取超时（受 proxy_connect_timeout 等约束）
- http_502、http_503、http_504：网关类错误，常见于后端崩溃或过载
- 避免配置 http_404 或 http_400：这类错误通常属业务逻辑问题，重试无意义
限制重试次数与总耗时
防止请求在多个节点间反复兜转，尤其要防雪崩：
- proxy_next_upstream_tries 2：最多尝试 2 次（含首次请求），即最多换 1 台后端
- proxy_next_upstream_timeout 8s：从第一次发起请求开始计时，整个重试过程不能超过 8 秒
- 若不设 tries，默认为 0（无限重试），极易引发级联超时
配合 upstream 的故障判定逻辑
重试行为需与节点健康状态联动，否则可能反复打向已失效节点：
- max_fails=2 fail_timeout=5s：连续失败 2 次即标记不可用，5 秒后自动重试该节点
- 该组合适合短连接微服务，比默认的 max_fails=1 fail_timeout=10s 更灵敏且恢复更快
- 节点被摘除后，proxy_next_upstream 自动跳过它，只在剩余可用节点中重试
验证是否生效
上线前务必实测，不能只看配置：
- 停掉一台主 server，观察 access log 是否有请求落到 backup 或其他存活节点
- 检查 error log，确认出现类似 “upstream failed (111: Connection refused)” 后立即转向 next upstream 的记录
- 用 curl -v 发起单次请求，结合 time 命令确认总耗时未超出 proxy_next_upstream_timeout
