单机nginx稳定承载百万级静态连接需四层协同调优:系统级fs.file-max、用户级ulimit、nginx进程级worker_rlimit_nofile及events块精调(epoll/multi_accept/off accept_mutex),缺一不可。

要让单机 Nginx 稳定承载百万级静态连接,光调大 worker_connections 远远不够——它只是“纸面并发数”,真正起作用的是它与系统资源的协同闭环。核心在于:每个连接都要占用一个文件描述符(fd),而 fd 总量受操作系统硬性限制,一旦突破,就会报 accept() failed (24: Too many open files),新连接直接被丢弃。
worker_connections 不能孤立设置
这个参数定义的是每个 worker 进程能同时管理的连接数,理论最大并发 = worker_processes × worker_connections。例如:
worker_processes 8;worker_connections 131072;- → 理论值 = 8 × 131072 = 1 048 576(约 100 万)
但若系统 fs.file-max 只有 65536,或用户级限制(ulimit -n)仍是默认的 1024,那连 1 万个连接都撑不住。必须确保:
系统总上限 ≥ 用户级上限 ≥ 进程级上限
四层关键协同调优
百万连接不是改一个配置就能达成,而是操作系统、用户权限、Nginx 进程、运行时行为四层联动的结果:
-
系统级句柄上限:
fs.file-max建议设为worker_processes × worker_connections × 1.3左右。例如目标 100 万,则设为1300000,写入/etc/sysctl.conf并执行sysctl -p -
用户级限制:在
/etc/security/limits.conf中添加* soft nofile 1000000* hard nofile 1000000
重启会话或重登生效(注意:systemd 服务需额外配置LimitNOFILE) -
Nginx 进程级声明:在
nginx.conf全局块中加worker_rlimit_nofile 1000000;
该值必须 ≥ 单个 worker 的worker_connections× worker 进程数,否则启动即失败 -
events 块精调:
启用use epoll;(Linux 默认,确认不被覆盖)
关闭accept_mutex off;(高并发下锁竞争反成瓶颈)
开启multi_accept on;(一次收多个连接,减少事件循环次数)
静态资源场景专项优化
百万连接多用于静态文件分发(如 CDN 边缘节点、大促活动页),此时应最大限度减少内核拷贝和上下文切换:
-
sendfile on;:绕过用户态,内核直接 DMA 发送文件 -
tcp_nopush on;:配合 sendfile,等数据包填满再发,降低小包开销 -
tcp_nodelay off;:静态场景不追求极低延迟,宁可稍等也要攒包 - 关闭日志写入或异步刷盘:
access_log /dev/null;或用buffer+flush缓冲 - 禁用不必要的模块(如 Lua、realip 多层解析),减小 worker 内存 footprint
验证与观测要点
调完不验证等于没调。重点关注三个层级是否对齐:
- 运行时检查:
cat /proc/$(pidof nginx)/limits | grep "Max open files"→ 应显示 1000000 - 系统总量:
cat /proc/sys/fs/file-nr(三列:已分配 / 未使用 / 最大值),第三列应 ≥ 预设值 - Nginx 实时连接:
curl http://127.0.0.1/nginx_status(需启用 stub_status)看Active connections是否能持续稳定在 80 万以上 - 监控 TIME_WAIT:大量短连接易堆积,可调
net.ipv4.tcp_tw_reuse = 1+ 合理keepalive_timeout(静态资源建议 30~60s)










