curl 下载得到 301 HTML 页面：先检查重定向与最终内容

用 curl 保存压缩包，文件却是一个写着 301 Moved Permanently 的 HTML 页面。curl 默认不会自动跟随 HTTP 重定向，--location（-L）能让它请求 Location 指向的地址。

但如果 Location 本来就指向下载说明页、登录页或错误页，加上 -L 后仍可能得到 HTML。重定向被跟随，与拿到了目标文件，是两项不同的检查。

保存响应链，查看最终地址与状态

下面是 HTTPS 文件下载的示例，适用于 Bash 等 POSIX shell。替换成可信的实际地址，并使用新的输出文件名，避免覆盖已有文件：

curl --fail --location --max-redirs 10 \
  --proto-redir '=https' \
  --dump-header download-headers.txt \
  --output download.part \
  --write-out '\nstatus=%{http_code}\nurl=%{url_effective}\n' \
  'https://downloads.example.net/package.tar.gz'

--location 跟随重定向，--max-redirs 设置跳转次数上限。--proto-redir '=https' 将后续跳转限制为 HTTPS，避免这份 HTTPS 下载自动降级到其他协议。出现协议限制错误时，应检查下载地址与服务配置，不要直接把所有协议都放开。

--output 保存响应体，--dump-header 另存收到的响应头；结尾显示最终响应状态与最终 URL。.part 只是暂存文件名，不代表 curl 会自动判定文件完整，也不会自动续传。网络或其他错误发生后，应检查退出状态，不能因为这个文件存在就继续解压或安装。

--fail 可将通常的 HTTP 400 及以上响应作为失败处理，但不会识别一个返回 200 的 HTML 登录页。还要看最终内容，不能只依赖命令是否返回零。

最终仍是 HTML 时，按页面用途处理

响应链结束后，核对最后一次响应的 Content-Type、最终地址和保存内容。压缩包扩展名只是 URL 或本地文件名，不是响应体格式的保证。

如果最终地址是下载说明页，应在该页面找到实际文件下载入口，或使用服务提供的直接下载接口。curl 的 -L 只跟随 HTTP 响应头里的重定向，不会像浏览器一样自动执行页面 JavaScript，也不会自行点击 HTML 中的链接。

如果最终地址是登录或授权页面，先确认文件确实需要身份验证，再按服务支持的方式取得访问权限。浏览器里能下载，可能依赖已有会话或带时效的下载链接；不要把个人浏览器的完整 Cookie 随意写进公共脚本。

如果最后是 404、410 或业务错误页，可能是文件被移除、链接失效或权限不足。改文件名、增加 -O，都不能把这类页面变成原来的压缩包。

不要为跨站跳转自动转发凭据

重定向可能从主站跳到 CDN，也可能跳到意外地址。先核对目标站点，再处理认证需求；不要为消除失败直接加 --location-trusted，这个选项允许把凭据和其他秘密发给后续主机。

保存的响应头和最终 URL 也可能含 Cookie、签名参数或临时令牌，只在本机受控位置检查。分享排查信息前应去除这些内容，不要把原始头部日志提交到公共仓库。

下载完成后，确认最终响应符合预期、文件格式正确，并按发布方提供的可信校验值或签名核验内容。只有这些检查通过，才把暂存文件纳入解压、安装或部署流程。取得了一段 HTML、跟随完所有跳转，或命令退出为零，都不能单独算下载成功。