worker_processes 应设为CPU物理核心数，过多会因上下文切换降低吞吐；配合worker_cpu_affinity绑定核心可提升缓存命中率；反向代理中优先调优worker_connections和upstream keepalive而非增加进程数。

worker_processes 不是设得越多越好，关键要匹配 CPU 核心数和业务模型。反向代理场景下，它直接影响并发连接处理能力和上游连接复用效率。

按 CPU 核心数设置最稳妥

每个 worker 进程是单线程、事件驱动的，不依赖多线程锁竞争。所以通常设为 CPU 物理核心数（非超线程数）即可：

• 2 核服务器 → worker_processes 2
• 4 核服务器 → worker_processes 4
• 8 核服务器 → worker_processes 8

超过核心数反而可能因上下文切换增加开销，尤其在高并发反向代理中，表现为 CPU 利用率升高但吞吐未提升。

配合 worker_cpu_affinity 绑定 CPU 提升缓存命中率

启用 CPU 绑定可减少进程跨核调度带来的 L1/L2 缓存失效，对反向代理这种 I/O 密集型任务效果明显：

• 4 核机器配 worker_processes 4 时，加上：
  worker_cpu_affinity 0001 0010 0100 1000;
• 2 核机器配 worker_processes 2 时，加上：
  worker_cpu_affinity 01 10;

这样每个 worker 独占一个物理核心，响应延迟更稳定，压测时 P99 波动明显降低。

Nginx Hosting

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

下载

反向代理场景下慎用 auto 或过高值

虽然 worker_processes auto 看似省事，但在容器或虚拟机环境中常误读为“总逻辑 CPU 数”（含超线程），导致进程数翻倍。而反向代理本身不大量消耗 CPU 计算，过多进程反而争抢 epoll 句柄和共享内存区域，引发 accept() 饥饿或连接排队延迟。

若确实需要更高并发承载力，优先调优 worker_connections 和 upstream keepalive，而不是盲目加 worker 数。

结合 upstream 连接池做整体平衡

反向代理性能瓶颈常不在 Nginx 本体，而在与后端建立/维持连接的开销。此时单个 worker 的能力比数量更重要：

• 每个 worker 能维护的上游空闲连接数由 upstream keepalive N 控制
• 总可用上游连接 ≈ worker_processes × upstream keepalive
• 例如：4 个 worker + keepalive 32 = 最多 128 条复用连接，足够应对多数 API 网关场景

若后端响应快、连接复用率高，4 个 worker 往往比 8 个更高效；若后端延迟波动大，则需增大 proxy_read_timeout 并确保 keepalive_requests 足够支撑请求复用周期。