worker_connections过小本身不直接导致502，但会暴露文件描述符不足等底层瓶颈，引发上游连接失败而报502；需结合error.log、ss命令、ulimit及系统限制综合排查，优先排除后端服务、配置错误等更常见原因。
worker_connections 设置过小本身不会直接导致 502，但它会暴露或加剧底层资源瓶颈，最终表现为上游连接失败、响应中断，Nginx 转发时收不到有效数据而报 502。排查关键不是盲目调大数值，而是验证它是否真成了瓶颈，并定位背后的真实限制。
看 error.log 里有没有明确线索
打开 /var/log/nginx/error.log，搜索以下两类典型提示：
- “worker_connections are not enough” 或 “accept() failed (24: Too many open files)”：说明 Nginx 想建连接但系统不允许，是文件描述符不足的直接信号
- “upstream prematurely closed connection” 或 “connect() failed (111: Connection refused)”：需结合时间点和上游状态判断——如果大量出现在高并发时段，且上游日志无异常，就可能是连接池耗尽后 Nginx 无法复用 socket 导致 upstream 连接反复失败
查当前连接与资源使用是否匹配
运行命令对比理论值与实际值：
- 查活跃连接：ss -s | grep "TCP:"，看 ESTAB 数量是否远低于 worker_processes × worker_connections
- 查 Nginx 进程的文件描述符上限：cat /proc/$(pgrep nginx)/limits | grep "Max open files"
- 查系统级限制：ulimit -n（当前 shell）和 grep nginx /etc/security/limits.conf（持久配置）
若 ulimit -n 是 1024，而 worker_connections 设为 8192，那几乎必然卡在文件句柄上，502 就是连不上 upstream 的表象。
确认是不是系统级限制拖了后腿
worker_connections 是“目标”，但操作系统才是“裁判”。重点检查三项是否协同调高：
- nginx.conf 中加：worker_rlimit_nofile 65536;（放在 events 块外、http 块上方）
-
/etc/security/limits.conf 中加（用户换成实际运行者，如 www-data）：
www-data soft nofile 65536
www-data hard nofile 65536 - 内核参数补充：sysctl -w net.core.somaxconn=65535（避免 SYN 队列溢出丢包）
改完必须重启 shell 或重新登录，再用 ulimit -n 验证生效，否则配置无效。
排除其他更常见的 502 根因
别让 worker_connections “背锅”。先快速过一遍更高频原因：
- 后端服务是否存活？systemctl status php-fpm 或 curl -v http://127.0.0.1:8000/health
- proxy_pass 地址是否写错？IP、端口、socket 路径是否与后端监听一致？
- 防火墙是否放行？ufw status 或 iptables -L -n | grep :8000
- 后端自身是否扛不住？PHP-FPM 的 pm.max_children 是否打满？Tomcat 的 maxThreads 是否排队超时？
只有当这些都排除，且 error.log 明确指向连接资源不足时，才聚焦 worker_connections 及其依赖项。
