nginx性能优化需匹配硬件、内核与业务，worker_processes设为物理核心数（auto最佳），worker_connections需满足ulimit限制，理论并发=进程数×连接数，keepalive_timeout建议60–75秒并配合keepalive_requests防资源滞留。

Linux 下 Nginx 性能优化不是靠堆参数，而是靠理解每个参数背后的资源约束与系统协同逻辑。关键在于匹配硬件能力、内核限制和业务特征，而非盲目调高数值。下面按层级说明核心参数的计算依据与合理取值标准。

worker_processes 与 CPU 资源匹配

该参数决定 Nginx 启动多少个 worker 进程，直接影响并发处理能力和 CPU 利用效率。

• 理论取值：通常设为物理 CPU 核心数（非超线程数），高 I/O 密集型场景可设为 cpu_cores × 1~2
• 推荐写法：worker_processes auto; —— Nginx 自动识别物理核心数，避免人工误判
• 注意点：超过物理核心数后，进程上下文切换开销可能抵消并发收益；若启用了 worker_cpu_affinity，必须确保掩码位数与进程数一致

worker_connections 与文件描述符上限联动

单个 worker 进程能同时处理的最大连接数，其实际生效受系统级文件描述符限制制约。

Nginx Hosting

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

下载

• 计算公式：系统 ulimit -n ≥ worker_processes × worker_connections × 2（×2 是因每个连接至少占用 1 个 socket 描述符 + 1 个文件句柄，如静态文件）
• 常见取值：65535 或 16384（取决于系统配置能力），不建议直接写 65535 若未同步提升系统限制
• 配套操作：
  • 在 /etc/security/limits.conf 中设置：* soft nofile 100000 和 * hard nofile 100000
  • 在 nginx.conf 全局块中加：worker_rlimit_nofile 100000;
  • 验证命令：cat /proc/$(pgrep nginx)/limits | grep "Max open files"

总并发能力估算与瓶颈识别

Nginx 理论最大并发连接数由两个参数共同决定，但真实承载能力还受限于内存、网络栈和后端服务响应速度。

• 理论并发上限：worker_processes × worker_connections
• 内存消耗参考：每个空闲连接约占用 2.5–4 KB 内存；活跃连接（含请求头、缓冲区等）可能达 10–20 KB
• 实际建议：生产环境建议按理论值的 60%~70% 设定监控告警阈值，例如 8 核服务器配 worker_processes 8; worker_connections 16384;，则理论并发为 131072，但应将连接数告警线设在 80000 左右

keepalive_timeout 与客户端行为适配

长连接保持时间并非越长越好，需平衡复用收益与连接堆积风险。

• 取值标准：一般设为 60–75 秒，略高于典型 HTTP 请求往返时间（RTT）+ 后端处理时间
• 配套参数：keepalive_requests 10000;（单连接最多请求数），防止一个慢连接长期占用资源
• 慎用场景：移动端弱网环境下，客户端可能异常断连但未发 FIN，过长的 timeout 会导致连接滞留；此时可结合 keepalive_disable mobile 或缩短 timeout 至 30s