浏览器对websocket并发连接数的限制是客户端硬约束，同一域名下仅6～10个，源于http/1.1同源tcp连接池限制；websocket无法复用http/2多路复用，每个连接独占tcp通道；增加服务端资源或集群无效，因限制发生在浏览器端dns解析后、tcp握手前；可行方案为子域名分片或单连接多路复用，后者更轻量可控。
浏览器对 WebSocket 的并发连接数限制不是由协议决定的，而是由客户端实现强制执行的硬约束：同一域名下最多 6～10 个活跃连接。超过这个数，新 new WebSocket() 调用不会立即失败，但会排队、延迟建立，甚至直接触发 onerror 或静默超时。
Chrome/Firefox/Safari 实际连接上限为什么是 6 个？
这不是 WebSocket 特有策略，而是复用了 HTTP/1.1 同源 TCP 连接池限制。每个 WebSocket 连接独占一条 TCP 连接，无法像 HTTP/2 那样多路复用——即使服务端启用了 HTTP/2，WebSocket 握手仍走独立 TCP 通道。
- Chrome / Edge（Chromium 内核）：默认 6 个同源连接（含
fetch、XMLHttpRequest、图片、WebSocket 等） - Firefox：默认 6 个，可通过
network.http.max-persistent-connections-per-server修改，但仅限本地配置，前端无法干预 - Safari：iOS/macOS 表现接近 6，部分版本在 HTTP/2 下略有弹性，但 WebSocket 不受益
为什么增加后端服务器或启用集群对突破限制完全无效？
服务端能支撑百万并发，不代表浏览器愿意建那么多连接。关键点在于：每个 WebSocket 连接 = 一个 socket 文件描述符 + 一个 TCP 连接 + 浏览器连接池计数器。浏览器端的限制发生在 DNS 解析之后、TCP 握手之前，服务端根本收不到请求。
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
- 前端无法通过 JS 修改
chrome://flags或调用任何 API 查询当前已建连接数 - 频繁
ws.close()后立刻new WebSocket()，反而加剧连接队列阻塞，可能触发重试风暴 - 试图用
SharedWorker统一管理连接？它不跨标签页共享 WebSocket 实例，各页面仍独立计数
子域名分片和单连接多路复用哪个更实用？
子域名分片（如 wss://ws1.example.com、wss://ws2.example.com）能快速绕过同源限制，但运维成本高：需额外 DNS 解析、TLS 证书覆盖、负载均衡策略适配；而路径级多路复用只需维护一个连接，所有业务消息靠 type 字段路由，更轻量也更可控。
- 推荐优先采用单连接方案：发送
{ "type": "chat", "data": {} }或{ "type": "notify", "data": {} }，前端按type分发到对应模块 - 若必须分片，请控制子域名数量（建议 ≤ 4），避免 DNS 查询延迟和证书管理复杂度上升
- 非强实时场景（如后台数据同步）改用
EventSource或定时fetch，把宝贵的 WebSocket 连接留给音视频信令、交易指令等高频通道
真正容易被忽略的是连接状态监控——浏览器不会告诉你“已达连接上限”，只会让后续 WebSocket 构造函数卡住或报模糊的 CLOSE_ABNORMAL。必须主动监听 onclose 和 onerror，统计失败率，并在连续失败时自动降级到长轮询。
