Nginx 不支持对 497、499 等非标准状态码触发 proxy_next_upstream 重试，因其由 Nginx 内部生成且不经过 upstream；仅标准错误码（如 502/503/504）可被识别并重试。
直接测试非标准状态码（如 497、499）的“重试触发”没有实际意义，因为它们根本不会触发 proxy_next_upstream 重试——Nginx 不支持对这类状态码做自动故障转移。
哪些非标准码根本不能用于重试
Nginx 内部生成的非标准状态码（如 497、499）不是后端返回的 HTTP 响应，而是 Nginx 自身在处理连接时产生的标记：
-
497：表示 HTTP 请求被发到了 HTTPS 端口，是 Nginx 主动拦截并生成的状态，不经过 upstream，
proxy_next_upstream完全不感知 -
499：表示客户端主动断开连接，Nginx 甚至没发出响应，日志中仅作标记，无法被
error_page拦截，更不可能触发重试 -
500+ 自定义码（如 599）：若后端返回了非标准码（如 599），Nginx 默认按 500 处理（取决于版本和配置），但
proxy_next_upstream只认明确声明的http_XXX形式（如http_500），不支持http_599
真正能测试的“类非标”场景：用 limit_req_status 或 error_page 模拟语义
如果你的目标是验证“某种异常条件下是否走备用路径”，可绕过重试机制，改用 error_page + 命名 location 实现可控跳转：
- 用
limit_req_status 429配合限流规则，让特定请求稳定返回 429，再通过error_page 429 = @fallback跳转到备用 upstream - 在测试环境 mock 后端，让它对某条路径固定返回
HTTP/1.1 503 Service Unavailable，这是标准码，proxy_next_upstream http_503可正常捕获并重试 - 不要试图让后端返回 499 或 497 来测重试——它们压根不会进入 upstream 流程，测了也白测
可靠测试方法：聚焦标准错误码 + 日志验证
生产级验证只依赖三件事：真实后端行为、Nginx 日志、明确配置：
- 启动两个后端服务，A 正常，B 固定返回
502 Bad Gateway（标准码） - upstream 中配置两个 server，并启用
proxy_next_upstream error timeout http_502 - 用
curl -v发起请求，同时查看 Nginx access log 和 error log：
– 若看到两次 upstream 访问（分别打到 A 和 B），说明重试生效
– 若只记录一次失败且返回 502，说明配置未命中或节点被标记为不可用 - 配合
proxy_next_upstream_tries 2和proxy_next_upstream_timeout 3s控制边界，避免误判超时为重试失败
为什么别折腾非标准码的重试测试
所有主流文档和线上实践都表明：proxy_next_upstream 的设计目标是应对网络层失败（error/timeout）和服务层瞬态错误（502/503/504）。它不处理协议解析异常、客户端中断或 Nginx 内部逻辑分支。强行测试 499 或 497，本质是在验证一个不存在的功能。把精力放在标准码的路径覆盖、健康检查联动和幂等性保障上，才真正影响可用性。
