tcp_nodelay仅对长连接、小响应、高频交互场景有效，如WebSocket、SSE、微服务实时接口等；需配合keepalive、proxy_http_version 1.1及清空Connection头，并在location或upstream块中按需启用，禁用sendfile和延迟ACK才能真正生效。
tcp_nodelay 能提升 API 接口响应实时性，但只对特定场景有效：它禁用 Nagle 算法，让小数据包不等待、不合并，立即发出。关键不是“开了就行”，而是必须匹配长连接 + 小响应 + 高频交互这三要素，且要和 proxy_pass 协同配置才真正起效。
只在适用的接口上启用，别全局开
`tcp_nodelay` 对普通 REST API（短连接、单次大 JSON）基本无效。它真正起作用的是： - WebSocket 升级路径（如 `/ws`） - SSE 流式推送（如 `/api/events`） - 微服务间高频低延迟调用（如 `/api/realtime/`） - 前端复用连接的极简轮询（返回 `{"ok":true}` 这类几十字节响应）
全局放在 http 块中不仅浪费，还可能干扰静态资源传输逻辑。应下沉到具体 location 或 upstream 块。
location 级配置示例（面向客户端连接）
适用于 Nginx 与客户端之间的小包低延迟优化： ```nginx location /api/events { proxy_pass http://sse_backend; proxy_http_version 1.1; proxy_set_header Connection ''; tcp_nodelay on; tcp_nopush off; /* 避免与 Nagle 机制叠加缓冲 */ } ``` 注意： - `proxy_http_version 1.1` 和清空 `Connection` 头，确保客户端长连接不被中间设备中断 - `tcp_nopush off` 是配套动作，防止 Nginx 自身缓冲干扰实时性 - 此处的 `tcp_nodelay` 控制的是 **Nginx → 客户端** 的 TCP 发送行为
upstream 级配置示例（面向后端连接）
若你希望优化 Nginx 到后端服务之间的通信延迟（比如微服务集群），需在 `upstream` 中启用，并配合 `keepalive`： ```nginx upstream api_cluster { server 10.0.1.10:8080; keepalive 32; /* 必须显式声明，否则 proxy_pass 不启用长连接 */ }
location /api/realtime/ { proxy_pass https://www.php.cn/link/1a2bc964c840cdbb81b6b40792c6e490; proxy_http_version 1.1; proxy_set_header Connection ''; tcp_nodelay on; / 此处生效于 Nginx → 后端 的连接 / }
重点： - `keepalive 32` 是前提，没有它，`tcp_nodelay` 在 upstream 场景下不会触发 - 后端服务自身也需支持快速 flush（如 Go 中调用 `Flush()`，Node.js 中 `res.flush()`） <h3>必须同步检查的失效点</h3> 以下任一情况存在，`tcp_nodelay` 都等于没配： - 客户端未复用连接（抓包看 TCP Stream 是否持续，或 `ss -i` 查连接状态） - 响应体超过 1KB（内核自动触发发送，Nagle 本就不介入） - 同时启用了 `sendfile on`（零拷贝绕过 socket 缓冲区，`tcp_nodelay` 失去作用对象） - 后端应用有输出缓冲（如未显式 flush、使用了 gzip 中间件但未配置 `gzip_vary off` 等） - 内核仍启用延迟 ACK：`sysctl -w net.ipv4.tcp_delack_min=0` 验证是否生效，不能只靠 reload： - 建立连接后执行：`ss -i dst <client_ip>:<port> | grep nodelay` - 或抓包观察两个小响应包的时间间隔是否压缩到 1ms 级别 不复杂但容易忽略</port></client_ip>
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
