设为3是生产环境最稳妥的起点，表示最多1次原发+2次重试；需配合proxy_next_upstream_timeout（如10s）和健康检查，且错误触发条件应最小化，仅error/timeout重试。

设为 3 是生产环境最稳妥的起点，不是越大越好；设为 0 或不设等于放任重试失控，极易引发雪崩。

proxy_next_upstream_tries 的计数逻辑容易被误解

它统计的是“整个请求生命周期内最多尝试多少次”，包含首次转发 + 后续重试。设为 3 意味着最多发 3 次请求（1 次原发 + 最多 2 次重试），不是“轮转 3 台机器”。

• 若 upstream 中只剩 1 个节点在线，tries 设为 10 也只会反复打它，形成无效循环
• 默认值是 0（不限制），这在生产中极其危险，必须显式覆盖
• 设为 1 表示禁用重试，适合 POST 等非幂等写操作或强一致性场景

必须配合 proxy_next_upstream_timeout 控制总耗时

proxy_next_upstream_timeout 不是单次超时，而是从第一次发起请求开始、到最终返回或放弃的总时间上限。只限次数不限时间，照样会拖垮响应链路。

Bailian Usage Proxy

阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。

下载

• 若 proxy_read_timeout 是 5s，建议 proxy_next_upstream_timeout 设为 8s–12s（例如 10s）
• 该值应略大于「单次合理耗时 × 预期最大重试次数」，但不能超过客户端可接受的总等待阈值（如前端 timeout 是 30s，这里不宜设成 25s）
• 没有这个限制，前两次都超时（各 5s），第三次可能还在傻等，导致整体延迟飙升

不配健康检查，proxy_next_upstream 就是空中楼阁

重试机制本身是被动容错：等出错了才换人。没有健康检查，Nginx 就不知道谁已经挂了，重试大概率打向同一台故障节点。

• 启用主动探测：health_check interval=3 fails=2 passes=2;（需 Nginx Plus 或编译 upstream_check_module）
• 搭配 max_fails=2 fail_timeout=30s，让短暂抖动不会立刻踢节点，但连续失败后能及时隔离
• 确保 check_http_expect_alive 只认 2xx/3xx，避免把 5xx 当存活
• 健康检查间隔别设太长（如 >10s），否则节点宕机后仍会长时间参与重试

错误触发条件要最小化，别乱加 http_404 或 http_500

proxy_next_upstream 默认只对 error 和 timeout 重试。盲目加上 http_404、http_500，会让 Nginx 把业务确定性错误当成可重试故障，造成重复提交或无效负载放大。

• 推荐基础配置：proxy_next_upstream error timeout;
• 仅当确认后端幂等且稳定时，再谨慎添加 http_502/http_503/http_504
• 绝对不要加 http_404、http_403——它们代表资源不存在或权限不足，重试无意义
• 对非幂等请求启用 non_idempotent 前，必须确保后端已做幂等防护，否则可能引发资金扣减、订单重复等严重后果

真正决定重试是否有效，不是 tries 设多大，而是它和健康检查、错误触发条件、总耗时限制三者是否咬合紧密。漏掉任意一环，就可能让本意是容错的配置，变成压垮集群的扳机。