代理下载中断后能续传吗？HTTP 206、416 与文件版本排查

通过代理下载文件，中断后能不能接着下载，主要看下载工具和文件服务是否支持续传，以及远端文件有没有变化。换一个机场节点，可以改变后续连接的路径，却不会自动让服务器支持断点续传。先看续传请求得到的响应，再判断是否需要重下，比反复点击“继续”更有依据。

作者：小六｜资料核对日期：2026年10月14日。本文讨论 HTTP、HTTPS 文件下载的范围请求；网盘应用的分块协议、加密缓存和专属恢复机制，应按对应软件说明处理。

一、断点续传不是把旧连接接回来

普通 HTTP 续传可以用 Range 请求文件的一部分。下载工具保留已收到的片段，再向服务端请求缺少的内容；这与让已经断开的连接继续存在，是两回事。原理见 MDN 的范围请求说明。

节点切换后，旧任务是否被中断，是连接状态的问题；中断后能否取得剩余文件，是文件服务与下载工具的问题。前一种情况可参考本站切换节点与旧连接的区别，本篇重点检查后一种。

续传时观察到的响应	含义与检查方向
206 Partial Content	返回部分内容，继续核对其范围与文件版本
200 OK	按完整资源响应，可能忽略了范围请求，也可能是验证条件不满足
416 Range Not Satisfiable	无法满足所请求范围，核对偏移位置与当前资源长度

这些状态用于区分响应，不是节点质量分数。206 也不能单独证明工具已经正确保存每个片段；出现 200 时，更不能把返回的完整文件直接追加到旧文件末尾。

MDN 的范围请求说明介绍了这些状态。HTTP 标准允许服务端忽略范围请求，所以“网站能下载”不等于“该文件在当前条件下一定能续传”。

Accept-Ranges: bytes 表示服务端对该资源提供字节范围支持的线索，但不是后续响应的保证。标准还允许客户端在没有收到这个字段时发起范围请求。因此，缺少它也不能单凭这一项认定绝对无法续传，最终仍应核对实际响应。见 RFC 9110 的 Accept-Ranges 规定。

如果工具能够展示响应信息，可进一步看 Content-Range。例如：

Content-Range: bytes 1000-1999/5000

这是字段读法示例，不是实测数据：响应包含从零编号的第 1000 至 1999 字节，资源总长度为 5000 字节。部分响应的 Content-Length 描述本次响应体长度，不能直接当成整个文件大小。字段解释见 MDN 的 Content-Range 文档。

记录下载工具、目标文件、已下载大小、中断时间和具体提示。保留软件自己的未完成文件及任务信息，不先删除缓存或把临时文件改名成正式文件。

还要区分“连接中途断开”和“继续时取得了错误响应”。如果下载工具连代理入口都没有接通，应先查客户端；如果返回的是登录页或授权提示，应回到文件服务核对访问条件，范围设置不能替代授权。

文件名相同，不保证内容相同。If-Range 可让范围请求附带验证条件：符合条件时请求相应部分，不符合时改为获取当前完整内容。其比较有标准要求，不能随便把一个弱 ETag 或猜测时间写进去。见 RFC 9110 的 If-Range 说明。

一般用户不需要手写这些请求头，优先使用工具支持的恢复机制。服务方若更新了文件，应让工具按新版本处理，不把旧片段与新内容强行拼接。实际大小、版本提示和发布方的文件信息，都可以作为检查线索。

固定同一个文件、工具和可用节点，按软件支持的方式继续任务，记录新提示。如果得到 416，先看请求位置是否超过当前文件长度，以及任务记录是否仍对应这份文件。不要只凭 416 宣布“已下载完整”，也不要靠连续换节点修改进度判断。

如果只能重新下载，保留原任务记录，按工具说明另行获取，避免覆盖唯一的片段文件。完成后用软件校验或发布方提供的校验信息确认结果；文件能打开一次，也不能替代完整性检查。

多线程下载可能同时请求多个范围，但不能让一个不支持范围的服务自动支持它。增加线程还会改变连接数量，排查时应先减少变量，用软件支持的单任务方式观察结果。

如果工具不展示请求细节，就记录它的恢复提示、文件大小与服务方说明，不伪造“服务器返回 206”的结论。确需进一步调查时，应使用软件自己的诊断方式，只保留必要的脱敏信息。

不能这样判断。先看工具有没有保留旧任务、续传请求是否实际发出，以及文件服务返回了什么。连接路径变化与文件恢复能力，需要分别核对。

大小只是一项线索，不能证明片段顺序和内容正确。尤其不要手工把多次下载结果直接拼在一起。根据来源提供的校验信息及工具处理结果确认，更有依据。

欢迎带着下载工具名称、中断或恢复阶段、响应状态和脱敏后的范围信息交流，不必发送带授权参数的下载链接或私人文件：Telegram 联系我。