sendfile 在回源链路（如 Nginx → Thumbor）中不生效，因其要求数据源为本地文件句柄，而 proxy_pass 指向远端 socket，迫使 Nginx 经 read/write 完成用户态拷贝；仅当 Nginx 直接服务本地静态图片时才有效。
sendfile 在图片处理服务（如 Thumbor 或 GraphicsMagick）前的回源链路中不生效，它无法优化该场景下的性能——这不是配置问题，而是由 sendfile 的底层机制决定的。
sendfile 为什么对 Thumbor/回源类图片服务无效
sendfile 要求数据源必须是本地磁盘上的真实文件句柄（fd），且目标是 socket。但在以下典型回源架构中：
- Nginx →
proxy_pass http://thumbor-server/unsafe/... - 或 Nginx →
proxy_pass http://graphicsmagick-gateway?src=...
Nginx 的 upstream 是一个远端 socket，不是本地文件。此时 Nginx 必须：
- 先从后端读取响应体（
read()进用户态缓冲区） - 再写入客户端 socket（
write()）
整个过程绕不开用户态内存拷贝，sendfile on 完全被忽略。即使后端返回的是 JPEG 文件，只要路径含 proxy_pass，零拷贝路径就不可达。
真正能用 sendfile 的图片服务场景
仅当 Nginx 自己直接提供静态图片文件时才有效，例如：
- 原图已预生成并存于本地
/data/images/photo.jpg - 缩略图也已批量生成并落盘，如
/data/thumbs/photo_w300_h200.jpg - Nginx 通过
root /data;+location ~* \.jpg$ { }直接响应
此时可安全启用：
location ~* \.(jpg|jpeg|png|webp|gif)$ {
sendfile on;
tcp_nopush on;
tcp_nodelay off;
gzip off;
}回源图片服务的替代优化方向
既然 sendfile 失效，应聚焦代理链路本身：
- 启用
proxy_buffering off;：避免等待完整响应再发送，降低首字节时间（TTFB），尤其利于大图流式输出 - 调整缓冲区大小以匹配图片体积：
proxy_buffer_size 128k; proxy_buffers 8 256k; proxy_busy_buffers_size 512k;
- 设置合理超时，防卡死：
proxy_read_timeout 120; proxy_connect_timeout 10;
- 若 Thumbor 返回的缩略图被反复请求，应在 Nginx 层加
proxy_cache，缓存其响应（注意proxy_cache_key需包含全部影响结果的参数，如宽、高、格式、裁剪方式） - 对于高频小图，考虑在 Nginx 边缘缓存层预热或设置
proxy_cache_valid 200 7d;
如何验证 sendfile 是否被绕过
运行命令观察 worker 进程实际系统调用：
strace -e trace=sendfile64,read,write -p $(pgrep -f "nginx: worker") 2>&1 | grep -E "(sendfile64|read|write)"
若只看到 read() 和 write()，没有 sendfile64()，说明当前 location 已退化为常规代理路径。
不复杂但容易忽略
