用 curl -w 拆开一次 HTTP 请求的耗时

接口变慢的时候，浏览器的网络面板不一定打得开。登录云主机排查，手头往往只有 curl。很多人只看它打出来的状态码，状态码是 200 就以为“不慢”。其实同一次请求里，时间可能花在域名解析、TCP 握手、TLS、服务端计算，或者正文传输上。curl 的 -w 可以把这些累计时刻打出来，先看清慢在哪一段，再决定查 DNS、查证书、查应用还是查带宽。

下面这条命令访问一个公开地址。-s 关掉进度条，-o /dev/null 丢掉正文，只保留计时。把网址换成自己的健康检查接口即可。

curl -s -o /dev/null -w ‘dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total} code:%{http_code}\n’ 你的健康检查地址

这些 time_ 字段都是从发起请求开始累计的秒数，不是每一段单独的时长，读的时候要做减法。

time_namelookup 是 DNS 完成的时刻。它经常超过零点二秒时，先看本机的解析配置和云上的 DNS，而不是先改业务代码。

time_connect 减去 time_namelookup，是 TCP 三次握手。跨地域访问这一段会明显变长，同一可用区里通常只有几毫秒。如果这里就很大，加机器解决不了，要先看链路和安全组是否绕远。

time_appconnect 减去 time_connect，是 TLS 握手。证书链太长，或者还在协商过时的协议版本，这一段会被抬高。访问的是明文 HTTP 时，这项为 0，不必紧张。

time_starttransfer 减去 time_appconnect，是服务端从收齐请求到吐出第一个字节的时间，也就是 TTFB。应用逻辑慢、数据库慢、网关排队，多半体现在这里。

time_total 减去 time_starttransfer，是正文下载。大文件、没有压缩、带宽不够，会体现在这一段，而不是 TTFB。接口只返回几十字节时，这一段应该接近 0。

只测一次不够。网络抖动会让单次结果骗人。同一个地址连跑五次，丢掉最高和最低，看中间三次的 TTFB 是否稳定。DNS 一次快一次慢，多半是缓存没命中，不要据此判断服务本身坏了。

还有两个容易看错的地方。第一，curl 默认会复用连接，紧接着的第二次请求，connect 可能接近 0。要比建连成本，加上 --no-keepalive，或者每次都新开一个进程。第二，前面如果有 HTTP 代理，time_connect 量的是到代理的时间，不是到源站的时间，结论会偏。需要看源站时，先确认没有 http_proxy 环境变量。

我把这条命令和 ss、journalctl 放在同一条排障顺序里：先确认端口在听，再确认服务日志没有报错，最后用 curl -w 看时间花在哪一段。三段对得上，才值得打开性能分析工具。否则很容易在错误的一层上耗一下午。