Nginx 不原生支持 WebSocket 异步处理，仅透传 TCP 连接；其作用限于 HTTP 升级握手转发，帧解析、状态管理及保活均由后端承担，真正瓶颈通常在系统层或后端服务。
Nginx 本身并不原生支持 WebSocket 的异步处理，它对 WebSocket 的支持本质上是基于 HTTP 协议升级（Upgrade: websocket）的反向代理转发，而非在 Nginx 内部实现 WebSocket 协议解析或长连接状态管理。因此，“Nginx 中异步处理机制对大并发 WebSocket 支持”这一说法存在常见误解——Nginx 不处理 WebSocket 数据帧，也不维护 WebSocket 连接状态，它的角色是高效地透传 TCP 连接。
WebSocket 在 Nginx 中的实际工作方式
Nginx 从 1.3.13 版本起支持 Upgrade 和 Connection 头的透传，从而允许客户端与后端服务完成 WebSocket 握手。关键点在于：
- Nginx 不解析 WebSocket 帧（如文本、二进制、ping/pong），不干预消息内容
- 握手成功后，Nginx 将该 TCP 连接保持为“长连接透传模式”，类似隧道（tunnel mode）
- 所有后续 WebSocket 数据（包括心跳）直接转发，不经过 Nginx 的 HTTP 处理逻辑
- 真正的异步 I/O、帧编解码、连接保活、消息分发均由后端应用（如 Node.js、Go、Java Spring WebFlux）承担
影响大并发 WebSocket 的核心 Nginx 配置项
虽不处理协议，但 Nginx 的连接管理能力直接影响 WebSocket 并发上限：
-
worker_connections：每个 worker 进程可维持的最大并发连接数，需结合
worker_processes auto充分利用多核 -
keepalive_timeout：应设为较大值（如
75s或更高），避免 Nginx 主动断开空闲长连接 -
proxy_read_timeout / proxy_send_timeout：必须显著延长（如
3600），否则默认 60 秒超时会中断静默连接 - proxy_buffering off：禁用缓冲，防止 Nginx 缓存未完成的 WebSocket 帧导致延迟或粘包
- proxy_http_version 1.1 与 proxy_set_header Upgrade $http_upgrade 等头透传指令必不可少
真实瓶颈通常不在 Nginx 层
当 WebSocket 并发量达数万甚至十万级时，常见瓶颈出现在：
- 操作系统层面：文件描述符限制（
ulimit -n）、端口耗尽、TIME_WAIT 连接堆积 - 后端服务：单机连接数上限、事件循环/线程池饱和、内存泄漏、心跳响应延迟
- 网络层：负载均衡器（如云厂商 SLB）的连接数配额、SSL 卸载性能、跨机房延迟
- Nginx 自身极少成为瓶颈，除非配置严重不合理（如过小的
worker_connections或频繁重连触发大量握手）
提升大规模 WebSocket 场景稳定性的建议
聚焦真正可控的环节：
- 启用
epoll（Linux）并确认use epoll;已生效；关闭不必要的模块减少内存占用 - 为 WebSocket 路由单独配置 upstream，使用
least_conn或一致性哈希（hash $remote_addr consistent）优化后端连接分布 - 配合后端实现连接健康检查（如定期发送 ping）和优雅降级（如自动重连 + 消息队列兜底）
- 监控关键指标：Nginx 的
Active connections、Reading/Writing/Waiting状态，以及后端每秒新建连接数与错误率
