nginx的worker_connections必须与系统资源协同调整才能提升并发能力，单独调大无效；实际并发上限受worker_processes×worker_connections、ulimit -n和net.core.somaxconn三者最小值约束，需按确认瓶颈、修改events块、放宽系统限制、配平worker_processes四步实操。
Nginx 的 worker_connections 本身不是独立可“扩展”的参数，它必须和系统资源、进程配置协同调整才能真正提升并发连接能力。单纯改大这个数字没用，系统不放行，Nginx 会静默降级或报错。
关键逻辑是：实际并发上限 = worker_processes × worker_connections，但最终受三者最小值约束——
→ Nginx 配置值
→ 系统单进程文件描述符限制（ulimit -n）
→ 内核连接队列深度（如 net.core.somaxconn）
下面分四步实操：
确认当前瓶颈在哪
先看错误日志有没有 accept() failed (24: Too many open files) 或 worker_connections are not enough；
再查真实限制：
-
nginx -V 2>&1 | grep -o 'worker_connections.*'（编译默认值，仅参考） -
grep worker_connections /etc/nginx/nginx.conf（当前配置） -
ulimit -n（当前会话限制） -
sysctl net.core.somaxconn（内核监听队列上限） -
ss -s | grep "total:"（当前活跃 socket 总数）
调大 worker_connections 并匹配 events 块
该指令只能写在 events { ... } 块里，不能放在 http 或 server 中：
events {
use epoll; # Linux 必加，提升 I/O 效率
worker_connections 8192; # 常见合理值，非越大越好
}
数值建议按内存反推：每个连接约占 2–4 KB，8 GB 内存服务器不建议单 worker 超过 16384。
同步放宽系统级文件描述符限制
否则 Nginx 启动时会截断到 ulimit -n 值，且可能连 error.log 都打不开：
- 临时生效（当前终端）：
ulimit -n 65536 - 永久生效（推荐）：
编辑/etc/security/limits.conf，追加：nginx soft nofile 65536 nginx hard nofile 65536
若 Nginx 用 systemd 管理，还需创建
/etc/systemd/system/nginx.service.d/override.conf：[Service] LimitNOFILE=65536
然后执行：
systemctl daemon-reload && systemctl restart nginx
配平 worker_processes 并验证效果
-
worker_processes auto;通常够用（自动匹配 CPU 核心数）； - 若业务有长阻塞（如慢 SQL、无超时上游），可略高于核心数（如 8 核配 10 个 worker），但不宜翻倍；
- 修改后务必：
nginx -t（语法检查）→nginx -s reload（热重载）→ps aux | grep nginx（确认 worker 进程数）→lsof -p $(cat /var/run/nginx.pid) | wc -l（观察 fd 实际占用）
压测时盯住 /var/log/nginx/error.log 和 ss -s 输出，确认不再出现文件描述符不足或连接拒绝。
