WebSocket并发卡在1k–5k是因系统文件描述符未调高、Nginx未透传Upgrade/Connection头、服务端事件模型低效；需改ulimit与内核参数、配全Nginx三行升级头并关缓冲、选Libevent等高效事件循环。
WebSocket连接数卡在1k–5k，不是代码写得差，而是系统资源没放开、Nginx没配对、服务端事件模型没选准——这三个环节任一没调好，65535这个理论上限就永远只是理论。
Linux文件描述符限制必须改
每个WebSocket连接至少占用1个文件描述符（fd），而Linux默认ulimit -n是1024。不改这个，accept()失败、新连接被静默拒绝，日志里常出现Too many open files或空连接超时。
- 临时生效：在启动服务的同一shell中执行
ulimit -n 65535 - 永久生效：向
/etc/security/limits.conf追加两行：* soft nofile 1048576和* hard nofile 1048576，并确认Nginx、Uvicorn、Workerman等进程由该用户启动 - 同步调优内核参数：在
/etc/sysctl.conf中加入net.core.somaxconn = 65535、net.ipv4.tcp_tw_reuse = 1、net.ipv4.ip_local_port_range = 1024 65535，再执行sysctl -p
Nginx代理WebSocket必须显式透传Upgrade头
90%的“连不上”问题出在这里：Nginx默认把WebSocket握手当成普通HTTP请求，过滤掉Upgrade和Connection头，导致后端收不到升级请求，返回200而非101——浏览器报错Unexpected response code: 200。
-
location块中必须写全这三行：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade" -
proxy_read_timeout和proxy_send_timeout建议设为86400（24小时），不能沿用默认60秒，否则空闲心跳期间连接会被主动切断 - 务必关闭缓冲：
proxy_buffering off；禁用缓存：proxy_cache off；否则消息可能延迟甚至丢失
服务端事件循环模型决定单机吞吐天花板
Workerman默认用Select，Python websockets库默认启用压缩，Node.js默认libuv——这些选择直接影响每连接内存开销和并发极限。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- Workerman：在
start_gateway.php中启用Libevent扩展（比Select高效得多），并把$gateway->count设为CPU核心数的1–2倍（如8核设8–16） - Python
websockets：禁用压缩可将单连接内存从~64KB降至~14KB，加参数compression=None - FastAPI + Uvicorn：worker数不宜超过CPU核心数×1.5（如4核设-w 6），且必须配
--limit-concurrency 100防止单个worker压垮内存
浏览器端连接数限制无法靠服务端扩容解决
Chrome/Firefox/Safari对单个域名的WebSocket并发连接数限制为6～10个，这是客户端策略，与协议无关。WebSocket不复用HTTP/2多路复用，每个连接独占一条TCP通道——服务端支持百万并发，浏览器仍卡在“每域名最多6条TCP连接”上。
- 前端无法通过JS修改该上限，也无API可查当前已建连接数
- 子域名分片（如
wss://ws1.example.com、wss://ws2.example.com）是绕过限制最直接的方式，需DNS解析支持+通配符TLS证书 - 更推荐路径级多路复用：只建1个连接，所有业务消息通过
{"type": "chat", "data": {...}}这类自定义协议路由，由前端分发到对应模块
真正卡住并发上限的，往往不是某一行代码，而是系统层ulimit没生效、Nginx配置漏了$http_upgrade变量、或者前端还在用10个独立连接去干一件事——这些地方一错，调再多参数也没用。
