sendfile 是 CDN 边缘节点中提升静态资源分发效率的关键内核级优化，仅对磁盘真实静态文件生效，需配合 tcp_nopush、禁用压缩及合理缓存策略协同使用。
在 CDN 边缘节点中部署 Nginx 时，sendfile 是提升静态资源分发效率的关键内核级优化，但它不能孤立启用——必须与 CDN 缓存逻辑、文件特性及系统能力协同设计，否则可能无效甚至引发兼容问题。
明确 sendfile 的适用边界
该参数仅对磁盘上真实存在的静态文件（如 CSS、JS、图片、字体）生效，且要求：
- 文件由
location中的root或alias直接服务，而非经proxy_pass转发； - 响应状态码为 200/206（非重定向、非错误页）；
- 未启用
gzip或brotli压缩（压缩需用户空间处理，会绕过 sendfile）； - 底层文件系统支持（ext4/xfs 均支持，NFS/CIFS 等网络文件系统通常不支持零拷贝）。
CDN 边缘节点中的典型配置组合
以阿里云或自建边缘节点为例，Nginx 配置应聚焦“强缓存 + 零拷贝 + 快速响应”三位一体：
- 全局启用：
sendfile on;（默认关闭，必须显式开启）； - 配合 TCP 优化：
tcp_nopush on;（让 sendfile 发送完整包，避免小包堆积）； - 禁用无意义头：
tcp_nodelay off;（与 tcp_nopush 协同，避免 Nagle 算法干扰大文件传输）； - 静态资源 location 示例：
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2|ttf)$ {<br> root /var/www/cdn/;<br> expires 1y;<br> add_header Cache-Control "public, immutable, max-age=31536000";<br> sendfile on;<br> tcp_nopush on;<br> # 不加 gzip，避免破坏零拷贝<br>}规避常见失效场景
CDN 边缘节点常因以下原因导致 sendfile 实际未生效：
-
启用了 proxy_pass：若边缘节点只是反向代理源站（而非本地托管），
sendfile完全不参与，此时应优化 upstream 连接复用和 keepalive； -
文件被动态生成或带查询参数：如
/logo.png?v=123，Nginx 默认不缓存带参数 URI，也不会触发 sendfile（除非配置了try_files映射到真实文件）； -
内核或网卡不支持 SG-DMA：可通过
ethtool -k eth0 | grep scatter-gather检查，不支持时 sendfile 仍有效（1次拷贝），但无法达到最优性能； -
使用了 open_file_cache 但未配 valid：文件句柄缓存失效会导致反复 open/close，抵消 sendfile 优势，建议搭配
open_file_cache_valid 60s;。
与 CDN 缓存策略联动
sendfile 是传输层加速，而 CDN 加速依赖的是缓存命中。二者需统一设计：
- 浏览器与边缘节点都应设置长缓存（如
max-age=31536000），减少回源，让 sendfile 更高频调用； - 资源发布务必带哈希指纹（如
app.a1b2c3d4.js），确保更新后 URL 变更，避免旧缓存阻塞新文件的 sendfile 服务； - 对不支持缓存的路径（如
/api/或带 Cookie 的资源），直接 bypass sendfile 配置，改用 proxy_buffering + keepalive 优化回源链路。
