worker_connections 是单个 worker 进程的最大活跃连接数，真实并发能力由它与 worker_processes 共同决定，且须满足系统文件描述符、进程级上限和内核句柄三项硬性条件，否则配置无效。
worker_connections 不是单机并发总数，而是每个 worker 进程能同时处理的最大活跃连接数。真实并发能力由它和 worker_processes 共同决定，且必须落在系统资源允许的范围内，否则配置无效甚至启动失败。
worker_connections 的实际作用范围
它只在 events 块中生效，定义的是“单个 worker 进程”的连接上限，不是全局或全站总值。例如：
- 配置
worker_processes 4;和worker_connections 8192;→ 理论最大并发为 32768 - 但若启用了 proxy_pass，一个客户端连接可能对应一个上游连接，实际占用翻倍
- keepalive 连接也计入该统计——它限制的是“同时维持的连接数”，不是请求数
必须同步满足的三个硬性条件
仅调大 worker_connections 没用，以下三项缺一不可：
- 系统级文件描述符限制（ulimit -n）：必须 ≥ worker_processes × worker_connections，建议预留 10% 余量，例如目标 10 万连接，ulimit -n 至少设为 131072
- Nginx 进程级上限（worker_rlimit_nofile）：需显式配置，值应 ≥ worker_connections，推荐与 ulimit -n 一致或略高
-
内核全局句柄上限（fs.file-max）：通过
sysctl net.core.somaxconn和/proc/sys/fs/file-max调整，建议设为理论值的 1.2～1.5 倍
影响真实并发的隐藏瓶颈
即使上述都达标，仍可能卡在其他环节：
-
本地端口耗尽：反向代理时每个 upstream 连接占一个临时端口，默认范围仅约 32K，可扩至
1024 65000 -
监听队列溢出：
net.core.somaxconn过低（如默认 128）会导致新连接在内核层被丢弃，无错误日志，只表现为请求无响应 - 内存压力：每个空闲 keepalive 连接约占 128–256 KB，8GB 内存服务器实际支撑的长连接数可能远低于文件描述符理论值
验证是否真正生效的方法
不能只看配置，要结合运行态确认：
- 查 worker 进程实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 看实时连接数：
ss -s | grep tcp或启用 stub_status 后访问/nginx_status中的 Active connections - 盯 error.log：频繁出现
accept() failed (24: Too many open files)就是 fd 真实耗尽 - 压测观察：用 wrk 或 ab 发起流量，同时监控 CPU、内存、连接数变化趋势
