浏览器同源websocket并发连接数实际限制为6个，源于http/1.1同源tcp连接池共享机制；所谓256个是误读node.js配置或混淆跨源场景，突破需子域名分片或单连接多路复用。
浏览器对 websocket 的并发连接数没有统一标准，但实际限制非常明确：同源（同一域名+端口+协议）下，主流浏览器普遍卡在 6 个 tcp 连接上限，而非“256 个 websocket”这种常见误传。
为什么说“256 个 WebSocket”是误导性结论
这个数字常来自对 Node.js http.globalAgent 默认 maxFreeSockets 值（256）的误读，或测试时未控制同源条件（比如混用 ws://localhost:3000 和 ws://127.0.0.1:3000，它们算不同源）。真实限制来自浏览器底层网络栈，和 HTTP/1.1 共享同一套 TCP 连接池。WebSocket 虽然协议不同，但每个连接仍需独占一个 TCP socket —— 所以它被计入“同源并发 TCP 连接总数”，不是单独计数。
- Chrome / Edge（Chromium 内核）：默认最多 6 个同源 TCP 连接（含 WebSocket、XHR、fetch、图片等）
- Firefox：默认也是 6，可通过
network.http.max-persistent-connections-per-server修改，但仅限本地配置，前端无法干预 - Safari（macOS/iOS）：HTTP/2 下静态资源可复用连接，但 WebSocket 仍走独立 TCP，实测稳定上限仍是 6～8 个
- 所谓“Safari 支持 1273 个”是早期 macOS 特定版本的异常行为，2024 年后已回归常规限制
什么时候会真的遇到 254 或 256 的报错
这类错误通常不是浏览器原生限制，而是叠加了其他约束后的表现：
-
EMFILE错误（Too many open files）：操作系统级限制触发，Linux 默认ulimit -n为 1024，一个页面开 256 个 WebSocket 就可能耗尽 fd（尤其配合大量图片、XHR 时） - 服务端拒绝新连接但返回模糊提示：比如 Nginx 默认
worker_connections是 512，或后端框架（如 Spring Boot）未调优连接池，导致客户端重试时误判为“浏览器封顶” - 前端脚本未复用连接、盲目轮询创建：例如每秒 new 10 个
WebSocket实例却不 close，连接堆积后触发浏览器内部队列溢出或 TLS 握手失败
如何验证当前页面的真实连接占用
不能只看 WebSocket 实例数量，要观察底层 TCP 连接：
- Chrome DevTools → Network → Filter 输入
ws，看协议列为ws或wss的请求数；再切到Other，勾选 “Waterfall”，观察是否有请求长期显示 “Stalled” —— 这是排队等待空闲 TCP 连接的典型信号 - 命令行辅助诊断：
lsof -i :<port> -u $USER | grep ESTABLISHED | wc -l</port>（Mac/Linux），可看到当前用户与目标端口建立的 TCP 连接总数 - 注意：即使
WebSocket.readyState === 1（OPEN），若底层 TCP 已断开而 JS 层未感知，该连接仍可能占用 fd，造成“幽灵连接”
突破限制的可行路径只有两个方向
服务端扩容、集群、负载均衡对浏览器端限制完全无效；前端也无法用 JS 绕过内核限制。真正能落地的解法只有：
-
域名分片（Domain Sharding）：将 WebSocket 拆到多个子域，如
wss://ws1.example.com、wss://ws2.example.com。注意必须是 DNS 可解析的真子域（ws1.example.com≠ws1.example.com.），且证书需覆盖全部子域 - 协议合并（Multiplexing）：单个 WebSocket 连接内实现多路复用（如用自定义帧头区分业务通道），避免为每个业务模块建独立连接。RSocket、GraphQL over WebSocket、或简单 JSON 消息路由都属于这一类
容易被忽略的是：WebSocket 连接建立成本高（TLS 握手、证书验证、RTT），盲目增加连接数不仅不提升吞吐，反而加剧 CPU 和熵池压力，尤其在低端设备或 iOS Safari 上更容易触发静默断连。真正需要的不是“更多连接”，而是“更少连接 + 更高效复用”。
