sendfile 是 nginx 静态文件传输的内核级零拷贝机制，需同时满足本地磁盘文件、无用户态干预、无 upstream 处理三大前提，并配套 tcp_nopush on、tcp_nodelay off 才能生效；否则退化为 read/write，性能差 2–5 倍。
要让 Nginx 成为真正高效的静态文件网关，sendfile 不是“开个开关”就能见效的配置项，而是一整套协同生效的内核路径保障机制。它只在严格满足条件时走零拷贝通路，稍有偏差就退化为传统 read/write 模式——性能差距可达 2–5 倍。下面从启用前提、核心配置、避坑要点和验证方法四方面说清楚。
必须同时满足的三个硬性前提
缺一不可，否则 sendfile 形同虚设：
- 文件必须是真实本地磁盘文件：root 或 alias 必须指向 ext4/xfs 等原生支持 sendfile 的本地路径；NFS、容器卷、FUSE 挂载点大多不支持
- 响应必须无用户态干预：不能启用 gzip、gunzip、sub_filter、add_before_body、etag 动态生成、Range 分片请求
- 不能经过任何 upstream 处理：location 中只要出现 proxy_pass、fastcgi_pass、grpc_pass，Nginx 就自动禁用 sendfile，哪怕后端返回的是 .jpg 文件
真正起效的最小配置组合
仅写 sendfile on; 远不够。这三行必须成对出现，且建议统一放在 http 块顶层：
-
sendfile on;—— 启用内核直传能力 -
tcp_nopush on;—— 让内核攒够 TCP 包再发，避免小包泛滥（依赖 sendfile 路径） -
tcp_nodelay off;—— 关闭 Nagle 算法，防止与 tcp_nopush 冲突
补充推荐（非必需但显著提升稳定性）：
-
sendfile_max_chunk 512k;—— 防止单次大文件传输阻塞事件循环，适合图片/视频首帧 -
open_file_cache max=10000 inactive=60s;—— 缓存文件句柄和元数据，减少 stat/open 开销 -
access_log off;—— 静态资源 location 中关闭日志，避免高并发 I/O 成瓶颈
按资源类型做精准控制更安全
不建议在全局 http 块盲目开启，应按后缀隔离，避免误伤动态接口：
-
图片类：
location ~* \.(jpg|jpeg|png|webp|gif|avif|svg)$ { root /var/www; sendfile on; tcp_nopush on; tcp_nodelay off; gzip off; } -
大文件类：
location ~ \.(mp4|zip|iso|tar\.gz|dmg)$ { sendfile on; tcp_nopush on; tcp_nodelay off; sendfile_max_chunk 512k; expires 7d; } -
JS/CSS 类：搭配
gzip_static on;提前压缩好 .gz 文件，仍走 sendfile 路径，无需运行时压缩
怎么确认它真的在工作
别信配置，看系统行为：
- 用
strace -e trace=sendfile64,read,write -p $(pgrep nginx | head -1)请求一个静态文件，持续看到sendfile64()调用，且几乎无read()/write() - 压测对比 CPU：开启后 worker 进程的
%sy（系统态）占比应明显下降，QPS 提升 20%–50% - 检查响应头：有
Content-Length、无Transfer-Encoding: chunked、无Vary: Accept-Encoding（说明没进压缩逻辑）
