events块是nginx网络连接管理中枢，worker_connections须与ulimit和worker_rlimit_nofile对齐，linux下必须显式配置use epoll，配合accept_mutex on和multi_accept on缓解惊群，值应按业务类型合理设定而非盲目调高。
events 块是 Nginx 管理网络连接的底层控制中枢，它不处理业务逻辑，但直接决定服务器能多快、多稳地接收和分发连接请求。配置得当，才能支撑高并发场景；配错或忽略系统约束，反而会引发连接拒绝、CPU空转或日志报错。
核心参数：worker_connections 与系统资源对齐
该值定义每个 worker 进程最多同时处理多少个连接（含 keepalive 空闲连接）。它的实际生效上限受两个硬性限制：
- 操作系统单进程文件描述符上限（ulimit -n），默认常为 1024，需提前调高，例如设为 65535
- Nginx 主配置中 worker_rlimit_nofile 的值，必须 ≥ worker_processes × worker_connections，否则启动时会警告甚至失败
- 例如：4 核机器设 worker_processes 4，想支持 40 万连接，则 worker_connections 10240，对应 worker_rlimit_nofile 至少设为 41000，并确保系统 ulimit -n ≥ 41000
事件模型选择：显式指定 use epoll（Linux 环境）
Linux 2.6+ 内核应使用 epoll，它是高性能、无连接数硬限制的 I/O 多路复用机制。虽然 Nginx 通常自动选用，但生产环境建议显式声明，避免因版本或编译差异误选 select/poll（二者有 1024 连接上限且性能差）：
events {
use epoll;
worker_connections 10240;
}
连接接收优化：multi_accept 与 accept_mutex 协同使用
这两个指令共同缓解“惊群”问题（多个 worker 同时被唤醒争抢新连接）：
- accept_mutex on：让 worker 轮流获取新连接，避免 CPU 浪费在无意义竞争上
- multi_accept on：允许单次事件循环中尽可能多地从内核 accept 队列取出连接，适合突发流量（如秒杀、爬虫高峰）
- 两者搭配更稳：既防争抢，又提吞吐。常见写法：
accept_mutex on;
multi_accept on;
其他实用设置项
部分指令虽非必需，但在特定场景下能提升稳定性或可观测性：
- worker_connections 值不宜盲目调高——连接数翻倍，内存占用也近似翻倍，需结合实际负载压测调整
- 若部署在容器中，注意容器级 ulimit 限制（如 Docker 的 --ulimit 参数）同样生效，不能只改宿主机
- 修改后务必运行 nginx -t 检查语法，并用 nginx -s reload 平滑重载，避免中断现有连接
