WebSocket经Nginx代理延迟的核心原因是Nginx默认按短连接处理长连接，导致缓冲积压、超时中断、协议升级失败及Nagle算法攒包；须协同优化Nginx配置（proxy_buffering off、proxy_read_timeout 86400、透传Upgrade/Connection头、tcp_nodelay on）、后端onOpen去同步阻塞、传输层启用permessage-deflate压缩与二进制帧。
WebSocket 经 Nginx 代理后出现消息延迟，核心原因不是网络带宽或物理距离，而是 Nginx 默认按短连接逻辑处理长连接——缓冲积压、超时中断、协议升级失败、小包合并等环节都会把毫秒级的实时性拖成秒级卡顿。优化必须从配置、后端、传输三端协同，单改一处往往无效。
确保 WebSocket 升级握手成功
握手失败会导致连接降级为轮询或直接断开，看似“延迟”，实为反复重连：
- location 块中必须显式设置 proxy_http_version 1.1，WebSocket 升级仅支持 HTTP/1.1
- 透传两个关键头：proxy_set_header Upgrade $http_upgrade 和 proxy_set_header Connection "upgrade"，缺一不可
- 建议加校验逻辑：用 if ($http_upgrade != "websocket") { return 403; } 拒绝非法请求，避免静默转发干扰
- 用 curl 验证：运行 curl -i -H "Connection: Upgrade" -H "Upgrade: websocket" http://your-domain/ws，响应中必须含 101 Switching Protocols
关闭缓冲与延长超时周期
Nginx 默认缓冲和短超时是延迟最隐蔽的推手：
- 必须设 proxy_buffering off：否则服务端推送的流式消息会卡在 Nginx 缓冲区，直到凑满才下发
- proxy_read_timeout 和 proxy_send_timeout 均设为 86400（24 小时），防止空闲连接被误杀；设为 0 在部分旧版 Nginx 不生效，不推荐
- 禁用 proxy_cache、proxy_redirect 等与缓存/重定向相关的指令，WebSocket 场景完全不需要
启用 TCP_NODELAY 并同步关闭 Nagle 算法
小消息（如心跳、状态更新）若被 Nagle 算法攒包，延迟立刻上升几十毫秒：
- 在 location 中添加 tcp_nodelay on，但注意：它只对已升级成功的 WebSocket 连接生效
- 后端 socket 必须同步关闭 Nagle：Node.js 调
socket.setNoDelay(true)；Java Netty 使用channel.config().setOption(ChannelOption.TCP_NODELAY, true) - 客户端也需配合：浏览器 WebSocket 自动处理，但原生 TCP 客户端（如移动端）需手动设置
- 用 ss -i dst your-server-ip:port 查连接，输出含 nodelay 才算真正启用
规避后端与链路层瓶颈
即使 Nginx 配置完美，后端阻塞或网络选线不当仍会导致首帧延迟飙升：
- onOpen 回调里禁止任何同步操作：MySQL 查询、Redis 同步读、文件 I/O 等都会卡住事件循环；应改用协程、异步驱动或丢进独立线程池
- 多节点部署时开启粘性会话（sticky cookie 或 ip_hash），避免消息因路由漂移而丢失或乱序
- 跨运营商场景下，前端不要只写一个 wss 地址；预置电信/联通/移动专线 endpoint，用 fetch + performance.now() 测速择优连接
- 启用 permessage-deflate 压缩（尤其 JSON 类文本），减少传输体积；后端发送改用 binaryType = 'arraybuffer'，降低序列化开销
