高并发下Nginx报502主因是连接卡在建连、等待响应或被主动断开等环节，需结合error.log错误码精准定位阶段，直连验证后端健康性，检查Nginx连接资源与upstream keepalive配置，并排查后端accept队列溢出等系统级瓶颈。
高并发下 Nginx 报 502，往往不是后端“挂了”，而是连接卡在某个环节——可能是连不上、连上了但等不到响应、或连上了却立刻被断开。关键在于分清阶段、抓准日志线索、验证真实路径。
看 error.log，锁定出错阶段和错误码
Nginx 的 /var/log/nginx/error.log 是唯一可信现场。不要猜，直接查最近的报错行，重点关注括号里的系统错误码和“while”后面的阶段描述：
- connect() failed (111: Connection refused) → 连接上游时被拒：后端没监听、端口错、服务根本没启、防火墙拦了
-
upstream timed out (110: Connection timed out) while connecting to upstream → 建连超时：网络延迟大、后端 accept 队列满（
ss -lnt | grep :端口看 Recv-Q 是否长期 > 0）、SYN 包丢弃 -
upstream timed out (110: Connection timed out) while reading response header → 已建连，但等不到响应头：典型 504，但 Nginx 有时也返回 502；重点查
proxy_read_timeout和后端处理耗时 - upstream prematurely closed connection → 后端主动断连：常见于 PHP-FPM worker 耗尽、Spring Boot accept 队列溢出、进程被 OOM kill、keepalive 超时
绕过 Nginx，直连后端验证健康性
用 curl -v http://127.0.0.1:8080/health 或 telnet 127.0.0.1 8080 直连后端，确认三点：
- 端口是否真在监听（
netstat -tulnp | grep :8080） - 响应是否及时（
time curl -s http://... > /dev/null） - 并发压测是否稳定（
ab -n 1000 -c 200 http://127.0.0.1:8080/health）
如果直连都慢或失败，问题一定在后端或系统层；如果直连快而 Nginx 慢，问题就在代理链路本身。
检查 Nginx 连接资源与 upstream 配置
高并发下，Nginx 自身可能先扛不住：
- 确认 worker 进程数足够：
ps aux | grep nginx看 worker 数，建议设为 CPU 核心数 - 检查文件描述符限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，不足需调worker_rlimit_nofile - upstream 必须启用 keepalive：
keepalive 200;并在 location 中配proxy_http_version 1.1;和proxy_set_header Connection "";，否则每请求新建 TCP 连接，极易打满后端 accept 队列 - 避免盲目调大超时：先确认是哪个 timeout 生效，再针对性调整
proxy_connect_timeout（建连）、proxy_read_timeout（等响应头/体）、proxy_send_timeout（发请求体）
排查后端系统级瓶颈
即使后端应用进程显示正常，也可能被系统层卡住：
- 检查 accept 队列是否溢出：
ss -lnt查目标端口的 Recv-Q 值，若持续 ≥net.core.somaxconn（默认 128），说明新连接被丢弃，Nginx 收到 RST 或超时，报 502 - 确认系统参数：
sysctl net.core.somaxconn和后端框架（如 Tomcat 的acceptCount、Spring Boot 的server.tomcat.accept-count）是否匹配，建议统一调至 1024 或更高 - 观察后端进程状态：
top -p $(pgrep -f "java.*tomcat")看 CPU 是否跑满、线程数是否接近 ulimit -u 限制 - 检查是否有大量 TIME_WAIT 占用端口：
netstat -ant | grep TIME_WAIT | wc -l，过高需优化内核参数或复用连接
