Nginx代理HTTPS后端时状态码未透传，主因是默认行为与业务意图不匹配：需明确选择原样透传、拦截自定义或补充诊断头；禁用proxy_intercept_errors可透传4xx/5xx，启用则需配error_page；重试机制不影响最终状态码。
Nginx 代理 HTTPS 后端时，后端返回的状态码（如 401、404、503）没有按预期透传或处理，本质不是“状态码被改了”，而是 Nginx 默认行为与你的业务意图不匹配。关键在于明确你想要的效果：是原样交给客户端？还是拦截后统一兜底？或是根据状态做条件跳转？下面分场景给出直接可用的解法。
让后端状态码原样透传给客户端
这是最常见也最容易被误操作的场景。默认情况下，Nginx 确实会透传 4xx/5xx，但有两个隐性前提：
- 后端响应体长度 ≥ 512 字节（否则可能绕过代理逻辑，触发默认错误页）
- 没有启用
proxy_intercept_errors on，且未配置对应error_page
若发现本该返回 404 却变成 502 或空白页：
- 检查是否误加了
proxy_intercept_errors on;但没配error_page→ 直接删掉这行，或补全error_page 404 /404.html; - 确保后端真实返回了带内容的 404 响应（用
curl -i https://backend/xxx验证响应头和 body 长度） - 不要依赖
add_header覆盖状态码（return或error_page才能真正改变状态）
对特定状态码做拦截与自定义响应
比如所有后端 503 都返回静态维护页，或把 401 重定向到登录页：
- 在
location块中启用拦截：proxy_intercept_errors on; - 显式声明拦截哪些码：
error_page 500 502 503 504 /err50x.html;（路径需在root下存在） - 对 401 这类需逻辑跳转的，推荐用
map + error_page替代if：map $upstream_http_status $login_redirect { 401 1; default 0; } error_page 401 = @login; location @login { return 302 https://login.example.com?from=$request_uri; }
保留原始状态码并补充诊断信息
既不想干预状态，又需要前端或监控识别“这是后端报的 503”：
- 添加响应头传递上游真实状态：
add_header X-Backend-Status $upstream_http_status; add_header X-Backend-Time $upstream_response_time;
- 注意：
$upstream_http_status仅在成功收到后端响应后有效；若连接失败（如超时、SSL 握手失败），该变量为空，此时实际返回的是 Nginx 自身生成的状态（如 502/504）
避免混淆状态处理与重试机制
状态码处理（error_page / proxy_intercept_errors）和请求重试（proxy_next_upstream）完全独立：
-
proxy_next_upstream http_503表示：后端返回 503 时，Nginx 换个 upstream 节点重发请求，不会改变最终返回给客户端的状态码（除非重试后成功） - 如果你希望“503 时返回维护页”，必须用
error_page 503 /maint.html，而不是指望重试兜底
不复杂但容易忽略
