sendfile仅加速本地静态文件传输，不适用于proxy_cache代理场景；后者依赖磁盘缓存链路（keys_zone映射、两级目录存储、共享内存查表），通过use_temp_path=off等优化i/o效率。
sendfile 是 Nginx 内核级零拷贝传输机制，只适用于本地文件系统；而代理缓存（proxy_cache）面向的是远程 HTTP 响应体，两者底层路径完全不同——前者绕过用户态内存拷贝，后者必须经由 Nginx 的内存缓冲与磁盘持久化流程。
sendfile 不参与对象存储代理缓存
当 Nginx 作为反向代理访问 OSS/S3 时，所有响应数据都来自上游 HTTP 连接，不是本地文件。此时 sendfile on 完全不生效：Nginx 必须先将上游响应读入内存 buffer，再写入 proxy_cache 磁盘目录，最后从缓存文件中读取并发送给客户端。整个过程无法跳过用户态，sendfile 被自动忽略。
常见误解是“开了 sendfile 就能加速代理”，实际它仅在以下场景起作用：
- 直接提供本地静态资源（如
location /static { root /var/www; }） - 使用
alias或root指向磁盘路径且无代理逻辑 - 启用
directio或aio时需注意与 sendfile 的互斥性
proxy_cache 才是对象存储边缘加速的真正载体
OSS/S3 加速依赖的是完整的代理缓存链路：请求 → 缓存键计算 → 共享内存查表 → 磁盘读取/回源拉取 → 响应封装 → 返回。这个流程中关键环节包括：
-
proxy_cache_path定义的两级目录结构（如levels=1:2）避免单目录 inode 爆炸 -
keys_zone在共享内存中维护 key→cache file 映射，1MB 约支撑 8000 个 key - 缓存文件本身是普通磁盘文件（非块设备直写），由 Nginx 自主管理生命周期
- 即使启用了
use_temp_path=off，仍需经过 open/read/write 系统调用，无法绕过 VFS 层
为什么不能把 OSS 当作“本地文件”来 sendfile？
对象存储本质是 RESTful 服务，没有传统意义上的“文件句柄”或“inode”。即便通过 FUSE 挂载（如 ossfs、s3fs），挂载层也已将 HTTP 请求转译为 POSIX 调用，此时 Nginx 若代理该挂载路径，仍是走 proxy_pass http:// 而非 root，依然不触发 sendfile。
更关键的是：OSS/S3 的 ETag、Last-Modified、Content-Length 等头部由服务端动态生成，Nginx 无法预知文件大小或偏移量，而 sendfile 需要精确的 fd + offset + size 三元组——这在代理模式下根本不可得。
性能优化应聚焦 proxy_cache 本身
替代 sendfile 的有效手段，是强化 proxy_cache 的 I/O 效率和命中率：
- 禁用临时路径：
use_temp_path=off减少一次 write+rename 文件系统操作 - 合理设置
inactive（如3d）主动清理冷数据，避免磁盘碎片 - 用
proxy_cache_use_stale提升异常时可用性，降低用户感知延迟 - 配合
X-Cache-Status头做可观测性，快速定位缓存未命中原因
