Nginx实现多实例WebSocket高可用代理需满足三点：透传协议升级（proxy_http_version 1.1、Upgrade $http_upgrade、Connection "upgrade"）、稳定连接路由（ip_hash/cookie/token哈希）及适配长连接超时与缓冲（proxy_read_timeout、keepalive、禁用buffering）。
要在 Linux 上用 Nginx 实现多实例 WebSocket 的高可用代理，关键不是堆机器，而是让连接不乱、不断、不丢消息。核心就三点：协议升级必须透传、连接路由必须稳定、超时和缓冲必须适配长连接特性。
必须写对的三行握手头配置
WebSocket 握手失败（返回 200/400/502 而非 101）90% 是这三行没配或配错位置：
- proxy_http_version 1.1：HTTP/1.0 不支持 Upgrade，缺了它 Nginx 会静默降级转发
- proxy_set_header Upgrade $http_upgrade：必须用变量，硬写 "websocket" 会卡住带 h2c 或 custom upgrade 值的客户端
- proxy_set_header Connection "upgrade"：必须是字符串 "upgrade"，不能是 $http_connection（通常是 keep-alive）或 add_header（那是响应头，无效）
这三行必须放在 location 块内，写在 server 或 http 块顶层不生效。
连接级路由：让同一个用户始终落在同一台后端
WebSocket 是长连接，不是每次请求轮询。一个用户连上来后发几十条消息，必须全落到同一台 acc-server，否则消息乱序、状态不同步、掉线重连频繁。
- ip_hash：最简方案，按客户端 IP 哈希固定后端。适合直连、IP 分布较均匀的场景；但有 NAT 或 CDN 时可能把大量用户压到一台机器
- sticky cookie：Nginx Plus 支持，开源版需配合 lua-nginx-module + Set-Cookie 头实现。首次响应下发 route_id，后续请求带 Cookie 即可粘滞，更健壮
- hash $arg_token consistent：若前端登录后携带唯一 token（如 JWT 中的 uid），直接哈希 token，业务层解耦 IP 限制，推荐用于 App 或已鉴权 Web 场景
超时与连接保持：防止“静默断连”
Nginx 默认 proxy_read_timeout=60 秒，只要后端 60 秒没发数据，它就主动关 TCP 连接——前端只看到“突然掉线”，毫无报错提示。
- proxy_read_timeout 86400：设为 24 小时最稳妥；若后端有心跳（如每 30 秒 ping），至少设为 ≥ 心跳间隔 × 3
- proxy_send_timeout 86400：保障服务端推送大消息或延迟响应时不被中断
- upstream 中 keepalive 32：复用 Nginx 到后端的空闲连接，降低建连开销，避免 TIME_WAIT 暴涨
- 禁用缓冲：proxy_buffering off 和 proxy_cache off，防止帧被攒包，影响实时性
WSS 和后端协同：别只靠 Nginx 粘滞
即使路由稳了，用户 A 在实例 1 登录，系统要给 A 推送消息时，请求可能打到实例 2 —— 单靠 Nginx 无法解决跨节点消息投递。
- WSS 必须配 listen 443 ssl，证书域名匹配，否则连接卡在 TLS 层，根本进不了 HTTP 升级阶段
- 后端需接入共享中间件：比如用 Redis 存用户在线状态+所在节点，所有 acc-server 订阅统一频道，收到消息后查表再投递给本机连接
- 加 proxy_set_header X-Forwarded-Proto $scheme 和 X-Real-IP，避免后端因协议误判生成 http 链接或重定向循环
