引言
在用curl调试网站性能时，大多数人只会用-w "%{http_code}"看一下状态码。其实curl的-w/--write-out参数提供了一组时间变量，能帮你精准定位网站慢在哪里——是DNS解析慢？TCP连接慢？还是后端响应慢？
本文把curl所有时间变量整理成一张完整对照表，配合实战示例，让你一次性搞懂每个变量的含义和用法。
一、curl -w 时间变量完整对照表
| 变量名 | 含义 | 单位 | 典型值参考 |
|---|---|---|---|
time_namelookup | DNS域名解析完成耗时 | 秒 | 0.001~0.05 |
time_connect | TCP连接到目标服务器耗时 | 秒 | 0.01~0.1 |
time_appconnect | SSL/SSH握手完成耗时（HTTPS专属） | 秒 | 0.05~0.3 |
time_pretransfer | 从请求开始到准备发送数据耗时 | 秒 | 0.05~0.3 |
time_redirect | 所有重定向跳转的总耗时 | 秒 | 0~2.0 |
time_starttransfer | 从请求开始到收到第一个响应字节耗时（TTFB） | 秒 | 0.1~1.0 |
time_total | 整个请求完成的总耗时 | 秒 | 0.2~5.0 |
注：所有时间变量的单位都是秒，精确到毫秒（3位小数）。
二、每个时间变量详解
1. time_namelookup——DNS解析耗时
这个变量衡量的是从发起请求到DNS解析完成的时间。如果这个值偏大（大于0.1s），说明DNS解析慢，可以检查：
- DNS服务器响应慢→换公共DNS（8.8.8.8 / 223.5.5.5）
- 域名没配置DNS缓存→在Nginx或CDN层开启DNS缓存
- DNS劫持或链路问题→用
dig或nslookup排查
实战命令：
curl -o /dev/null -s -w "DNS解析耗时: %{time_namelookup}s\n" https://www.youres.cn2. time_connect——TCP连接耗时
衡量TCP三次握手的耗时。这个值大，说明网络链路到服务器慢，或者服务器连接队列满了。
典型场景：跨地域访问（从国内访问美国服务器），time_connect 可能到 0.3~0.5s。
curl -o /dev/null -s -w "TCP连接耗时: %{time_connect}s\n" https://www.youres.cn3. time_appconnect——SSL握手耗时
只在使用HTTPS时有效，衡量SSL/TLS握手的耗时。如果这个值大，原因可能是：
- 服务器SSL配置差（密码套件不合理、证书链不完整）
- 客户端到服务器的网络延迟高
- TLS版本协商慢（客户端不支持服务器优选版本）
对比HTTP和HTTPS的差异：
# HTTP（无SSL握手，time_appconnect = 0）
curl -o /dev/null -s -w "SSL握手: %{time_appconnect}s\n" http://example.com
# HTTPS
curl -o /dev/null -s -w "SSL握手: %{time_appconnect}s\n" https://example.com4. time_pretransfer——准备传输耗时
从请求开始到准备开始传输数据的耗时，等于 time_appconnect + time_connect + time_namelookup（HTTPS场景）。
这个值可以用来判断：连接阶段是否异常。如果 time_pretransfer 正常，但 time_starttransfer 很大，说明问题在服务器端（后端处理慢）。
5. time_redirect——重定向总耗时
所有重定向跳转的累计耗时。配合 num_redirects 变量可以看出平均每次跳转耗时。
如果重定向耗时过高，需要排查：
- 跳转链是否过长（A→B→C→D）
- 每次跳转是否都重新建立TCP连接（用Connection: keep-alive优化）
- 重定向目标是否跨域（跨域跳转会增加DNS+TCP耗时）
相关文章：curl -w num_redirects配合url_effective追踪完整跳转链路
6. time_starttransfer——首字节响应时间（TTFB）
这是最重要的性能指标之一，衡量从请求发起到服务器返回第一个字节的耗时，即 TTFB（Time To First Byte）。
TTFB 高的常见原因：
- 服务器后端处理慢（PHP/Java/Python执行耗时高）
- 数据库查询慢（没加索引、全表扫描）
- 服务器负载高（CPU/内存/IO打满）
优化方向：
- 开启OPCache（PHP）或类似字节码缓存
- 数据库加索引、优化慢查询
- 使用CDN缓存静态资源
- 升级服务器配置
7. time_total——总耗时
整个请求从发起到完成的总耗时。下载大文件时，time_total 主要受文件大小影响；API接口场景下，time_total 应该接近 time_starttransfer。
如果 time_total - time_starttransfer 很大，说明下载响应体很慢，可能是带宽受限或服务器网速慢。
三、实战：一次性输出所有时间变量
用 -w 的格式化输出，一次性打印所有时间指标：
curl -o /dev/null -s -w "
DNS解析: %{time_namelookup}s
TCP连接: %{time_connect}s
SSL握手: %{time_appconnect}s
准备传输: %{time_pretransfer}s
重定向耗时: %{time_redirect}s
首字节TTFB: %{time_starttransfer}s
总耗时: %{time_total}s
" https://www.youres.cn输出示例：
DNS解析: 0.004s
TCP连接: 0.021s
SSL握手: 0.068s
准备传输: 0.068s
重定向耗时: 0.000s
首字节TTFB: 0.145s
总耗时: 0.148s从输出可以看出：DNS解析很快（4ms），TCP连接正常（21ms），SSL握手略高（68ms），TTFB 145ms 属于正常范围。
四、用时间变量诊断性能瓶颈：实战案例
案例1：网站打开慢，但不知道慢在哪里
用这条命令快速定位：
curl -o /dev/null -s -L -w "
time_namelookup: %{time_namelookup}s
time_connect: %{time_connect}s
time_appconnect: %{time_appconnect}s
time_redirect: %{time_redirect}s
time_starttransfer:%{time_starttransfer}s
time_total: %{time_total}s
" https://www.youres.cn诊断逻辑：
- time_namelookup 高 → DNS问题
- time_connect 高 → 网络链路问题
- time_appconnect 高 → SSL配置问题
- time_starttransfer - time_pretransfer 高 → 后端处理慢
- time_total - time_starttransfer 高 → 响应体下载慢（大文件/慢带宽）
案例2：对比HTTP和HTTPS的性能差异
# HTTP
curl -o /dev/null -s -w "HTTP TTFB: %{time_starttransfer}s\n" http://example.com
# HTTPS
curl -o /dev/null -s -w "HTTPS TTFB: %{time_starttransfer}s\n" https://example.com如果HTTPS比HTTP慢很多（大于100ms），检查服务器SSL配置，考虑开启TLS 1.3、开启SSL会话复用。
案例3：批量检测多个网站的TTFB
for url in https://www.youres.cn https://www.baidu.com https://www.qq.com; do
printf "%s: " "$url"
curl -o /dev/null -s -w "%{time_starttransfer}s\n" "$url"
done五、时间变量输出到文件：方便记录日志
把时间变量输出到日志文件，方便后续分析：
curl -o /dev/null -s -w "$(date '+%Y-%m-%d %H:%M:%S') %{time_total}s %{time_starttransfer}s %{http_code}\n" https://www.youres.cn >> /var/log/curl_perf.log结合crontab定时任务，可以实现网站性能监控，当TTFB超过阈值时触发告警。
相关文章：curl重定向耗时过长钉钉告警配置
六、注意事项和常见坑
- 时间变量单位是秒，不是毫秒。如果看到 0.145，表示145毫秒。
- time_appconnect 在HTTP请求中为0，只有HTTPS才有值。
- time_redirect 包含所有跳转的累计时间，不是单次跳转时间。
- 用 -L 参数才会跟随重定向，否则 num_redirects 和 time_redirect 都是0。
- 用 -o /dev/null 丢弃响应体，避免输出干扰；用 -s 静默模式，避免进度条干扰。
七、总结
curl的7个时间变量是网站性能诊断的利器，不需要安装任何额外工具，一条命令就能精准定位慢在哪里。建议把这条命令保存成脚本，定期跑一下，建立性能基线，及时发现异常。
如果你的网站TTFB长期超过500ms，建议认真排查后端性能；如果time_connect长期超过100ms，考虑换机房或用CDN加速。
内链参考：
版权声明
本文仅代表个人观点。
本文系AI辅助作者原创，未经许可，转载请保留原文链接。
发表评论