sendfile 对反向代理无效，因其要求一端为文件句柄、另一端为 socket，而 proxy_pass 等指令使 upstream 变为 socket，迫使 nginx 回退到 read()+write() 模式；仅当 nginx 直接服务本地静态文件时才生效。
sendfile 配置对 Nginx 反向代理性能没有提升作用，它在 proxy_pass、fastcgi_pass 或 grpc_pass 存在的 location 中完全失效。
为什么 sendfile 在反向代理中不生效
sendfile 是内核提供的零拷贝系统调用，要求一端是磁盘文件句柄，另一端是网络 socket。而反向代理时，Nginx 的 upstream 是另一个 socket —— 数据从后端服务经用户态缓冲再发给客户端，不存在“磁盘直连网卡”的路径。这是协议层和架构设计决定的限制，不是配置错误或参数没调好。
- 只要 location 块里有 proxy_pass，无论后端返回的是 HTML、JS 还是图片，Nginx 都会退回到 read() + write() 模式
- 即使显式写上 sendfile on;，strace 也捕获不到 sendfile64() 系统调用
- 某些人误以为“反代缓存目录里的静态文件”能触发 sendfile，实际只要走 proxy 流程，就绕不开用户态中转
真正能用上 sendfile 的场景
仅限 Nginx 直接读取本地磁盘文件并响应客户端，不经过任何 upstream 转发：
- 用 root 或 alias 指向真实物理路径，例如 root /var/www/dist;
- 匹配静态资源扩展名，如 location ~ \.(js|css|png|woff2)$ { ... }
- 不启用内容改写（如 sub_filter）、不注入动态头、不启用 gzip_static 或 brotli 预压缩
反向代理场景下的替代优化方向
既然 sendfile 不可用，应聚焦代理链路本身：
- proxy_buffering off：适合大文件流式传输，降低首字节时间（TTFB），避免整包缓存
- 调大缓冲区：如 proxy_buffer_size 128k; proxy_buffers 8 128k;
- 延长超时：如 proxy_read_timeout 300;，防止大响应体被中断
- 启用 open_file_cache：若使用 proxy_store 或自建本地缓存目录，可加速文件元数据访问
- 优先用 proxy_cache 替代手动暂存：支持 key 定制、过期控制、内存+磁盘两级缓存
如何验证是否真走 sendfile 路径
不要只看配置，要观察运行时行为：
- 用 strace -e trace=sendfile64 -p $(pgrep -f "nginx: worker")，请求一个静态资源，看是否有系统调用输出
- 检查响应头：若含 X-Accel-Buffering: no 或 Content-Length 存在且无 Transfer-Encoding，是潜在信号
- 对比 CPU 使用率：高并发小文件下，开启 sendfile 后 worker 进程 %CPU 应明显下降
