tcp_nodelay能提升小报文即时性，但仅在长连接、小响应（≤1KB）、后端快速写入三者齐备时生效；需在location或upstream中按需启用，避免全局配置。

tcp_nodelay 能有效提升小报文推送的即时性，但只在长连接、小响应、快速写入三者齐备时才真正起作用。它不是万能开关，盲目开启对短连接 API 几乎无益，还可能干扰其他流量。

它解决的是“攒包延迟”，不是网络传输慢

Nagle 算法默认启用，目的是合并小数据块以节省带宽：当上一个 TCP 包还没收到 ACK，又来了几十字节的 JSON 或事件帧，内核会等一等——可能多等 20–200ms。这对实时交互很致命。
tcp_nodelay on 的作用就是关掉这个等待，让每个 write() 调用的数据立刻发出去，不攒、不等、不卡。

必须同时满足三个前提条件

• 连接是长连接：配置 keepalive_timeout 65;，且客户端实际复用连接（HTTP/1.1 显式带 Connection: keep-alive，或 HTTP/2 原生支持）
• 响应体足够小：单次响应通常 ≤ 1KB（如 SSE 的 data: {...}\n\n、WebSocket 控制帧、JSON 片段），大响应本身就会触发立即发送
• 后端能快速写入：上游服务（如 Go/Node.js 微服务）不能自身缓冲或阻塞输出；否则 Nginx 层开 tcp_nodelay 也无济于事

只应在具体 location 或 upstream 中按需启用

全局放在 http { } 块中不仅无效，还可能影响静态资源传输逻辑。推荐精准控制：

• WebSocket 接口

  

  用于自动切换项目中适合的node 版本

  根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。

  下载

  location /ws {
      proxy_pass http://backend;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      tcp_nodelay on;
  }

• SSE 或消息流接口

  location /api/events {
      proxy_pass http://backend;
      proxy_http_version 1.1;
      proxy_set_header Connection '';
      tcp_nodelay on;
      tcp_nopush off;  # 避免零拷贝机制引入缓冲
  }

• 后端微服务集群（配合 upstream keepalive）

  upstream api_backend {
      server 127.0.0.1:3000;
      keepalive 32;  # 复用到后端的连接
  }
  
  location /api/notify {
      proxy_pass http://api_backend;
      proxy_http_version 1.1;
      proxy_set_header Connection '';
      tcp_nodelay on;
  }

比 tcp_nodelay 更值得优先做的几件事

• 启用并调优 upstream keepalive（如 keepalive 32），大幅减少后端建连开销
• 对低延迟敏感接口，设 proxy_buffering off，避免 Nginx 缓冲整个响应体
• 关闭 access_log 或切为异步日志，防止磁盘 I/O 拖慢 worker
• 确保客户端真实复用连接（检查请求头是否有 Connection: keep-alive，响应头是否有 Keep-Alive: timeout=65）

怎么确认它真的生效了

改完配置不能算完。用 ss -i 查看连接详情，找 nodelay 字段是否为 on；或用 Wireshark 抓包，观察小响应是否在 write 后立刻发出，而非等待 ACK 或合并。

不复杂但容易忽略