Nginx如何实现WebSocket协议下的负载均衡连接持久化策略？

本文共计895个文字，预计阅读时间需要4分钟。

为了让Nginx正确配置WebSocket和负载均衡，关键不在于开启某个功能，而在于确保连接从握手到持续全程不被中断、不被错分——核心在于连接的保持（session stickiness）。默认轮询请求会将同一客户端的后续请求分发到不同的后端服务器，导致状态丢失、认证失效，甚至消息乱序。

为什么必须做连接保持

WebSocket 是单次握手、长期存活的 TCP 连接，所有后续数据帧都复用该连接。后端服务（如 Swoole、Netty、gowebsocket）通常将用户会话、心跳状态、内存 Session 存在本地，不跨节点共享。若 Nginx 把重连请求或 ping 帧路由到新节点，后端无法识别该连接，直接拒绝或丢弃消息。

• 轮询（round-robin）会导致连接“漂移”，首次连 A，第二次 ping 到 B，B 无上下文 → 断连
• IP 哈希在 CDN 或 NAT 后失效（所有用户 IP 相同）
• 没有连接保持时，哪怕配置了超时和头部，也只解决“断连”问题，不解决“错连”问题

推荐的三种连接保持方式

根据部署环境选择最稳妥的一种：

• ip_hash（简单场景首选）：适用于客户端直连 Nginx、无前置代理的内网或可信公网环境。Nginx 对 client IP 做哈希，固定映射到某台后端。配置简洁，无需后端配合。
• Cookie 粘滞（生产推荐）：后端在 WebSocket 握手成功后，通过 HTTP 响应头 Set-Cookie: ws_route=server-02; Path=/; HttpOnly; SameSite=Lax；Nginx 配置 sticky cookie ws_route expires=1h domain=.example.com path=/;，后续所有 /ws/ 请求自动带该 Cookie 并路由到对应节点。兼容 CDN、移动端、动态 IP 场景。
• 自定义 Header + hash 指令（高阶控制）：后端在握手响应中注入唯一标识（如 X-WS-Node: node-a），Nginx 使用 map 提取并 hash：map $upstream_http_x_ws_node $backend_node { ~^(.+)$ $1; }，再 proxy_pass http://backend_pool/$backend_node; 需配合 upstream 的 hash $backend_node;

配套必须启用的基础配置

连接保持只是路由逻辑，还需底层参数协同，否则仍会超时断开：

• 强制 HTTP/1.1：proxy_http_version 1.1;（WebSocket 升级机制依赖）
• 透传升级头：proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection $connection_upgrade;（配合 map 预处理更健壮）
• 延长空闲超时：proxy_read_timeout 86400; 与 proxy_send_timeout 86400;（必须显式设置，不能依赖默认 60 秒）
• 禁用缓存与缓冲：proxy_buffering off;、proxy_cache off;（WebSocket 是流式二进制帧，缓存会破坏协议）

验证连接是否真正保持

上线前务必实测验证，避免“配置写了但没生效”：

• 用 wscat 或浏览器 console 连接，观察 Nginx access log 中 $upstream_addr 字段是否始终为同一 IP:PORT
• 在后端服务中打印连接 ID + 所在节点名，对比多次 ping/pong 是否始终落在同一进程
• 模拟客户端断网重连：等待 2 分钟后再发消息，确认是否回到原节点（而非轮询到新节点）