nginx代理websocket负载均衡的核心是正确透传协议升级头并实现连接级路由；必须配置proxy_http_version 1.1、proxy_set_header upgrade $http_upgrade、proxy_set_header connection "upgrade"，配合ip_hash/sticky cookie等会话保持策略及proxy_read_timeout 86400等超时调优。
Nginx 代理 WebSocket 实现多实例负载均衡，核心在于两点：正确透传协议升级请求，并确保同一客户端的整个长连接始终路由到同一个后端实例。这不是普通 HTTP 的“每次请求轮询”，而是基于连接生命周期的持久化分发。
必须配置的协议升级头
WebSocket 握手依赖 HTTP 协议升级机制，Nginx 必须把关键头部原样转发给后端，否则握手失败，连接无法建立：
- proxy_http_version 1.1：强制使用 HTTP/1.1，这是 Upgrade 机制的前提
- proxy_set_header Upgrade $http_upgrade：将客户端带的 Upgrade: websocket 头传递下去
- proxy_set_header Connection "upgrade"：显式声明连接需升级，不能写成 $connection_upgrade（除非你额外定义了 map）
连接级路由策略选型
为避免消息乱序或连接中断，必须让一个客户端的所有帧都落在同一台 acc-server 上。常用方案有：
- ip_hash：最简单直接，按客户端 IP 哈希固定后端。适合公网直连、IP 分布较均匀的场景
- sticky cookie：更健壮，通过 Set-Cookie 在首次响应中下发路由标识，后续请求携带该 Cookie 即可粘滞。适合存在 NAT 或 CDN 的环境
- hash $arg_token consistent：若客户端登录后携带唯一 token（如 JWT payload 中的 uid），可用此方式实现业务层会话绑定，解耦 IP 限制
超时与连接保持配置
WebSocket 是长连接，Nginx 默认的 60 秒空闲超时会主动断开连接，必须延长：
- proxy_read_timeout 86400：设置为 24 小时（或根据心跳周期略大于 ping 间隔），防止静默断连
- proxy_send_timeout 86400：同理，保障服务端主动推送不被中断
- upstream 中 keepalive 32：复用 Nginx 到后端的空闲连接，降低建连开销
后端状态协同不可少
仅靠 Nginx 粘滞还不够。当用户在 A 实例上线，消息却从 B 实例发出时，需依赖中间件完成跨节点路由：
- gowebsocket 使用 Redis 存储用户在线状态和所在节点信息
- 所有 acc-server 订阅统一 Redis 频道，收到消息后查表投递给本机连接
- 这样即使负载均衡把新连接分到任意节点，全局消息仍能准确触达
