单纯开启 proxy_next_upstream 不能保障高可用，反而可能引发雪崩；必须配合 proxy_next_upstream_tries（建议设2或3）、proxy_next_upstream_timeout 与 proxy_read_timeout、幂等性控制及健康检查协同使用。
单纯开启 proxy_next_upstream 并不能保障高可用，反而可能在后端局部抖动时引发连锁重试，把单点压力扩散成集群雪崩。关键在于用 proxy_next_upstream_tries 做精准节流——它不是“多试几次更可靠”，而是“最多试几次才安全”。
明确 tries 的真实含义：含首次的总尝试次数
proxy_next_upstream_tries 3 表示整个请求生命周期内，Nginx 最多向 upstream 中的服务器发起 3 次转发（1 次原始请求 + 最多 2 次重试）。这不是“重试 3 次”，而是“总共不超过 3 次”。生产环境建议设为 2 或 3，避免一次失败触发全量重发。
- 设为 1：等同于关闭重试，失去容错能力
- 设为 2：原始请求失败后仅再试 1 次，平衡可用性与风险
- 设为 3：适用于读多写少、延迟敏感但非强一致场景（如商品详情页）
- 超过 3：显著增加尾部延迟和上游负载，不推荐
必须搭配 timeout 使用，否则 tries 失效
proxy_next_upstream_tries 单独存在时约束力极弱。若某次重试耗时 8 秒，而总超时未设限，Nginx 仍会执行满 3 次，导致用户等待长达 24 秒。必须同步配置：
-
proxy_next_upstream_timeout 6s：所有尝试加起来不能超过 6 秒。哪怕只试了 2 次已超时，立刻终止并返回错误 -
proxy_read_timeout 5s：控制单次请求等待响应的上限，防止某次卡死拖垮整体 - 两个 timeout 要形成嵌套关系：单次超时 ≤ 总重试超时 / tries
区分请求类型，非幂等操作慎用重试
GET/HEAD 请求天然可重试；但 POST、PUT、DELETE 等默认不重试，因为 Nginx 认为它们不具备幂等性。强行开启（如加 non_idempotent）可能导致重复扣款、重复下单。
- 确认业务幂等：上游服务必须保证重复提交产生相同结果（例如带唯一 request_id 校验）
- 禁用非必要重试：对支付、库存、订单创建等接口，建议显式设置
proxy_next_upstream off - 分离路由：将读写接口拆到不同 location，读接口开重试，写接口关重试
结合健康检查，从被动重试转向主动规避
靠失败后重试是“亡羊补牢”，而健康检查能提前剔除问题节点，大幅降低重试触发概率。
- 在 upstream 块中添加：
health_check interval=3 fails=2 passes=2; - 每 3 秒探测一次，连续 2 次失败则标记为不可用，恢复需连续 2 次成功
- 配合
max_fails=2 fail_timeout=30s，双重机制兜底 - 健康检查 + 有限重试 = 更快发现故障 + 更稳应对抖动
