worker_processes auto 实际读取的是操作系统标记为“online”的逻辑cpu总数，即调用sysconf(_sc_nprocessors_onln)或执行nproc命令的结果，包含超线程核，不区分物理核、不感知numa、不识别cgroup限制。
worker_processes auto 不是智能调度，而是启动时一次性读取系统标记为“online”的逻辑 CPU 总数，并据此固定派生对应数量的 worker 进程。
它实际读的是什么？
nginx 启动时调用 sysconf(_SC_NPROCESSORS_ONLN)，等价于在当前环境执行 nproc 命令的结果。这个值代表操作系统当前标记为在线的逻辑 CPU 数量，特点是：
- 不区分物理核心与超线程（HT）产生的逻辑核
- 不感知 NUMA 节点分布
- 不主动识别 cgroup 限制（如 Docker 的
--cpus=2或 Kubernetes 的resources.limits.cpu） - 在容器中是否受限，取决于内核版本、cgroups 版本及 nginx 版本（≥1.19 才开始尝试从 cgroups 中读取）
为什么说它是探测，不是自适应？
auto 行为仅发生在 master 进程启动瞬间，且只执行一次。之后 worker 进程数量完全固定，不会随系统负载变化、CPU 热插拔或容器资源调整而动态更新。
配置位置和常见误区
这行指令必须写在 nginx.conf 的最外层（main 块），否则无效：
- ✅ 正确：
worker_processes auto; - ❌ 错误：
worker_processes_auto on;（语法不存在） - ❌ 错误：
worker_processes = auto;（语法非法） - ❌ 错误：把它写进
events或http块里（作用域错误）
什么时候不能直接信 auto？
在资源受限环境中，auto 可能给出误导性结果：
- 容器中只分配了 2 个 CPU，但宿主机有 32 核 →
nproc返回 32，nginx 启 32 个进程，造成严重争抢 - 混合部署场景（如 Nginx + MySQL 共存）→ 应预留部分核心，例如
worker_processes $(nproc --all)-2;（需在启动脚本中计算） - 追求物理核绑定效果 → 配合
worker_cpu_affinity auto;（Nginx ≥ 1.9.10），它会跳过超线程对称核，优先绑定真实物理核心
配套调优才真正生效
只设 auto 不够，必须协同以下配置才能让每个 worker “稳坐”一个 CPU 核心：
-
worker_cpu_affinity auto;（自动绑定，减少上下文切换） -
worker_rlimit_nofile与系统ulimit -n对齐（避免文件描述符瓶颈） -
worker_connections与worker_rlimit_nofile匹配（防止连接数超限）
不复杂但容易忽略。
