Keepalived 仅管理 VIP 漂移和节点健康，不处理 WebSocket 流量；需与 Nginx 等七层代理协同，配置 WebSocket 升级头、长超时、脚本化健康检查（检测 HTTP 101）、内核调优及后端会话一致性机制。
Keepalived 本身不处理 WebSocket 流量，它只负责 VIP（虚拟 IP）的漂移和节点健康状态管理。要构建高可用的 WebSocket 代理网关集群，必须将 Keepalived 与能正确代理长连接的七层代理（如 Nginx、HAProxy 或自研网关）协同使用，并在协议层、连接保持、会话粘性等关键环节做针对性配置。
以下是从生产实践出发的核心要点：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
确保代理层原生支持 WebSocket 长连接
Nginx 是最常用且成熟的选择，需显式启用 WebSocket 协议升级机制：
- 在
location块中添加标准 WebSocket 头部透传：proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr;
- 关闭代理超时（避免连接被意外中断）：
proxy_read_timeout 86400; proxy_send_timeout 86400; proxy_buffering off;
- 禁用
proxy_redirect和缓冲区压缩，防止帧篡改或延迟。
Keepalived 配置必须绑定服务存活而非仅进程存在
仅检测 nginx 进程是否运行是不够的——进程可能卡死、端口未响应、或 WebSocket upgrade 失败。应使用脚本级健康检查：
- 编写检测脚本（如
/etc/keepalived/chk_ws.sh），通过curl -I -s -o /dev/null -w "%{http_code}" http://127.0.0.1:80/ws-test检查实际 WebSocket 升级响应（HTTP 101）； - 若返回非
101，脚本退出非零码，触发 Keepalived 降低优先级或释放 VIP； - 在
keepalived.conf中引用：vrrp_script chk_ws { script "/etc/keepalived/chk_ws.sh" interval 3 weight -20 }
网络与内核层面规避连接中断
WebSocket 长连接对网络稳定性极度敏感：
- 关闭两台 Keepalived 节点上的
iptables或明确放行 VRRP 协议（IP 协议号 112）； - 调整内核参数防止 TIME_WAIT 泛滥影响新连接：
net.ipv4.tcp_tw_reuse = 1 net.ipv4.ip_local_port_range = 1024 65535 net.core.somaxconn = 65535
- 若部署在云环境（如阿里云、腾讯云），禁用组播，改用单播通信并配置
unicast_src_ip和unicast_peer，避免因云平台组播限制导致脑裂。
后端 Real Server 需保持连接上下文一致性
WebSocket 连接有状态，若后端是无状态服务（如多个独立 Node.js 实例），必须引入外部会话协调机制：
- 使用 Redis 存储连接元数据（如 client ID → node ID 映射），配合消息总线（如 Redis Pub/Sub）广播事件；
- 或采用 sticky session（IP hash / cookie），但注意：Nginx 的
ip_hash对 WebSocket 有效，而hash $cookie_jsessionid类方式需客户端主动携带 cookie； - 不推荐依赖源 IP 哈希——经 LVS-DR 或云 LB 后源 IP 可能被替换，应优先基于业务标识（如 token、user_id）做路由。
不复杂但容易忽略。
