nginx 默认不因后端返回404重试，因其视404为正常业务响应；需避免错误配置proxy_next_upstream包含http_404、关闭proxy_intercept_errors，并通过x-upstream-status验证来源。
Nginx 默认就不因后端返回 404 而重试，这是它的设计原则：404 是正常业务响应，不是连接失败或超时。所以“不重试”本身就是默认行为，无需额外配置来“禁止重试”。
但很多人误以为 Nginx 会自动重试 404，其实是混淆了两类情况：
- 后端服务器根本连不上（connection refused / timeout）→ 触发重试（默认含
error和timeout） - 后端成功响应但状态码是 404 → 不触发重试，直接透传给客户端
要确保这个默认逻辑不被意外覆盖，只需注意以下三点：
确认没开启不必要的重试条件
检查 proxy_next_upstream 指令是否错误包含了 http_404：
# ❌ 错误：显式加入 http_404 会导致 404 也被重试 proxy_next_upstream error timeout http_404; # ✅ 正确：保持默认或只写 error timeout（http_404 不写就是不重试） proxy_next_upstream error timeout; # 或者干脆不写这行——Nginx 默认值就是 error timeout
关闭错误拦截，避免干扰透传
如果启用了 proxy_intercept_errors on;，Nginx 会拦截 404 并尝试用 error_page 处理——这反而可能掩盖原始响应或引发跳转/重定向。
如需原样返回后端的 404，应确保：
proxy_intercept_errors off; # 默认就是 off，除非你主动开了
若已开启，且未配 error_page 404，它反而可能返回 Nginx 自己的 502/503；若配了 error_page 404 = @xxx，就会执行命名 location（比如跳转），不再是“直接返回”。
验证确实是后端返回的 404，而非 Nginx 自己生成的
用响应头快速区分：
- 加
add_header X-Upstream-Status $upstream_status always;- 若响应头中
X-Upstream-Status: 404→ 确实是后端返回的，Nginx 透传了 - 若
X-Upstream-Status为空或502→ 说明 upstream 连接失败，这时才可能触发重试
- 若响应头中
再配合 curl -I 看原始状态码，确认没有被 error_page 或 try_files 等机制二次处理。
不需要加任何“禁用重试”的开关，只要不主动启用 http_404、不开启 proxy_intercept_errors，Nginx 就会安静地把后端的 404 原样交给客户端。
