tcp_nodelay on仅在长连接、响应≤1KB、后端已flush三个硬前提下禁用Nagle算法，使小响应立即发出；必须配在location或upstream块并关闭proxy_buffering等干扰项。
直接在 Nginx 中配置 tcp_nodelay on 并不能“自动提升响应速度”，它只在满足三个硬性条件时，才能禁用 Nagle 算法、消除小包的 20–200ms 人为延迟。配错位置或忽略前提，该指令完全不生效。
必须同时满足的三个前提
缺一不可，否则即使写了 tcp_nodelay on 也等于没开：
-
连接是长连接：HTTP/1.1 的
Connection: keep-alive或 HTTP/2；需显式配置keepalive_timeout 60;（建议 60–65 秒），并确认客户端真实复用连接（可用ss -i dst <client_ip>:443查看输出是否含nodelay标志） -
响应体 ≤1KB：如
/health返回的{"ok":true}、SSE 事件帧、WebSocket ping 帧、favicon.ico；大文件（JS/CSS/图片）不受 Nagle 影响，开了也无用 -
后端已显式 flush：例如 Node.js 中调用
res.flush()，Go 中调用rw.(http.Flusher).Flush()；若 Nginx 自身开启proxy_buffering on，数据卡在缓冲区，tcp_nodelay就失去作用对象
必须写在正确的位置
该指令控制的是当前层级所对应的 TCP 连接方向，不能乱放：
-
写在
location块中 → 控制 Nginx 到客户端 的连接，适用于 WebSocket、SSE、前端轮询等场景 -
写在
upstream块中 → 控制 Nginx 到后端服务 的连接，适用于微服务间高频低延迟调用 -
不要写在
http块全局启用：会干扰静态资源传输，对普通 REST API（短连接、大 JSON）完全无效
必须关闭或规避的干扰项
以下配置与 tcp_nodelay 冲突，共存会导致其静默失效：
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
-
proxy_buffering on→ 必须设为off，否则响应滞留在用户态缓冲区，tcp_nodelay无数据可发 -
tcp_nopush on→ 必须设为off，二者逻辑相斥（一个攒包、一个立刻发）；仅在sendfile on场景下可共存，且此时tcp_nodelay仅影响末尾不满包 -
sendfile on（配合proxy_pass动态路径时）→ 若走用户态读取路径（如大多数代理场景），sendfile应关闭；零拷贝路径下内核接管发送行为，tcp_nodelay在用户态 proxy 场景才生效
典型有效配置示例
SSE 实时接口（Nginx → 客户端）：
location /api/events {
proxy_pass http://sse_backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
tcp_nodelay on;
tcp_nopush off;
proxy_buffering off;
}
WebSocket 升级路径：
location /ws {
proxy_pass http://backend;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
tcp_nodelay on;
proxy_buffering off;
}
微服务间高频调用（Nginx → 后端）：
upstream api_cluster {
server 10.0.1.10:8080;
keepalive 32;
}
location /api/realtime/ {
proxy_pass http://api_cluster;
proxy_http_version 1.1;
proxy_set_header Connection '';
tcp_nodelay on;
} 
