nginx最大理论并发连接数=worker_processes×worker_connections，代表所有worker进程能同时维持的活跃tcp连接总数，但受ulimit -n、fs.file-max及内存网络资源三重约束。
直接用 worker_processes × worker_connections 就是 Nginx 的最大理论并发连接数。这个乘积不是“配比”，而是能力上限的线性叠加结果——它告诉你这台机器在理想条件下最多能维持多少个活跃 TCP 连接（含客户端、上游、keepalive 等）。
先确认两个参数的实际取值
· worker_processes：查 nginx.conf 主上下文，常见为 auto（自动匹配 CPU 核心数）、或显式数字如 4、8。
可通过 nproc 或 grep -c processor /proc/cpuinfo 验证物理核心数。
· worker_connections：在 events { } 块内，例如 worker_connections 4096;。注意它是每个 worker 进程的上限，不是全局值。
· 相乘即得理论值：比如 worker_processes 8; + worker_connections 16384; → 8 × 16384 = 131072。
但不能只看乘积，必须同步满足三层限制
这个数字要真正生效，需同时满足：
-
单进程限制：每个 worker 进程的
ulimit -n必须 ≥worker_connections；否则启动报错或静默降级 -
Nginx 自身限制：主配置中应设
worker_rlimit_nofile≥ 该乘积（推荐设为相同值或略高） -
系统级限制：内核参数
/proc/sys/fs/file-max应 ≥ 该乘积 × 1.2～1.5（预留日志、TIME_WAIT、缓存等开销）
实际配置时的协同逻辑
不是“先定一个再配另一个”，而是按目标反推：
- 若目标是稳定支撑 10 万并发：8 核机器可设
worker_processes 8;+worker_connections 12500;（8×12500=100000） - 接着必须设
worker_rlimit_nofile 131072;，并确保系统ulimit -n≥ 131072，fs.file-max≥ 15 万 - 反向代理场景下还要考虑端口耗尽：每个 upstream 连接占一个本地端口，需调大
net.ipv4.ip_local_port_range
别被“乘积”误导内存和性能
这个乘积不等于内存占用，也不代表真实吞吐能力：
- 内存主要来自 worker 进程基础开销（约 12MB/个）+ 活跃连接缓冲区（8–64KB/连接，按需分配）
- 性能还受 CPU 类型影响：IO 密集型业务（如静态文件）适合 worker 数 ≈ 核心数；高延迟后端则可略超核心数
- 超过核心数太多（如 8 核配 16 个 worker）会引发频繁上下文切换，反而降低效率
