curl 超时排查顺序：连不上、连上了没响应、响应慢分别怎么查（运维笔记）

[admin]

朗读 点击，生成分享二维码

用 curl 请求一个接口卡住，先别急着怀疑对方服务，按下面顺序分段定位，能省掉大量来回试的时间。

第一步：分清是连接问题还是响应问题

代码： 全选

curl -v -o /dev/null -s -w 'dns=%{time_namelookup} conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

几个时间点的含义：

代码： 全选

time_namelookup  DNS 解析耗时，偏大是解析问题
time_connect     TCP 握手耗时，偏大是网络或对端未监听
time_appconnect  TLS 握手耗时，偏大是证书或加密套件协商
time_starttransfer 首字节时间，偏大是后端处理慢
time_total       总耗时

第二步：区分超时类型

默认的

代码： 全选

--max-time

是把整个请求一刀切。更精确的做法是分开设：

代码： 全选

curl --connect-timeout 5 --max-time 30 https://example.com/

连接超时说明 TCP 层就没通，多半是防火墙、安全组，或者对端进程根本没起来。
连接很快但总时长卡满，说明连上了但数据回不来，往应用层查。

第三步：对比对照

代码： 全选

# 同一台机器访问其他站点，确认是不是本机出网问题
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.baidu.com

# 同站点用 IP 直连，绕过 DNS
curl -sS --resolve example.com:443:1.2.3.4 https://example.com/

这一步的价值在于：能把「本机网络」「DNS」「目标服务」三个变量分开。

第四步：POST 与长连接的特殊情况

POST 卡住常见原因是请求体没发完：如果 body 从 stdin 读，而 stdin 没有关闭，服务端会一直等。

代码： 全选

curl -X POST --data-binary @body.json https://example.com/api
curl -X POST --data-binary @- < body.json https://example.com/api

开启 keepalive 复用连接后如果出现偶发卡顿，可以试试

代码： 全选

--no-keepalive

对比，排除连接复用导致的时序问题。

第五步：抓包兜底

以上都正常但现象依旧，再上

代码： 全选

tcpdump

或

代码： 全选

ss -tnp

看有没有重传和连接堆积。到这一步再抓，效率才高。

小结

先量化再判断：把 DNS、连接、TLS、首字节四个时间点打出来，问题在哪一段基本就清楚了，不用靠猜。

[admin]

感谢分享，已经在自己的环境上试了，一次通过。