worker_processes是Nginx配置文件nginx.conf中靠前的几行配置之一，很多人安装完Nginx后从来没有动过它，一直使用默认值1在跑线上服务。也有一部分人听说了经验之谈，直接把它改成CPU核数的两倍甚至四倍，结果性能不升反降。要搞清楚这个参数到底该设多少，需要先理解Nginx的多进程架构以及worker进程在请求处理中扮演的角色，本文就从原理到实践完整讲一遍。
Nginx多进程架构与worker进程的作用
Nginx启动后会先创建一个master进程，由master进程读取并验证配置文件，然后fork出若干个worker进程。master进程本身不处理任何客户端请求，它的职责是管理worker进程的生命周期，包括根据配置创建、监控、回收worker，以及在收到reload信号时平滑地让旧worker处理完现有连接后退出。真正干活的是worker进程，每个worker都是独立的进程，彼此之间完全对等，都可以独立接受新连接、处理请求、返回响应。
这种多进程模型带来的最大好处是稳定性：某个worker进程崩溃或被阻塞，不会影响其他worker继续服务，master进程检测到异常后会立刻重新fork一个新的worker补上。同时每个worker都是单线程且基于epoll的事件驱动模型，一个worker就能同时维持成千上万的连接，这也是Nginx高并发的根基。理解了这一点就能明白，worker进程的数量本质上决定了Nginx并行利用CPU的能力，因为单个worker在同一时刻只能跑在一个CPU核心上。
所以worker_processes的设置逻辑其实非常清晰：让每个CPU核心在同一时刻都有一个worker在干活，不多也不少。设少了，多核CPU的部分核心闲置；设多了，多个worker挤在少数核心上，操作系统频繁进行上下文切换，白白消耗CPU时间片，性能反而下降。
不同场景下的最优配置方案
最通用的做法是使用auto，让Nginx自动检测CPU核心数并按此数量启动worker进程，这是官方文档推荐的方式，适用于绝大多数物理机和虚拟机环境。
# nginx.conf 核心配置
worker_processes auto;
# 如果auto检测结果不准，可以手动指定
# 例如4核8线程的服务器可以尝试设为 4 或 8
# worker_processes 8;
events {
# 每个worker能同时处理的最大连接数
worker_connections 10240;
# （新版本已默认开启）允许一个worker接受所有新连接
multi_accept on;
}需要注意auto检测的是逻辑核心数，也就是包含了超线程。一块8核16线程的CPU，auto会启动16个worker。超线程的两个逻辑核心共享一个物理核心的执行单元，所以16个worker的实际吞吐未必比8个worker高。如果追求极致性能，建议在自己的服务器上分别用8和16压测对比，取表现更好的那个。对一般业务来说，两者差距通常在百分之几以内，直接用auto即可。
再来看几个特殊场景。第一类是CPU密集型服务，比如开启了gzip压缩、大量SSL握手、动态代理转发大流量，这类负载CPU消耗大，worker数严格等于物理核心数往往最优，甚至可以把超线程关掉来获得更稳定的延迟。第二类是磁盘IO密集型，比如纯静态文件下载站，worker经常阻塞在磁盘读写上，这时适当超过核心数（比如核心数的1.5倍）反而能提升吞吐，因为一部分worker等磁盘时，其余worker还能继续利用CPU。第三类是容器环境，这是重灾区：容器内执行nproc看到的可能是宿主机的核心数，而容器实际被cgroup限制了CPU配额，比如限制为2核却启动了32个worker，进程互相争抢极其严重。正确的做法是根据cgroup的CPU限额手动指定worker数，例如配额是2个CPU就设为2。
与worker数配套的关联参数
worker_processes只决定了进程数量，真正的并发能力还取决于worker_connections，两者的乘积才是理论最大并发连接数。例如4个worker乘以每个10240连接，理论上可同时维持40960个连接。worker_connections的取值受操作系统文件描述符限制约束，需要同时调整nginx.conf中的worker_rlimit_nofile以及系统的ulimit，否则Nginx会在error日志里报too many open files错误。
# nginx.conf
worker_rlimit_nofile 65535;
events {
worker_connections 10240;
}
# 系统层面调整（编辑 /etc/security/limits.conf）
# * soft nofile 65535
# * hard nofile 65535
# 再调整内核级限制
# sysctl -w fs.file-max=2097151另一个重要的配套参数是worker_cpu_affinity，它可以把worker进程绑定到指定的CPU核心上，减少缓存失效和线程迁移带来的开销。对于4核机器绑定4个worker的写法如下：
# 4个worker分别绑定到cpu0到cpu3 worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; # 也可以使用auto让Nginx自动绑定 worker_cpu_affinity auto;
绑定不是万能药，在核心利用率不均匀的业务里，手动绑定可能让某个核心过载而其他核心空闲，现代调度器本身已经做得不错，一般场景使用auto即可，只有在对延迟极度敏感的服务上才值得精细手工调优。
最后还有worker_priority，可以设置worker进程的调度优先级，默认是0，取值范围从-20到20，数字越小优先级越高。当Nginx与数据库等其他服务混布在同一台机器上时，可以适当给Nginx设置一个稍低的优先级，避免它抢占关键业务的CPU资源。
如何验证当前配置是否合理
改完配置不要急着上线，先用nginx -t检查语法，然后通过nginx -s reload平滑加载，再用ps命令确认worker数量是否与预期一致：
# 检查配置语法 nginx -t # 平滑重载配置 nginx -s reload # 查看master和worker进程 ps -ef | grep nginx
性能层面，推荐使用wrk或ab做压测，逐步增加并发数，观察Nginx服务器的CPU利用率和请求延迟。判断标准很简单：压测到目标并发时，如果所有CPU核心利用率能均匀达到80%以上且延迟达标，说明worker数合理；如果部分核心跑满而其他核心几乎空闲，多半是绑核或进程数配置有问题；如果CPU整体跑满但吞吐上不去，就要考虑增大worker_connections或者优化业务逻辑，而不是继续加worker数。
日常运维中还要留意error日志，如果出现worker process exited on signal 11之类的段错误，或worker CPU占用长期不均，都值得回头审视进程数配置。总结起来，worker_processes的最优设置没有玄学：普通物理机用auto，容器里看cgroup配额手动指定，CPU密集型贴着物理核心数走，IO密集型可以适当超出，再配合压测数据微调，就能得到适合自己业务的最优值。
Nginxworker_processes进程数配置修改时间：2026-08-31 12:31:05