Apache通过HTTP/1.1的Range请求和206响应原生支持断点续传,只需确保Accept-Ranges: bytes头存在、禁用压缩与重写干扰,并配合客户端正确发起Range请求即可实现。

Apache 本身不直接提供“流式传输”或“断点续传”的业务逻辑,但它通过标准 HTTP/1.1 协议支持 Range 请求 和 206 Partial Content 响应,这是实现分段下载与断点续传的底层基础。只要文件放在 Apache 静态服务目录下、未被 PHP/脚本拦截,且服务器配置得当,浏览器、curl、wget、Alist、Nextcloud 等客户端就能天然使用断点续传——无需额外开发。
确认 Apache 已启用范围请求支持
Apache 默认开启 mod_headers 和 mod_mime,而核心模块 mod_negotiation 或 mod_mime 会自动为静态文件响应 Accept-Ranges: bytes 头。你只需验证:
- 访问一个大文件 URL(如
https://yoursite.com/files/big.zip),用 curl 检查响应头:curl -I https://yoursite.com/files/big.zip - 若返回中包含
Accept-Ranges: bytes,说明已就绪;若为Accept-Ranges: none或无此头,则需排查。 - 常见禁用原因:启用了某些压缩模块(如
mod_deflate)对大文件误压缩、或使用了不兼容的缓存代理(如 Varnish 未透传 Range)、或文件被 .htaccess 中的重写规则意外代理到后端脚本。
避免干扰 Range 请求的典型配置陷阱
以下配置错误会直接导致断点续传失效:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
-
禁止在静态文件目录启用输出压缩:在站点或目录配置中移除或注释掉
SetOutputFilter DEFLATE或AddOutputFilterByType DEFLATE ...—— 压缩会破坏原始字节偏移,使 Range 定位失效。 -
禁用 ETag 强校验干扰:若使用
FileETag All(默认),Apache 会为每个 Range 响应生成不同 ETag,部分旧客户端可能拒绝续传。建议改为:FileETag MTime Size(保留时间+大小,更稳定)。 -
不要用 RewriteRule 把文件请求重写到 PHP 脚本:例如
RewriteRule ^files/(.*)$ /download.php?file=$1 [L]会绕过 Apache 原生 Range 处理。如需权限控制,请改用mod_authz_core+<filesmatch></filesmatch>限制访问,而非重写。
配合客户端实现可靠断点续传的关键行为
服务端配置只是基础,客户端必须正确发起 Range 请求并持久化进度:
- 首次下载时,客户端发普通 GET 请求获取文件总大小(看
Content-Length头); - 中断后重启,客户端读取本地已下载字节数(如 12345678),然后发带头请求:
GET /big.zip HTTP/1.1<br>Range: bytes=12345678-
; - Apache 收到合法 Range 后自动返回
HTTP/1.1 206 Partial Content,附带Content-Range: bytes 12345678-104857599/104857600; - 客户端将响应体追加写入文件(非覆盖),即可完成续传。
进阶:用 .htaccess 控制大文件行为(可选)
在存放超大文件的子目录下添加 .htaccess,可增强兼容性与安全性:
<IfModule mod_headers.c>
# 显式声明支持字节范围
Header set Accept-Ranges "bytes"
# 禁用对大文件的压缩(仅针对 zip/mp4/mkv 等二进制类型)
<FilesMatch "\.(zip|rar|7z|mp4|mkv|iso|dmg)$">
SetEnv no-gzip 1
</FilesMatch>
# 缓存策略:允许客户端缓存但强制校验(避免 stale 续传)
<FilesMatch "\.(zip|mp4|mkv)$">
Header set Cache-Control "public, max-age=3600, must-revalidate"
</FilesMatch>
</IfModule>

















