curl 的连接超时和总超时怎么设？别把两种等待混在一起

用 curl 检查机场节点时，--connect-timeout 和 --max-time 经常被写成同一个值。它们约束的阶段不同：前者限制建立连接所允许的时间，后者限制整个操作的总时间。设置不当会让慢下载被误判成连不上，或者让失败脚本等得过久。

两个时间分别管什么

curl 官方手册说明，连接超时覆盖连接阶段；对 HTTPS 来说，这一阶段还包括需要完成的协议握手。--max-time 则是整个传输从开始到结束的上限。总超时应大于连接超时，否则较小的总上限会先终止请求。

先用一个无副作用的公开地址做基线：

curl.exe --connect-timeout 5 --max-time 20 -o NUL -sS `
  -w "code=%{response_code} connect=%{time_connect} first=%{time_starttransfer} total=%{time_total}\n" `
  "https://example.com/"

macOS 或 Linux 把 NUL 换成 /dev/null。这里的 5 秒和 20 秒不是通用标准，而是一组便于观察的起点。

用症状调整，而不是随意加大

经常在连接阶段失败，但成功轮次的连接时间接近上限：先比较另一网络或节点，再小幅增加连接超时。
连接很快，首字节也很快，但大文件中途终止：连接超时无关，应检查总超时、吞吐和文件大小。
DNS、TCP、TLS 任何一段都可能占用连接前的等待。仅凭“超时”文字，不足以认定机场节点离线。

将 --max-time 无限加大也不是修复。无人值守任务会因此堆积；交互式请求则让用户长时间没有结果。合理做法是先为单次操作设上限，再为整个重试流程设预算。

三组测试定位边界

对同一 URL、同一节点连续执行三组：连接/总超时分别设为 3/15、5/20、8/30 秒，每组 3 次。记录成功次数、退出码和三个时间变量。若只在放宽连接超时后恢复，问题集中在建连阶段；若都能连接但总耗时逐渐拉长，关注正文传输；若三组都随机失败，再检查网络切换、丢包或目标站稳定性。

不要把需要上传、付款或提交表单的地址用于自动重试。测试应选择安全、可重复、不会改变服务器状态的 GET 或 HEAD 请求。

验收方法

最终配置应满足：正常网络下绝大多数请求远低于上限；故障时能在可接受时间内退出；日志能区分连接失败与总时限耗尽；换节点或换网络时仍沿用同一测试条件。这样得出的机场推荐证据才可以复查。

参考资料

curl 官方手册：--connect-timeout、--max-time 与 --write-out

curl 的连接超时和总超时怎么设？别把两种等待混在一起