curl返回 Operation timed out 或退出码28，表示操作在设定的时间限制内没有完成。这条错误只说明超时发生，不能直接证明是目标服务器宕机、DNS故障或本机网络慢。
一次HTTPS请求会依次经历名称解析、建立TCP连接、TLS握手、等待首字节和接收内容。正确处理方式是先测出时间消耗在哪个阶段，再调整网络、服务或超时策略。
先记录完整错误与实际超时时间
保留详细输出和curl版本，不要只截取最后一行：
curl –version curl -v –connect-timeout 10 –max-time 30 \ https://example.com/ -o /dev/null
--connect-timeout限制连接阶段，--max-time限制整个操作。脚本、环境变量或封装SDK可能已经设置超时，必须记录实际命令和数值。
用时间指标区分卡在哪一步
curl可以输出各阶段耗时：
curl -sS -o /dev/null \ –connect-timeout 10 –max-time 30 \ -w ‘dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\ncode=%{http_code}\n’ \ https://example.com/
名称解析耗时高应检查DNS；TCP连接增长可能与路由、防火墙或服务监听有关；TLS阶段异常应检查证书与握手；首字节很慢通常需要继续看上游应用。
这些时间值需要在同一网络条件下多次采集，单次结果只能作为线索，不能当成稳定基线。
分别验证DNS和目标地址
先确认名称解析结果：
getent ahosts example.com resolvectl query example.com dig +time=2 +tries=1 example.com A
要绕过当前DNS结果进行对照，可让curl把域名临时映射到指定地址，同时保留TLS主机名：
curl –resolve example.com:443:203.0.113.10 \ –connect-timeout 10 –max-time 30 \ https://example.com/ -o /dev/null
不要长期把生产域名硬编码到IP。 CDN、负载均衡和证书路由可能依赖域名，--resolve适合受控诊断，不是永久配置。
检查TCP端口与网络路径
连接阶段超时时，确认本机路由和目标端口：
ip route get 203.0.113.10 nc -vz -w 5 example.com 443 traceroute -T -p 443 example.com
云安全组、本机防火墙、出口ACL、代理和目标服务监听都可能丢弃连接。端口测试成功只证明TCP握手可完成，不代表TLS、HTTP或后端应用一定正常。
检查TLS握手与代理环境
HTTPS在TCP之后还要完成TLS握手。可以查看握手信息，并检查curl是否使用代理：
openssl s_client -connect example.com:443 \ -servername example.com -brief env | grep -iE ‘^(http|https|all|no)_proxy=’
错误代理、代理认证、SNI不匹配或中间设备检查都可能拖慢握手。不要用 -k 把证书校验永久关闭，证书错误与超时应分别定位。
连接成功后仍可能卡在首字节
若DNS、TCP和TLS都很快，但 time_starttransfer明显增长，应查看目标服务的访问日志、反向代理日志、应用队列和数据库等待。可先只请求响应头作对照：
curl -sS -D – -o /dev/null \ –connect-timeout 10 –max-time 30 \ https://example.com/health
需要隔离不同地区的网络路径时，可在 萤光云 准备测试节点，或使用 LightNode 按小时创建对照服务器。测试应使用健康检查或受控URL，不要对生产接口制造额外压力。
合理设置连接和总超时
交互请求通常需要较短失败时间，批量下载则可能允许更长总时限。示例：
curl –connect-timeout 5 \ –max-time 60 \ –retry 2 \ –retry-delay 2 \ https://example.com/file -o file
重试会增加总流量，并可能重复非幂等操作。curl还支持低速检测，可在传输长期低于阈值时终止：
curl –speed-limit 1024 –speed-time 30 \ –max-time 300 https://example.com/file -o file
超时值应来自业务允许的延迟和实测分布，不应为了消除错误无限放大。
修复后怎样验收
从原故障网络重复执行同一URL与相同参数，记录状态码、各阶段时间和退出码：
curl -sS -o /dev/null \ –connect-timeout 10 –max-time 30 \ -w ‘exit_ok code=%{http_code} total=%{time_total}\n’ \ https://example.com/
验收标准是请求在业务时限内稳定完成，超时阶段对应的根因指标恢复，并且重试没有造成重复写入或流量放大。 偶尔一次成功不能证明网络已经稳定。
FAQ
curl错误码28一定是服务器响应慢吗？
不一定。DNS解析、TCP连接、TLS握手、等待响应或下载过程中的任一阶段都可能耗尽时间限制。
connect-timeout和max-time有什么区别？
前者限制建立连接所需的阶段，后者限制整个curl操作。连接成功后服务器迟迟不返回内容，仍可能触发max-time。
把max-time删掉就不会报错了吗？
可能不再由这个限制终止，但程序也可能无限等待并占用连接。生产脚本仍应设置与业务目标相匹配的超时和受控重试。
温馨提示
先测阶段耗时，再决定改DNS、网络、TLS、应用还是超时参数。 只把等待时间加长，往往会掩盖根因，并让故障时的连接堆积更加严重。
