nginx高效代理websocket需精准适配其长连接特性：透传upgrade/connection头、启用http/1.1、动态设置connection_upgrade、调高proxy_read/send_timeout、upstream启用keepalive、负载均衡用ip_hash或sticky cookie、禁用proxy_buffering并精简头部。
要让 Nginx 高效处理 WebSocket 代理，核心不是“加功能”，而是精准适配其长连接、协议升级和状态敏感的特性。默认配置按短连接 HTTP 设计，直接代理 WebSocket 必然低效甚至失败。
确保协议升级头正确透传
WebSocket 握手依赖两个关键请求头：Upgrade 和 Connection。Nginx 默认会丢弃或覆盖它们，必须显式保留：
-
启用 HTTP/1.1：WebSocket 升级机制只在 HTTP/1.1 中定义，必须写
proxy_http_version 1.1; -
动态传递 Upgrade 头：用
map指令做条件映射，避免 if 性能损耗：map $http_upgrade $connection_upgrade { default upgrade; '' close; } -
设置 Connection 头为变量值：配合上面的 map，写
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection $connection_upgrade;，而非硬编码"upgrade"——这样空 Upgrade 时自动设为 close，兼容普通 HTTP 请求
延长超时并保持连接活跃
WebSocket 是长连接，Nginx 默认 60 秒超时会主动断开空闲连接，导致频繁重连：
-
调高读写超时：如
proxy_read_timeout 86400;（24 小时），proxy_send_timeout 86400;，数值按业务最长静默期设定 -
避免 connect 超时过短：握手阶段需预留足够时间，
proxy_connect_timeout 60;通常够用，高延迟网络可略增 -
后端 keepalive 复用连接：在 upstream 块中加
keepalive 32;，减少与后端建连开销
实现连接级负载均衡
WebSocket 连接有状态，不能像 HTTP 请求那样随意轮询分发：
- 优先用 ip_hash：简单可靠，同一客户端 IP 始终路由到同一后端节点
-
更灵活选 sticky cookie：适用于多域名或移动端 IP 变动场景，例如
sticky cookie srv_id expires=1h domain=.example.com path=/; - 禁用健康检查干扰：默认被动健康检查可能误判长连接为异常，建议关闭或调宽阈值
精简头部与安全透传
减少冗余转发，同时保障必要上下文不丢失：
-
只传必要头：除 Upgrade/Connection 外，至少保留
X-Real-IP、X-Forwarded-For、Host，便于后端日志和权限控制 -
禁用 proxy_buffering：WebSocket 数据帧需实时透传，设
proxy_buffering off;避免缓存阻塞 -
HTTPS 场景下 SSL 终结合理：Nginx 做 TLS 卸载，后端走 HTTP，既减压又统一证书管理；若后端需原始加密流量，则用
proxy_ssl_*系列指令透传
