调高nginx并发连接数核心在events块：需协同配置worker_connections（单进程连接上限）、use epoll（linux必显式指定）、multi_accept与accept_mutex（控制连接接收节奏），并同步调高系统ulimit -n和nginx的worker_rlimit_nofile，否则参数无效。

调高 Nginx 并发连接数，核心在 events 块 的几项关键配置，但不能只改一个参数——必须和系统限制、Nginx 全局设置联动，否则调再高也接不住连接。

worker_connections：单进程连接上限

它决定每个 worker 进程最多处理多少并发连接（含 keepalive 空闲连接）。实际总并发 = worker_processes × worker_connections。

• 常见取值：1024（默认）、4096、10240、65535；高并发场景推荐 10240 或更高
• 硬性约束有两个：
  – 系统单进程文件描述符限制（ulimit -n），需 ≥ worker_connections
  – Nginx 自身的 worker_rlimit_nofile（写在 events 外层），需 ≥ worker_processes × worker_connections
• 例如：4 核机器设 worker_processes 4，想支持 4 万连接，就至少要：
  → worker_connections 10240
  → worker_rlimit_nofile 41000
  → ulimit -n 临时或永久设为 ≥ 41000

use epoll：Linux 下必须显式启用

Linux 2.6+ 内核中，epoll 是唯一能稳定支撑数万连接的事件模型。select/poll 有 1024 连接上限且性能差，应避免。

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• 务必在 events 块中写明：use epoll;
• Nginx 虽会自动选 epoll，但显式声明可防止误判，也提升配置可读性和运维确定性

multi_accept 与 accept_mutex：协同控制连接接收节奏

这两个参数共同影响“新连接进来时，Nginx 怎么抢、怎么收”。

• multi_accept on;：让一个 worker 在一次事件循环里尽量多 accept 几个连接，适合突发流量（如秒杀、爬虫）
• accept_mutex on;（默认开启）：避免多个 worker 同时被唤醒争抢新连接（惊群问题），降低锁竞争
• 二者搭配使用更合理：mutex 控制“谁来收”，multi_accept 控制“一次收几个”
• 注意：Nginx 1.11.3+ 对 accept 逻辑做了优化，一般不建议关掉 accept_mutex；除非已启用 reuseport 且确认无惊群影响

配套系统级调优不能漏

events 块只是“软件开关”，底层资源没放开，配置再高也白搭。

• 临时提高单进程限制：ulimit -n 65535
• 永久生效（需 root）：
  → 编辑 /etc/security/limits.conf，加两行：
  * soft nofile 65535
* hard nofile 65535
• 检查系统总句柄上限：cat /proc/sys/fs/file-max，若偏低（如低于 20 万），可临时调高：sysctl -w fs.file-max=2097152
• 确保内核连接队列足够：net.core.somaxconn 建议设为 65535，避免 accept 队列溢出丢包