Nginx默认不因后端返回404而重试，因404属正常业务响应而非传输失败；重试需显式配置proxy_next_upstream http_404，并配合proxy_intercept_errors on才能生效。
Nginx 默认不会因后端返回 404 而自动重试其他上游服务器。是否重试，完全取决于 proxy_next_upstream 的显式配置——它不包含 http_404 就不会触发重试，哪怕 404 是由某台宕机或配置错误的后端返回的。
404 不是“失败”，而是“成功响应”
Nginx 把 HTTP 状态码视为应用层响应结果，而非连接或传输异常。只要后端完整返回了含 404 状态行和响应头的报文（哪怕内容为空），Nginx 就认为本次代理请求已成功完成。此时不满足 error、timeout 等默认重试条件，自然跳过重试流程。
常见误解：以为“404 = 后端不可用”。实际中，404 更多表示路径不存在、路由未匹配、资源未部署等业务逻辑问题，和服务器是否存活无关。
让 404 触发重试的必要配置
需在 location 或 upstream 作用域中明确启用：
- proxy_intercept_errors on; —— 必须开启，否则 Nginx 不会拦截后端返回的 4xx/5xx 状态码，直接透传给客户端
- error_page 404 = @retry; 或直接使用 proxy_next_upstream
- proxy_next_upstream http_404; —— 显式声明将 404 纳入重试判定条件
- 建议组合使用：proxy_next_upstream error timeout http_404;
重试行为的实际表现
当配置生效后，Nginx 收到某台 upstream 服务器返回的 404 时：
- 立即终止当前连接，不等待响应体读取完毕
- 按 upstream 定义的顺序（或负载均衡算法）选择下一台可用服务器重发请求
- 若所有服务器都返回 404，且未配置 fallback 或自定义 error_page，则最终返回 404 给客户端
- 注意：重试仅发生在同一请求周期内，不改变原始 HTTP 方法（如 POST 默认不重试，除非加 non_idempotent）
比重试更合理的处理方式
多数场景下，盲目重试 404 并非最佳实践：
- 404 本质是客户端请求了不存在的资源，换一台后端大概率仍返回 404
- 可能掩盖真实问题（如部署遗漏、路由配置不一致）
- 建议优先通过健康检查（如
max_fails/fail_timeout）隔离长期异常节点，再配合日志分析定位 404 根源 - 对确实需要兜底的接口，可结合
error_page 404 = @fallback跳转至降级服务，而非简单重试
