生产环境 worker_processes 需按硬件与部署形态校准：裸金属用 auto；容器需显式设为 CPU 限制核数；高吞吐场景全开核心并启用 CPU 亲和性，同时必须配置 ulimit、worker_rlimit_nofile 及分阶段压测验证。

生产环境的 worker_processes 不是填个数字就完事，它必须和 CPU 物理核心数、系统资源限制、容器运行环境以及业务类型联动校准。设错会直接引发上下文切换风暴、CPU 利用率失衡或连接被静默拒绝。

匹配硬件与部署形态的配置起点

裸金属或独占 CPU 的虚拟机：用 worker_processes auto; 是稳妥选择，Nginx 会自动识别物理核心数（非超线程逻辑核），避免调度干扰。

容器环境（Docker/K8s）：禁用 auto，显式设为 2 或 4。需根据 resources.limits.cpu 反推——例如限制为 2 核，就配 worker_processes 2;；若设为 64，却只分到 2 核，所有 worker 争抢调度，反而拖垮性能。

高吞吐 API 网关类场景：可设为物理核心数全开（如 16 核 → worker_processes 16;），但必须同步启用 CPU 亲和性，否则无效。

Nginx Hosting

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

下载

必须同步落地的系统级配套

worker_processes 单独调高毫无意义，以下三项不落实，压测必失败：

• 执行 ulimit -n 确认输出 ≥ worker_processes × worker_connections（例如 8×4096=32768），否则连接直接被 accept() failed (24: Too many open files) 拒绝
• 在 /etc/security/limits.conf 中固化：
  nginx soft nofile 65535
nginx hard nofile 65535
• 全局块中声明 worker_rlimit_nofile 65535; —— 若漏掉这行，Nginx 启动不报错，但高并发下自动降级为默认 1024

分阶段压测验证最优值

跳过基线直接压满，看不出拐点。按三步走：

• 基线测试：设 worker_processes 1，用 wrk -c 500 -t 4 http://host/ 压测，记录 QPS、p99 延迟、错误率作为基准
• 线性扩展：依次设为 2、4、8（对应物理核心），保持 worker_connections 4096 不变，压测相同并发量。若从 4→8 时 QPS 提升＜5%，而 sys CPU 上升＞25%，说明已过收益拐点
• 饱和观察：固定 worker_processes = CPU 核心数，逐步提升并发至 5k→10k，重点看 htop 中各核心负载方差是否缩小、p99 是否下降——若启用 worker_cpu_affinity auto; 后方差收窄且延迟下降，即确认亲和生效

关键避坑与验证手段

常见翻车点不在配置写法，而在验证缺失：

• 容器里配了 worker_cpu_affinity auto; 却没做 CPU pinning？用 ps -eo pid,psr,args | grep nginx 查看各 worker PID 分布的 PSR 编号，不均匀即未生效
• 用了 nginx:alpine 镜像？默认无 numactl，worker_cpu_affinity 静默失效，应换 nginx:slim 或自编译
• 压测中出现 nginx: [alert] 1024 worker_connections are not enough？不是加进程数，而是先查 ulimit -n 和 worker_rlimit_nofile 是否到位

最终推荐组合（2026 年主流 16 核服务器实测收敛）：
worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 65535;