curl -w 可精准测量 Web 接口各阶段耗时，需绕过 DNS 缓存（--dns-servers 8.8.8.8 -4）、区分 TCP 与 TLS 时间（%{time_connect} 和 %{time_appconnect}）、丢弃响应体（-o /dev/null）并静默输出（-s），再批量测试取平均值判断性能瓶颈。
直接用 curl -w 就能测出 Web 接口各阶段的真实耗时，关键不是只看总时间，而是拆开看 DNS、TCP、TLS、首字节这些环节谁拖了后腿。
DNS解析时间怎么测才准
默认的 %{time_namelookup} 可能被本地 hosts、nscd 或系统 DNS 缓存干扰，显示接近 0，不代表真实公网解析快。要测真实 DNS 耗时，得绕过所有缓存：
- 加
--dns-servers 8.8.8.8强制走公共 DNS（要求 curl ≥ 7.33.0） - 加
-4强制 IPv4，避免因 AAAA 记录查询失败再回退 A 记录带来的额外延迟 - 配合
dig example.com @8.8.8.8 +short单独验证 DNS 响应时间，和 curl 输出对比——若 curl 的 namelookup 明显更长，说明它在做额外尝试（比如 IPv6 fallback）
TCP连接与TLS握手分开看
HTTP 和 HTTPS 的建连逻辑不同，参数含义也不同：
CurlShip Directory Submission
下载
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
-
%{time_connect}是从开始到 TCP 三次握手完成的时间，不含 TLS -
%{time_appconnect}只对 HTTPS 有效，代表 TLS/SSL 握手完成耗时；HTTP 下恒为 0 - 如果
%{time_appconnect}显著偏高（如 >300ms），重点查证书链完整性、服务器 TLS 版本配置（是否支持 TLS 1.3）、客户端信任库是否过期 - TLS 1.3 下
%{time_appconnect}可能趋近于 0，此时应参考%{time_pretransfer}更准确反映协议建立总耗时
让输出干净可读的关键操作
不屏蔽响应体或进度条，-w 输出就会混着 HTML 或下载内容，根本没法解析：
- 必须加
-o /dev/null丢弃响应体 - 必须加
-s关闭进度条和错误提示 - 推荐组合写法：
curl -s -o /dev/null --dns-servers 8.8.8.8 -w "DNS:%{time_namelookup}\nTCP:%{time_connect}\nTLS:%{time_appconnect}\nTTFB:%{time_starttransfer}\nTotal:%{time_total}\n" https://api.example.com/health
批量测试与结果判断技巧
单次测试容易受瞬时网络抖动影响，建议多次运行取平均值：
- 用 shell 循环跑 5–10 次，把结果存入文件再用 awk 统计平均值
- 加
-f参数让 curl 在 HTTP 错误码（如 4xx/5xx）时返回非零退出码，便于脚本判断是否请求失败 - 注意：所有时间变量仅在请求成功时有值；DNS 失败、连接拒绝等异常下，
-w输出可能为空，需结合退出码判断
