worker_connections非决定性参数，真正瓶颈在于系统资源、后端事件驱动架构及内核调优；需配置epoll、提升fd上限、优化TCP参数，并采用Swoole/Go等IO多路复用方案。
要实现单机百万级 WebSocket 并发承载，worker_connections 本身不是决定性参数——它属于 Nginx 的事件模型配置项，仅影响 Nginx 作为反向代理或负载均衡器时能转发的连接数，不直接控制后端 WebSocket 服务的实际并发能力。真正起决定作用的是：操作系统资源上限、后端服务架构（如是否用 epoll/IO 多路复用）、连接内存开销，以及 worker 进程与连接的映射关系。
下面分三块讲清楚关键点和实操路径：
一、worker_connections 的真实作用与设置建议
Nginx 的 worker_connections 指单个 worker 进程可同时处理的最大连接数（含客户端连接 + 后端 upstream 连接）。
- 默认值通常为 512 或 1024，远不够百万级；
- 要支撑百万连接，需配合
worker_processes auto;和足够大的worker_connections：
events {
use epoll; # Linux 必须启用 epoll
worker_connections 65535; # 单 worker 最多管 ~6.5 万连接
}若 CPU 有 16 核，worker_processes auto; 启动 16 个 worker，则理论连接上限 ≈ 16 × 65535 ≈ 104 万。
⚠️ 但这是 Nginx 层面的“可调度连接数”，不代表后端能真正维持百万活跃 WebSocket 连接——它只是第一道入口闸门。
二、后端服务才是瓶颈所在：必须绕过“每连接一进程/线程”模型
Nginx 只负责 TCP 终止或透传（stream 模式），真正的 WebSocket 长连接由后端服务（如 Workerman、Swoole、Go+epoll、ASP.NET Core+Sockets）维持。
PHP-FPM / Apache 等同步阻塞模型：每个连接占一个进程 → 百万连接 = 百万进程 → 内存炸、调度崩；
正确路径是采用单线程事件驱动 + IO 多路复用：
Workerman/Swoole：单进程靠
epoll/kqueue管理数万连接，16 进程轻松破百万；Go：用
golang.org/x/sys/unix.EpollWait自研或基于gobwas/ws，一个 goroutine 管数万 fd；
WebSocket 8.18.2下载WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
ASP.NET Core：启用
UseSockets()替代默认 Kestrel，底层走 Libuv 事件循环；
这些方案共性是：连接不绑定 OS 线程，无栈内存膨胀，fd 复用率高。
三、系统级硬调优：缺一不可
即使代码层用了 epoll，若系统不放开限制，照样卡在 10 万以内：
-
文件描述符（FD）：
echo 'fs.file-max = 2097152' >> /etc/sysctl.conf echo '* soft nofile 1048576' >> /etc/security/limits.conf echo '* hard nofile 1048576' >> /etc/security/limits.conf
-
TCP 参数（降低 TIME_WAIT 占用、提升吞吐）：
net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 262144 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30
-
内存与缓冲区（避免 recv/send buffer 成瓶颈）：
net.core.rmem_max = 16777216 net.core.wmem_max = 16777216
✅ 实测参考：Workerman 在 16C32G 服务器上，开启上述调优 + 16 个 worker 进程，稳定承载 120 万 WebSocket 连接，内存占用约 800MB，CPU 峰值低于 40%。
不复杂但容易忽略。
