排查Nginx代理异常状态码需先区分来源：5xx/4xx若来自上游则查$upstream_status和error.log中的连接失败、超时或SSL错误；若$upstream_status为空则为Nginx未连通后端；须结合access.log三字段与透传请求头验证链路完整性。
排查 Nginx 代理转发失败导致的异常状态码，核心是区分“谁返回的码”和“为什么返回这个码”。Nginx 本身不生成业务逻辑错误，所有 5xx、4xx 异常状态码要么来自上游服务，要么是 Nginx 在通信失败时兜底返回的默认响应。关键不是看 $status 单一字段，而是结合 $upstream_status 和 error.log 中的底层错误线索，定位断点在哪儿。
先看 access.log 里三个关键字段的组合含义
打开 /var/log/nginx/access.log，聚焦以下三列（顺序可能因 log_format 而异）：
- $status：Nginx 最终返回给客户端的状态码，比如 502、403、302；
- $upstream_status：上游真实返回的状态码，比如空值、502、404、302；
- $upstream_http_location：后端响应头里的原始 Location 值，用于判断重定向是否泄露内网地址或路径错误。
典型组合及含义：
-
502 -（$upstream_status 为空）→ Nginx 根本没连上后端，可能是端口未监听、防火墙拦截、DNS 解析失败； -
502 502→ 后端自己返回了 502，说明它作为网关也转发失败了，问题在更上游； -
403 403→ 后端明确拒绝，常见于 Referer 校验、IP 白名单、Host 头不匹配或权限配置； -
302 302但$upstream_http_location是http://192.168.1.100:8080/login→ 重定向地址未被 proxy_redirect 修正，浏览器跳转失败； -
404 404→ 后端路由未命中，不是 Nginx 配置问题，而是后端自身路径处理逻辑有误。
再查 error.log 找通信层真实原因
access.log 告诉你“发生了什么”，error.log 解释“为什么发生”。重点搜这些关键词：
- connect() failed (111: Connection refused) → 后端进程没启动，或监听地址/端口配错；
-
upstream timed out → 后端响应太慢，需调大
proxy_read_timeout或查慢查询； - recv() failed (104: Connection reset by peer) → 后端主动断连，常见于 SSL 握手失败、协议不匹配（如 HTTP/1.1 与 HTTP/2 混用）、或应用崩溃；
- SSL_do_handshake() failed → HTTPS 后端证书不可信、域名不匹配或 TLS 版本不兼容；
- no live upstreams → upstream 组中所有节点都被标记为 down，健康检查持续失败。
验证请求链路是否完整透传
很多 4xx 状态码其实源于请求头丢失或篡改，例如：
- 后端校验
Host头，但 Nginx 默认不透传，需显式加proxy_set_header Host $host;； - 后端依赖
X-Forwarded-For做 IP 限流，但 Nginx 没配或前端有 WAF 清洗了该头； - 后端要求
Referer不为空，而 Nginx 默认不传，需补proxy_set_header Referer $http_referer;。
快速验证方法：用 curl -v -H "X-Test: 123" http://your-domain.com 发请求，再在 access.log 中查 $http_x_test 是否记录；若没出现，说明头在进 Nginx 前就被截断了。
区分 502、504、499 的排查边界
别把三类问题混在一起查：
-
502 Bad Gateway：Nginx 收到了无效响应——查后端进程、端口、fastcgi/proxy 参数、
upstream_status是否为空或非法； -
504 Gateway Timeout：Nginx 等不到响应——调大
proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout，再查后端性能瓶颈； - 499 Client Closed Request：客户端自己断开——基本不用动 Nginx，检查前端超时设置、网络抖动或用户手动刷新。
