sendfile对反向代理完全无效，仅在Nginx直服务本地静态文件时生效；一旦启用proxy_pass等指令，Nginx必回退至read()+write()模式，无法触发零拷贝。
开启 sendfile on 对反向代理后端的动态请求完全无影响——它根本不会作用于这类请求。
sendfile 与反向代理互斥是设计事实
sendfile 是内核提供的零拷贝系统调用，要求一端是磁盘文件句柄、另一端是网络 socket。而反向代理（proxy_pass）场景中，Nginx 的 upstream 是另一个 socket，数据必须经用户态缓冲区中转：从后端读取 → 存入内存 → 再写入客户端 socket。这条路径天然无法触发 sendfile。
- 只要 location 块里出现
proxy_pass、fastcgi_pass或grpc_pass，Nginx 会立即回退到read() + write()模式 - 即使全局或该 location 下写了
sendfile on，strace 也看不到sendfile64()系统调用 - 动态请求（如 PHP/Java/Node.js 接口）本身不走文件系统，更不可能进入 sendfile 路径
真正受影响的是静态资源直出路径
sendfile 只在 Nginx 自己读取本地真实文件并直接响应时生效，例如：
location ~ \.js$ { root /var/www/app; }location /images/ { alias /data/pics/; }- 且未启用
gzip on、sub_filter、etag等需修改响应体的模块
如何确认 sendfile 是否真在工作
别依赖配置开关，看运行时行为：
- 用
strace -e trace=sendfile64 -p $(pgrep -f "nginx: worker")抓取 worker 进程，再请求一个静态资源，观察是否有输出 - 对比高并发小文件请求下 CPU 使用率：开启且生效时，worker 进程 %CPU 应明显下降
- 检查响应头是否含准确
Content-Length，且无X-Accel-Buffering: no等干扰信号
动态请求性能瓶颈不在 sendfile
反向代理动态内容的耗时主要来自：
- 与后端建立连接的延迟（
proxy_connect_timeout） - 等待后端响应的时间（
proxy_read_timeout） - 缓冲区大小不足导致多次拷贝（
proxy_buffer_size、proxy_buffers） - HTTP/1.1 keepalive 未开启，频繁重连
优化方向应聚焦代理链路本身，比如启用 proxy_buffering off 降低 TTFB，或用 proxy_cache 缓存高频接口响应，而非调整 sendfile。
