nginx代理websocket需精准匹配其长连接、全双工特性，核心是协议透传（proxy_http_version 1.1、proxy_set_header upgrade $http_upgrade、connection "upgrade"）、连接池与tcp keepalive（upstream keepalive 32、proxy_socket_keepalive on）、超时调优（proxy_read_timeout等设为长值）及会话粘性（ip_hash或sticky cookie）。
要让 Nginx 代理 WebSocket 时通信更高效，关键不是堆参数，而是精准匹配 WebSocket 的长连接、全双工、低开销特性。重点在协议透传、连接保持和超时管理三方面。
确保协议升级头正确透传
WebSocket 握手依赖 Upgrade: websocket 和 Connection: upgrade 这两个请求头。Nginx 默认会过滤掉它们，必须显式转发：
-
proxy_http_version 1.1：强制使用 HTTP/1.1，这是 Upgrade 机制的前提 -
proxy_set_header Upgrade $http_upgrade：把客户端原始的 Upgrade 头原样传给后端 -
proxy_set_header Connection "upgrade"：固定写死为"upgrade"，不能用变量，否则可能被误判为普通连接
启用后端连接池与 TCP keepalive
避免每次新帧都重建 TCP 连接，减少握手和慢启动开销：
- 在
upstream块中加keepalive 32：维持最多 32 个空闲长连接供复用 - 在
location块中加proxy_socket_keepalive on：启用底层 TCP 的 keepalive 探测，防止中间网络设备（如 NAT、防火墙）静默断连 - 配合
keepalive_timeout（在 upstream 或 server 级别）控制后端连接空闲存活时间
合理设置超时参数，避免假断连
WebSocket 是长连接，但 Nginx 默认 60 秒超时会主动关闭空闲连接，导致心跳失败或消息丢失：
-
proxy_read_timeout：设为业务最大空闲间隔（例如 86400 表示 24 小时），决定 Nginx 等待后端响应的最长时间 -
proxy_send_timeout：同样建议设长，尤其当后端批量推送数据时 -
proxy_connect_timeout：可保持默认 60 秒，它只影响初始建连阶段
负载均衡时保证会话粘性
WebSocket 连接建立后，所有后续帧必须路由到同一台后端节点，否则协议中断：
- 用
ip_hash最简单可靠，适合客户端 IP 相对稳定场景 - 若需更精细控制（如移动端 IP 频繁变化），可用
sticky cookie或基于 token 的 session 粘滞 - 避免使用轮询（
round-robin）或最少连接（least_conn），它们不适用于长连接路由
