worker_connections 仅表示单个 worker 进程的连接上限，实际并发能力取决于 worker_processes × worker_connections 的乘积，并受 ulimit -n、worker_rlimit_nofile 和 net.core.somaxconn 三者最小值制约，必须置于 events 块内且需配套调优。
worker_connections 本身不直接决定并发性能，它只是单个 worker 进程能同时管理的连接上限。真正影响并发能力的是它与 worker_processes 的乘积，再叠加系统资源的实际约束——调高这个值若不配套调整，几乎不会带来任何提升。
它只管“每个进程能撑多少连接”
worker_connections 必须写在 events 块里，比如：
events {
worker_connections 4096;
use epoll;
}
它不是全局总连接数，也不是 QPS 或请求数。一个 keepalive 连接可服务多个请求，但只要还活着，就算占一个 connection 槽位。反向代理场景下更复杂：一个客户端请求通常要同时维持客户端连接 + upstream 连接，实际占用翻倍甚至更多。
并发能力由三者共同卡死
理论最大连接数 = worker_processes × worker_connections，但这只是纸面数字。真实可用值永远受限于以下三项中的最小值：
- 系统级文件描述符限制（ulimit -n）：必须 ≥ 该乘积，并建议预留 10%～20% 余量
- Nginx 进程级上限（worker_rlimit_nofile）：需显式配置，且不能小于 worker_connections
- 内核连接队列深度（net.core.somaxconn）：应 ≥ worker_connections ÷ worker_processes，否则新连接会在内核层被丢弃
常见配置组合与避坑点
4 核服务器典型配置：
- worker_processes 4
- worker_connections 2500 → 理论 1 万连接
- worker_rlimit_nofile 16384（≥ 1.2 × 10000）
- /etc/security/limits.conf 中设 nginx 用户 soft/hard nofile 16384
- sysctl 设置 net.core.somaxconn = 16384
容易忽略的问题：
- worker_connections 写在 http 或 server 块里 → Nginx 启动失败
- 设了 65535，但 ulimit -n 还是 1024 → 实际生效值就是 1024，且 error.log 里可能只报 “accept() failed (24: Too many open files)”
- 没开 use epoll 或 multi_accept on → I/O 效率大幅下降，尤其在 Linux 下
验证是否真生效，别只看配置
运行后检查三项：
- cat /proc/$(pgrep nginx)/limits | grep "Max open files" → 看 worker 进程实际 fd 上限
- ss -s | grep tcp → 查当前 TCP 连接总数
- 启用 stub_status 后访问 /nginx_status → 看 Active connections 实时值
压测时同步观察 CPU、内存和 error.log，才能确认瓶颈到底在哪。
