tcp_nodelay仅在长连接、小响应（≤1kb）、后端已flush的精准场景下生效，用于禁用nagle算法以消除20–200ms攒包等待；必须在location或upstream中按需启用，禁用sendfile和tcp_nopush，并配合后端flush与内核调优。
tcp_nodelay 不能靠全局开启来解决小报文实时延迟，它只在长连接 + 小响应（≤1KB）+ 后端已 flush 的精准场景下才真正生效。开错位置、配错组合，不仅没效果，还可能干扰大文件传输和系统吞吐优化。
它到底解决什么问题
不是网络卡、不是后端慢，而是 TCP 协议栈自己“守规矩”造成的等待：Nagle 算法默认会把小数据（比如 {"ok":true}、WebSocket ping 帧、SSE 事件）缓存起来，等前一个包的 ACK 回来，或者凑够一个 MSS（通常 1448 字节）再发。这个等待在 20–200ms 之间，用户感知就是“点了没反应”“消息延迟刷新”。
tcp_nodelay on 就是告诉内核：“别等，有数据就发”——不提速，不增吞吐，专治这种人为卡顿。
哪些地方配才起作用
必须满足全部三个条件，否则配置等于白写：
- 连接是 HTTP/1.1 keepalive 或 HTTP/2，且客户端真实复用（可通过 ss -i dst
: 查看是否带 nodelay 标志） - 响应体 ≤1KB，例如健康检查接口、实时通知、SSE 流、WebSocket 控制帧
- 后端服务已显式 flush 输出（Node.js 要 res.flush()，Go 要 rw.(http.Flusher).Flush()）
怎么配才不踩坑
只在具体 location 或 upstream 中启用，禁用干扰项：
- WebSocket 升级路径：location /ws { proxy_pass http://backend; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; tcp_nodelay on; proxy_buffering off; }
- SSE 实时接口：location /api/events { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ''; tcp_nodelay on; tcp_nopush off; }
- 务必关闭 sendfile on（零拷贝绕过 socket 缓冲区，tcp_nodelay 失去作用对象）
- 避免与 tcp_nopush on 共存（两者逻辑冲突，Nginx 会静默忽略 tcp_nodelay）
- 对流式接口必须设 proxy_buffering off，否则 Nginx 自身缓冲会卡住小包
比配 tcp_nodelay 更关键的事
很多延迟根本不在 Nagle 上，先确认这些基础是否到位：
- 上游 upstream 块中声明 keepalive 32（或更高），让 Nginx 复用后端连接
- 服务端内核开启低延迟支持：sysctl -w net.ipv4.tcp_low_latency=1
- 客户端和服务端 socket 都要设置 TCP_NODELAY（仅 Nginx 层开不够，后端代码也得设）
- 高并发下优先调优 reuseport 和 net.core.somaxconn，避免建连队列溢出
