启用tcp_nodelay on可降低websocket端到端延迟，前提是作用于已升级的长连接，专治nagle算法导致的小包攒发延迟；需满足websocket协议升级、keepalive_timeout配置及小数据包传输三个条件。

直接启用 tcp_nodelay on 能降低 WebSocket 消息的端到端延迟，但前提是它必须作用于已建立的长连接，并且只对小数据包（如心跳帧、行情更新、控制指令）起效。它不解决网络传输、后端响应慢或协议升级失败等问题，而是专治 Nagle 算法导致的“攒包等待”。

为什么 WebSocket 需要 tcp_nodelay

Nagle 算法默认开启，会把多个小写操作合并发送——比如连续发 3 条 20 字节的行情消息，可能被内核缓存，等收到前一个包的 ACK 或凑够 MSS 才发出，引入 20–200ms 延迟。WebSocket 是典型的高频、小包、强实时场景，用户对“下单即成交”“报价秒刷新”极为敏感，这种延迟不可接受。tcp_nodelay on 关闭该机制，让每个 write() 调用的数据立即封装成 TCP 包发出。

必须满足的三个前提条件

该指令仅在以下条件下生效：

Zenlink - Node SDK for ZenHeart

ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。

下载

• 连接已完成 WebSocket 升级：配置中必须包含 proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";，否则仍是普通 HTTP 连接，tcp_nodelay 不起作用
• 使用长连接且未被提前中断：需设置 keepalive_timeout（建议 ≥65s），并确保客户端与后端都维持连接；若 Nginx 因 proxy_read_timeout 过短主动断连，长连接就不存在
• 消息体足够小：单次推送为几十到几百字节（如 JSON 行情、ping/pong 帧）时效果最明显；若一次推送 10KB 行情快照，TCP 自动触发立即发送，Nagle 本就不介入

推荐的 Nginx 配置方式

不要在全局 http 块盲目开启，应聚焦 WebSocket 路径精准启用：

• 在 location /ws 或类似路径块中添加：
  tcp_nodelay on;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
• 同步关闭缓冲干扰：
  proxy_buffering off;（防消息卡在 Nginx 缓冲区）
  tcp_nopush off;（避免零拷贝机制延迟小包）
• 延长空闲容忍时间：
  proxy_read_timeout 86400;（24 小时），配合后端每 30 秒发一次 ping 帧，防止误杀静默连接

怎么确认它真的起效了

改完配置不能只靠重启，要实证：

• 用 ss -i dst <client_ip>:80</client_ip> 查看活跃连接，输出中出现 nodelay 标志才表示生效
• 浏览器 DevTools → Network → WebSocket → 查看 Frames 面板，观察消息发出到接收的时间差是否稳定在 10–50ms 区间（排除后端处理耗时）
• 对比开启前后抓包（tcpdump + Wireshark），重点看连续小包的发送间隔是否从 100ms+ 缩短至接近 0ms