浏览器对单个域名的WebSocket并发连接数限制为6～10个，属客户端策略而非协议限制；Chrome/Edge/Firefox/Safari均沿用HTTP/1.1同源TCP连接上限，WebSocket无法复用HTTP/2多路复用；突破限制需采用子域名分片或单连接多路复用等前端方案。
现代浏览器对单个域名的 WebSocket 并发连接数有明确限制，通常为 6～10 个（与 HTTP/1.1 同源并发限制一致），超出后新连接会被阻塞或直接失败。这不是 WebSocket 协议本身的限制，而是浏览器为防止资源滥用和保障稳定性所设的客户端策略。
主流浏览器的实际连接上限
Chrome、Firefox、Edge 和 Safari 均沿用其 HTTP/1.1 的同源并发连接数限制：
- Chrome / Edge（基于 Chromium）：默认 6 个 同源 TCP 连接（含 WebSocket、XHR、fetch、图片等）
- Firefox：默认 6 个，可通过 network.http.max-persistent-connections-per-server 配置调整（仅限本地设置，无法前端控制）
- Safari：iOS/macOS 表现接近 6，部分版本在 HTTP/2 环境下略有弹性，但 WebSocket 仍走独立 TCP，不享受 HTTP/2 多路复用
服务端扩容 ≠ 浏览器解限：关键误区澄清
WebSocket 是全双工长连接，每个连接独占一个 TCP 通道。即使服务端支持百万并发，浏览器端仍卡在“每域名最多 6 条 TCP 连接”这一硬约束上。因此：
- 增加后端机器、优化 socket 复用、启用集群广播——这些对突破浏览器限制完全无效
- 前端无法通过 JS 修改浏览器连接数上限，也无 API 可查询当前已建连接数
- 试图频繁新建连接替代复用，反而加剧队列阻塞、触发断连重试风暴
可行的前端扩容方案
绕过单域名限制的核心思路是“分散连接到不同源”，同时保持逻辑统一性：
立即学习“前端免费学习笔记（深入）”；
- 子域名负载分片：如将 wss://ws.example.com 拆为 wss://ws1.example.com、wss://ws2.example.com……每个子域名独立计数（需 DNS 解析支持 + TLS 证书覆盖）
- 路径级多路复用（推荐）：只建 1 个 WebSocket 连接，所有业务消息通过自定义协议路由。例如发送 { "type": "chat", "data": {...} } 或 { "type": "notify", "data": {...} }，由前端分发到对应模块
- 连接生命周期管理：非强实时场景（如后台数据同步）改用短连接（Server-Sent Events 或轮询）；高频实时通道（如音视频信令）优先保活，低频通道按需启停
补充建议：监控与降级
实际部署中应主动感知连接瓶颈：
- 监听 onerror 和 onclose 事件，统计连接失败率；若大量出现 CLOSE_ABNORMAL 或超时未 open，大概率是连接被限
- 准备 HTTP fallback：当 WebSocket 连续失败 N 次，自动切换至长轮询（如使用 EventSource 或定时 fetch）
- 服务端配合做连接亲和（sticky session）与消息广播，确保分片连接间状态可协同
