Traefik 2 Docker Swarm环境下粘性会话与WebSocket异常登出问题咨询

我在Docker Swarm模式下使用Traefik 2部署一款需粘性会话的WebSocket应用，用户偶发登录后无明显原因立即登出，捕获Chrome网络追踪后发现是WebSocket消息触发了登出操作。

此问题仅在服务器多副本环境中出现，单实例的开发/测试环境未出现该情况，因此怀疑与负载均衡和会话持久化机制有关。

观察到的现象 #

• 正常情况下，Traefik粘性Cookie的值为会话绑定的副本Docker内部IP地址，格式如下：

  traefiksticky=http://10.0.24.149:8080; Path=/
  

• 异常场景中，该Cookie的初始值（由常规HTTP请求而非WebSocket响应设置）格式不同：

  traefiksticky=7361779c89a76cdc; Path=/
  

• 建立WebSocket的请求会发送此异常Cookie，但响应中的Set-Cookie头会将其值修改为IP地址格式：

  traefiksticky=http://10.0.24.149:8080; Path=/
  

• 连接建立后不久，WebSocket向浏览器发送'session timeout'消息，推测是WebSocket连接到了不同的服务器副本，导致会话不被识别。
• 应用启动流程中会先后建立两个WebSocket连接，异常可能影响第一个或第二个连接，并非所有连接都会受影响。

疑问 #

1. 粘性Cookie的不同格式有何含义？
2. 这是否与当前问题相关，还是无关的干扰项？

补充：该环境中Traefik本身是多副本部署，而开发/测试环境中Traefik为单实例，暂未找到该配置对粘性会话影响的相关文档。

1. 粘性Cookie不同格式的含义 #

Traefik 2的粘性会话机制对应两种配置模式，分别产生不同格式的Cookie值：

• IP:Port格式：属于service级别的粘性会话配置（对应Traefik的sticky.service参数），Cookie值直接指向具体的后端容器实例的IP和端口，确保后续所有请求都会被路由到该实例。
• 哈希值格式：属于loadbalancer级别的粘性会话配置（对应sticky.loadbalancer参数），这个哈希值是后端服务的唯一标识（比如Docker Swarm服务的ID哈希），Traefik会通过哈希映射到对应的实例组。但如果后端实例发生变动，或者Traefik副本间的实例列表不同步，哈希对应的实例可能出现偏差。

另外，当Traefik自身以多副本部署时，若某个Traefik节点未及时同步到后端实例的IP信息，就可能返回哈希格式的Cookie而非直接的IP格式。

2. 与当前问题的相关性 #

这是导致问题的核心原因，绝非干扰项：

• 异常场景中，初始HTTP请求得到哈希格式的Cookie后，若不同Traefik副本对该哈希的实例映射不一致（比如实例列表同步延迟），WebSocket请求携带这个Cookie时，就可能被路由到和之前HTTP请求不同的后端实例。
• 虽然WebSocket响应会将Cookie修正为IP格式，但此时WebSocket连接已经建立在错误的实例上，该实例没有用户的会话数据，因此会触发'session timeout'导致登出。
• 应用的两个WebSocket连接可能被分配到不同的Traefik节点，进而出现其中一个连接命中错误实例的偶发现象。

额外排查方向 #

• 检查Traefik的粘性会话配置，确保统一设置为sticky.service（绑定具体实例），而非sticky.loadbalancer（绑定服务哈希）——后者在多Traefik副本+动态实例环境下极易出现映射偏差。
• 验证Docker Swarm中Traefik服务的配置同步机制，确保所有Traefik副本能实时获取后端服务的实例列表，避免因实例信息不同步引发路由错误。
• 检查Traefik的会话Cookie配置是否开启secure、httpOnly等属性，防止Cookie被意外篡改或丢失。

内容的提问来源于stack exchange，提问作者Aron