curl -w 拆解接口耗时：从 DNS 解析到 TTFB 的慢请求定位实战

背景

线上接口偶发变慢，浏览器开发者工具只给一个总耗时，看不出时间到底花在哪一步。上周排查一个内部接口超时，靠猜测折腾了半天，最后发现是 DNS 解析偶发抖动。从那以后，凡是遇到“接口慢”，我第一反应都是先用 curl 的 -w 参数把各阶段耗时拆出来，一行命令就能定位慢在 DNS、建连、TLS 还是服务端处理。

核心命令

curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} pretransfer:%{time_pretransfer} starttransfer:%{time_starttransfer} total:%{time_total}\n' https://example.com/api/health

• -o /dev/null -s：丢弃响应体并静默，避免下载大 body 干扰计时
• time_namelookup：DNS 解析耗时
• time_connect：TCP 建连完成耗时（含 DNS）
• time_appconnect：TLS 握手完成耗时（HTTPS 才有意义）
• time_pretransfer：开始发送请求前的准备耗时（含 TLS）
• time_starttransfer：收到首字节耗时，即 TTFB
• time_total：请求总耗时

实战解读

一次真实的输出长这样：

dns:0.012 connect:0.045 tls:0.132 pretransfer:0.133 starttransfer:0.412 total:0.415

注意这些值是“从请求开始算起”的累计值，相邻两项相减才是该阶段的增量：

• DNS 增量 = dns 本身（0.012s，正常）
• TCP 建连增量 = connect - dns（0.033s，正常）
• TLS 握手增量 = appconnect - connect（0.087s，略高）
• 服务端处理 ≈ starttransfer - pretransfer（0.279s，这是大头）

结论很清楚：慢主要慢在服务端处理，TLS 顺带看一眼即可，不用在网络层浪费时间。

常见慢因对照

进阶用法

1. 多次采样取中位数：单次请求可能正好撞上抖动，循环几次再看：

for i in 1 2 3 4 5; do curl -o /dev/null -s -w '%{time_total}\n' https://example.com/api/health; done

2. 写成 shell 函数：放进 ~/.bashrc，以后随手调用：

ct(){
  curl -o /dev/null -s -w 'dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' "$@"
}

3. 压测前先定基线：压测之前先用它确认接口本身各阶段耗时，区分“网络慢”还是“服务慢”，避免压测结论背锅。

小结

接口慢不要先猜，curl -w 把时间拆开再看：DNS、建连、TLS、TTFB 四段一减，慢在哪一段一目了然，再顺着上面的对照表去查，排查效率至少翻倍。建议把那个 ct 函数加进你的常用工具箱。