节点慢在 DNS、连接还是首字节？用 curl 拆分耗时

节点慢在 DNS、连接还是首字节？用 curl 拆分耗时

“这个机场节点很慢”通常把多个阶段混在了一起。域名解析慢、TCP 连接慢、TLS 握手慢、服务器迟迟不返回首字节，以及正文下载慢，给人的感觉都可能是“网页转圈”。如果不拆分阶段，只看总耗时，很难知道应该换 DNS、换节点，还是换测试目标。

curl 的 --write-out 可以在请求结束后输出各阶段计时。先选一个稳定、允许访问的 HTTPS 页面，在同一台设备上执行：

curl -o NUL -sS -w "dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" https://example.com/

在 macOS 或 Linux 上把 NUL 换成 /dev/null。example.com 只是示例，应替换成你平时真实使用且可公开访问的目标。

五个时间怎样看

• time_namelookup：从开始到域名解析完成。
• time_connect：从开始到 TCP 连接完成；若使用显式 HTTP 代理，这里通常对应到代理的连接。
• time_appconnect：从开始到 TLS 等应用层握手完成。
• time_starttransfer：从开始到收到首字节，包含此前阶段和服务器处理时间。
• time_total：整次传输总时间。

这些值大多是累计时间。要估算某个阶段的增量，应做相减，例如 TLS 相关增量可粗略观察 time_appconnect - time_connect，首字节等待增量可观察 time_starttransfer - time_appconnect。它们是诊断线索，不等于服务商的长期性能承诺。

做公平的节点对照

1. 固定设备、网络、目标 URL 和测试命令。
2. 每个节点只测少量几次，交替测试，避免把时段变化误当成节点差异。
3. 同时记录是否失败与 curl 退出码，不能只保留成功样本。
4. 最后用浏览器、下载或视频等真实任务验收。

如果 DNS 时间在所有节点都高，先查本机或网络解析；如果连接阶段只在一个节点高，再检查该入口路径；如果首字节等待对所有路径都高，目标网站本身也可能是因素。

机场推荐中怎样使用这组数据

不要把一次最低值写成“最快节点”。更有用的做法是记录中位表现、失败次数、测试时段和目标类型，并说明测试条件。这样读者能区分“连接建立快”和“内容传输快”，也能知道结论能否复现。

curl 官方手册定义了这些 --write-out 变量及其计时边界：curl 命令行手册。