理论最大并发数=worker_processes×worker_connections，但实际受ulimit -n、worker_rlimit_nofile、/proc/sys/fs/file-max三重限制；反向代理时需除以2～4；内存与CPU才是最终瓶颈。
这个公式只给出理论上限，不能直接当作实际可用并发数来用。
必须满足三重系统限制
理论值 = worker_processes × worker_connections，但只有在以下三个条件同时满足时才可能跑满：
- 系统级文件描述符上限（
ulimit -n）≥ 该理论值 - Nginx 自身限制
worker_rlimit_nofile≥ 该理论值 - 内核全局句柄上限
/proc/sys/fs/file-max≥ 该理论值
反向代理场景要打对折
当 Nginx 做反向代理时，每个客户端请求会占用两个连接：一个连客户端，一个连后端服务。所以真实对外并发能力 ≈ worker_processes × worker_connections ÷ 2。
如果后端响应慢、连接复用率低，或启用了长连接保活，这个比值可能更低。
内存和 CPU 才是最终瓶颈
每条连接平均消耗几 KB 到几十 KB 内存。4 核 8G 机器设成 65535 连接，光连接状态就可能吃掉 1~2GB 内存，还没算 SSL、缓存、日志等开销。
CPU 方面，HTTPS 握手、正则 rewrite、gzip 压缩都会快速拉高负载。QPS 极限往往远低于连接数极限——比如 4 万并发连接，实际稳定 QPS 可能只有 1~2 万。
业务类型决定怎么算
不同场景下，“并发连接”的含义差异很大：
- WebSocket / 长轮询：重点看连接保活能力，内存和 FD 是主因
- HTTP API 网关：更关注 QPS 和平均响应时间，CPU 和后端延迟是关键
- 静态资源服务：磁盘 IO 和带宽容易先打满，连接数反而不是瓶颈
