nginx最大理论并发连接数=worker_processes×worker_connections，代表所有worker进程能同时维持的活跃tcp连接总数，但受ulimit -n、fs.file-max及内存网络资源三重约束，非实际稳定承载值。
直接用 worker_processes × worker_connections 就是 Nginx 的最大理论并发连接数。这个数字代表所有 worker 进程能同时维持的活跃 TCP 连接总数，包括客户端连接、上游代理连接、keepalive 连接等。
怎么算出具体数值
分两步看配置：
-
查 worker_processes：在 nginx.conf 的主上下文里找，常见值有
auto（自动识别 CPU 核心数）、或显式数字如4、8。可通过nproc或cat /proc/cpuinfo | grep processor | wc -l确认实际核心数。 -
查 worker_connections：在
events { ... }块内，例如worker_connections 4096;。注意它不是全局值，而是每个 worker 进程的上限。
相乘即得：比如 worker_processes 8; + worker_connections 16384; → 理论并发 = 8 × 16384 = 131072。
这个数为什么只是“理论值”
它不等于实际能稳定承载的并发量，因为受三重硬性约束：
-
单进程文件描述符限制：由
ulimit -n控制，必须 ≥worker_connections。否则启动时会报错或运行中触发 “too many open files”。 -
系统级文件描述符上限：由
/proc/sys/fs/file-max决定，必须 ≥worker_processes × worker_connections × 1.2～1.5，预留空间给日志、缓存、TIME_WAIT 连接等。 - 内存与网络资源：每个连接约占用几 KB 内存，高并发下需评估可用内存；短连接场景还受限于端口耗尽（65535 个本地端口）和 TIME_WAIT 回收速度。
反向代理场景要打折吗
官方文档和实践中都不建议机械套用 “除以 4” 这类经验公式。真实瓶颈取决于业务模型：
- 如果后端服务响应快、复用率高，一个 client 连接可能对应多个 upstream 连接，但平均仍可接近理论值；
- 如果后端延迟高、连接池小，可能出现连接堆积，此时并发能力会下降，但这属于后端或负载均衡策略问题，不是 Nginx 本身的计算逻辑变了。
所以评估起点始终是 worker_processes × worker_connections，再结合监控（如 ngx_http_stub_status_module 输出的 Active connections）和压测结果校准实际水位。
快速验证当前配置是否生效
执行以下命令确认运行时参数：
-
nginx -t && nginx -V 2>&1 | grep -i "process\|connection"（检查配置语法和编译参数） -
ps aux | grep nginx | grep -v master（确认 worker 进程数） -
ss -s | grep -i "tcp:"或cat /proc/$(pgrep nginx)/limits | grep "Max open files"（核对单进程 fd 限制）
