sendfile 支持 range 请求，但需满足文件可读、未启用 gzip、未禁用 max_ranges 等条件，并配合 tcp_nopush on、tcp_nodelay off 及 add_header accept-ranges bytes; 才能稳定生效。
sendfile 本身支持 Range 请求，但某些内核版本、小文件场景或特定组合下可能表现异常——不是它“不兼容”，而是需要避开干扰项、确认启用条件并做针对性验证。
确保 sendfile 正常参与 Range 响应
sendfile 是零拷贝机制，Nginx 在处理静态文件的 Range 请求时，默认会用它直接从磁盘 DMA 传输指定字节段，无需用户态内存中转。前提是：
- 请求含合法 Range: bytes=0-1023 头，且文件存在、可读、大小明确
- 未启用 gzip on 或未加 gzip_disable "range"（压缩会破坏字节边界）
- location 中没写 max_ranges 0 或 slice 指令（二者会绕过原生 range 流程）
- 没用 rewrite、auth_basic 或 satisfy 等拦截指令中断 range 处理链
常见异常与对应调整
若发现 Range 请求返回 200 而非 206，或 Content-Range 缺失，先排查以下典型情况：
- 小文件（如 ：临时设 sendfile off; 测试，确认是否恢复 206；若有效，说明当前内核或文件系统对小范围 sendfile 的 range 支持有偏差
- 启用了 gzip 且未隔离 Range：必须加 gzip_disable "range";，否则 Nginx 可能尝试压缩整个响应体，导致 range 计算失效
- 代理场景中 sendfile 未生效：proxy_pass 不走 sendfile，此时需关注 proxy_buffering 和后端是否真正支持 Range，而非 sendfile 配置本身
协同优化提升稳定性
sendfile 不是孤立参数，需配合其他设置才能在大文件断点续传中长期稳定：
- 开启 tcp_nopush on;：与 sendfile 协同，合并响应头与数据包，减少小包数量
- 设 tcp_nodelay off;：避免 Nagle 算法拆分大块连续数据，适合视频、镜像等流式传输
- 添加 add_header Accept-Ranges bytes;：显式声明能力，增强客户端识别可靠性
- 禁用 expires 或强缓存干扰：避免浏览器复用过期的 200 响应，跳过 Range 请求流程
验证是否真正生效
别只看状态码，要确认底层确实是 sendfile + range 协同工作：
- 用 curl -v -H "Range: bytes=0-1023" https://example.com/file.zip 查看响应头：必须含 Accept-Ranges: bytes、Content-Range、206
- 检查 Nginx error 日志，搜索 "sendfile" "range" 相关报错或警告
- 用 strace -p $(pgrep nginx) -e trace=sendfile64 观察 worker 进程是否实际调用了 sendfile64 系统调用
