proxy_next_upstream实现无感切换的关键是精准控制重试时机与范围：需显式配置http_502/503/504触发重试，配合proxy_next_upstream_tries和timeout限制次数与时长，依赖max_fails/fail_timeout健康检查，并仅对幂等请求（如GET）启用。
要让后端节点故障时请求“无感切换”，关键不是堆配置，而是让 proxy_next_upstream 在正确时机、以可控方式换节点——它本身不预测故障，只在失败发生后快速兜底。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
明确哪些错误真正值得重试
默认只对 error（连接拒绝、断连等）和 timeout（超时）触发重试。生产中建议显式补充：
• http_502 / http_503 / http_504：网关类错误，大概率是后端瞬时不可用，适合换节点重试
• 不加 http_404 或 http_403：这类是业务逻辑结果，重试不会改变结果，反而可能放大问题
• 避免盲目加 http_500：除非确认是后端偶发异常（如 GC 暂停），否则应先排查日志，而非依赖重试掩盖问题
限制重试的次数和总耗时
proxy_next_upstream_tries 和 proxy_next_upstream_timeout 必须成对设置，缺一不可：
• proxy_next_upstream_tries 3：表示最多尝试 3 个不同节点（含首次），不是“重试 3 次”
• proxy_next_upstream_timeout 6s：从第一次请求发出开始计时，6 秒内无论试了几个节点，超时即返回错误
• 若单次请求 P95 耗时约 3 秒，设为 6 秒既能覆盖一次重试，又防止长尾拖累整体响应
让重试真正落在健康节点上
光靠重试不行，得配合被动健康检查，避免反复打坏节点：
• 在 upstream 中为每个 server 设置 max_fails=3 fail_timeout=30s：连续 3 次失败（包括重试触发的失败）后，该节点 30 秒内不再参与调度
• 可选加 backup 节点：仅当所有主节点被标记为不可用时才启用，作为最后一道防线
• 若使用 Nginx Plus 或编译了 upstream_check_module，建议启用主动健康检查：health_check interval=3 fails=2 passes=2，比被动等待更早发现故障
区分请求类型，守住幂等底线
重试安全的前提是“重复执行无副作用”：
• GET / HEAD 请求可放心启用重试，天然幂等
• POST / PUT / DELETE 默认不重试，Nginx 有安全机制保护
• 若业务层已严格保障幂等（如通过 X-Request-ID + Redis 记录处理状态），且日志可追溯，才考虑谨慎开启；否则宁可让客户端重试或返回明确错误
