worker_connections直接决定单个Nginx工作进程能维持的WebSocket长连接数，需与ulimit、worker_rlimit_nofile、net.core.somaxconn及proxy超时等参数协同调优，否则导致静默拒绝、502/503或心跳中断。
在 WebSocket 海量长连接场景下，worker_connections 不只是个“连接数上限”数字，它直接决定单个 Nginx 工作进程能同时维持多少活跃的长连接（含 keepalive 空闲状态），而这些连接会长期驻留、持续占用内存和文件描述符。配置不当会导致连接被静默拒绝、502/503 错误、心跳中断或消息积压，尤其在 10 万+ 并发时尤为明显。
必须同步调高系统级资源上限
worker_connections 的实际生效受操作系统限制，若底层不放开，Nginx 会 silently 降级使用默认值（如 512 或 1024）：
- 用 ulimit -n 查看当前进程允许打开的最大文件描述符数，WebSocket 连接每个至少占 1 个 fd；建议设为 ≥ worker_processes × worker_connections × 1.2
- 永久生效需修改 /etc/security/limits.conf：
nginx soft nofile 1048576
nginx hard nofile 1048576 - 确保 systemd 服务未覆盖限制：检查 /etc/systemd/system/nginx.service.d/override.conf 中是否包含 LimitNOFILE=1048576
数值设定要匹配硬件与业务特征
不能盲目堆高数值，需结合 CPU 核心数、内存容量和连接平均生命周期综合判断：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 常见高并发部署参考（8 核 / 32GB 内存）：
worker_processes auto;
worker_connections 65535;
此时理论最大连接数为 8 × 65535 ≈ 52 万，但需确保后端服务能承载同等规模连接 - 若连接多为短生命周期（如频繁重连的心跳型客户端），可适当降低至 32768，减少内存碎片
- 若单连接内存占用高（如带大 buffer 或自定义 session 数据），应保守设置，例如 16384，并增加 worker_processes 分摊压力
配套 Nginx 事件与代理参数必须对齐
仅调大 worker_connections 不足以支撑 WebSocket 长连接稳定运行，以下参数必须协同调整：
- use epoll;（Linux 必选）+ multi_accept on;：提升事件批量处理能力，避免 accept 队列积压
- keepalive_timeout 65;：保持长连接活性，但不宜过长（超过 90s 易被中间设备断连）
- WebSocket 代理块中必须显式设置超时：
proxy_read_timeout 86400;
proxy_send_timeout 86400;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
验证是否真正生效而非仅配置加载
改完配置后，务必通过运行时指标确认效果：
- 执行 nginx -t && nginx -s reload 后，检查错误日志是否有 "worker_connections is not enough" 提示
- 运行 ss -s 查看当前 ESTAB 连接数，对比 ps aux | grep nginx | grep -v grep | wc -l 得到的工作进程数，估算平均连接负载
- 监控 nginx_stub_status 模块输出中的 Active connections 值，长期稳定在 worker_connections × 0.7–0.85 区间属健康状态
