tcp_nodelay的核心作用是禁用Nagle算法，使≤1KB小包在长连接中立即发出；仅对WebSocket、SSE、高频轻量API有效，须配合keepalive、禁用sendfile/tcp_nopush，并在location/upstream块精准启用。
tcp_nodelay 的核心作用是禁用 Nagle 算法，让小数据包（通常 ≤1KB）在写入后立刻发出，不等待 ACK 或凑满 TCP 段。但它不是万能开关——只在长连接、小响应、真实复用的场景下生效，配错位置或忽略协同条件，反而无效甚至有害。
明确适用场景：不是所有接口都适合开
盲目全局启用 tcp_nodelay 会干扰大流量静态资源传输，且对短连接完全无用。真正受益的只有以下三类：
- WebSocket 升级后的双向控制帧与消息流（如
/ws、/api/chat） - Server-Sent Events（SSE）实时通知接口（如
/api/events） - 高频低延迟 API，响应体为轻量 JSON 或空体（如
/api/status、/api/heartbeat）
HTTP/1.0 或每次请求关闭连接的接口，即使配置了也毫无效果。
精准配置位置：按语义而非全局开启
必须放在 location 或 upstream 块中，而不是 http 全局块。典型有效写法：
Blender Geometry Nodes Script Generator
下载
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
- 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>} - SSE 流式推送：
location /api/events {<br> proxy_pass http://backend;<br> tcp_nodelay on;<br> tcp_nopush off;<br>} - 后端微服务代理（如 Node.js/Go）：
upstream api_cluster {<br> server 127.0.0.1:3000;<br> keepalive 32;<br>}<br>location /api/ {<br> proxy_pass http://api_cluster;<br> proxy_http_version 1.1;<br> proxy_set_header Connection '';<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() -
服务端内核仍用延迟 ACK：需配合
sysctl -w net.ipv4.tcp_delack_min=0，否则客户端发完还得等 40ms ACK
验证是否真生效：别信配置，要看报文
配置 reload 后，务必通过终端命令确认实际行为：
- 检查连接状态：
ss -tin 'dst <ip>:<port>'</port></ip>，输出中出现nodelay字样即表示已启用 - 抓包验证时序：
tcpdump -i any port <port> -w trace.pcap</port>，过滤连续两个小包，间隔应 ≤1ms（非 20–200ms） - 观察重传与 RTT：
ss -i中若rto稳定、retrans无异常增长，说明未因禁用 Nagle 引发拥塞
如果 ss 无输出或 tcpdump 显示明显间隔，优先排查是否漏设 proxy_http_version 1.1 或客户端未复用连接。
