Nginx中tcp_nopush与tcp_nodelay须按业务路径分工:静态资源启用tcp_nopush+sendfile+proxy_buffering,动态接口启用tcp_nodelay+proxy_buffering off+upstream keepalive。

在 Nginx 中配置 tcp_nopush 和 tcp_nodelay,关键不是简单开关,而是按业务路径区分用途:静态资源走“攒包发”,动态接口走“有数据立刻发”。两者逻辑冲突,不能共存生效,必须明确分工。
静态资源代理:开 tcp_nopush,关 tcp_nodelay
适用于 /static/、/images/、CDN 回源等已知长度、整块返回的场景。要让 tcp_nopush 真正起作用,需同时满足:
- 启用
sendfile on;(tcp_nopush 仅在此模式下生效) - 后端响应带准确
Content-Length,不能是 chunked 编码 - 开启缓冲:
proxy_buffering on;,并设足够大的缓冲区,例如proxy_buffers 8 128k;和proxy_buffer_size 128k; - 显式关闭纳格算法干扰:
tcp_nodelay off;
动态与实时接口:开 tcp_nodelay,关 tcp_nopush
适用于 /api/、/ws/、/events/ 等低延迟敏感路径。此时 tcp_nodelay 才能真正减少小包延迟:
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw,涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 必须设为
tcp_nodelay on; - 同步关闭
tcp_nopush off;(否则 Nginx 可能静默忽略 tcp_nodelay) - 禁用用户态缓冲:
proxy_buffering off;,避免响应卡在 Nginx 内存里 - 上游启用连接池:
upstream xxx { keepalive 32; },且后端空闲超时 ≥ Nginx 的keepalive_timeout
位置与作用范围
两个指令都支持出现在 http、server、location 块中,建议按需下沉到具体 location 级别,避免全局误配:
-
tcp_nopush默认为off,只在sendfile on时有效 -
tcp_nodelay默认为on,但仅在 keep-alive 连接或 upstream 到客户端转发时才实际生效
常见误配与验证要点
以下配置组合会导致预期失效:
- 对动态接口开了
proxy_buffering on却还设tcp_nodelay on—— 数据被缓存,tcp_nodelay 没东西可发 - 静态资源用了 chunked 响应,却强开
tcp_nopush on—— Nginx 自动降级,不触发 TCP_CORK - 没配
upstream keepalive就指望tcp_nodelay加速 API —— 连接反复新建,纳格算法仍在首包生效
可通过抓包观察 TCP 报文间隔与 PSH 标志位,或使用 ss -i 查看 socket 的 cork / nodelay 状态确认是否生效。

















