worker_processes 应设为物理核心数而非逻辑核数，需配合cpu绑定和系统级文件描述符调优；超线程对nginx收益有限，auto仅在识别numa且避开超线程时可靠，容器等特殊场景须人工校准。

worker_processes 不是“开越多越好”，而是要让每个 worker 稳定运行在独立物理核心上，减少调度干扰和缓存抖动。连接性能提升的关键，不在于堆数量，而在于进程与硬件资源的精准匹配。

按物理核心数设置，别信逻辑核或 auto 的默认表现

超线程（如 32 物理核 + 64 逻辑 CPU）对 Nginx 这类 I/O 密集型服务收益有限，反而加剧 L1/L2 缓存争用和 TLB 刷新。盲目设为 64 容易引发上下文切换、惊群效应和内存浪费。

• 查清真实物理核心总数：用 nproc --all 或 lscpu | grep "Core(s) per socket"，再乘以 socket 数
• 推荐值：32 物理核 → worker_processes 32；双路服务器需结合 NUMA 节点分布（如每节点 16 核，则分设两组）
• auto 是便捷选项（Nginx 1.9.10+ 支持），但仅当确认它能识别 NUMA 且避开超线程对时才真正可靠

必须绑定 CPU，否则调优等于没做

只设对进程数不够，不绑定就无法让 SSL 缓存、共享内存锁、文件元数据等热点数据长期驻留本地缓存，跨核访问延迟会明显升高。

Nginx Hosting

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

下载

• 通用写法：worker_cpu_affinity auto;（自动错开超线程对，优先分配物理核）
• 精细控制示例（8 核）：worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
• 禁止多个 worker 绑定同一物理核——否则绑定失效，还可能引发锁竞争

连接能力要同步放开，否则 worker 再多也跑不满

worker_processes × worker_connections 决定理论并发上限，但实际受系统级限制制约。常见瓶颈是 “too many open files” 报错或静默降级。

• 单 worker 连接数建议：2048～4096（静态资源可略高；动态接口建议保守些）
• 系统级 ulimit -n 至少 ≥ worker_processes × worker_connections，并预留 20% 给日志、上游连接等
• Nginx 配置中加：worker_rlimit_nofile 65535;，并在 /etc/security/limits.conf 为 nginx 用户设硬限制

特殊场景需手动干预，auto 不万能

容器化、混合负载或高延迟上游等场景下，auto 会误读宿主机核数或忽略资源隔离，必须人工校准。

• 容器内限 2 核？显式写 worker_processes 2;，避免 auto 读到宿主机 64 核
• 与数据库共存？预留 1～2 核，设为 worker_processes $(nproc --all)-2;
• 后端响应慢（如 API 平均 800ms）？可适度上浮至物理核数 ×1.2～1.5，但优先优化 upstream timeout 和重试策略