WebSocket经Nginx代理延迟的本质是Nginx默认按短连接处理长连接，需从代理配置（关闭proxy_buffering、设proxy_read_timeout/proxy_send_timeout为86400、透传Upgrade/Connection头）、后端行为（避免onOpen同步阻塞、启用心跳）和前端协同（启用binaryType、节流）三方面协同优化。
WebSocket 经 Nginx 代理后出现延迟，本质不是网络慢，而是 Nginx 默认按短连接逻辑处理长连接，导致消息积压、心跳中断或协议升级失败。优化需聚焦代理配置、后端行为和前端协同三个层面，缺一不可。
关闭缓冲与延长超时时间
Nginx 默认启用响应缓冲和 60 秒读超时，是延迟最常见根源：
-
必须关闭 proxy_buffering：在对应 location 块中添加
proxy_buffering off;，否则流式消息会滞留在 Nginx 缓冲区，直到填满才下发； -
设足够长的 proxy_read_timeout：建议设为
proxy_read_timeout 86400;（24 小时），避免空闲连接被误杀； -
同步设置 proxy_send_timeout：同样设为
86400;，防止大消息发送中途断连； -
禁用默认缓冲区限制：如使用 Nginx Proxy Manager，可调大
proxy_buffer_size 16k;、proxy_buffers 8 16k;和proxy_busy_buffers_size 32k;，缓解高频小包拥塞。
确保协议升级正确完成
若 Upgrade 头未透传，连接根本没升为 WebSocket，后续所有优化都无效：
-
必须显式传递两个关键头：
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";，缺一不可； -
强制使用 HTTP/1.1：
proxy_http_version 1.1;是 WebSocket 升级的前提； -
验证是否成功升级：用 curl 检查返回是否含
HTTP/1.1 101 Switching Protocols，浏览器 Network 面板确认状态为WS而非Pending或反复重连。
稳定连接并减少处理开销
连接看似通了，但频繁断开或首帧卡顿，往往来自心跳、后端阻塞或前端负载：
-
后端主动发 ping / 客户端及时 pong：心跳间隔须严格小于
proxy_read_timeout（如设 30 秒），单向心跳无法防超时； - 避免 onOpen 内同步操作：查数据库、读文件、同步 HTTP 请求都会阻塞事件循环，应改用协程（Swoole）、异步驱动（Uvicorn + async DB）或丢入后台任务；
-
启用 tcp_nodelay：在 location 块中加
tcp_nodelay on;，但仅对已升级的长连接生效——前提是上述 Upgrade 头和超时配置已到位； -
前端启用二进制帧与节流：设
ws.binaryType = 'arraybuffer'降低序列化成本；每秒推送消息超过 20 条时，需在前端做合并、采样或 requestIdleCallback 调度，避免主线程卡死。
规避外部干扰因素
有些“延迟”其实来自链路之外：
- 慎用 CDN 或托管型 SLB：Cloudflare 免费版强制 100 秒断连，阿里云 SLB 的 WebSocket 超时不可调，建议直连或换 ALB；
-
跨运营商线路问题：电信用户访问联通机房服务，RTT 可能翻倍。前端应预置多 endpoint（如
wss://ws-telcom.example.com），通过 HEAD 请求测速后自动选择最优地址； - 延迟初始化 WebSocket：不要在页面加载时立即 new WebSocket()，改为用户触发（如点击按钮）或 setTimeout 延后 2 秒，避开首屏渲染关键路径。
