worker_connections 是单个 worker 进程的最大活跃连接数，非全站并发上限；实际并发受系统文件描述符限制、worker_processes 数量、keepalive 复用、upstream 连接开销等共同制约。
Nginx 中 worker_connections 并不直接等于整个 Nginx 的并发连接上限，它只是单个 worker 进程能处理的最大**活跃连接数**，最终并发能力还受多个因素共同制约。
worker_connections 的实际作用
该指令定义每个 worker 进程最多能同时处理多少个客户端连接（包括与上游服务器的连接）。例如：
events {
worker_connections 1024;
}
若启用了 4 个 worker 进程，则理论最大活跃连接数为 4 × 1024 = 4096。但这只是理想值，真实上限往往更低。
真正限制并发的几个关键因素
-
系统级文件描述符限制（ulimit -n）：每个 TCP 连接、每个打开的文件、每个 upstream 连接都会占用一个 fd。Nginx 启动前必须确保
ulimit -n≥worker_processes × worker_connections，否则启动失败或运行时报too many open files。 -
worker_processes 数量：默认为 1，通常建议设为 CPU 核心数（如
worker_processes auto;）。超过 CPU 核心数可能因上下文切换反而降低性能。 -
keepalive 连接复用行为：HTTP/1.1 默认启用 keepalive，一个客户端可复用连接发送多个请求。此时
worker_connections限制的是“同时保持的连接数”，而非请求数。高并发短连接场景更易打满该值。 -
upstream 连接开销：使用 proxy_pass 时，一个客户端连接可能对应一个后端连接（甚至多个，如负载均衡、重试），这些也计入
worker_connections总数。
如何查看和调优
- 检查当前限制：
cat /proc/$(pidof nginx)/limits | grep "Max open files" - 临时提升（仅当前会话）：
ulimit -n 65536；永久生效需修改/etc/security/limits.conf和 systemd 服务配置（如LimitNOFILE=65536）。 - 验证配置是否生效：
nginx -t后重启，并观察 error.log 是否有 fd 相关错误。 - 监控实际连接数：
ss -s | grep "tcp:"或 Nginx stub_status 模块输出中的Active connections。
一个典型配置示例
在 8 核服务器上支持约 32K 并发连接：
worker_processes auto;
events {
worker_connections 4096;
use epoll; # Linux 推荐
multi_accept on; # 尽快接受所有待处理连接
}
同时确保系统 ulimit ≥ 8 × 4096 = 32768，且内核参数如 net.core.somaxconn 和 net.ipv4.ip_local_port_range 也匹配高并发需求。
