Nginx 502 先别重启：从日志定位上游故障的排查顺序

看到 502 先别急着重启 Nginx。502 的意思是 Nginx 收到了上游的无效响应，或者根本没能和上游完成一次有效通信，问题往往不在 Nginx 本身。先分清是偶发还是持续、是某个接口还是全站，再去翻日志，排查会快很多。

第一步：看错误日志，锁定时间点。先用 tail 看 error.log 里 502 出现前后的记录，重点看 upstream、connect() failed、Connection refused、upstream timed out、no live upstreams 这类关键词。把时间点和用户报错时间对齐，能直接排除掉很多猜测。如果日志里反复出现连接被拒绝，说明上游进程可能没起来，或者监听端口变了；如果出现超时，就要往后看是上游处理太慢，还是网络不通。

第二步：确认上游是不是活着。用 curl 直接请求上游地址，绕开 Nginx 测试一次；再用 ss 或 netstat 看端口是否在监听，用 ps 看进程是否存在。很多 502 其实是部署后服务没启动成功、端口被占用导致新进程退出，或者上游只监听了 127.0.0.1，而 Nginx 配的是其他地址。这一层确认只要一分钟，却能避免改一堆配置。

第三步：核对 proxy_pass 和 upstream 配置。检查 proxy_pass 有没有多余或缺失的斜杠，这会影响路径拼接；检查 upstream 里的地址、端口、权重是否和实际部署一致；如果是域名上游，确认解析结果是否指向了已经下线的机器。改配置前先用 nginx -t 检查语法，再 reload，不要直接 restart，reload 不会中断已有连接。

第四步：看超时和资源。upstream 超时时间太短时，接口本身没问题但跑得慢，也会表现为 502 或 504。看上游日志的耗时、数据库慢查询、磁盘和内存是否打满。尤其要留意连接数：如果上游连接池满了，新请求排队超时，表现就是间歇性 502，这时扩连接池、优化慢接口比加机器更有效。

第五步：看是不是只在个别节点出问题。如果是多台上游，逐台摘掉再测试；如果某台持续 502，单独看它的日志和健康检查。负载均衡把请求分到一台异常节点上时，全站会呈现时好时坏，这类问题靠重启 Nginx 是修不好的，必须先把异常节点下线再修。

一个实用的排查顺序是：时间点对齐日志，确认上游存活，核对代理配置，检查超时与资源，最后做单节点隔离。按这个顺序走，大多数 502 都能在日志里找到直接证据，而不是靠反复重启碰运气。养成先看日志、再动配置的习惯，线上故障的定位时间会明显缩短。