proxy_next_upstream_tries设为3表示最多尝试3次（含首次），需与proxy_next_upstream_timeout和健康检查联动，形成次数、时间、节点状态三重闭环，单独设置无法防雪崩。
要严格限制重试总次数，关键不是设个数字就完事，而是让 proxy_next_upstream_tries 在次数、时间、节点状态三个维度上形成闭环控制。它本身不自动防雪崩，只是一道“计数闸门”，必须和其他机制咬合才能真正生效。
明确 tries 是总尝试次数（含首次）
设为 3 表示：第一次请求 + 最多再发 2 次，整个请求生命周期最多转发 3 次。不是“失败后再重试 3 次”。常见配置误区：
-
proxy_next_upstream_tries 1→ 禁用重试，适合支付回调、订单创建等非幂等操作 -
proxy_next_upstream_tries 3→ 覆盖网络抖动、单点瞬时不可用，是生产环境最常用的安全值 -
proxy_next_upstream_tries 0或 ≥5 → 默认无限重试，极易在节点少于 3 台时反复打同一故障机
必须绑定 proxy\_next\_upstream\_timeout 控制总耗时窗口
只限次数不管时间，等于放任慢节点拖垮整体。timeout 是从第一次请求发起开始计时的**整体上限**，超时即刻终止所有后续尝试：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 若单次正常响应约 3–4 秒，建议
proxy_next_upstream_timeout 8s - timeout 不应超过
proxy_read_timeout的 2 倍（如后者为 5s，则前者不宜 >12s） - 避免
tries 5+timeout 30s组合：前两次各耗 15s，第三次根本没机会执行
重试目标不固定，靠健康检查剔除坏节点
Nginx 每次重试是随机选一个当前未被标记为不可用的 upstream 节点，不是轮询切换。没有健康检查，重试大概率仍在打宕机机器：
- 在 upstream 块中启用主动探测：
health_check interval=3 fails=2 passes=2; - 配合被动摘除：
max_fails=2 fail_timeout=30s; - 检查路径必须真实反映服务可用性（如调用 /health 且返回 200 不够，需验证 DB 连通性）
只对真正可恢复的错误开启重试
重试不是万能兜底，而是风险放大器。错误类型必须精准筛选：
- 推荐：
proxy_next_upstream error timeout http_502 http_503 http_504; - 慎用
http_500：业务逻辑异常导致的 500，重试大概率重复失败 - 禁用
non_idempotent：除非 100% 确认 POST/PUT 接口幂等（如带唯一请求 ID + 服务端去重） - 4xx 错误（如 403、404）代表客户端问题，重发无意义
