Nginx 502 排查顺序：从 upstream 到 fd 上限

502 的含义只有一句：Nginx 作为反向代理，没能从上游拿到合法响应。所以排查方向永远在上游，而不是 Nginx 的配置文件写错了什么。

第一步：确认是全部 502 还是部分 502

tail -f /var/log/nginx/error.log 里看关键行：

connect() failed (111: Connection refused) while connecting to upstream
upstream prematurely closed connection while reading response header
no live upstreams while connecting to upstream

• Connection refused：上游进程没起，或监听地址不对（127.0.0.1:8080 vs 0.0.0.0:8080 是最常见的坑）
• prematurely closed：进程活着但处理请求时崩了，去看应用日志
• no live upstreams：健康检查把后端全部摘掉了

第二步：绕过 Nginx 直接打上游

curl -sv http://127.0.0.1:8080/health
ss -ltnp | grep 8080

如果 curl 正常、通过 Nginx 却 502，问题在 Nginx 的 upstream 配置或网络命名空间；如果 curl 也失败，问题在应用本身。

第三步：看超时设置是否错配

proxy_read_timeout 默认 60s。上游跑一个 90s 的任务，Nginx 会先断开，日志里是 upstream timed out。这类 502 的特征是"偶发、集中在慢请求上"。

location /api/ {
    proxy_connect_timeout 5s;
    proxy_send_timeout 60s;
    proxy_read_timeout 120s;
}

要跟应用的超时对齐，但不要为了消除报错把超时无脑调大——真正的慢查询会在别处爆炸。

第四步：检查文件描述符和连接数

高并发下 502 经常不是超时，而是打不开新连接：

cat /proc/$(pgrep -f 'nginx: worker' | head -1)/limits | grep 'open files'
ss -s

worker 的 worker_connections 与系统 nofile 都要够。worker_rlimit_nofile 要在 nginx.conf 里显式设置，因为 systemd 的 LimitNOFILE 只作用于主进程。

第五步：确认不是上游把连接重置了

如果应用是 Go/Java 这类带连接池的，后端在重启时会 RST 掉存量连接，Nginx 正好复用到这条连接，就会 502。特征是"发布瞬间一小批 502"。解决方式是上游优雅停机（先摘流量、等连接排空），或者 Nginx 侧开启 proxy_next_upstream error timeout，让失败请求换一个后端重试。

一份可复用的检查清单

1. nginx -t 通过，配置重载成功
2. ss -ltnp 能看到上游端口，地址族匹配
3. curl 直连上游返回 200
4. error.log 里的错误类别与上面的四类对上
5. 超时、fd、worker_connections 三项与压测结果匹配
6. 发布窗口是否有集中的 502（说明是优雅停机问题）

按这个顺序走，绝大多数 502 在第三步之前就能定位，不需要改 Nginx 配置。