开启 sendfile 提升大文件传输效率的关键是让内核走通“磁盘→页缓存→socket发送队列”零拷贝链路，必须同时满足三项基础配置（sendfile on、tcp_nopush on、tcp_nodelay off）、路径可控（本地ext4/xfs真实静态文件且含准确content-length）及干扰清零（禁用gzip、sub_filter、proxy_pass等）。
开启 sendfile 提升大文件传输效率，关键不是加一行 sendfile on; 就完事，而是让内核真正走通“磁盘→页缓存→socket发送队列”的零拷贝链路。这需要配置协同、路径可控、干扰清零三者同时满足。
必须成套启用的三项基础指令
单独开启任意一项都无效，必须在同一个 location 块中显式写全：
- sendfile on;：激活内核直送能力，跳过用户态缓冲区
- tcp_nopush on;：依赖 sendfile 路径，把响应头和文件开头数据合并进同一 TCP 报文段，减少小包
-
tcp_nodelay off;：关闭 Nagle 算法；若设为
on，会强制立即发包，直接破坏tcp_nopush的攒包逻辑
只对真实静态文件生效，路径必须可控
sendfile 只对满足以下条件的响应起作用：
- 文件位于本地 ext4/xfs 文件系统（非 NFS、FUSE、Docker overlay2 默认卷、符号链接指向容器路径）
- 响应是 Nginx 直接读取的磁盘文件（如用
root或alias指向真实路径），不是proxy_pass、fastcgi_pass或X-Accel-Redirect返回的内容 - 响应头中含准确的
Content-Length（Nginx 需提前知道大小才能调用 sendfile；若为 chunked 或动态生成，则自动退化）
避开所有导致零拷贝中断的干扰项
以下任一操作都会让 Nginx 强制回退到 read()+write() 模式：
- 启用
gzip on、gunzip on或gzip_static on（但 .gz 文件缺失时也会 fallback） - 使用
sub_filter、add_before_body、etag、expires等需改写响应头或内容的指令 - 客户端发起
Range请求（如视频拖拽），Nginx 需切片处理，无法整块直传 - 文件被其他进程加锁，或以
O_DIRECT方式打开
推荐按资源类型做 location 级精准控制
不建议在 http 块全局开启，应结合后缀精细化配置：
- 图片类：
location ~* \.(jpg|jpeg|png|webp|gif|avif|svg)$中启用sendfile on; tcp_nopush on; tcp_nodelay off; gzip off; - 大文件类：
location ~ \.(mp4|zip|iso|tar\.gz|dmg)$可额外加sendfile_max_chunk 512k;，防止单次传输阻塞事件循环 - 已压缩资源：用
gzip_static on;+gzip off;，配合预生成的.gz文件，仍可走 sendfile 路径
验证是否真走零拷贝，不能只看配置
配置正确 ≠ 运行生效，需通过运行时行为确认：
- 用
strace -p $(pgrep nginx) -e trace=sendfile64观察 worker 进程是否持续调用sendfile64系统调用 - 对比开启前后高并发请求下 CPU 的
sy（系统态）占比：真实生效时应明显下降，QPS 通常提升 20%–50% - 检查错误日志是否有
sendfile() failed、Permission denied或 SELinux 相关报错
