curl 超时排查顺序：连不上、连上了没响应、响应慢分别怎么查（运维笔记）
发表于 ： 周一 10月 05, 2026 10:03 am
用 curl 请求一个接口卡住，先别急着怀疑对方服务，按下面顺序分段定位，能省掉大量来回试的时间。
第一步：分清是连接问题还是响应问题
几个时间点的含义：
第二步：区分超时类型
默认的 是把整个请求一刀切。更精确的做法是分开设：
连接超时说明 TCP 层就没通，多半是防火墙、安全组，或者对端进程根本没起来。
连接很快但总时长卡满，说明连上了但数据回不来，往应用层查。
第三步：对比对照
这一步的价值在于：能把「本机网络」「DNS」「目标服务」三个变量分开。
第四步：POST 与长连接的特殊情况
POST 卡住常见原因是请求体没发完：如果 body 从 stdin 读，而 stdin 没有关闭，服务端会一直等。
开启 keepalive 复用连接后如果出现偶发卡顿，可以试试 对比，排除连接复用导致的时序问题。
第五步：抓包兜底
以上都正常但现象依旧，再上 或 看有没有重传和连接堆积。到这一步再抓，效率才高。
小结
先量化再判断：把 DNS、连接、TLS、首字节四个时间点打出来，问题在哪一段基本就清楚了，不用靠猜。
第一步：分清是连接问题还是响应问题
代码： 全选
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、首字节四个时间点打出来，问题在哪一段基本就清楚了，不用靠猜。