Nginx零拷贝需同时启用sendfile on和tcp_nopush on，并满足location显式配置、响应为真实磁盘文件、含Content-Length三前提；仅适用于静态API文件服务或反向代理中的缓冲区指针复用，gzip、sub_filter、directio等均会使其失效。
Nginx 的零拷贝不是万能加速开关，它只在特定路径下生效，核心是绕过用户态内存拷贝，把数据从磁盘或内核缓冲区直接送入网络协议栈。真正起作用的不是单个指令，而是一组配置与运行时条件的协同。
必须同时启用的两个基础配置
单独打开其中任意一个都无效：
- sendfile on;：启用内核级 sendfile() 系统调用，这是零拷贝的入口开关，但仅对真实磁盘文件有效
- tcp_nopush on;：配合 sendfile 使用，确保响应头和文件首段能合并进一个 TCP 包发送；若 sendfile 未生效，该指令会被 Nginx 忽略并记录警告
真正生效的三个硬性前提
配置写对只是第一步，每次响应时 Nginx 都会动态校验，缺一不可：
- 当前 location 块中显式声明了 sendfile on（server 或 http 块中的设置可能被覆盖）
- 响应内容来自真实磁盘上的常规文件（如 /data/api/spec.json），不支持管道、设备文件、NFSv3 或加密文件系统
- 响应头中必须包含 Content-Length 字段——Nginx 需提前知道大小才能调用 sendfile()；动态生成、chunked 编码或流式响应会直接回退到 read/write 模式
API 场景中实际可用的两类情况
零拷贝不参与业务逻辑，只优化传输链路：
- 静态 API 响应文件服务：例如 OpenAPI 规范文件（/api/v1/openapi.json）、预生成的 JSON 模板、版本说明等，用 location + root 直接返回，此时 sendfile 可全程生效
- 反向代理转发中的“逻辑零拷贝”：当 upstream 返回响应后，Nginx 使用 ngx_buf_t 和 ngx_chain_t 缓冲区链表复用指针，避免内存复制；但这不是内核级 sendfile，而是用户态的高效引用传递，适用于大多数 API 网关场景
常见导致零拷贝失效的操作
这些功能一旦启用，无论配置多规范，都会强制退出零拷贝路径：
- 开启 gzip on 或 gzip_static on（压缩必须读取并处理内容）
- 使用 sub_filter、access_by_lua_block、proxy_buffering on
- 响应被子请求（subrequest）修改，或通过 add_header 设置了影响缓存/编码的头部
- 启用了 directio 4m（O_DIRECT 绕过 page cache，与 sendfile 互斥）
