sendfile 不能加速代理模式下临时文件的发送，因其仅支持真实磁盘文件到 socket 的零拷贝，不适用于 proxy_pass、临时文件（如 /tmp 或 tmpfs）、流式响应等场景；代理应改用 proxy_buffering 调优或分离静态服务路径。

不能通过 sendfile 指令加速代理模式下临时文件的发送效率。

原因很明确：sendfile 不适用于代理场景，它根本无法在代理（proxy）路径中生效。

sendfile 的硬性限制决定它不支持代理

• in_fd（源文件描述符）必须指向真实磁盘上的普通文件（如 open("a.jpg", O_RDONLY)），且需支持 mmap；
• out_fd（目标描述符）必须是已建立连接的 socket；
• 不支持任何中间处理环节：不能加密、不能压缩、不能修改数据、不能拼接响应头；
• 更关键的是：它不支持从内存缓冲区、管道、socket 或临时文件描述符（如 tmpfile() 创建的 fd）出发传输。

而代理模式（例如 Nginx 的 proxy_pass、C++ 中用 read + buffer + write 转发上游响应）天然违背以上全部前提：

• 上游响应通常是流式生成的，没有 Content-Length，也没有本地磁盘文件路径；
• 临时文件（如用 mkstemp() 创建后写入的缓存文件）看似符合“磁盘文件”条件，但实际仍难触发 sendfile 零拷贝，因为：
  • 若该临时文件由 O_TMPFILE 或 O_DIRECT 打开 → 内核拒绝 sendfile（errno = EINVAL）；
  • 若文件在 /tmp（tmpfs）上 → 多数内核版本不支持 sendfile 零拷贝路径（退化为 read/write）；
  • Nginx 在 proxy_buffering on 时，即使落盘为临时文件，其内部 I/O 路径也绕过 sendfile 机制，改用常规 copy。

代理场景下真正可行的优化方向

• ✅ 启用 proxy_buffering on + 合理设置 proxy_buffer_size 和 proxy_buffers，减少小包和系统调用次数；
• ✅ 对静态资源走直连（location 匹配后用 root/alias + sendfile on），把代理和静态服务分离；
• ✅ 使用 sendfile 的替代方案：
  • 若临时文件已落盘且确定是 ext4/xfs 上的普通文件，可尝试 copy_file_range()（Linux ≥ 4.5），它比 sendfile 更宽松，支持部分 tmpfs 和跨文件系统；
  • 若需保持代理逻辑，改用 splice() 配合 pipe（要求两端都支持 vmsplice/splice），但对临时文件支持仍有限，且代码复杂度高；
• ✅ 关闭无谓开销：禁用 gzip（否则 Nginx 自动禁用 sendfile）、避免 chunked 响应、确保上游返回 Content-Length（若可能）。

简单验证你是否真能用上 sendfile

运行以下命令观察实际系统调用：

strace -p $(pgrep nginx) -e trace=sendfile,read,write 2>&1 | grep sendfile

如果代理请求全程没出现 sendfile( 调用，说明它压根没走该路径——这不是配置问题，而是架构不匹配。

不复杂但容易忽略：sendfile 是“文件到 socket”的专用快车道，不是代理系统的加速器。