Workerman多机部署需配置支持长连接会话保持的负载均衡器，推荐Nginx（ip_hash或sticky cookie）或HAProxy；若采用无状态方案，则必须依赖高可用Redis集群实现状态同步与Pub/Sub广播，避免数据污染与连接中断。

Workerman多机部署时，负载均衡配置错误会导致用户连接反复断开、消息丢失、状态错乱，尤其在聊天室、在线游戏等强会话场景下，一次错误的转发就可能让玩家掉线或房间数据错位。

选对负载均衡器类型

必须使用支持长连接会话保持的四层或七层负载均衡器，禁用纯轮询LVS或未配置sticky的Nginx。LVS默认不感知TCP连接状态，Nginx若未启用ip_hash或cookie粘性，会把同一用户的WebSocket升级请求分发到不同后端，导致HTTP 101响应失败后连接直接中断。

推荐方案：Nginx（七层）或HAProxy（四层/七层），二者均能稳定维持长连接并提供灵活的会话保持策略。

配置Nginx实现连接粘性

方法一：基于客户端IP哈希（适用于公网IP稳定的场景）

在upstream块中添加ip_hash指令：【ip_hash必须放在upstream第一行，且不能与least_conn、hash等其他负载策略共存】

方法二：基于Cookie绑定（推荐，兼容NAT和移动端）

在upstream中加入sticky cookie配置：sticky cookie=workerman_sid expires=1h domain=.example.com path=/;

这一步操作起来很简单，直接把配置写进nginx.conf的upstream段就行。但要注意：WebSocket连接必须在首次HTTP握手时就携带该cookie，否则后续upgrade请求无法关联到同一后端实例。

方法三：彻底无状态+Redis兜底（适合广播类业务）

关闭所有会话保持，所有Workerman实例在onConnect时立即从Redis加载用户身份和房间信息；所有onMessage写入都带用户ID前缀，并通过Redis Pub/Sub广播给其他机房实例。此时负载均衡可使用最简轮询，但【Redis必须是跨机房高可用集群，单点Redis写入将成致命瓶颈】。

验证连接不丢的关键检查项

第一步：确认客户端建立连接后，连续发送3次心跳包，观察是否始终由同一台Workerman服务器响应；

第二步：手动kill掉当前服务节点的Worker进程，等待30秒，检查客户端是否自动重连且被路由回原节点（需DNS健康探测生效）；

第三步：抓包验证TCP连接五元组（源IP:端口→目标IP:端口）在整个会话周期内未发生变化；

第四步：登录Redis，执行KEYS "user:*"，确认用户状态键只在一个机房的Redis分片中存在——若跨分片重复出现，说明状态同步逻辑有误，连接虽未丢，但数据已污染。