排查tcp_nopush与sendfile异常，本质是确认零拷贝路径是否退化为用户态读写及tcp_nopush是否参与tcp包组装；需检查error log中“tcp_nopush is ignored”等日志、用strace验证sendfile64调用、用tcpdump观察响应头体是否合一，并逐项核对sendfile on、gzip off、tcp_nodelay off、content-length存在及直连磁盘文件等前提条件。
排查 tcp_nopush 与 sendfile 相关异常，本质是确认“本该启用零拷贝路径的静态响应，是否实际退化为用户态读写”，以及“tcp_nopush 是否真正参与了 TCP 包组装”。两者不冲突，但极易因配置错位或条件缺失而**同时失效**，表现为延迟高、小包多、CPU 上升、日志报错等。
看日志：快速识别被忽略的 tcp_nopush
Nginx 在无法启用 tcp_nopush 时会明确记录警告，这是最直接的线索：
- 检查 error log 中是否出现
tcp_nopush is ignored - 同时留意
sendfile() failed（如Broken pipe、Invalid argument）——说明sendfile已尝试调用但失败，tcp_nopush自然也无效 - 若看到大量
write() failed (32: Broken pipe)，且发生在大文件传输中，大概率是sendfile路径崩溃后回退到write，此时tcp_nopush完全不生效
抓系统调用：验证 sendfile 是否真实运行
tcp_nopush 依赖 sendfile 路径存在才能起作用。用 strace 确认内核是否真在调用零拷贝接口：
- 找到一个活跃 worker 进程 PID：
pgrep -f "nginx: worker" | head -1 - 执行：
strace -p $PID -e trace=sendfile64,read,write -f 2>&1 | grep -E "(sendfile64|read|write)" - 发起一次静态资源请求（如
curl -I http://x/logo.png） - 若输出中持续出现
sendfile64(且几乎无read(和write(，说明零拷贝路径畅通 →tcp_nopush才有作用基础；若全是read+write组合，说明已退化，tcp_nopush必然被跳过
抓网络包：观察 tcp_nopush 是否攒包成功
即使 sendfile 成功，tcp_nopush 也可能因配套设置错误而未生效。用 tcpdump 观察响应是否“头体合一”：
- 执行：
tcpdump -i any 'port 80 and host [client_ip]' -w nopush.pcap -c 100 - 用 Wireshark 打开 pcap，过滤 HTTP 响应（如
http.response.code == 200） - 查看第一个含响应体的 TCP 包：是否同时包含
HTTP/1.1 200 OK和文件开头字节（如 PNG 的89 50 4E 47）？ - 若是 →
tcp_nopush生效；若响应头和文件数据分属两个包，或首包只有 header 无 body，则说明tcp_nopush未触发（常见于tcp_nodelay on或gzip on干扰）
查配置前提：逐项核对生效条件
tcp_nopush 不是开关，而是一组协作机制。以下任一缺失都会导致其静默失效：
-
sendfile on;必须在当前 location 或上游生效（全局或 server 块设也可，但 location 内显式覆盖更安全） -
gzip off;必须关闭，压缩强制走用户态，一开即禁用sendfile -
tcp_nodelay off;必须显式关闭，否则 Nagle 算法与tcp_nopush的 TCP_CORK 行为冲突 - 响应必须含
Content-Length：Nginx 需预知大小才能调用sendfile()；若后端返回Transfer-Encoding: chunked，整条路径自动降级 - 请求路径必须直指磁盘文件：不能经过
proxy_pass、alias指向 NFS/FUSE、或被sub_filter/lua_code修改响应体
