单机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）