Nginx 中怎么结合 worker_processes 与 worker_connections 计算总并发容量-Nginx-PHP中文网

总并发容量由worker_processes×worker_connections乘积决定，但需同时满足ulimit -n、worker_rlimit_nofile及/proc/sys/fs/file-max三重限制，缺一不可；实际承载力还受业务类型（短连/长连/https）和运行时指标影响。

nginx 中怎么结合 worker_processes 与 worker_connections 计算总并发容量

总并发容量不是某个参数单独决定的，而是 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 等开销）

HTTP 服务器和反向代理场景下，真实可用连接数会打折扣，因为连接资源要分给不同对象：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

纯静态 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，否则宿主机设置无效