websocket连接数卡在1k–5k，主因是ulimit -n未调、fs.file-max未扩、服务进程未继承新限制；改limits.conf仍报错，因pam未启用、systemd服务不读该文件、需单独配limitnofile并重载。
websocket 连接数卡在 1k–5k，基本可以断定不是代码问题，而是 ulimit -n 没调、/proc/sys/fs/file-max 没扩、服务进程没继承新限制——三者缺一不可。
为什么改了 limits.conf 还是报 Too many open files
常见现象：明明在 /etc/security/limits.conf 里加了 * soft nofile 65535，重启后 ulimit -n 仍是 1024。
- 根本原因：PAM limits 模块未启用，
/etc/pam.d/common-session缺少session required pam_limits.so - systemd 服务完全不读
limits.conf，必须显式配置LimitNOFILE - 用户登录 shell 类型影响加载（比如
su -会加载，su不会） - Node.js 或 Nginx 启动脚本若用
nohup或systemctl start直接拉起，不会继承当前终端的ulimit
systemd 服务必须单独设 LimitNOFILE
几乎所有现代 Linux 发行版（包括麒麟 OS、CentOS 8+、Ubuntu 20.04+）都用 systemd 管理服务，limits.conf 对它无效。
- 查当前值：
systemctl show -p LimitNOFILE nginx.service - 新建覆盖配置：
/etc/systemd/system/nginx.service.d/override.conf，写入：[Service] LimitNOFILE=1048576
- 重载并重启：
systemctl daemon-reload && systemctl restart nginx.service - 若要全局生效（所有服务），改
/etc/systemd/system.conf中的DefaultLimitNOFILE=1048576
内核级 fs.file-max 必须同步调大
fs.file-max 是系统总水坝，单个进程的 ulimit 再大，也超不过这个总数。默认值常为 8192～65536，撑不住 10 万连接。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 临时生效：
sysctl -w fs.file-max=2097152 - 永久生效：往
/etc/sysctl.d/99-file-max.conf写一行fs.file-max = 2097152，再sysctl -p /etc/sysctl.d/99-file-max.conf - 验证是否到位：
cat /proc/sys/fs/file-max和cat /proc/sys/fs/file-nr（第三列是当前已分配总数） - 注意：该值建议设为单机目标连接数 × 2～3 倍（例如目标 10 万连接，设 200 万较稳妥）
浏览器端的连接数其实和你服务器没关系
别被“服务端撑到 10 万”误导——Chrome/Firefox/Safari 对单域名 WebSocket 并发连接数硬限制是 6～10 个，这是 TCP 层面的同源限制，和服务端配置完全无关。
- 现象：前端反复
new WebSocket()，但第 7 个开始卡在connecting或直接onerror - 错误日志里看不到服务端拒绝，因为连接压根没发出去
- 唯一解法是前端分片：用
wss://ws1.example.com、wss://ws2.example.com等子域名分流，或只建 1 个连接 + 自定义消息路由 - 服务端再怎么优化，也无法让浏览器多开一条 TCP 连接
真正卡住高并发的，往往不是代码逻辑，而是 LimitNOFILE 漏配、pam_limits.so 没启用、或者误以为“调了 ulimit 就万事大吉”。每层限制都要独立验证，尤其 systemd 服务和浏览器侧，最容易被忽略。
