测试不会打开你平时用的网站，也不会验证订阅是否过期。它只回答：在这一刻，按设置里的方式去探测，这条节点返回了多少毫秒，或者是否超时。数字低，说明到探测目标更近或当时更空；数字高或超时，可能是探测被限制、当时拥塞，或探测地址本身不适合这条线路。实际访问的网站仍可能正常。

因此，测速是排序工具，不是健康检查。服务方标明可用的节点，即使测速偏高，也应先实际打开一个常用地址再决定要不要换。反过来，测速很低但目标域名在「配置」模式下被规则直连，你感受到的快慢和测速无关。

数字从哪里来

延迟测试的地址与方式可以在设置里改。改探测目标之后，新旧数字不能直接横比：你比较的已经不是同一条路径。同一时刻、同一网络、同一探测设置下，比较多条节点才有意义。隔了几个小时再测，网络条件变了，单独一条的升降说明不了配置被改坏。

Wi-Fi 和蜂窝下的数字差一截很常见。先确认当前用的是哪一种网络，再判断节点。公司 Wi-Fi 有时会干扰探测，蜂窝反而更接近你平时的使用。不要在两种网络之间来回测，却把差异记在节点头上。

设置项的位置见 设置。名称以已安装版本为准。

常见误判

  • 把一次超时标成节点永久不可用，并立刻删除。删除后若服务方列表里还有这一条，下次更新又会回来；若没有备份，等于丢掉一条仍能访问的线路。
  • 在同一条上连续重试，把瞬时拥塞当成参数填错。连续探测还可能让服务方暂时限流，数字会更差。
  • 测速很低，全局路由却停在「配置」，目标被规则送到直连或另一个策略组。此时应改对比方法，见 全局路由。
  • 全部节点超时，同时直连也打不开常用网站。这是本地网络或目标站点的问题，继续测速不会给出新信息。
  • 把测速失败理解成订阅更新失败。更新走的是订阅 URL，测速走的是探测地址，见 订阅更新。

更稳妥的用法

  1. 需要选用节点时，先看服务方标明可用的条目，再测速作参考，而不是只按数字从低到高点。
  2. 测速异常时，选中该节点，打开一个你确实要访问的地址。能打开就继续用。
  3. 实际也打不开时，固定这个地址，按直连、代理、配置的顺序对比。直连失败先查本地网络；代理失败再换节点；只有「配置」失败则查规则和 DNS。
  4. VPN 图标都不在，先回到 授权。没有隧道时，测速结果没有操作意义。
  5. 全部超时且直连失败，检查系统时间、当前 Wi-Fi / 蜂窝，以及是否被其他 VPN 占用。

和策略组、按需连接

策略组可能按延迟自动选出口。测速数字会进入这一逻辑，但自动选出的节点仍可能打不开你的目标网站——因为探测地址和目标不是同一个。若策略组选出的出口不稳定，改为手动指定，再观察实际访问，比反复全量测速更清楚。

按需连接会在特定网络下自动连上或断开。测速时如果隧道刚被断开，数字会差一截。先看开关和状态栏，确认隧道还在，再测。小组件与 App 内开关控制的是同一条连接，不要两处反复拨动后再读数字。

什么时候可以忽略测速

第一次导入订阅后，列表往往还没有数字。这不妨碍先连服务方推荐的那一条。证书或 TLS 报错时，应先核对系统日期，而不是看毫秒数。耗电或发热明显时，应检查是否误开「代理」、规则是否把大量流量送进隧道，这和某一条的测速高低不是同一类问题。

同一条节点在不同时段的数字起伏，多数是线路负载和本地网络在变，不是参数被改写。若你没有改过服务器字段，也没有更新订阅，不必根据一次升高就重填地址和端口。重填更容易填错，把本来能用的节点变成真正不能用。

批量测速会在短时间里对多条服务器发起探测。列表很长时，排在后面的条目可能赶上本地网络变忙，数字普遍偏高。这种「越往下越差」不能理解成排序靠后的节点质量更差。需要比较时，只勾选准备使用的几条，在同一分钟内测完。

超时有时显示为特定标记而不是毫秒。把它读成「这条已经从服务方删除」并不准确。服务方删除的节点，通常要等订阅更新后才会从列表消失。测速超时而更新成功、数量没变，说明条目还在，只是探测没完成。

游戏或通话一类依赖 UDP 的应用，延迟测试更不能代表体验。测试往往只反映探测路径上的往返，不包含 UDP 是否被当前协议和节点支持。这类应用打不开时，应向服务方确认能力，并按全局路由做对比，而不是只盯着毫秒数。

界面位置见 图文教程。功能摘要见 功能。本站不提供节点；没有配置时，测速没有对象。也不要把测速页当成下载入口，安装只走 App Store。