502错误由连接数限制引发时，本质是Nginx或上游在连接建立、维持、复用环节被硬性截断，需从Nginx自身连接能力、内核资源、上游服务承载力三层交叉验证。
502 错误由连接数限制引发时，往往不是“服务挂了”，而是 Nginx 或上游在连接建立、维持、复用环节被硬性截断——典型表现是：请求偶发失败、错误日志里反复出现 connect() failed (111: Connection refused) 或 upstream prematurely closed connection，但上游进程明明活着、端口也监听着。这类问题本质是配置项之间存在隐性冲突，需从 Nginx 自身连接能力、内核资源、上游服务承载力三层交叉验证。
查 Nginx worker 连接上限是否耗尽
Nginx 实际能并发处理的连接数 = worker_processes × worker_connections。若该值过小，高并发下新连接会被直接拒绝，上游还没收到请求，Nginx 就返回 502。
- 确认当前配置：
grep -E "worker_processes|worker_connections" /etc/nginx/nginx.conf - 检查实际使用率：用
ss -s | grep "TCP:"查看 ESTAB 连接总数，再对比理论上限 - 注意：若启用了
use epoll;（Linux 默认），单个 worker 能高效支撑上万连接；但若设为worker_processes 1; worker_connections 1024;，理论上限仅 1024，极易打满
查 Linux 内核级连接队列是否溢出
即使 Nginx 配置宽松，当上游服务（如 PHP-FPM、Gunicorn）的 accept 队列（backlog）填满，内核会丢弃新 SYN 包，Nginx 尝试 connect 时就会报 Connection refused——这常被误判为上游没启动。
- 查看当前 backlog 设置：
ss -lnt | grep :端口号（第三列是 Recv-Q，若持续接近或等于第二列 Send-Q，说明队列积压） - 上游服务需同步调大：PHP-FPM 的
listen.backlog = 65535，Node.js 的server.listen(port, host, backlog)参数，Gunicorn 的--backlog 2048 - 系统级兜底：
sysctl net.core.somaxconn应 ≥ 上游 backlog 值，否则内核会自动截断
查 upstream 连接复用与超时配置是否矛盾
Nginx 默认启用 keepalive，但若 keepalive_timeout 远小于上游服务的空闲连接关闭时间，或 proxy_http_version 1.1 + proxy_set_header Connection '' 没配全，会导致连接被上游主动 reset，Nginx 收到后返回 502。
- 关键配置必须成对出现：
upstream backend {<br> server 127.0.0.1:8000;<br> keepalive 32;<br> }<br> location / {<br> proxy_pass http://backend;<br> proxy_http_version 1.1;<br> proxy_set_header Connection '';<br> } - 若上游不支持 HTTP/1.1 keepalive（如老旧 CGI），则应禁用：
proxy_http_version 1.0; proxy_set_header Connection 'close';
查 upstream server 的连接数分配是否失衡
当 upstream 块中多个 server 共享同一组连接池，而某台上游机器响应慢或故障，Nginx 可能因 max_fails 和 fail_timeout 临时剔除它，导致剩余节点连接压力陡增，触发其自身连接限制。
- 检查健康检查配置：
upstream backend { server 10.0.1.10:80 max_fails=3 fail_timeout=30s; } - 观察实时状态：
curl http://localhost/status（需启用 stub_status）或用nginx -T | grep -A 10 "upstream"确认配置是否生效 - 临时绕过健康检查测试：
proxy_next_upstream off;（仅用于验证，勿长期开启）
不复杂但容易忽略：连接数类 502 很少单独发生，通常伴随上游日志里的 accept() failed (24: Too many open files) 或 connection limit reached。把 Nginx error.log、上游服务日志、ss -s 输出三者对照着看，冲突点很快浮出水面。
