Nginx 的 worker_processes auto 通过调用 sysconf(_SC_NPROCESSORS_ONLN)（等价于 nproc）获取系统可见逻辑 CPU 数启动 worker 进程，不识别 cgroup 限制，故容器中易失准，需结合验证与显式配置确保生效。

直接在 Nginx 主配置文件（通常是 /etc/nginx/nginx.conf）的最外层（即 main 块）写入 worker_processes auto; 即可。Nginx 启动时会自动读取系统报告的在线逻辑 CPU 数，并以此数量启动 worker 进程，无需手动计算或硬编码。

它怎么自动获取核心数？

Nginx 调用系统接口 sysconf(_SC_NPROCESSORS_ONLN)，等价于执行 nproc 命令的结果。这个值反映的是操作系统当前“可见”的逻辑 CPU 个数，比如：

• 一台物理机为 4 核 8 线程 → 返回 8
• Docker 容器限制为 2 核，但宿主机有 32 核 → 仍返回 32（不识别 cgroup 限制）
• OpenVZ 等旧虚拟化环境可能始终返回 1 → 上线前务必验证

为什么推荐用 auto 而不是固定数字？

硬编码如 worker_processes 4; 在多环境部署中容易失效：

• 开发机 2 核、测试机 4 核、生产机 32 核 → 配置需反复修改
• Kubernetes 中调整了 resources.limits.cpu → worker 数未同步，导致资源争抢或浪费
• 云服务器升级规格后忘记改配置 → 无法利用新增核心

auto 让 Nginx 启动时自适应运行时环境，减少人工干预和配置漂移风险。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

容器或资源受限场景要注意什么？

auto 在容器中容易失准，需额外处理：

• 显式指定更稳妥：例如容器限制为 2 核，就写 worker_processes 2;
• 若坚持用 auto，建议搭配 worker_cpu_affinity auto;（Nginx ≥ 1.12.0），减少跨核调度开销
• 混合部署（如 Nginx + Java 共存）可预留核心：通过启动脚本动态计算，如 worker_processes $(nproc --all | awk '{print $1-2}');

怎么确认配置真的生效了？

别只看配置文件，要验证运行态：

• 查错误日志：tail -f /var/log/nginx/error.log，启动时会打印 using X processes
• 看实际进程数：ps -C nginx --no-headers | wc -l（结果应等于配置值，含 master 进程）
• 检查加载配置：nginx -T 2>/dev/null | grep 'worker_processes'