应精准配置nginx重试策略：仅对502/503/504及timeout重试，禁用4xx和500；设tries=2、timeout=1.5s；配合健康检查主动规避故障节点；非幂等操作（如登录、token刷新）严禁nginx层重试。

要防止后端安全路径（如登录、鉴权、Token刷新等）偶发超时导致请求大面积挂起，关键不是盲目开启重试，而是让 proxy_next_upstream 在“该重试时精准重试、不该重试时快速失败”，同时避开非幂等操作的风险。安全路径通常依赖数据库查用户、调用密钥服务或触发风控逻辑，一旦慢，往往是资源争抢或依赖阻塞，重试不当极易引发雪崩。

只对真正可恢复的错误启用重试

安全接口返回 502/503/504 多因瞬时过载（如 Tomcat 线程池满、Redis 连接池耗尽），这类故障换节点大概率成功；但 401/403/429 或业务层 500（如 JWT 解析失败、签名验签异常）是确定性结果，重试只会放大无效流量：

• 显式配置：proxy_next_upstream error timeout http_502 http_503 http_504; —— 不加 http_401、http_403、http_500
• 禁用所有 4xx 触发：它们代表客户端状态或权限决策，非后端临时不可用
• 若上游偶发因 GC 暂停导致响应延迟，timeout 条件必须开启，否则 Nginx 根本不会切节点

严格限制重试范围：tries + timeout 必须配对生效

安全路径通常要求低延迟（如登录接口 P95 ≤ 800ms），重试不能拉长整体等待。设 tries 为节点数上限，timeout 为总耗时硬闸：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• proxy_next_upstream_tries 2; —— 主节点失败后仅尝试一次 backup，避免打遍全部节点
• proxy_next_upstream_timeout 1.5s; —— 总窗口略大于单次 proxy_read_timeout 1s，确保首次超时后还有余量切走
• 若 proxy_read_timeout 设为 1s，而 proxy_next_upstream_timeout 小于 1s，首次请求就会被截断，失去重试意义

配合健康检查，把“被动重试”变成“主动规避”

单纯靠出错再重试，等于每次请求都先撞一次墙。对安全路径这类高敏感链路，应提前筛掉风险节点：

• 在 upstream 块中为每个 server 添加：max_fails=2 fail_timeout=15s;
• 搭配主动健康检查（需 Nginx Plus 或编译 upstream_check_module）：health_check interval=2 fails=2 passes=2;
• 检查路径建议用轻量接口，如 /health?check=auth，返回 200 即认为鉴权模块就绪，不依赖数据库

非幂等操作必须零重试，哪怕返回 502

安全路径中的 POST /login、POST /token/refresh 等操作天然非幂等。Nginx 默认不对其重试，这是保护机制，切勿用 non_idempotent 强行打开：

• 保持默认行为：proxy_next_upstream error timeout http_502 http_503 http_504; 不加 non_idempotent
• 这样即使返回 502，Nginx 也只发一次，避免重复登录、重复发 Token、重复触发风控规则
• 若业务侧确需容错，应在应用层实现幂等（如基于 X-Request-ID 缓存处理状态），而非依赖 Nginx 转发层