Nginx事件驱动模型不处理WebSocket业务逻辑，而是以单线程事件循环+非阻塞I/O支撑海量连接透传：通过epoll/kqueue监听socket状态，零拷贝转发帧数据，依赖proxy_read_timeout等参数匹配心跳周期，并由多worker进程隔离与共享监听实现横向扩展与高可用。
Nginx 事件驱动模型本身不处理 WebSocket 业务逻辑，但它是支撑海量 WebSocket 连接稳定透传的关键底座——核心优势在于用极低开销维持连接、精准转发帧数据，并把真正的长连接管理交给后端。
单线程事件循环 + 非阻塞 I/O，连接数不再被线程拖垮
每个 worker 进程只用一个线程跑事件循环，靠 epoll（Linux）或 kqueue（macOS/FreeBSD）监听成千上万个 socket 状态变化。WebSocket 连接建立后只是挂在事件表里，不占栈空间、不触发线程调度：
- 没有“每连接一进程/一线程”的内存爆炸风险，几 MB 内存就能撑起数万并发连接
- 读写操作全设为非阻塞，连接空闲时不会卡住整个线程，CPU 时间始终用于响应就绪事件
- 握手阶段完成 101 Switching Protocols 后，后续 ping/pong、文本/二进制帧都按普通数据流透传，不解析内容
连接复用与状态机协同，长连接生命周期可控
Nginx 把 WebSocket 当作升级后的 HTTP 连接来管理，通过内置状态机分阶段处理：
- 收到 Upgrade: websocket 请求时，检查 Connection: upgrade 头并透传给后端，不自行拦截或响应
- 连接建立后，持续监听 read/write/close 事件，支持零拷贝发送（如 sendfile）和输出缓冲，降低延迟
- 超时由 proxy_read_timeout 和 proxy_send_timeout 控制，而非 TCP keepalive，便于匹配业务心跳周期
多 worker 进程隔离 + 共享监听，横向扩展不破连接一致性
多个 worker 并行工作，但共享同一个监听 socket，靠内核 SO_REUSEPORT 或 accept_mutex 协调新连接分配：
- 充分利用多核 CPU，避免单 worker 成为瓶颈
- worker 故障互不影响，某个进程崩溃时其他进程继续服务已建立的 WebSocket 连接
- 配合 ip_hash 或 sticky cookie，确保同一客户端所有帧始终路由到同一台后端服务器，满足连接粘滞要求
轻量模块链路，转发路径短、无冗余抽象
所有代理逻辑（rewrite、access、proxy、gzip）都以回调形式注册进事件循环，没有中间层封装：
- WebSocket 帧从网卡收进来，经简单头透传后直发后端，不进 buffer 重写、不走 content phase
- 模块间无共享状态，避免锁竞争；热重载配置时新 worker 接管新连接，老连接平滑维持
- 真正压力不在 Nginx，而在后端是否采用事件驱动模型（如 Swoole/Go/ASP.NET Core+Sockets）来承载百万级 fd
