worker_processes 是 nginx 中真正处理请求的独立进程，每个 worker 单线程、非阻塞，独享一个 epoll 实例，通过事件循环高效管理数千连接；其数量应匹配 cpu 核心数（如 8 核设为 8），避免过多导致调度开销，过少则无法充分利用多核资源。
worker_processes 不是填个数字就完事的，它和 epoll 这类多路复用机制深度耦合——配少了压不住并发，配多了反而因进程争抢和上下文切换拖慢整体响应。
明确 worker_processes 的角色定位
它不是“越多越好”的线程池，而是 Nginx 主从模型中真正干活的独立进程。Master 进程只管调度、加载配置、平滑重启；所有 HTTP 请求的接收、解析、转发、响应，全由 worker 进程完成。每个 worker 是单线程、非阻塞的，靠 epoll 高效监听成千上万个 socket 事件。
结合 CPU 核心数精准设置
Linux 下一个 worker 进程基本绑定一个 CPU 核心运行效率最高。过多进程会导致内核频繁调度，反而增加延迟。推荐做法：
- 查真实核心数：
nproc或lscpu | grep "^CPU(s):" - 生产环境直接写死，比如 8 核就写
worker_processes 8;，避免 auto 在容器或虚拟化环境中误判 - 若机器还跑其他 CPU 密集型服务（如 Java 应用），可预留 1~2 核，设为 6 或 7
- 不建议设为 1：单 worker 无法充分利用多核，且故障时无冗余
与 events 模块协同调优
worker_processes 必须和 events 块里的参数配合才能发挥多路复用优势：
-
use epoll;—— Linux 必选，比 select/poll 更高效，支持海量连接就绪通知 -
worker_connections 10240;—— 每个 worker 最大处理连接数，建议设为 8192～16384（需同步调高系统ulimit -n至 ≥65535） -
accept_mutex on;—— 默认开启，防止“惊群”，让多个 worker 有序争抢新连接，避免内核唤醒全部进程 - 搭配
multi_accept on;可让单次事件循环尽可能多地接受连接，提升吞吐
网关场景下的特殊考量
作为反向代理网关，Nginx 要同时维持客户端连接和上游连接（比如到后端服务），实际内存和文件描述符消耗翻倍。此时：
- 理论最大并发 =
worker_processes × worker_connections，但应按 70%～80% 留余量预估可用值 - 若上游服务响应慢，连接会长时间挂起，建议启用
proxy_timeout类参数主动释放资源 - 开启
reuseport（需 Nginx 1.9.1+ 且内核支持）可进一步分摊 accept 压力，尤其在高 QPS 场景下效果明显
