worker_connections 控制每个 worker 进程能同时打开的文件描述符上限，涵盖 TCP 连接、监听套接字、上游连接等；需与系统 nofile 限制及 worker_rlimit_nofile 配置对齐，并配合 epoll、multi_accept 等选项才能支撑高并发长连接。
worker_connections 不是“能处理多少请求”，而是“能维持多少并发连接”。它管的是连接数，不是请求数——尤其在直播、长连接场景下，这个区别非常关键。
它到底控制什么？
每个 worker 进程能同时打开的文件描述符（FD）上限。TCP 连接、监听套接字、上游代理连接、甚至日志文件句柄，都算在内。Nginx 用它来决定单个进程最多挂起多少个活跃连接。
- RTMP 推流：1 路推流 ≈ 1 个持久连接（publish）
- HTTP-FLV 播放：1 个观众 ≈ 1 个长连接（持续读取流数据）
- HLS 播放：按 ts 片请求，属短连接，不长期占 worker_connections
- 反向代理到后端：每条 upstream 连接也计入此限制
怎么算够不够？
先明确你的典型连接模型：
- 假设单机承载 3000 名 HTTP-FLV 观众 + 15 路 RTMP 推流 → 总连接需求 ≈ 3015
- 若服务器为 8 核，worker_processes auto → 约 8 个 worker
- 则 worker_connections 至少需 ≥ ⌈3015 ÷ 8⌉ = 377（建议向上取整到 4096 或 8192，留余量）
别只看理论值——实际要预留 10%~20% 给心跳、管理连接、临时 upstream 连接等额外开销。
调大了为什么还是报 “Too many open files”？
因为 Nginx 只是“想用”，系统未必“给得起”。三个层级必须对齐：
- 系统级：/etc/security/limits.conf 中 nginx 用户的 nofile 限制（soft/hard）
- Nginx 级：配置中 events 块的 worker_connections 值
- 运行时级：nginx 配置里可加 worker_rlimit_nofile，显式声明进程能打开的最大 FD 数（应 ≥ worker_processes × worker_connections）
三者中最小的那个，就是最终瓶颈。
配套必须开的选项
光改 worker_connections 不够，得配齐事件模型和调度行为：
- use epoll：Linux 下必须启用，否则无法高效处理数千连接
- multi_accept on：让 worker 一次从内核事件队列中收多个就绪连接，减少排队延迟
- accept_mutex on（默认开启）：避免多 worker 同时争抢新连接导致的“惊群”问题
这些不是锦上添花，而是高并发连接场景下的基础支撑。
