nginx代理websocket需透传upgrade/connection头、关闭缓冲并调大超时、避开缓存与cors陷阱：设proxy_http_version 1.1；proxy_set_header upgrade $http_upgrade；connection "upgrade"；proxy_buffering off；proxy_{read,send}_timeout 86400；tcp_nodelay on；禁用proxy_cache和add_header cors。
必须透传升级头，握手才能成功
WebSocket 握手依赖两个逐跳 HTTP 头：`Upgrade` 和 `Connection`。Nginx 默认丢弃它们，必须显式处理：• proxy_http_version 1.1; —— HTTP/1.0 不支持 Upgrade，缺了这句，握手直接失败
• proxy_set_header Upgrade $http_upgrade; —— 用变量转发原始值，兼容 WebSocket、STOMP、MQTT 等多种升级场景
• proxy_set_header Connection "upgrade"; —— 必须写死为字符串 "upgrade"，不能用 $http_connection（它可能带 keep-alive，导致后端收不到升级信号）
关闭缓冲与调大超时，维持长连接稳定
WebSocket 是全双工长连接，而 Nginx 默认按短连接逻辑处理，容易静默断连：• proxy_buffering off; —— 防止后端发送的多个 TEXT/BINARY 帧被缓存合并，造成粘包或延迟
• proxy_read_timeout 86400; —— 设为 24 小时，避免空闲期间 Nginx 主动关闭连接（默认仅 60 秒）
• proxy_send_timeout 86400; —— 同步调大，确保服务端心跳或大数据分片能完整发出
• tcp_nodelay on; —— 绕过 Nagle 算法，小帧（如光标移动、按键事件）立即送达
避开常见陷阱，避免“看着正常实则脆弱”
很多配置看似合理，却会导致连接不可靠甚至握手失败：• 不用 add_header Access-Control-Allow-Origin "*" —— CORS 头应由后端在 101 响应中返回，Nginx 加了反而可能覆盖或引发跨域异常
• 不启用任何 proxy_cache_* 指令 —— WebSocket 消息不可缓存，启用会直接导致连接失败
• 不设 proxy_set_header Connection $http_connection —— 客户端 Connection 值常含多个字段（如 "Upgrade, keep-alive"），Nginx 清理后只剩 keep-alive，后端无法识别升级意图
• 推荐配合 map 指令做安全兜底：map $http_upgrade $connection_upgrade { default upgrade; "" close; }
再在 location 中写 proxy_set_header Connection $connection_upgrade;，更严谨地处理空 Upgrade 头场景
