nginx能做websocket负载均衡，但必须配置proxy_http_version 1.1、upgrade/connection头透传、proxy_read_timeout与proxy_send_timeout延长至86400、禁用缓冲，并依后端状态选择ip_hash或least_conn算法。
直接上结论：Nginx 能做 WebSocket 负载均衡，但前端必须配合「固定连接路径 + 重连策略」，否则连接会随机漂移、消息丢失、甚至触发重连风暴。
为什么 proxy_pass 后 WebSocket 连接会断开或路由错乱
Nginx 默认把每个新请求当作独立 HTTP 请求处理。WebSocket 握手虽是 HTTP 请求，但后续是长连接；若没显式告诉 Nginx “这是要升级的”，它就会按普通 HTTP 代理转发，然后在超时后主动关闭 TCP 连接。
-
proxy_http_version 1.1缺失 → 后端拒绝升级，返回 400 或直接关闭 -
Upgrade和Connection头没透传 → 握手失败，浏览器报ERR_CONNECTION_REFUSED或卡在 pending - 没设
proxy_read_timeout→ 空闲 60 秒（默认值）后 Nginx 断连，前端看到close event且event.code === 1006
nginx.conf 必须写的 5 个关键配置项
这些不是可选优化，而是 WebSocket 能跑通的底线。漏一个，连接就不可靠。
-
proxy_http_version 1.1：强制走 HTTP/1.1，否则不支持Connection: upgrade -
proxy_set_header Upgrade $http_upgrade：把客户端带的Upgrade: websocket原样传给后端 -
proxy_set_header Connection "upgrade"：注意是硬编码字符串"upgrade"，不是$http_connection（后者可能为空） -
proxy_read_timeout 86400：单位是秒，建议设为 24 小时（86400），避免空闲断连；别用7d这种写法，部分旧版 Nginx 不识别 -
proxy_send_timeout 86400：和服务端发心跳或延迟推送有关，和read对齐更稳妥
upstream 里要不要加 ip_hash？看你的后端是否共享状态
如果后端节点之间**不共享用户连接状态**（比如没用 Redis 存 session 或 connection map），那必须开启会话保持，否则用户发消息时可能被转到没它连接记录的机器上，导致消息发不出。
- 用
ip_hash：简单，但客户端 IP 变化（如走 NAT、移动网络切换）会导致连接重置 - 用
hash $http_sec_websocket_key consistent：更稳定，基于 WebSocket 握手里的唯一 key 做一致性哈希，推荐 - 不用任何 hash，改用
least_conn：仅当后端有全局状态同步机制（如 gowebsocket + Redis）才安全
前端 JavaScript 怎么配合才不掉线
Nginx 层无法解决所有问题。前端必须主动应对连接漂移和瞬时中断。
- WebSocket URL 里**不要拼随机参数**（如
?t=123），否则每次重连都算新连接，Nginx 可能分到不同后端 - 重连逻辑要加退避（backoff）：第一次 1s，失败后 2s、4s、8s… 避免瞬间几千连接打爆某台 backend
- 发消息前检查
ws.readyState === WebSocket.OPEN，别假定连接一直活着 - 服务端下发消息时带上
msg_id，前端收到后存 localStorage，重连后主动拉取未确认消息（补偿机制）
最易被忽略的一点：Nginx 的 proxy_buffering off 在 WebSocket 场景下几乎无用——它只影响 HTTP 响应体缓存，而 WebSocket 数据走的是原始 TCP 流，不受该指令控制。别在这上面浪费调试时间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
