Google Cloud Platform负载均衡器WebSocket连接数秒后断开求助

嘿，这个问题我太熟了！之前帮团队排查过几乎一模一样的场景——两台GCE服务器配了负载均衡后，Socket.io的WebSocket连接总是几秒就断开，单节点跑完全正常，核心就是负载均衡的几个关键配置没跟上，给你梳理下具体要改的点：

1. 必须配置会话亲和性（Session Affinity） #

Socket.io的连接完全依赖持久化的会话绑定：握手阶段的HTTP请求和后续的WebSocket帧必须发到同一台后端服务器。如果负载均衡把同一个用户的请求打散到不同节点，连接直接就断了。

• 打开GCP控制台找到你的HTTP(S)负载均衡器
• 编辑对应的后端服务（Backend Service），找到「会话亲和性」设置项
• 选择Cookie-based affinity（基于Cookie的亲和性），超时时间建议设成至少30分钟（要覆盖Socket.io默认的心跳周期）
• 保存后等个几分钟让配置生效

2. 调整负载均衡的超时阈值 #

GCP负载均衡默认的HTTP超时设置太短，根本扛不住WebSocket的长连接：

• 还是在后端服务的配置页，找到「超时设置」
• 把连接超时（Connection timeout）改成至少600秒（10分钟），或者根据你的业务需求再拉长
• 同时把空闲超时（Idle timeout）设成和连接超时一样的值，避免负载均衡因为连接暂时没数据就主动断开

3. 适配Socket.io的健康检查配置 #

默认的HTTP健康检查可能会误判后端状态，甚至干扰Socket.io的连接：

• 编辑后端服务的健康检查规则
• 如果你的Socket.io服务跑在/socket.io路径，把健康检查路径改成/socket.io/?EIO=3&transport=polling（模拟Socket.io的轮询握手请求，确保健康检查能正确识别服务状态）
• 调整健康检查的间隔和失败阈值，别太频繁，不然可能会打断正常连接

4. 后端Socket.io的配套确认 #

虽然单节点没问题，但配合负载均衡还是要确认下：

• 确保Socket.io显式配置了transports: ['websocket', 'polling']（默认是开的，但显式写出来更稳妥）
• 如果用了自定义Cookie名称，要保证负载均衡的Cookie亲和性能识别这个Cookie
• 后端服务器的连接超时设置要和负载均衡对齐，别自己搞个更短的超时

验证方法 #

改完配置后可以这么验证：

• 用浏览器开发者工具看Network面板的WebSocket连接，确认建立后不会在几秒内断开
• 查负载均衡的日志，确认同一个用户的所有请求都落到了同一台后端服务器
• 模拟长时间在线场景，比如挂着不动半小时，看连接能不能稳定保持到主动断开

补充：如果用的是TCP负载均衡而非HTTP(S)的，逻辑类似——开启基于IP的会话亲和性，同时调长TCP连接的超时时间就行。

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