curl 慢得像蜗牛？先用 -w 把耗时拆成三段再下结论

线上接口突然变慢，第一反应往往是"后端挂了"。但先别急着重启服务——用 curl -w 把一次请求的耗时拆开，很多时候慢的根本不是后端。

一条命令就够：

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

五个数字对应五个阶段：

1. time_namelookup：DNS 解析耗时。这一段大，先查本地 DNS 和运营商解析，别去动应用。
2. time_connect：TCP 建连耗时。从 namelookup 结束算起。这一段大，多半是网络链路或对端防火墙/安全组的问题。
3. time_appconnect：TLS 握手耗时（HTTPS 才有）。证书链过长、OCSP 检查卡住都会拖慢这一段。
4. time_starttransfer：首字节时间。从请求发出到收到第一个字节——这一段大，才轮到怀疑后端逻辑或数据库。
5. time_total：总耗时，用来和上面四段对账。

对号入座举例：dns:0.002 conn:2.104 tls:0.001，慢在建连，查网络；ttfb 占比超过总耗时八成，再去看应用日志和慢查询。

两个容易踩的坑：

• 第一次慢、后面几次快：可能是 DNS 缓存或连接复用生效了，对比时要固定条件（比如每次都加 --resolve 或清掉复用）。
• 忘记加 -o /dev/null -s：进度条和 body 输出会干扰计时，计时场景下 body 本来也不用看。

排查顺序总结：先拆耗时，再定位到 DNS / 网络 / TLS / 后端中的一段，最后才去动那一段的配置。慢请求不可怕，可怕的是没拆开就全盘重启——重启治不好 DNS。