Nginx中WebSocket代理多节点同步与广播支持-Nginx-PHP中文网

nginx 默认不支持 websocket 跨节点广播与状态同步，需应用层实现；须配置会话保持（ip_hash 或 sticky cookie）避免连接漂移；广播依赖消息中间件或分布式存储；需全链路保活并协同处理连接生命周期。

nginx中websocket代理多节点同步与广播支持

WebSocket 在 Nginx 中默认不支持跨节点广播或状态同步，因为 Nginx 本身是无状态的反向代理，不维护 WebSocket 连接的会话上下文，更不具备消息路由、集群通信或广播能力。要实现多节点 WebSocket 的同步与广播，必须在应用层（后端服务）配合实现，Nginx 仅负责连接转发和负载均衡。

WebSocket 连接需保持长连接粘性

Nginx 默认使用轮询等策略分发请求，但 WebSocket 升级后若被调度到不同后端节点，会导致消息丢失或连接中断。解决方法是启用 ip_hash 或基于 cookie 的会话保持：

使用 ip_hash：确保同一客户端 IP 始终落在同一后端节点（适合公网 IP 较稳定场景）
使用 sticky cookie（Nginx Plus 或 OpenResty）：通过 set_cookie 标记节点 ID，后续请求携带该 cookie 路由到对应实例
避免用 least_conn 或纯轮询，否则连接易漂移

广播逻辑必须由业务服务自行实现

Nginx 不提供消息广播功能。若需向所有在线客户端（跨多个后端节点）推送消息，需构建独立的消息分发机制：

引入消息中间件（如 Redis Pub/Sub、Kafka、RabbitMQ），各节点订阅统一频道，收到消息后各自推送给本节点所管理的 WebSocket 连接
使用分布式状态存储（如 Redis + 连接元数据），记录每个连接所属节点及用户标识，广播时先查连接归属，再向对应节点发起内部 RPC 或 HTTP 通知
避免“节点间直连广播”——不推荐让节点互相调用接口推送，易引发环路、超时或雪崩

健康检查与连接生命周期需协同处理

WebSocket 连接长期空闲时，Nginx 或中间网络设备可能主动断连（如默认 60s timeout）。需全链路协同保活：

在 Nginx 配置中显式延长超时：proxy_read_timeout 3600、proxy_send_timeout 3600、proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade 等不可遗漏
后端服务需发送 ping/pong 帧（如每 30s 一次），既维持连接，也用于探测客户端存活
断连事件必须及时上报至共享存储（如 Redis），其他节点广播时跳过已失效连接