worker_processes 应设为 CPU 物理核心数或 auto，避免超配引发上下文切换、惊群效应和内存浪费；容器化等特殊场景需手动匹配实际可用 vCPU，并配合 worker_cpu_affinity、worker_rlimit_nofile 等参数协同调优。
worker_processes 是 Nginx 主进程启动时 fork 出的工作进程数量，它不决定“能处理多少连接”，而是决定“由几个独立进程来争抢并处理连接”。配置不对，轻则浪费资源，重则引发上下文切换、惊群效应和缓存失效。
worker_processes 的合法取值与含义
该指令只能出现在 main 块（即配置文件最外层），支持以下写法：
- auto：Nginx 自动读取系统可见的 CPU 物理核心数（推荐生产环境首选）
-
数字：如
worker_processes 4;，固定启动指定数量进程 - off：仅 Windows 支持，Linux/Unix 下无效
为什么通常等于物理核心数？
Nginx Worker 是事件驱动、非阻塞模型，单个进程已能高效支撑上万并发。多进程的价值在于并行利用 CPU，而非“分摊压力”。超核设置反而带来三类开销：
- CPU 时间片频繁切换，消耗有效计算资源
- 多个 Worker 同时被内核唤醒争抢新连接（惊群效应），虽有
accept_mutex缓解，但未根除 - 每个 Worker 加载完整配置、缓存结构、连接表等，内存占用线性增长
特殊场景下的适配逻辑
不能只看宿主机核数，而要看 Nginx 实际可用的计算资源：
-
容器环境：Docker/K8s 中若限制
--cpus=2或resources.limits.cpu: "1.5"，应显式设为对应整数值（如worker_processes 2;），避免 auto 误读宿主机 64 核 -
混部服务器：Nginx 与数据库共用机器时，可预留 1～2 核，用脚本动态计算：
worker_processes $(nproc --all)-2; -
高延迟上游：反向代理后端响应慢（如老旧 HTTP API），可小幅上调（如 ×1.2），但优先优化
proxy_read_timeout和重试策略
必须同步检查的配套参数
worker_processes 不是孤立存在，需与以下三项联动调优：
-
worker_rlimit_nofile：设为大于
worker_connections的值（如 65535），否则 worker 进程打不开足够文件描述符 - events { worker_connections }：单进程最大连接数，总并发能力 = 进程数 × 此值
-
系统 ulimit -n：Linux 级别限制，需在
/etc/security/limits.conf中提升，且确保 systemd 服务单元中未覆盖
