Nginx需显式配置proxy_next_upstream指定http_500等状态码才重试，推荐500/502/503/504/429，禁用4xx客户端错误；配合proxy_cache_use_stale可返回陈旧缓存。
直接在 Nginx 的 upstream 块或 location 块中配置 proxy_next_upstream 指令，就能让 Nginx 在遇到指定状态码时自动把请求转发给下一个上游服务器。
明确哪些状态码适合重试
重试只对瞬态错误有意义，不是所有 5xx 或 4xx 都该重试。Nginx 默认只对 error 和 timeout 触发重试，不包含任何 HTTP 状态码。必须显式启用并限定范围：
- 推荐重试的：500、502、503、504、429 —— 这些代表服务暂时不可用或过载，后端可能很快恢复
- 通常不重试的：400、401、403、404、405 —— 属于客户端问题，重试不会改变结果
- GET 请求可额外加 404？需谨慎 —— 仅当确认是临时路由错误（如蓝绿发布期间短暂缺失）才考虑，否则易掩盖真实问题
基础配置写法
在 upstream 或 server 块内添加指令，支持空格分隔多个条件：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
upstream backend {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
# 启用状态码重试，并指定具体码
proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_429;
# 可选：限制最多重试次数（默认为 1 次，即最多尝试 2 台服务器）
proxy_next_upstream_tries 3;
}注意：http_500 是 Nginx 内部标识符，对应 HTTP 状态码 500；不能写成 500 或 http/500。
配合 proxy_cache_use_stale 提升容错能力
当所有上游都失败时，若已缓存过响应，可返回陈旧内容避免完全中断：
- 添加
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; - 需提前配置好
proxy_cache，否则该指令无效 - 适用于静态资源、API 结果等允许短暂陈旧的场景
验证与调试要点
重试行为不会改变原始响应码，除非最终成功。排查时注意：
- 查看 Nginx
error.log，搜索upstream prematurely closed connection或no live upstreams - 开启
proxy_next_upstream_tries后，可通过$upstream_tries变量记录当前重试次数 - 使用
curl -v观察响应头中的X-Upstream-Addr（需自定义add_header）确认是否发生切换
