curl 不支持 -W 参数，正确选项是 -w（--write-out），配合 time_namelookup、time_connect、time_appconnect 等变量可精确测量 DNS、TCP、TLS、HTTP 各阶段耗时。
在 Linux 中，curl 本身不支持 -W 这个参数（该选项并不存在），你可能是想用 curl -w（--write-out）配合时间变量来输出 HTTP 请求各阶段的耗时。真正用于测量 TLS/HTTP 握手各阶段延迟的是 curl 内置的时间变量，如 time_connect、time_appconnect 等，它们能精准反映 DNS、TCP、TLS、HTTP 各环节耗时。
理解关键时间变量含义
curl -w 支持一组以 time_ 开头的变量，代表请求生命周期中不同阶段的耗时（单位：秒，支持小数）。定位网络或 TLS 延迟，重点关注：
- time_namelookup：DNS 解析完成耗时（从开始到拿到 IP）
- time_connect：TCP 连接建立完成耗时（含 DNS 时间，即到 SYN-ACK）
- time_appconnect：TLS/SSL 握手完成耗时（含 TCP 连接，即到 Finished 消息）
- time_pretransfer：所有前置操作完成耗时（DNS + TCP + TLS + 重定向等，到即将发送请求）
- time_starttransfer：首字节响应到达耗时（即“TTFB”，含 request 发送和 response header 到达）
- time_total：整个请求总耗时
常用诊断命令写法
直接输出各阶段耗时（单位：秒，保留 3 位小数），便于对比分析：
curl -s -o /dev/null -w "
DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
TTFB: %{time_starttransfer}s
TOTAL: %{time_total}s
" https://example.com若需更高精度（毫秒级），可乘以 1000 并用 %{json} 或外部工具处理，但更简单的是用 printf 格式化：
curl -s -o /dev/null -w "DNS: %.3f s\nTCP: %.3f s\nTLS: %.3f s\nTTFB: %.3f s\n" \ --write-out "TOTAL: %.3f s\n" https://example.com
区分网络层与 TLS 层延迟
通过比对关键差值快速定位瓶颈：
-
DNS 延迟高？ → 看
time_namelookup是否显著大于 0.1s；尝试换 DNS（如--dns-servers 8.8.8.8）或加-v确认是否启用缓存 -
TCP 建连慢？ → 计算
time_connect - time_namelookup，若 > 0.3s，可能存在路由、防火墙或服务端 SYN 队列问题 -
TLS 握手慢？ → 计算
time_appconnect - time_connect，> 0.5s 常见于证书链长、OCSP Stapling 失败、服务端 TLS 版本协商慢或客户端不支持 ALPN - TTFB 高但 TLS 正常？ → 说明服务端处理慢（后端逻辑、数据库阻塞等），非网络问题
增强诊断的实用技巧
结合其他选项提升排查效率：
- 加
-v查看详细握手日志（尤其 TLS 版本、Cipher、证书信息） - 用
--resolve绕过 DNS，确认是否 DNS 导致延迟：--resolve example.com:443:93.184.216.34 - 禁用 TLS 验证（仅测试）：
-k，排除证书校验开销（但实际生产中不应禁用） - 强制协议版本定位兼容问题：
--tlsv1.2或--ciphers ECDHE-ECDSA-AES128-GCM-SHA256 - 多次运行取平均：
for i in {1..5}; do curl -s -o /dev/null -w "%.3f\n" https://example.com; done | awk '{sum+=$1} END {print "AVG:", sum/NR}'
不复杂但容易忽略：确保使用较新版本 curl（≥7.59.0），旧版可能缺失 time_appconnect 或精度不足；同时注意，HTTP/2 over TLS 会将 ALPN 协商计入 time_appconnect，而纯 HTTP/1.1 不涉及。
