开启sendfile后下载进度条卡住或中断，主因是其绕过用户态缓冲导致Content-Length错误、gzip冲突或内容改写模块互斥；需检查响应头准确性、禁用不兼容模块并确保静态文件直服务。
开启 sendfile 后客户端下载进度条卡住或提前中断，通常不是 sendfile 本身的问题，而是它与某些 Nginx 配置、后端行为或客户端特性交互时引发的副作用。核心原因在于 sendfile 绕过用户态缓冲，直接由内核在文件描述符间拷贝数据，导致部分依赖用户态控制流的机制失效。
检查是否启用了不兼容的响应头或过滤模块
sendfile 与以下配置存在已知冲突：
-
add_header或more_set_headers在响应体生成前动态注入头信息：Nginx 可能因无法预知完整响应长度而错误设置Content-Length，尤其当启用gzip或chunked时； -
启用
gzip on且文件未预压缩：sendfile和gzip不能同时用于动态压缩（Nginx 会自动禁用sendfile，但若配置不当可能残留半生效状态）； -
使用
sub_filter、echo、lua_content_by_lua*等内容改写模块：这些模块需要读取并修改响应体，与sendfile的零拷贝路径互斥，Nginx 通常会静默回退，但某些版本可能行为异常。
确认 Content-Length 是否准确且未被覆盖
进度条卡住最常见原因是浏览器收不到正确的 Content-Length，导致无法计算百分比或误判结束。开启 sendfile 时需确保：
- 静态文件由
location直接服务（如root+try_files），Nginx 才能从文件系统获取真实大小并设置Content-Length； - 避免在
location中使用proxy_pass后又强制开启sendfile on：上游响应若无Content-Length或为Transfer-Encoding: chunked，Nginx 无法安全启用sendfile，应关闭； - 用
curl -I检查响应头，确认Content-Length存在且值等于文件字节数，且没有Transfer-Encoding: chunked并存。
排查内核与 TCP 栈相关限制
极少数情况下，sendfile 触发底层传输异常：
-
TCP 窗口缩放或延迟 ACK 导致大文件传输卡顿：可在 Nginx 中添加
tcp_nopush on（配合sendfile on使用）和tcp_nodelay on（对小响应更友好，但大文件下载建议关掉nodelay）； -
Linux 内核
net.ipv4.tcp_sack或net.ipv4.tcp_dsack异常：在高丢包网络下可能引发重传混乱，可临时关闭测试：sysctl -w net.ipv4.tcp_sack=0； -
文件大于 2GB 且文件系统不支持 largefile：老内核或 XFS/ext3 未启用 largefile 支持时，
sendfile可能截断或返回错误，表现为下载到某位置停止。
快速验证与临时规避方案
无需彻底关闭 sendfile，可按顺序尝试：
- 在对应
location块中显式写sendfile off;，观察问题是否消失——若恢复，则确认是sendfile相关； - 关闭
gzip、移除所有add_header/sub_filter，仅保留最简静态服务配置，再开sendfile测试； - 换用
output_buffers 1 128k;+sendfile on;，增大内核发送缓冲，缓解突发拥塞； - 对大文件下载，改用
X-Accel-Redirect由后端控制，Nginx 仅做轻量转发，绕过sendfile路径。
本质上，sendfile 是个高效但“不透明”的优化，它要求响应流程足够简单、头信息可预测、后端行为确定。只要路径干净，它极少出问题；一旦混入动态处理、压缩或流式响应，就容易暴露边界情况。定位时优先看响应头和模块组合，而非怀疑内核或网络。
