Curl 的 timeout（即 --max-time）涵盖整个请求生命周期，包括 DNS 解析、TCP 连接建立及数据传输阶段；而 connect-timeout 仅限制连接建立阶段。二者独立生效，但 timeout 是全局总时限，优先触发。

curl 的 timeout 参数是否包含连接阶段耗时？答案是肯定的：`timeout`（对应 libcurl 的 `curlopt_timeout` 或命令行 `--max-time`）表示从请求发起开始到完成（或失败）的**总耗时上限**，完整覆盖 dns 解析、tcp 握手（即 `connect-timeout` 所约束的部分）、tls 协商以及 http 请求与响应全过程。

在实际行为中，timeout 与 connect-timeout 并非叠加关系，而是嵌套包含 + 独立裁决：

• connect-timeout 仅对“建立 TCP 连接”这一子阶段设限（不含 DNS 解析，默认由 timeout 统一管控，除非显式设置 --dns-timeout）；
• timeout 则作为全局兜底——一旦从 curl_easy_perform() 调用开始计时，任何阶段超时都会触发终止，并返回错误码 28（CURLE_OPERATION_TIMEDOUT）。

可通过实测验证该逻辑：

CurlShip Directory Submission

向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。

下载

# 场景1：全局 timeout=1s，connect-timeout=10ms
$ curl --max-time 1 --connect-timeout 0.01 https://stackoverflow.com
# 输出：curl: (28) Resolving timed out after 10 milliseconds
# → DNS 解析超时（因未设 dns-timeout，归入 timeout 总计时），10ms 时即被 kill

# 场景2：全局 timeout=10ms，connect-timeout=1s
$ curl --max-time 0.01 --connect-timeout 1 https://stackoverflow.com
# 输出：curl: (28) Connection timed out after 10 milliseconds
# → 尽管 connect-timeout 宽松，但全局 timeout 先触发，强制中断

关键结论：
✅ 若仅设置 --max-time N，已天然涵盖连接耗时——无需额外指定 --connect-timeout；
⚠️ 若同时设置两者，connect-timeout 不会延长 timeout 总时限，反而可能因更早触发而提前终止连接阶段；
? 实际开发中推荐优先使用 --max-time 保障端到端 SLA，仅在需精细化控制连接行为（如区分 DNS/Connect/Transfer 超时）时，再配合 --dns-timeout、--connect-timeout 和 --max-time 分层配置。

注意：libcurl 中 CURLOPT_TIMEOUT 默认包含所有阶段，而 CURLOPT_CONNECTTIMEOUT 仅作用于 connect() 系统调用阶段。务必避免将 timeout 设为小于 connect-timeout，否则后者将失效。