必须同时配置sendfile on、tcp_nopush on、tcp_nodelay off三项指令，缺一不可；需规避gzip、代理、内容改写、非本地文件系统及缺失Content-Length等退化条件，并通过strace和压测验证sendfile64调用及CPU sy占比下降。
在生产环境中开启 sendfile 不是写一行 sendfile on; 就完事，关键在于让零拷贝路径真正跑起来，并持续确认它没被悄悄绕过。
必须成套配置的核心指令
单独启用任意一项都无效，必须同时满足以下三项：
- sendfile on;：激活内核态直送能力，跳过用户态缓冲区
- tcp_nopush on;：等响应头和文件数据一起填满 TCP 包再发，避免小包泛滥
- tcp_nodelay off;：关闭 Nagle 算法，否则会与 tcp_nopush 冲突，导致攒包失效
必须规避的退化条件
只要出现以下任一情况，Nginx 就会自动回退到 read()+write() 路径，sendfile 形同虚设：
- 启用了
gzip on、gunzip on或未配好gzip_static on（压缩必须进用户态） - 使用了
proxy_pass、fastcgi_pass等代理指令（动态内容不走 sendfile） - 配置了
sub_filter、add_before_body等内容改写功能 - 静态文件放在 NFS、FUSE、Docker 默认 overlay2 卷等不支持 sendfile 的存储上
- 响应头缺失
Content-Length（如 chunked 编码或动态生成）
推荐补充的协同优化项
这些不改变零拷贝路径，但能减少干扰、提升稳定性：
- gzip_static on; gzip off;：用预压缩的 .gz 文件替代运行时压缩，仍走 sendfile
- open_file_cache max=10000 inactive=60s;：缓存文件句柄和元信息，降低高并发下 open/stat 开销
- sendfile_max_chunk 512k;：限制单次传输大小，防止单个大文件阻塞事件循环
- access_log off;：在纯静态资源 location 中关闭访问日志，减轻 I/O 压力
验证是否真实生效
不能只看配置有没有写，要观察运行时行为：
- 用
strace -p $(pgrep nginx | head -1) -e trace=sendfile64,read,write持续跟踪一个 worker 进程；看到大量sendfile64调用、极少或没有read/write，说明路径畅通 - 压测同一 1MB 静态文件（例如用
wrk -c 1000 -t 4 http://host/test.jpg），对比开启前后：CPU 的 sy（系统态）占比应明显下降，QPS 提升 20%–50%，延迟从 8–12ms 降至 2–4ms - 检查 Nginx 错误日志是否有
sendfile() failed类报错，尤其在容器或网络文件系统环境下
