curl 报错 28 怎样排查？把连接超时与总等待时间分开
curl 提示 28，首先说明某个超时条件被触发。它没有直接指出是节点、DNS、握手还是正文传输出了问题，也不能仅凭编号认定机场失效。
本文面向已使用 curl 的个人用户，只对允许访问的公开小页面做有限请求。不用登录、付款或上传操作测试超时，也不以不断重试增加负担。
示意图：总时间覆盖整次传输，连接时间只约束其中的连接阶段。
两个时间限制覆盖不同范围
everything curl介绍了连接阶段与整次传输的时间限制；退出码说明将 28 列为操作超时。
按 curl 官方手册，--connect-timeout 覆盖连接阶段，包括所需 DNS 查询以及 TCP、TLS 或 QUIC 握手；连接建立后的正文传输不由这一项单独限制。--max-time 则限制每次传输的总时长。
| 设置 | 回答的问题 |
|---|---|
| connect-timeout | 这次连接最多等多久 |
| max-time | 整次传输最多持续多久 |
| 错误文本与已收字节 | 超时前实际观察到了什么 |
总时长不是在连接时间之外额外赠送的等待时间。如果总限制设置得更短，它可能先被触发。
保存一轮有明确上限的请求
Windows PowerShell 示例：
$target = 'https://example.com/'
curl.exe -q --connect-timeout 8 --max-time 30 -o timeout-check-body.txt -w 'http=%{http_code} bytes=%{size_download} total=%{time_total}\n' --url $target
$LASTEXITCODE
8 秒和 30 秒只是示例诊断预算，并非所有机场的合格阈值。目标换为允许访问的小页面，输出用新文件名；保存控制台的完整错误原文。
-q 用于排除默认配置文件的影响，但环境变量中的代理设置仍需单独核对。要测试本地代理时，明确使用自己客户端提供的实际协议和端口，记录客户端模式。没有记录路径，就不能把结果自动归属给某个节点。
按超时前的观察继续检查
- 先看是否已有 HTTP 响应或正文。 已收到部分正文时，把观察重点放在后续等待；未收到也不能直接推断是 DNS。
- 核对实际超时设置。 完整命令、环境和工具版本要能复查，尤其留意是否另有总时间或低速条件。
- 只做一次单项对照。 同一小页面、网络和节点下，若原连接预算明显不够，可以适度增加连接等待；其他设置保持一致。若已有正文但总时长不足，则单独评估总限制。
- 保留失败结果。 延长后仍失败，记录等待阶段线索，继续核对目标服务与本地路径，不用无限等待代替诊断。
超时后，保存的文件可能只有部分内容；存在文件不等于任务完成。成功验收要同时核对退出状态、目标响应和预期内容。
怎样算定位取得进展
能够说明“哪个限制、超时前是否有响应、改了哪一项、同一任务是否完成”，就有了可用于下一步排障的证据。整理机场推荐中的客户端体验时，写清这轮预算与环境，不把一次超时或一次延长后成功当作长期稳定性证明。
来源与核验日期
官方资料核验日期：2026-10-10。本文的操作与判断方法供读者自行核对，不代表本站对某家机场的实测结论。
评论