tcp_nodelay作用是禁用nagle算法，使小响应（≤1kb、走http/1.1长连接、nginx直接服务）立即发出，降低200ms级延迟；需配套keepalive_timeout、sendfile on和tcp_nopush on才生效。
tcp_nodelay 的作用很明确：它不加快网络本身，也不缩短握手时间，而是让 Nginx 在长连接中，把几十字节到几 KB 的小响应（比如 JS chunk、JSON 头、favicon.ico、preload 资源）立刻发出去，避免被 Nagle 算法卡住等 ACK 或凑包——典型延迟可减少约 200ms，尤其在弱网或高 RTT 场景下感知明显。
哪些小文件真正受益
不是所有静态资源都适合开 tcp_nodelay。它只对满足以下条件的小响应起效：
- 体积通常 ≤ 1KB：如 React/Vue 的 .js/.json chunk、manifest.json、favicon.ico、robots.txt、内联的 HTML 片段
- 走 HTTP/1.1 长连接（Connection: keep-alive）：浏览器复用 TCP 连接加载多个小资源时才触发 Nagle 等待
- 由 Nginx 直接服务（非 proxy_pass）：例如 root 指向 ./build，用 try_files 提供前端路由支持
- 不适用于大文件：>50KB 的图片、字体、视频等不受 Nagle 影响，开或不开都没差别
必须配套的三项基础配置
单独写一句 tcp_nodelay on; 是无效的。它必须和另外两个行为协同才能落地生效：
- keepalive_timeout 必须设置：建议 60–65 秒，确保客户端能复用连接。没这个，就无“长连接”，tcp_nodelay 自然不触发
- sendfile on;：启用零拷贝，提升文件读取效率（尤其对中小文件），是 tcp_nodelay 发挥作用的前提路径之一
- tcp_nopush on;：和 tcp_nodelay 并不冲突，而是分工协作——tcp_nopush 让内核尽量填满 TCP 包再发（提吞吐），tcp_nodelay 则确保最后一个不满的包也立刻发出（保实时）
Nginx 配置示例（推荐放在 server 块）
以下为部署 React/Vue 单页应用时的典型静态服务配置，已剔除冗余、聚焦关键项：
server {
listen 80;
server_name example.com;
root /var/www/my-app/build;
index index.html;
<pre class="brush:php;toolbar:false;"># 关键三件套
keepalive_timeout 60;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
location / {
try_files $uri $uri/ /index.html;
}
# 小资源缓存强化（可选但推荐）
location ~* \.(js|json|ico|svg|png|gif|woff2?)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}}
注意：不要放在 http 块全局启用——若你同时代理 API 或提供大文件下载，全局开启可能干扰其他路径；按 server 或 location 精准控制更安全。
怎么确认它真在工作
改完配置 reload 后，别只信语法正确。实测验证更可靠：
- 用 ss -i dst 查看活跃连接，输出中出现 nodelay 字样即表示生效
- Chrome DevTools → Network → 点开任意一个 .js 或 .json 请求 → Headers → 检查 Connection: keep-alive 是否存在
- 进阶验证：Wireshark 抓包，对比开启前后，同一资源的首个 TCP 数据包发出时间是否提前（重点看从 SYN-ACK 完成到第一个 DATA 包的间隔）
