tcp_nodelay仅在长连接场景下提升小报文即时性，需满足keepalive启用、HTTP/1.1+显式长连接、上游支持快速写入三条件，且应按location或upstream精准启用。
tcp_nodelay 对小报文推送的即时性响应有明确作用，但仅在长连接场景下生效，不能用于优化短连接 API。它本质是禁用 Nagle 算法，让每个 write() 调用的数据立即发包，避免因等待 ACK 或攒包导致的 20–200ms 延迟。
必须满足的前置条件
该指令不会自动生效，需同时满足以下三点：
- 连接必须启用 keepalive：配置 keepalive_timeout（如 65s），且客户端实际复用连接
- HTTP 协议需为 1.1 或更高，并显式开启长连接：后端代理时设 proxy_http_version 1.1 和 proxy_set_header Connection ""
- 上游服务需支持快速、分块写入：若后端应用自身存在缓冲或同步阻塞，Nginx 层的 tcp_nodelay 无法绕过这些延迟
只应在具体 location 或 upstream 中启用
全局放在 http 块中不仅无效，还可能干扰静态资源传输逻辑。应按接口类型精准控制：
Blender Geometry Nodes Script Generator
下载
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
- 适用于 SSE（Server-Sent Events）、WebSocket 子协议、实时消息推送等连续小响应场景
- 示例配置（专用于流式接口）：
location /api/notify {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
tcp_nodelay on;
}
与 tcp_nopush 的协同关系
二者不互斥，但作用方向相反，需按内容特性区分使用：
- tcp_nodelay on：面向低延迟，适合小响应体、高频交互（如 JSON 片段、事件通知）
- tcp_nopush on：需配合 sendfile on，面向高吞吐，适合大文件或静态资源批量发送
- 动态 API 流量通常不走 sendfile，因此可放心启用 tcp_nodelay，无需关闭 tcp_nopush（默认即 off，无影响）
比 tcp_nodelay 更值得优先做的优化
若目标是整体降低 API 响应延迟，以下配置的影响远大于盲目开启 tcp_nodelay：
- 启用并调优 upstream keepalive（如 keepalive 32），减少后端建连开销
- 设置 proxy_buffering off（对低延迟敏感接口），避免 Nginx 缓冲响应体
- 使用 reuseport 提升多 worker 接收新连接的并发能力
- 关闭 access_log 或切至异步日志，减少磁盘 I/O 对 worker 的阻塞
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
