Nginx 反向代理 502 排查：先分清上游、超时与日志三条线

用户报 502，第一反应往往是重启 Nginx。其实 502 的意思是 Nginx 收到了上游的无效响应，或者根本没有拿到完整响应。问题可能在上游、网络、超时，也可能在 Nginx 自身的配置。先别急着改配置，按上游、超时、日志三条线分清，再动手，改动才可验证、可回滚。

一、先看日志定性，不要先猜

先查 error_log，再看 access_log。error_log 里常见的三类信息指向完全不同的方向：connect() failed 说明连不上上游，要查地址、端口、防火墙和上游是否在监听；upstream timed out 说明连上了但等不到响应，要查慢接口和超时配置；no live upstreams 说明健康检查已把全部上游摘掉，要查上游状态而不是单个请求。access_log 则要同时看状态码、上游地址和上游耗时：同一个接口有时 200、有时 502，往往是某台上游异常；全部请求都 502，往往是配置、DNS 或上游整体不可用。

二、上游线：先绕过 Nginx 直接测

在 Nginx 所在机器上，用 curl 直接请求上游地址和端口，排除浏览器缓存、域名解析和负载均衡的干扰。如果直连也失败，问题就在上游或网络；如果直连正常而经 Nginx 失败，问题大概率在 Nginx 配置。还要确认上游是不是刚重启、刚发布、连接数打满，或者只在某台机器上异常。多个上游时逐台测，不要只测域名解析到的第一台。keepalive 配置不当也会表现为偶发 502：上游已关闭空闲连接，Nginx 仍复用旧连接，第一次请求失败、重试才成功，这类问题要结合上游的超时和 keepalive 参数一起看。

三、超时线：区分连接超时、发送超时和读取超时

proxy_connect_timeout 是建连等待时间，太短会在上游稍忙时误判；proxy_send_timeout 是向后端发送请求体的等待时间；proxy_read_timeout 是等后端响应的时间，最常被误调。慢接口超时要先看上游耗时分布，而不是直接把超时调到很大：调大只能掩盖慢问题，还会让连接堆积、拖垮上游。正确做法是先确认接口正常耗时，再把超时设为合理上限，同时给关键接口加熔断或降级，避免一个慢接口拖住全部连接。还要检查客户端超时和中间件超时，避免 Nginx 还没等到上游、客户端已经断开，导致日志里出现看似矛盾的现象。

四、用一条证据链收尾

一次合格的排查应该能回答四个问题：哪个时间点、哪个接口、走了哪台上游、花了多长时间。把 error_log、access_log、上游日志和发布时间点对齐，必要时给请求加 request_id 并在各层日志里透传。改配置前先备份并做 nginx -t 检查，改完只改一处、观察一段时间再改下一处。常见的排查清单是：上游进程在吗、端口通吗、DNS 解析对吗、证书和协议对吗、超时合理吗、连接池健康吗、最近发布改了什么。

502 不可怕，可怕的是没有证据就重启、放大超时、来回改配置。按上游、超时、日志三条线走一遍，大多数 502 都能在半小时内定位到一层，而不是在三层之间反复猜测。