tcp_nodelay与tcp_nopush是互补机制：前者禁用nagle算法实现小包即时发送，提升响应及时性；后者配合sendfile合并大包发送，降低传输开销；二者共存可兼顾延迟与吞吐，linux 2.5.9+内核支持协同生效。

tcp_nodelay 和 tcp_nopush 不是对立选项，而是互补机制——一个管“小包发得快”，一个管“大包发得省”，合理共存才能兼顾延迟与吞吐。

tcp_nodelay：专注响应及时性

它禁用 Nagle 算法，让应用层有数据就立即发出，不等待 ACK 或凑满 MSS。这对 HTTP 头、Keep-Alive 探针、WebSocket 帧、API 返回体等小而关键的数据特别重要。

• 默认就是 on，多数场景无需改动
• 只在 keepalive 连接开启时生效（依赖于 keepalive_timeout 配置）
• 适用于动态内容、反向代理、实时接口等低延迟敏感链路
• 配置位置在 listen 指令后，例如：listen 80 tcp_nodelay;

tcp_nopush：专注传输高效性

它启用 TCP_CORK 机制，配合 sendfile 使用，把文件内容和响应头“攒在一起”发送，减少小包数量和协议开销。但前提是必须开启 sendfile，否则该指令完全无效。

Zenlink - Node SDK for ZenHeart

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

下载

• 默认是 off，静态资源服务建议显式设为 on
• 典型组合是：sendfile on; tcp_nopush on;
• 只对内核零拷贝路径起作用，proxy_pass、FastCGI 等不走这条路，设了也无影响
• 适合图片、JS、CSS、视频片段等静态文件分发场景

二者如何协同工作

Linux 2.5.9+ 内核支持两者同时启用。Nginx 会按需调度：前几段大块文件由 tcp_nopush 合并发送；最后一个可能不满的包，由 tcp_nodelay 强制推送，避免卡住。

• 不是“要么攒包、要么立刻发”，而是“大段攒着发，末段不等直接发”
• HTTP/2 下内核调度更精细，这两个参数影响减弱，但仍建议保留标准配置
• 真实生效需验证：nginx -t 检语法，tcpdump 抓包看 PUSH 标志与小包间隔

常见误配与规避建议

容易踩坑的地方不在写法，而在上下文缺失：

• 写了 tcp_nopush on 但没开 sendfile → 配置静默失效
• 在 proxy_pass 的 location 里盲目加 tcp_nopush → 实际不参与传输路径
• 为降低延迟而关掉 tcp_nodelay，却未评估对首字节时间（TTFB）的影响
• 仅靠配置不验证，误以为优化已落地