要降低Nginx代理下WebSocket延迟，必须配对启用三项基础设置：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade与Connection "upgrade"、proxy_buffering off；再结合tcp_nodelay on、延长超时、双向心跳、粘性会话及应用层优化。
要降低 Nginx 代理下 WebSocket 的数据传输延迟，关键不是调快某一个参数，而是让整个链路真正“跑在长连接上”，并消除中间环节对小包、实时帧的干扰。核心在于打破 Nginx 默认按短连接处理的惯性，让 TCP 层、HTTP 层、应用层协同释放实时性。
必须配对的三项基础代理设置
缺一不可，否则后续所有优化都无效：
-
启用 HTTP/1.1 协议升级：在 location 块中写
proxy_http_version 1.1;，WebSocket 握手依赖此版本的 Upgrade 机制； -
透传协议升级头：必须同时设置
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";，否则 Nginx 会丢弃 Upgrade 请求，降级为普通 HTTP； -
关闭响应缓冲：添加
proxy_buffering off;，避免 JSON 消息或二进制帧卡在 Nginx 缓冲区，等凑满才发，造成几十毫秒到数秒不等的积压延迟。
针对小包攒发的 TCP 层优化
高频心跳、行情更新、控制指令这类几十字节的消息，最容易被 Nagle 算法拖慢。此时 tcp_nodelay on; 才真正起效：
- 仅在 WebSocket 路径（如
location /ws { ... }）内启用，不全局开； - 需确保连接已完成升级且保持活跃——
proxy_read_timeout至少设为 65 秒（建议 86400），配合后端每 30 秒发一次 ping； - 同步关闭
tcp_nopush off;，防止零拷贝机制反而延迟小包发送。
防止连接中断带来的“伪延迟”
用户感知的“延迟高”，很多时候其实是连接反复断开重连。Nginx 主动杀掉“静默”连接是主因：
- 延长超时时间：
proxy_read_timeout 86400;（24 小时），keepalive_timeout 65s;； - 后端必须主动发 ping 帧，客户端及时回 pong，形成双向心跳；
- 多节点部署时启用粘性会话，例如
upstream块中用ip_hash;或sticky cookie，避免消息跨节点丢失或路由错乱。
减少应用层和传输层额外开销
即使链路通畅，低效处理仍会拖慢端到端：
- 启用
permessage-deflateWebSocket 扩展压缩文本类消息（如 JSON 行情），减小带宽占用与解析耗时； - 前端用
binaryType = 'arraybuffer'接收，后端尽量发二进制帧，避开字符串序列化/反序列化瓶颈； - PHP 项目弃用 FPM，改用 Swoole/Workerman；Python 服务确保用 Uvicorn + 异步 handler，禁止在 onOpen 或消息处理中做同步 DB 查询。
