Nginx upstream 支持 WebSocket 长连接负载均衡需三者协同：协议识别（透传 Upgrade 头、HTTP/1.1）、连接保持（keepalive、延长 proxy_read/send_timeout）、调度优化（least_conn、禁用默认健康检查）。
要让 Nginx 的 upstream 真正支持 WebSocket 长连接集群负载均衡，不能只靠简单转发，关键在于协议识别、连接保持和后端调度策略三者协同。核心不是“能不能转”，而是“转完之后连接不中断、不误判、不漂移”。
必须启用的 HTTP/1.1 升级机制
WebSocket 握手本质是一次 HTTP 请求升级（Upgrade: websocket），Nginx 必须在代理过程中完整透传并响应这个过程：
-
proxy_http_version 1.1：强制使用 HTTP/1.1，这是 Upgrade 机制的前提 -
proxy_set_header Upgrade $http_upgrade：把客户端带的Upgrade头原样传给后端 -
proxy_set_header Connection $connection_upgrade：配合map指令动态设置，避免硬写"upgrade"导致非 WebSocket 请求异常
推荐写法（更健壮）：
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream 层需适配长连接特性
普通 HTTP 负载均衡的短连接模型不适用于 WebSocket，需针对性优化：
- 用
least_conn替代默认轮询：WebSocket 连接生命周期长，按当前活跃连接数分发，防止单节点堆积过多长连接 - 慎用
ip_hash：虽能会话保持，但局域网出口 IP 相同会导致流量倾斜，且后端宕机时无法自动迁移连接 - 配置
keepalive 32（或更高）：维持与每个后端服务器的空闲长连接池，减少重复建连开销 - 禁用
max_fails/fail_timeout的默认健康检查：HTTP GET 检查无法反映 WebSocket 服务真实可用性，建议改用 TCP 层探测或自定义 health_check
超时设置必须匹配业务实际连接时长
WebSocket 不是“请求-响应”模式，Nginx 默认 60 秒超时会直接断连。需大幅延长：
-
proxy_read_timeout 86400（24 小时）：客户端长时间无数据时，Nginx 保持连接不主动关闭 -
proxy_send_timeout 86400：后端响应慢或网络延迟高时，避免发送卡住被中断 -
proxy_connect_timeout 30：仅控制初始建连阶段，保持合理即可，无需设过长
注意：这些值不是越大越好，应略大于你业务中最大预期空闲时长，并结合监控（如 nginx_stub_status 或 Prometheus）动态调优。
安全与生产就绪补充项
上线前建议补全以下细节：
- SSL 终止：若走 WSS，
server块需监听443 ssl，并正确配置证书；后端可走 HTTP（简化）或 HTTPS（端到端加密） - Origin 校验：后端常校验
Origin头防跨站滥用，Nginx 可加proxy_set_header Origin ""清空或透传可信来源 - 日志标记：在
log_format中加入$http_upgrade和$connection_upgrade，便于区分 WebSocket 流量做分析 - 限流防护：对
/ws/路径单独配置limit_req，防握手洪泛攻击
