worker_processes auto 通过 sysconf(_SC_NPROCESSORS_ONLN) 获取系统在线逻辑 CPU 数作为进程数，不考虑超线程、容器限制或 CPU 隔离；适合开发或轻量通用场景，生产环境需据负载、硬件与共存服务手动调优。
Nginx 的 worker_processes 决定启动多少个工作进程，直接影响并发处理能力和资源利用率。它既可设为固定数值，也能启用自动探测——但“自动”不等于“最优”，需结合实际场景权衡。
自动探测机制（auto）怎么工作？
当配置为 worker_processes auto; 时，Nginx 在启动时调用 sysconf(_SC_NPROCESSORS_ONLN)（Linux/Unix 系统）获取当前在线 CPU 核心数，并以此作为 worker 进程数量。它不考虑超线程、CPU 绑定、容器限制或负载类型，仅读取内核报告的逻辑 CPU 数量。
- 在 4 核 8 线程的机器上，通常返回 8；
- 在 Docker 容器中未限制 CPU 时，仍可能读到宿主机核心数；
- 若系统启用了 CPU 隔离（如
isolcpus），该值不会自动排除被隔离的核心。
什么情况下适合用 auto？
auto 是开发环境或通用部署的快捷起点，适合以下情况：
- 单机部署、无特殊性能调优需求；
- CPU 资源充足，且 Nginx 主要处理轻量 HTTP 请求（如静态文件、反向代理）；
- 运行在虚拟机或容器中，但已通过 cgroups/vCPU 明确限制了可用核心数（部分新版内核和容器运行时能正确暴露该信息）。
为什么手动配置更常见于生产环境？
真实业务中，worker 进程数需匹配硬件特性、工作负载模型和系统其他服务，盲目跟随 CPU 核心数反而可能引发争抢或浪费：
- 高 IO 场景（如大量磁盘读写、SSL 卸载）：过多 worker 会加剧上下文切换，建议设为 CPU 物理核心数（而非逻辑核心）；
- 多实例共存：若同一台机器还运行数据库、Java 应用等，应预留资源，worker_processes 可设为总核心数的 50%~75%；
-
CPU 绑定需求：配合
worker_cpu_affinity使用时，手动指定数量便于精确控制每个 worker 绑定到哪个核心； - 内存受限：每个 worker 进程会加载配置、缓存、连接结构体等，worker 数过多会显著增加内存占用（尤其开启大量 SSL 或 proxy_buffering 时）。
推荐配置策略
没有万能公式，但可按步骤判断：
- 先查真实可用 CPU：
nproc（容器内）、lscpu | grep "^CPU(s):"（物理机）、或cat /sys/fs/cgroup/cpuset/cpuset.cpus（cgroups v1）； - 观察典型负载下的
top或htop：看 CPU 是否持续饱和、是否存在明显等待（%wa）或调度延迟（vmstat 1中的cs列）； - 压测验证：用
wrk或ab对比不同 worker 数下的 QPS、延迟和系统负载，重点关注load average与idle%平衡点； - 保守起步：从
worker_processes 2;或物理核心数开始，再逐步调整，避免一上来就设成auto后忽略后续优化。
