Nginx并发能力由worker_processes与worker_connections共同决定：前者设为CPU物理核心数（或auto），后者按内存与文件描述符限制设为2048–10240，二者乘积即理论最大并发连接数，需同步调高系统ulimit并启用epoll、multi_accept等优化。
Worker Process 本身不直接“优化客户端连接数”，而是通过合理配置 worker_processes 和 worker_connections 这两个参数，共同决定 Nginx 能稳定支撑的客户端并发连接上限。关键不是单个进程处理多少连接，而是整个 Nginx 实例在资源约束下能高效、可靠地承载多少并发请求。
明确 worker_processes 的作用与取值逻辑
worker_processes 是 Nginx 启动的独立工作进程数量，每个进程是单线程、事件驱动的。它决定了并行处理能力的“宽度”：
- 设置为 auto 最稳妥：Nginx 自动读取 CPU 物理核心数，避免人为误判；
- 若服务器还运行数据库或 Java 应用等重负载服务，可适当减为物理核心数的 0.7–0.9 倍；
- 不建议设为逻辑核心数（如超线程总数）的 2 倍以上，否则上下文切换开销会抵消性能收益；
- 可通过
grep -c ^processor /proc/cpuinfo或nproc命令确认实际可用核心数。
worker_connections 决定单进程吞吐能力
该参数定义每个 worker 进程最多能同时管理的连接数（含客户端连接、上游连接、缓存文件句柄等），它和 worker_processes 共同构成总连接上限：
- 默认值（512 或 1024）通常偏低，生产环境建议设为 2048～10240，具体取决于内存和业务特性；
- 每连接约占用 10–20 KB 内存，若设为 10240 且有 8 个 worker，则仅连接结构体就需约 1.6 GB 内存；
- 必须同步提升系统级文件描述符限制（
ulimit -n），建议设为worker_processes × worker_connections × 1.5； - 在
events块中配置，例如：worker_connections 4096;
配套必须做的系统与配置协同
只调 Nginx 参数而不改系统限制，会导致 “too many open files” 错误，连接数根本无法生效：
- 临时生效：执行
ulimit -n 65536（当前会话）； - 永久生效：在
/etc/security/limits.conf中添加两行：
* soft nofile 65536
* hard nofile 65536 - 确保使用高效事件模型：
use epoll;（Linux 默认，但显式声明更稳妥）； - 启用
multi_accept on;，让单个 worker 尽可能一次接受多个新连接，减少惊群效应。
验证是否真正生效
配置修改后重启 Nginx，还需验证实际承载能力是否达到预期：
- 检查当前限制：
cat /proc/$(cat /run/nginx.pid)/limits | grep "Max open files"； - 启用 stub_status 模块，在 location 中配置
stub_status;，访问对应路径可看到活跃连接数； - 用
wrk -t8 -c4000 -d30s http://your-domain/压测，观察错误率与延迟是否突增——这是连接瓶颈的真实信号。
