tcp_nodelay的核心作用是禁用nagle算法，使小数据包在长连接中立即发送，显著降低交互式请求延迟；适用于websocket、sse、轻量api等高频小响应场景，需配合keepalive、http/1.1及后端及时flush方可生效。
tcp_nodelay 的核心作用是禁用 Nagle 算法，让小数据包在长连接中不等待、不攒包，立刻发出。它不提升吞吐量，专治“明明数据早写好了，却卡住几十毫秒才发出去”的延迟堆积问题——尤其在代理转发高频小响应（如 JSON、SSE 事件、WebSocket 控制帧）时效果明显。
明确适用场景：只对长连接 + 小响应生效
代理转发中启用 tcp_nodelay 并非总有效，必须同时满足：
- 客户端与 Nginx 之间是 keepalive 长连接（需配置 keepalive_timeout，例如
keepalive_timeout 65;） - 后端返回的响应体足够小（通常 ≤1KB），比如
{"code":0,"msg":"ok"}、SSE 的data: hello\n\n、WebSocket 升级响应头等 - 不是短连接 API（每次请求后断开），这种情况下 tcp_nodelay 完全无效
精准配置位置：在 location 块中启用，而非全局
代理转发类接口应按语义单独开启，避免干扰静态资源或大文件传输。典型配置如下：
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 实时消息流接口：
location /api/events {<br> proxy_pass http://backend;<br> proxy_http_version 1.1;<br> proxy_set_header Connection '';<br> tcp_nodelay on;<br> tcp_nopush off; # 防止 tcp_nopush 缓冲覆盖效果<br>} - WebSocket 升级路径：
location /ws {<br> proxy_pass http://backend;<br> proxy_http_version 1.1;<br> proxy_set_header Upgrade $http_upgrade;<br> proxy_set_header Connection "upgrade";<br> tcp_nodelay on;<br>} - 高频轻量 API（如健康检查、指令响应）：
location /health {<br> proxy_pass http://checker;<br> tcp_nodelay on;<br>}
避开常见失效组合
以下配置会直接让 tcp_nodelay 失效或抵消其效果：
- 同时启用 sendfile on：内核零拷贝绕过 socket 缓冲区，tcp_nodelay 失去作用对象
- 同时启用 tcp_nopush on：两者逻辑冲突，Nginx 会静默忽略 tcp_nodelay
-
后端未及时 flush：如 Node.js 的
res.write()后未调用res.flush()，或 Go 中未显式flusher.Flush() -
客户端未复用连接：可通过抓包看 TCP Stream 是否持续，或运行
ss -i 'dst <backend_ip>:<port>'</port></backend_ip>查看重传与 RTT 波动
验证是否真正生效
不能仅靠配置就认为起效，建议通过以下方式确认：
- 运行命令：
ss -tin 'dst <client_ip>:<port>'</port></client_ip>，若输出含nodelay字样，说明已启用 - 用 tcpdump 抓包，过滤小响应（如
tcp.len == 48 or tcp.len == 64），观察发送间隔是否从 100ms+ 降至接近 0ms - 对比开启前后首字节时间（TTFB）P95/P99：实际压测中，合理启用可将 P99 延迟从 30–50ms 降至 8–12ms
