节点延迟很低，网页却很慢：怎样读懂测试结果

摘要：健康检查、首字节等待和完整网页加载衡量不同环节。用少量可比较的请求定位卡顿，避免把延迟数字当成速度承诺。

客户端显示节点延迟很低，打开网页却迟迟没有内容，这两件事可以同时发生。面板上的数字对应某个测试目标和测试方法，网页还涉及目标服务器、资源下载与浏览器处理。选节点前，先问清这个数字究竟测了什么。

健康检查不是带宽测试

Mihomo的url-test代理组会对配置的URL进行检查，并按结果选择节点。一个很短的测试页面响应快，不代表图片、视频或AI服务也快。目标站点和节点出口之间的路径不同，站点自身的处理时间也不同，所以不能拿一次检查结果推导所有应用的体验。

再看检查条件。代理组文档允许设置预期状态码，默认不限制状态码。界面显示通过时，还要确认检查目标、时间和预期响应是否合适。记录里的旧结果不能代替刚刚发生的请求，也不要把页面能返回错误响应写成业务服务正常。

读懂累计计时

用curl做小请求时，time_connect是从开始到完成TCP连接的时间；经过本地代理，它可能只反映连接本地监听端口。time_appconnect到完成TLS握手，time_starttransfer到收到首字节，time_total到整个操作结束。这些字段多为从开始累计的时间点，不能直接相加，定义见curl手册。

首字节等得久，可能涉及前面的连接协商或服务端处理；首字节很快而结束很慢，则要继续看响应大小及后续传输。一次结果只能提供线索，不能直接判定运营商限速，也不能把本地端口连接时间称为远端节点延迟。

保持对照条件一致

先固定目标页面与实际出口，记录时间、状态码和预期内容是否匹配，再用另一个节点访问同样的两三个公开HTTPS页面。避免下载大文件，不带账号或Cookie，保留相同的超时设置。检查请求是否真的经过指定代理，避免直连结果混入记录。

浏览器网页还可能加载多个域名的脚本和图片。小请求正常而网页仍慢时，可观察具体哪个资源卡住。选节点时结合常用页面的少量实际响应，比盯着最低延迟数字更有用；短时结果也不能保证全天体验。