worker_connections是单个worker进程能打开的最大文件描述符数，本质为连接配额而非处理逻辑；其生效需与系统ulimit、worker_rlimit_nofile及内核参数协同，否则触发“too many open files”错误。
worker_connections 不是“实现并发连接处理”的技术手段，而是限制每个 worker 进程能同时管理的连接数上限。它本身不负责处理逻辑，而是配合事件驱动模型（如 epoll）和连接池机制，共同支撑高并发场景下的连接调度与复用。
它本质是文件描述符（FD）配额
每个 TCP 连接、上游代理连接、甚至部分日志句柄都会占用一个文件描述符。worker_connections 就是单个 worker 进程能打开的最大 FD 数。超过这个数，新连接会被拒绝，日志中常见 “Too many open files” 错误。
- RTMP 推流：1 路推流 ≈ 1 个连接（publish）
- HTTP-FLV 播放：1 个观众 ≈ 1 个长连接（play）
- HLS 播放：大量短连接，不持续占用 worker_connections 配额
- 反向代理场景下，1 个客户端请求可能消耗 2 个连接（client + upstream），实际并发能力约打五折
必须放在 events 块里才生效
worker_connections 是 events 模块指令，写在 main 上下文（如全局位置）会直接导致 Nginx 启动失败。正确结构如下：
worker_processes 4;
events {
use epoll;
worker_connections 8192;
multi_accept on;
}
其中 multi_accept on 表示 worker 被唤醒后尽可能多地接收就绪连接，减少排队延迟；use epoll 是 Linux 下最高效的 I/O 多路复用方式，支撑万级连接的关键基础。
真实并发能力取决于三者协同
仅调大 worker_connections 没用，必须同步满足：
- 系统级文件描述符限制：通过 ulimit -n 查看，需 ≥ worker_processes × worker_connections；修改 /etc/security/limits.conf 或 systemd 的 LimitNOFILE
- Nginx 自身资源上限：配置 worker_rlimit_nofile 65535，确保进程能申请到足够 FD
- 内核网络栈支持：调整 net.core.somaxconn、net.ipv4.tcp_tw_reuse 等参数，避免连接堆积或端口耗尽
连接不是越多越好，要结合业务模型
比如直播服务以长连接为主，连接生命周期长，更依赖连接池复用和内存控制；而 CDN 或 API 网关可能短连接密集，需关注 TIME_WAIT 回收与 accept 队列深度。
- 每连接约占用 2–4 KB 内存，8192 连接/worker 在 4 核机器上约需 256 MB 连接相关内存
- keepalive_timeout 和 keepalive_requests 影响连接复用率，调高可显著降低新建连接开销
- 用 ss -s 或 lsof -p [worker_pid] | wc -l 实时观察连接占用情况，比理论值更有参考价值
