curl 续传报错 33：HTTP server does not seem to support byte ranges

下载中断后再次运行，curl 先显示 Resuming transfer from byte position ...，随后报错：

curl: (33) HTTP server does not seem to support byte ranges. Cannot resume.

这时客户端想从本地文件已有长度之后继续获取数据，但本次响应没有满足续传要求。仅增加重试次数，不能让不合适的响应变成正确的剩余文件内容。

这里针对 HTTP 或 HTTPS 文件下载，包括 curl -C - 以及在背后调用 curl 续传的下载工具。示例中的 --proto-redir 需要 curl 7.21.0 或更新版本。先保留现有半成品，不要根据错误文字直接断言整个站点永远不支持 Range，也不要在不清楚缓存归属时删除一整个临时目录。

本地长度决定了请求的起点

--continue-at -（简写 -C -）让 curl 根据输入或输出文件确定恢复位置。下载时，指定输出文件已有的长度会参与确定续传起点。因此需要先确认这个文件确实是同一个资源的前半段，而不是旧版本、错误页面或另一条下载留下的文件。

例如，下面是续传调用的结构，只有确认 package.part 属于该地址对应的同一版本文件后才适用：

curl --continue-at - --output package.part \
  'https://downloads.example.com/package.tar.gz'

地址和文件名都是占位示例。不要把 -C - 当作“curl 自动证明已有部分正确”；文件大小相同，也不能证明内容一致。

如果上层工具自动续传，先找到它本次实际使用的输出路径和命令。不要看到文件名相似就删除，也不要在工具仍写文件时并发运行第二个下载进程。

核对这次响应，而不是只看 Accept-Ranges

在允许重复 GET 的受控下载场景，先保留半成品副本，再给原有续传命令增加独立响应头文件，例如：

curl --dump-header resume-headers.txt \
  --continue-at - --output package.part \
  'https://downloads.example.com/package.tar.gz'

resume-headers.txt 应使用可新建的文件名。此命令仍会发起续传，满足条件时也会继续写输出文件，所以备份和确认资源身份要在前面完成。头部可能包含 Cookie 或带签名的跳转地址，只在受控位置查看。

正常的单段范围响应使用 206 Partial Content，并用 Content-Range 说明返回的起止位置。若 GET 返回了完整的 200 响应，不能把它直接追加到已经有内容的文件末尾。服务可以忽略 Range，请求经过代理或跳转也可能取得不同响应。

416 Range Not Satisfiable 则需要核对请求起点与当前资源长度。它可能涉及已到文件末尾、远端资源变短或本地文件不匹配，不能直接视为文件已完整。收到 Accept-Ranges: bytes 也不是后续每次请求必定成功的保证，仍要看实际响应。

如果响应是重定向、登录页或错误资源，先纠正下载入口和授权。不要为了“让 33 消失”把 HTML 拼到压缩包后面，也不要用 --range 与 --continue-at 同时指定恢复方案；这两个选项不能在同一次传输中组合使用。

无法可靠续传时，保留旧文件并重新完整下载

确认地址、权限和版本正确，但无法得到所需范围响应时，选择一个未使用的新文件名，去掉续传选项重新下载：

curl --fail --location --proto-redir '=https' \
  --output package.full.download \
  'https://downloads.example.com/package.tar.gz'

这适用于原始地址及允许跳转目标都应使用 HTTPS 的文件。先确认有足够空间保存新旧两份文件；命令中的输出文件必须尚不存在，避免覆盖旧文件。完整下载会重新消耗带宽和时间，不能把这个代价隐藏在无限重试中。

--location 用于跟随正常下载跳转，--fail 将通常的 HTTP 错误作为失败。它们不会识别所有返回 200 的错误页面，因此成功退出后还要核对文件类型、预期版本和发布方可信的校验值或签名。

不要用 shell 的 >> 将新响应接到旧文件后，也不要手动把本地长度改成某个猜测值。只有确认字节范围与资源身份正确，拼接才有意义；否则完整重新获取更容易验证。

下载由包管理或构建工具管理时，应使用它支持的单个文件缓存重取方式，或先停止任务并核对那一份缓存的确切路径。不要照抄针对其他机器的缓存删除命令，更不需要清空所有包缓存或删除已安装程序。

验收文件后再替换旧产物

确认 curl 成功结束只是第一步。完成可信校验、确认这是预期安装包或数据文件后，再按原工作流替换待使用文件；失败或未校验的新文件不能进入解压、安装或部署步骤。

原半成品在问题查清前可以保留，避免丢失诊断依据。若新地址或参数不合适，恢复先前保存的下载配置；不需要通过恢复一段未经验证的文件内容来回退。反复得到同样的范围错误时，应保留实际状态码、范围响应及工具版本，针对下载源或中间代理处理，而不是继续增加重试次数。