websocket长连接需协同调优worker_connections、文件描述符限制（系统/用户/进程三级）、反向代理余量及内存占用；必须配置use epoll、multi_accept、proxy_timeout等参数保障稳定性。
WebSocket 是长连接，worker_connections 要设得够高，但不能只看这个数字——它必须和系统能打开的文件描述符、Nginx 进程声明、业务连接特征三者对齐，否则调再大也白搭。
先对齐三层文件描述符限制
真正起作用的是以下三者的最小值，缺一不可：
-
系统总上限：/proc/sys/fs/file-max，建议设为
worker_processes × worker_connections × 1.3～1.5，预留 TIME_WAIT、SSL 缓存、日志等开销 -
用户级限制：在
/etc/security/limits.conf中为 Nginx 运行用户（如www-data或nginx）添加：nginx soft nofile 65536nginx hard nofile 65536
然后重载 systemd 配置或重新登录会话 -
Nginx 进程级声明：在
nginx.conf主块（http 外）加：worker_rlimit_nofile 65536;
该值应 ≥worker_connections，推荐设为相同或略高（如 1.2 倍）
按 WebSocket 特性设合理数值
WebSocket 单连接复用时间长，fd 占用稳定但总量大，不适用短连接那一套：
- 单机支撑 1 万～3 万并发 WebSocket 连接，建议
worker_connections设为 32768～65535 - 若启用了反向代理（即每个客户端连接对应一个后端连接），实际可用连接数≈
worker_connections / 2，需留足余量 - 不要盲目堆到 10 万+，要结合内存估算：每个连接约占用 2–4 KB 内存，65535 连接 ≈ 130–260 MB 内存/worker
配套关键参数必须同步开启
只改 worker_connections 效果有限，这些必须一起配：
-
use epoll;：Linux 下必须显式指定，避免回退到 select/poll 的 1024 硬限 -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发建连压力 -
accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接导致“惊群” - 关闭日志缓冲或启用 buffer+flush，减少每个连接额外占用的 fd
WebSocket 场景下特别注意的点
除了连接数本身，这些配置直接影响长连接稳定性：
-
proxy_read_timeout和proxy_send_timeout必须设大（如86400），且要大于客户端心跳间隔，否则空闲连接会被静默断开 - 禁用
proxy_buffering off;和proxy_cache off;，避免帧被缓存截断或升级请求被误返回 200 - 确保透传头字段：
proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade";
