websocket集群中会话粘滞的核心问题是连接状态无法跨节点共享，ip_hash通过客户端真实ip哈希实现请求路由固化，需配合real_ip_module还原源ip，并设置proxy_read_timeout、proxy_buffering off等参数；其局限性包括ipv6哈希不均、nat环境过载及故障无自动迁移，推荐cookie粘滞作为更健壮的替代方案。
WebSocket 集群中会话粘滞的核心问题，是连接状态无法跨节点共享。客户端一次握手建立的长连接，若后续帧被轮询分发到不同后端，就会因无上下文而断连。ip_hash 是 Nginx 提供的轻量级解决方案，它不依赖后端改造，靠客户端真实 IP 哈希实现请求路由固化。
ip_hash 的工作原理与适用前提
ip_hash 对客户端源 IP 地址做哈希运算，再根据哈希结果固定映射到某台后端服务器。只要 IP 不变，所有请求（包括 WebSocket 握手、ping/pong、数据帧）都会落在同一节点上。该机制天然适配 WebSocket 的“单连接、长存活”特性。
但要注意：它要求 Nginx 能获取到客户端真实 IP。如果前端有 CDN、云 WAF 或 NAT 网关，需配合 real_ip_module 和 set_real_ip_from 指令还原 IP，否则所有请求会被识别为同一个代理 IP，导致全部打到一台后端。
基础配置要点
ip_hash 必须写在 upstream 块内，且不能与 weight、backup 等指令共存。典型配置如下：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
upstream ws_backend {
ip_hash;
server 192.168.1.10:5000;
server 192.168.1.11:5000;
server 192.168.1.12:5000;
}
同时，在 server 块中需透传关键协议头并调大超时：
- 确保 Upgrade 和 Connection 头不被过滤（Nginx 默认已支持，但自定义 proxy_set_header 时需显式保留）
- 设置 proxy_read_timeout 3600 和 proxy_send_timeout 3600，避免空闲连接被主动关闭
- 禁用缓存：proxy_buffering off，防止 WebSocket 帧被缓冲或合并
局限性与应对建议
ip_hash 简单有效，但存在几个现实约束：
- IPv6 地址哈希可能不均，部分节点负载偏高
- 企业内网或移动网络下大量用户共用出口 IP，会造成单点过载
- 后端节点宕机时，对应 IP 段的哈希槽会失效，连接无法自动迁移
若业务已部署 CDN 或面向公网移动端用户，建议改用 Cookie 粘滞：后端在 WebSocket 握手成功后下发 route Cookie，Nginx 依据该 Cookie 做路由。这种方式不受 IP 变化影响，也兼容各种前置代理环境。
