tcp_nodelay不是全局加速开关，仅在长连接、响应≤1kb、后端已flush三个前提同时满足时禁用nagle算法，消除20–200ms攒包延迟；必须置于location或upstream块中，且需关闭proxy_buffering和tcp_nopush等干扰项。
tcp_nodelay 不是“一开就快”的全局加速参数，它只在特定条件下禁用 Nagle 算法，让 ≤1KB 的小响应立即发出，从而消除 20–200ms 的攒包等待。配错位置、忽略前提，配置就等于没写。
明确生效的三个硬条件
该参数仅在以下三点同时满足时起作用：
- 连接必须是长连接：HTTP/1.1 keep-alive 或 HTTP/2，且实际被复用；需配置 keepalive_timeout 65;，并确认客户端未频繁断连（可用
ss -i查看 socket 是否带nodelay标志） - 响应体足够小：典型如
{"ok":true}、SSE 事件帧、WebSocket ping、/health接口、favicon.ico等，一般 ≤1KB；大文件（如 JS/CSS 超 50KB、图片）不受影响 - 数据已被后端显式刷出：Node.js 需调用
res.flush()，Go 需调用http.Flusher.Flush()；若后端未 flush，Nginx 层无数据可发，tcp_nodelay 失去作用对象
正确启用的位置与写法
不能放在 http 块顶层全局开启，必须按业务路径精细化控制：
- WebSocket 场景：location /ws { ... tcp_nodelay on; proxy_buffering off; }
- SSE 实时流接口：location /api/events { ... tcp_nodelay on; tcp_nopush off; proxy_buffering off; }
- 静态小资源直服（如构建产物中的 manifest.json、robots.txt）：location ~* \.(ico|txt|json)$ { ... tcp_nodelay on; }
- 动态 API 短响应接口（如登录、健康检查）：location /api/health { ... tcp_nodelay on; }
必须关闭或规避的干扰项
以下配置会直接抵消或静默忽略 tcp_nodelay 效果：
- proxy_buffering on;：Nginx 缓冲未释放，后端 flush 的数据卡在代理层，tcp_nodelay 无从作用
- tcp_nopush on; 与 tcp_nodelay on; 同时启用（非 sendfile 场景）：二者逻辑冲突，Nginx 可能静默忽略后者
- sendfile on; 用于 proxy_pass 动态请求：此时走用户态读取路径，tcp_nodelay 不生效；但对纯静态文件服务（root + try_files），sendfile 可保留，Nginx 会自动在 sendfile 路径下忽略 tcp_nodelay（无需手动关）
配套关键配置不可少
单独开 tcp_nodelay 效果有限，需协同设置：
- 确保 keepalive_timeout 65; 和 keepalive_requests 1000; 已启用
- 代理长连接时加：proxy_http_version 1.1; 和 proxy_set_header Connection '';（清空 Connection 头，防中间设备误断）
- 后端协议要匹配：如 WebSocket 需设 proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";
