浏览器对同一域名的websocket并发连接数限制为6个，属同源tcp连接池限制，与http/1.1共用；chrome/firefox/edge/safari均如此，websocket不享受http/2多路复用。
浏览器对 WebSocket 的最大并发连接数没有统一标准，实际值取决于同源策略下的 TCP 连接池限制，主流浏览器基本卡在 6 个左右 —— 不是你代码写错了，是浏览器故意这么干的。
为什么 Chrome 显示能建 256 个连接，实际却卡在第 7 个？
这是最常见的误解来源：把“HTTP 客户端默认 maxSockets（Node.js）”或“Windows 系统 socket 句柄上限”错当成浏览器限制。真实情况是：
- Chrome / Edge / Firefox / Safari 对同一域名（
ws://example.com或wss://example.com）的并发 WebSocket 连接数，和 HTTP/1.1 请求共用同一个 TCP 连接池，默认上限为6 - 你看到的 256、200、1273 等数字，多出自旧版测试（如 IE6 时代）、非同源场景（跨子域）、或混淆了“单页面内可建总数”和“同源并发数”
- 打开
chrome://net-internals/#sockets可实时看到当前已建立的ws:连接数，超过 6 后新连接会进入Pending状态，直到有连接释放
Firefox 能否通过 network.http.max-persistent-connections-per-server 改？
可以改，但只在本地生效，且不推荐用于生产环境适配：
Comet AI 浏览器
下载
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
- 该配置影响所有同源 HTTP/HTTPS/WS 流量，不是 WebSocket 专属开关
- 修改后需重启浏览器，前端 JS 完全无法读取或干预该值
- 用户不会为你调这个参数；依赖它等于放弃兼容性保障
- 实测 Firefox 120+ 即使设为 20，若同时加载大量图片 + XHR，WebSocket 仍可能被挤出连接队列
Chrome 和 Safari 在 HTTP/2 下是否放宽限制？
不放宽 WebSocket 限制。HTTP/2 多路复用只作用于 HTTP 请求，WebSocket 仍强制走独立 TCP 连接：
- 即使服务端启用了 HTTP/2，
Upgrade: websocket请求一旦完成，就会升级为裸 TCP 长连接，不再享受 HTTP/2 特性 - Safari 在 macOS 上某些版本对同源连接数略松动（比如短暂达到 8～9），但不可靠，也不可编程控制
- 不要试图用
fetch()+ HTTP/2 + 自定义协议模拟 WebSocket —— 缺少真正的双工、无消息边界、重连语义缺失，维护成本远高于分片方案
如何验证自己是否撞到了浏览器连接墙？
最直接的方式是监听连接生命周期并统计失败模式：
- 在
new WebSocket(url)后立即监听onerror和onclose，特别关注event.code === 1006（连接被拒绝）或event.reason为空但状态变为CLOSED - 打开开发者工具 → Network → Filter 输入
ws，观察新建连接是否长期停留在Pending或直接Failed - 用多个标签页分别打开不同子域名（如
ws1.example.com、ws2.example.com），对比连接成功率 —— 若子域下能稳定建满 6 个，而主域始终卡在第 7 个，基本可确认是浏览器同源限制
真正难处理的不是“怎么突破 6”，而是“如何让业务逻辑不感知这 6 个”。路径级多路复用（单连接 + type 字段路由）是最轻量、最可控的选择；子域名分片虽有效，但要额外管理 DNS、证书、心跳同步和故障转移。别在连接数上做假设，从第一天就按「最多只敢开 1 个 WS」来设计消息通道。
