websocket在swarm中连不上，根本原因是默认vip模式的routing mesh不兼容长连接，必须改用endpoint-mode=dnsrr并配合客户端直连具体容器ip，否则http upgrade握手失败或连接被中间层中断。
WebSocket服务在Swarm里为什么连不上？
直接用docker service create部署WebSocket服务，客户端大概率会断连或收不到消息——根本原因不是代码问题，而是Swarm默认的DNS轮询+HTTP层负载均衡机制不兼容长连接。WebSocket握手依赖首次HTTP Upgrade请求，而Swarm的路由网格（Routing Mesh）默认只对published端口做L4转发，且不感知连接生命周期。
常见错误现象包括：
- 客户端报
WebSocket connection to 'ws://...' failed: Error during WebSocket handshake - 连接建立后几秒内自动关闭，服务端日志无异常
-
curl -i http://service-name:port能通，但wscat -c ws://...失败
关键判断：必须绕过Routing Mesh，改用DNS RR（Round Robin）模式 + 客户端自己做服务发现，才能让每个WebSocket连接稳定绑定到单个后端实例。
如何配置endpoint-mode=dnsrr并验证解析
Swarm默认使用VIP模式（endpoint-mode=vip），所有请求都经由集群内置的虚拟IP分发；WebSocket必须切到dnsrr，让客户端直连具体容器IP，避免中间层干扰。
实操要点：
- 创建服务时显式指定
--endpoint-mode dnsrr，否则即使网络是overlay也无效 - 服务必须挂载同一
overlay网络，且该网络不能是ingress - 客户端容器内需用
dig或nslookup确认解析结果是多个A记录，而非单一VIP
示例命令：
docker network create --driver overlay ws-net docker service create \ --name ws-server \ --network ws-net \ --endpoint-mode dnsrr \ --replicas 3 \ registry.cn-hangzhou.aliyuncs.com/anoy/ws-echo:latest
进入任一客户端容器执行：dig ws-server.ws-net，应返回3个不同IP（如10.0.1.5、10.0.1.6、10.0.1.7），而不是一个VIP地址。
客户端如何实现连接粘滞（sticky connection）
DNS RR只是把服务名解析成多个IP，但普通WebSocket客户端（如浏览器或wscat）每次调用都会重新解析，可能连到不同后端，导致状态丢失。真正的“粘滞”得靠客户端逻辑控制。
可行做法：
- 首次连接前，用
getaddrinfo或dns.resolve主动获取全部IP，随机选一个并缓存，后续重连复用该IP - 服务端配合返回容器ID（如
HOSTNAME环境变量），客户端日志里可追踪连接归属 - 避免在Nginx等反向代理层做WebSocket负载均衡——Swarm里它和Routing Mesh叠加反而更不可控
Node.js客户端片段示意：
const dns = require('dns');
dns.resolve('ws-server.ws-net', (err, addresses) => {
if (addresses?.length) {
const target = addresses[0]; // 固定首IP，实现简单粘滞
const ws = new WebSocket(`ws://${target}:8080`);
}
});
为什么不能用--publish mode=host暴露WebSocket端口
有人尝试用--publish published=8080,target=8080,mode=host把端口直接绑到宿主机，以为能绕过Swarm网络——这在Worker节点上看似可行，但实际破坏了服务发现机制，且带来三个硬伤：
- 客户端必须知道每个Worker节点IP，无法通过服务名访问，失去Swarm抽象意义
- Swarm无法感知该端口健康状态，故障节点上的连接不会自动剔除
- 多副本时，客户端需自行实现负载策略（比如轮询节点列表），而Swarm本已提供DNS RR能力
真正要暴露给外部的WebSocket入口，应该单独起一个带TLS终止的边缘代理（如Nginx或Traefik），它通过dnsrr解析后端服务名，再转发WS流量——这样既保留服务发现，又可控地暴露端点。
复杂点在于：DNS解析结果会随副本扩缩容动态变化，客户端缓存时间（TTL）不能设太长；容易被忽略的是，dnsrr模式下服务名必须带网络后缀（如ws-server.ws-net），裸名ws-server在跨网络场景下会解析失败。
