根本原因是Nginx默认轮询不保持会话，导致WebSocket帧被分发到不同后端；必须配置proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"三行透传升级头，否则握手失败或静默断连。
为什么 WebSocket 负载均衡后连接频繁断开
根本原因不是负载均衡本身，而是连接被轮询打到了不同后端实例——WebSocket 协议要求同一连接的所有帧必须路由到同一个服务进程，否则 onmessage 会收不到、close 帧可能被丢弃、甚至触发 1006 异常关闭。Nginx 默认轮询策略不保持会话，这是最常见误配点。
Nginx 配置必须加的三行 header
光写 proxy_pass 不够，缺少协议升级头会导致握手失败或连接被静默关闭。以下三行缺一不可：
-
proxy_http_version 1.1：强制 HTTP/1.1，否则无法维持长连接 -
proxy_set_header Upgrade $http_upgrade：透传客户端的Upgrade: websocket请求头 -
proxy_set_header Connection "upgrade"：告诉 Nginx 这不是普通 HTTP，要升为 WebSocket 连接
漏掉任意一行，都可能在日志里看到 400 Bad Request 或连接几秒后自动关闭。
ip_hash 和 sticky cookie 怎么选
两者都解决会话绑定，但适用场景差异大：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
ip_hash：简单有效，适合公网用户 IP 分散的场景；但局域网（如公司内网）所有用户共用一个出口 IP，会全部打到同一台后端，造成单点压力和故障无转移能力 -
sticky cookie：需 Nginx Plus 或第三方模块（如nginx-sticky-module-ng），通过 Set-Cookie 绑定后端，支持故障时自动漂移到其他节点；适合 Web 页面嵌入 WebSocket 的场景，比如聊天窗口，用户刷新页面后仍连原实例
如果你用的是开源版 Nginx，ip_hash 是唯一开箱即用的选择；别指望靠 hash $remote_addr 自定义，它和 ip_hash 行为不一致，且不处理 IPv6 兼容性问题。
健康检查不能只看 HTTP 状态码
WebSocket 后端可能 HTTP 接口返回 200 OK，但 WebSocket 握手已失败或消息通道卡死。纯 HTTP 健康检查会误判：
- 必须暴露专用的 WebSocket 健康端点，例如
/health/ws，由负载均衡器用真实 WS 客户端探活 - 检查项至少包括：能完成握手、能收发 ping/pong、响应时间
- Nginx 开源版不支持 WebSocket 健康检查，得用 HAProxy 或自研探测脚本 +
tcp_check
很多团队把健康检查做成定时 curl /health，结果后端 WebSocket 实例早挂了，HTTP 接口却还在返回 200，流量照常导入，用户全连不上——这是最容易被忽略的盲区。
