总并发容量由worker_processes×worker_connections乘积决定，但需同时满足ulimit -n、worker_rlimit_nofile及/proc/sys/fs/file-max三重限制，缺一不可；实际承载力还受业务类型（短连/长连/HTTPS）和运行时指标影响。
总并发容量不是某个参数单独决定的，而是 worker_processes × worker_connections 这个乘积给出的理论上限。但这个数字要真正生效，必须满足系统资源链路全通——缺一环，实际并发就上不去。
核心公式与前提条件
最大客户端并发连接数 = worker_processes × worker_connections
- 例如：4 个 worker 进程 × 每个支持 8192 连接 → 理论值为 32768
- 这个值只在以下三个条件同时满足时才可稳定达到：
- 每个 worker 进程的文件描述符限制（
ulimit -n） ≥ 该乘积 - Nginx 主配置中
worker_rlimit_nofile≥ 该乘积（建议设为相同值或略高） - 系统全局句柄上限（
/proc/sys/fs/file-max）≥ 该乘积 × 1.3～1.5（预留日志、SSL 缓存、TIME_WAIT 等开销）
- 每个 worker 进程的文件描述符限制（
按角色区分的实际可用值
HTTP 服务器和反向代理场景下，真实可用连接数会打折扣，因为连接资源要分给不同对象：
-
纯静态 HTTP 服务（如图片、JS、CSS）：
浏览器通常复用连接，且无后端交互，可接近理论值，即worker_processes × worker_connections -
反向代理服务（如转发请求到 Tomcat/PHP）：
每个客户端连接需额外占用一个上游连接（client ↔ Nginx ↔ upstream），还涉及 SSL 握手、缓存句柄等，推荐按worker_processes × worker_connections ÷ 2估算实际承载力；部分资料提 ÷4，是为极端保守预留（含长连接、HTTP/2 多路复用等叠加开销）
别只看配置，得看运行时表现
配置再合理，也要靠实时指标验证是否真能撑住：
- 启用
stub_status模块，访问/nginx_status查看Active connections；若长期 >90% 理论值，说明连接池吃紧 - 执行
ss -s | grep "tcp:"，关注inuse和orphans；大量 orphaned sockets 往往意味着连接异常中断或内核回收慢 - 检查
error.log是否频繁出现accept() failed (24: Too many open files)—— 这是 fd 耗尽的直接信号 - 观察
Waiting占比：若长期超 90%，说明大量空闲长连接挂起，重点查内存与 fd 是否充足，而非盲目调高worker_connections
配套必须做的系统级动作
只改 Nginx 配置不碰系统限制，等于没调：
- 临时提升：运行
ulimit -n 65536（仅当前会话） - 永久生效：在
/etc/security/limits.conf中添加* soft nofile 65536* hard nofile 65536 - 确保 Nginx 配置中
events块启用高效模型：use epoll;multi_accept on; - 若使用 Docker，启动容器时必须显式传参：
--ulimit nofile=65536:65536，否则宿主机设置无效
