Linux curl 命令：检查 HTTP 响应、退出码与下载结果
curl 根据 URL 请求或发送数据，可检查 HTTP 响应、调用 API 或下载文件。判断请求是否成功时，要同时看 curl 的退出码、HTTP 状态与实际内容，不能只凭命令没有报错或屏幕上出现 200。
对常见 HTTP GET 请求，curl 默认把响应正文写到标准输出；进度与错误通常走标准错误。-L 跟随重定向，-o 指定保存位置，-f 则让常见 HTTP 错误作为失败返回，但这些参数的作用需要分开理解。
基本语法与运行环境
curl [options] URL这是说明性语法，options 与 URL 应换成实际参数。先用 curl --version 查看版本、支持协议与 TLS 后端，再用 man curl 或 curl --help all 核对选项。不同构建不一定支持相同功能。
URL 中出现 & 等 shell 特殊字符时应适当引用，避免参数被 shell 拆开。本文命令使用 Linux shell 写法；Windows PowerShell 中还应确认 curl 实际调用的是可执行文件还是别名，不直接混用丢弃输出的设备名。
HEAD、正文与文件保存
查看响应头。对 HTTP URL，-I 使用 HEAD 请求：
curl -I https://example.com/HEAD 不下载普通响应正文，但服务器可能拒绝该方法，或对 HEAD 与 GET 采用不同处理。因此遇到 403、405 等情况，应结合 GET 或浏览器重新确认，不能据此直接认定 URL 不存在。需要 GET 的头部时，可用 -D 保存响应头，而不是把 -X HEAD 当成 -I 的替代。
跟随重定向并检查错误。
curl -fL https://example.com/-L 依据重定向响应再次请求新位置；它不是浏览器，不会自动执行网页 JavaScript。-f 在通常的 HTTP 400 及以上响应中返回错误 22 并抑制正文，认证协商等仍有例外。业务脚本还应检查预期状态与响应格式，而不是认为启用 -f 后就能识别所有业务失败。
把正文保存到指定文件。
curl -fL -o example.html https://example.com/example.html 是当前目录下的本地文件，已有文件可能被覆盖。建议在独立目录中检查下载结果，确认状态、内容及所需完整性信息后再用于后续步骤。下载中途失败仍可能留下不完整文件；不要只凭文件存在就认定下载成功。
仅显示状态与分别判断失败
下面以 Linux 的 /dev/null 丢弃正文，再由 -w 输出状态：
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com收到相应正常响应时，输出格式可为：
200这行是状态格式示例，不保证 example.com 在任何环境都返回同一结果。200 表示服务器给出该状态，并不能证明正文就是预期页面、登录已成功或接口业务已完成。此命令没有 -L，遇到重定向时通常显示当前响应的 3xx；加 -L 后应结合最终状态及有效 URL 判断。
-s 隐藏进度和错误信息，-S 在与 -s 合用时恢复错误显示，所以 -sS 不是忽略错误。网络或 TLS 阶段未取得有效 HTTP 状态时，-w 可能输出 000；000 不是服务器发送的 HTTP 状态码，应读取标准错误并同时检查退出码。
默认收到 404、500 等 HTTP 回答时，curl 传输仍可能退出 0。需要错误正文时可用 --fail-with-body，它从 7.76.0 起提供，在这类 HTTP 错误时保留正文并返回 22；它与 -f 互斥，不要同时添加。HTTP 状态、传输退出码和业务结果是三个检查层次。
2026 年 11 月 5 日，在 Windows Git 的 curl 8.19.0 与临时 Python 回环 HTTP 服务中，实际对比了 404 默认退出 0、-f 退出 22 且无正文、--fail-with-body 退出 22 且保留正文；同一地址的 HEAD 405 与 GET 200 也得到确认。结束本地服务后的检查超时退出 28 并显示 000。这是 Windows 本地 HTTP 验证，不是 Linux 原生或公网 HTTPS、证书与认证验证。
主要选项与易混点
| 选项 | 作用与注意点 |
|---|---|
-I |
对 HTTP 使用 HEAD 查看响应头，不等于 GET 一定可用。 |
-L |
跟随重定向，需留意最终位置、请求方法和敏感信息。 |
-o file |
指定本地文件名，确认覆盖与失败后残留文件。 |
-O |
从 URL 提取文件名保存，不会默认采用 Content-Disposition 的名称。 |
-f |
通常将 HTTP 400 及以上作为错误 22，并抑制正文。 |
-H header |
添加或修改请求头，不能把令牌直接暴露到日志。 |
-o 和大写 -O 不能混淆。需要可控文件名时优先明确 -o；不要假设远程文件名可信或不会覆盖本地内容。本文文件示例只保存正文，不会自动创建缺失的父目录。
-L 对 GET 检查很方便，但对带数据的请求要核对重定向语义：POST 在某些 301、302、303 响应后可能转为 GET，不能把所有重定向当作原样重发。也不要为了跨主机继续认证而随意启用 --location-trusted；应先确认目标和凭证范围。
检查顺序与敏感信息
- 确认 URL、协议、所需 HTTP 方法和预期结果，先进行获准的只读请求。不要把陌生 URL 下载的脚本直接通过管道交给 shell。
- 保留退出码、标准错误和 HTTP 状态，必要时把正文另存文件后检查。使用 -w 时，避免把正文与状态混在一起解析。
- 请求等待过长时，用 --connect-timeout 控制连接阶段，用 --max-time 控制单次传输的总时间；若另有重试，还应考虑整体耗时。在交互终端中可按 Ctrl+C 停止。
- 检查认证、代理、TLS 和重定向条件。-k 会跳过证书验证，不应用它掩盖证书或信任配置问题；应修复证书链、名称或可信来源配置。
命令行中的令牌可能进入 shell 历史与进程列表，-v 或跟踪输出也可能包含敏感头部和正文。使用访问受限的配置或站点规定的凭证方式，并在保存或分享诊断记录前检查敏感数据；不要把真实凭证写进示例命令。
常见问题
为什么收到 404，curl 却看起来成功？
因为默认规则主要反映传输是否完成，不把 HTTP 4xx、5xx 一概视为传输失败。按需要使用 -f 或 --fail-with-body，并检查具体 HTTP 状态和正文，避免把错误页面当成有效结果。
官方文档
curl 官方命令手册列出失败处理、重定向、输出、超时与证书选项。页面对应的版本可能比发行版自带 curl 新，运行前应核对本机支持项。
