tcp_nodelay并非万能开关，仅在长连接、响应≤1kb、后端已flush三个硬前提下禁用nagle算法，使小响应立即发出；必须配在location或upstream块并关闭proxy_buffering等干扰项。
在 Linux 上用 Nginx 配置 tcp_nodelay，目的不是“禁用小包延迟”本身，而是**禁用 Nagle 算法**，让满足条件的小响应（≤1KB）在长连接中不等待 ACK、不攒包，立即发出，从而消除 20–200ms 的人为卡顿。它起效有硬边界，配错位置或忽略前提，等于没开。
必须满足的三个前提条件
缺一不可，否则配置无效：
-
连接必须是长连接：HTTP/1.1 的
Connection: keep-alive或 HTTP/2；需显式配置keepalive_timeout 60;（建议 60–65 秒），并确认客户端真实复用连接（可用ss -i dst <client_ip>:443</client_ip>查看输出是否含nodelay标志） -
响应体 ≤1KB：如
/health返回的{"ok":true}、SSE 事件帧、WebSocket ping 帧、favicon.ico等；大文件（如 JS bundle、图片）不受 Nagle 影响，开了也无用 -
后端已显式 flush：例如 Node.js 中调用
res.flush()，Go 中调用rw.(http.Flusher).Flush()；若 Nginx 自身开启proxy_buffering on，数据卡在 Nginx 缓冲区，tcp_nodelay就失去作用对象
正确启用位置：按需写在 location 或 upstream 块中
不要放在 http 块全局开启——既干扰静态资源传输，又对普通 REST API（短连接、大 JSON）完全无效。典型有效场景和写法：
-
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;
}
必须关闭或规避的干扰项
以下配置与 tcp_nodelay 冲突，共存会导致其静默失效：
-
避免
tcp_nopush on与tcp_nodelay on同时启用：二者逻辑相斥（一个攒包、一个立刻发）；仅在sendfile on场景下可共存，且tcp_nodelay仅影响末尾不满包 -
禁用
sendfile on时慎用tcp_nodelay：零拷贝路径下，内核才直接控制 TCP 发送行为；若走用户态读取（如proxy_pass、gzip 处理），tcp_nodelay无法作用于 socket 缓冲区 -
不依赖
proxy_buffering off不够：还需后端应用自身完成 flush；否则 Nginx 层的设置只是空转
验证是否真正生效
不能只看配置是否存在，要实证：
- 用
ss -i dst <client_ip>:443</client_ip>查看连接详情，输出中出现nodelay字样即表示已启用 - 用 Wireshark 抓包，观察两个相邻小响应（如连续 SSE 事件）的发送时间间隔是否接近 0ms（排除网络排队影响后）
- 对比开启前后端到端 P95 延迟变化，重点看 ≤1KB 响应的延迟分布是否左移 20–200ms
