节点列表里，一个显示 60 ms，另一个显示 180 ms。选了数字小的，网页却断断续续，下载也不快。这并不矛盾：延迟描述等一次响应要多久，下载速度描述一段时间能收到多少数据。 两者有关联，却不能互相换算。
挑节点，先用延迟测试排除明显不可用的选项，再用自己真正要完成的操作做比较。下面以 Clash Verge Rev 等使用 Mihomo 内核的客户端为例，说明测试数字怎么读、自动选择组怎么判断，以及遇到超时应该查哪里。
如果你还没有导入订阅，先按新手指引完成第一次连接；需要安装软件，可以从客户端下载总览选择对应版本。
01 延迟、速度、稳定性，分别看
可以把网络传输想成送包裹：第一件到得早，不代表后面每秒都能送来很多件；平均送得多，也可能时快时慢。网络里的延迟、带宽与实际吞吐量也是不同指标。延迟与吞吐量的区别
常见单位：ms
常见单位：Mbps、MB/s
看多次结果和实际过程
网页交互更容易让你感受到等待一次响应的时间；文件下载更依赖持续传输能力；通话等实时应用还需要关注中断、丢包和时延变化。一个短请求成功，不能代替对这些实际任务的验证。
速度单位也别看错：小写 b 表示 bit，大写 B 表示 Byte。按十进制单位换算，80 Mbps 相当于 10 MB/s；实际文件下载还受协议开销和整个传输路径影响。节点旁边的 80 ms 则是时间，和这两个速度没有这样的换算关系。
02 节点旁的数字，取决于怎么测、测哪里
在 Mihomo 的 URL 测试里，客户端通过节点向指定测试地址发起 HTTP 请求。它不是直接调用系统的 ICMP ping，也不是下载大文件测带宽。不同客户端、测试选项及内核设置可能采用不同计时方式，跨软件看到的数字不宜直接排在一起比较。
例如，健康检查很快，实际网站却响应缓慢，可能是节点到两个目的地的路径或网站服务状态不同。反过来，测试地址暂时不可用，也不能单凭一个红色结果认定该节点无法访问任何网站。健康检查的测试地址、超时时限和期望状态码都参与判断。Mihomo 代理组配置
因此，比较节点时尽量使用同一个客户端、同一个测试地址、相近时间和同一网络。先把条件固定，数字才有比较价值。
03 用一次小范围对比，找到真正好用的节点
不必把几十条免费节点全部跑满带宽。先从能通过测试的选项里挑两三条，逐条比较。
- 固定使用条件。 暂停正在进行的大文件下载和云盘同步，保持同一个 Wi-Fi 或有线网络。保留当前可用节点的名称，方便随时切回。
- 确认实际出口。 在目标网站对应的代理组中选中一个具体节点；若组里仍选择“自动选择”，测试过程中出口可能变化。打开连接记录，确认目标域名的新连接确实走了这条节点。组的嵌套关系见代理组选择说明。
- 看几次延迟，而不是最低一次。 隔开几秒测试三次，记下是否超时、结果是否大幅变化。三次只是快速筛选，不足以算出可靠丢包率，也不能代表全天表现。
- 做原本要做的事。 打开同一个实际网页，检查文字、图片和登录等操作是否完整。仅看到缓存页面秒开不能作为连接恢复的证据，要确认有新的网络请求。
- 确实需要下载时再看持续速度。 用同一来源、同一文件和同一下载方式，观察十几秒的持续速度与停顿，再停止测试。切到另一条节点重新建立连接后重复；别把浏览器单连接下载与测速工具的多连接峰值直接比较。
下面是一份假设记录，用于说明怎样做选择，不是节点测评结果，也不是速度及格线：
| 候选节点 | 三次延迟测试 | 同一下载任务 | 同一网页操作 |
|---|---|---|---|
| 甲 | 60 / 65 / 62 ms | 约 0.8 MB/s，基本连续 | 能正常完成 |
| 乙 | 180 / 185 / 178 ms | 约 4 MB/s，基本连续 | 能正常完成 |
| 丙 | 45 ms / 超时 / 310 ms | 速度跳动，数次停住 | 偶尔失败 |
需要下载时，乙可能更合适；以短小网页交互为主时，可以继续对比甲与乙的实际等待感受。丙虽然出现过最低数字，但不能因此排第一。免费节点的负载和可用性会变化，这张记录只帮助你决定现在用哪条，不适合做永久排名。
04 “自动选择”为什么没有选到下载最快的？
Mihomo 的 url-test 组围绕测试地址的延迟与可用性来选节点。它不会通过持续下载每条线路的大文件，替你比较下载吞吐量，所以选中的节点可能响应很快，却不适合你的大文件任务。自动选择组说明
读配置时，先看这几个字段的含义，不必为了一个更小的数字就改配置：
| 字段 | 表示什么 | 容易误解的地方 |
|---|---|---|
url | 健康检查访问的地址 | 不是对所有目标网站的综合检测 |
interval | 定时检查间隔，单位为秒 | 不是连续实时测速；调短也不会增加节点带宽 |
timeout | 一次健康检查的超时限制，单位为毫秒 | 调大只给请求更多等待时间，不会让慢连接加速 |
tolerance | 自动选择组的节点切换容差，单位为毫秒 | 当前节点正常时，不一定为了几毫秒差异切换 |
lazy | 是否在该策略组未被选用时暂停检查 | 看见旧测试值，不一定是客户端卡住了 |
如果订阅通过 use 引入 proxy-providers，还要看相应代理集合的 health-check 配置。不要以为改了代理组的测试地址，就同时改好了所有节点的健康检查。代理组通用字段与代理集合健康检查
当自动选择的结果不适合当前任务，可以在手动选择组中暂时固定到已经比较过的具体节点；使用结束后再决定是否恢复自动。直接编辑下载下来的订阅正文，可能被下一次更新覆盖；如果只是要固定选择，优先使用客户端现有的组内选择操作。
05 超时不等于只有一种故障
先观察是“一条失败”“所有测试都失败”，还是“测试正常、实际操作失败”。这三种情况的下一步不同。
| 现象 | 先做什么 |
|---|---|
| 只有一条节点反复失败，其他正常 | 换一条可用节点对比；这条线路暂时不可用时先跳过，不必重装客户端 |
| 所有节点测试失败，但实际网页可用 | 检查测试地址、超时和期望状态；确认测试结果是否及时刷新 |
| 所有节点和实际访问都失败 | 先确认本地网络正常、订阅已成功更新，再看日志中的连接错误；不要同时改 DNS、TUN 和路由 |
| 延迟正常，只有一个网站失败 | 核对这个网站的新连接、实际出口及网站自身状态，不能用测试地址的成功替代它 |
| 切了节点，表现完全不变 | 看实际命中的代理组，重新建立目标连接，排除旧连接、缓存或目标流量未被接管 |
连接列表里根本找不到目标应用时，先看系统代理与 TUN 的排查方法。如果有记录，却走了别的节点，就回到分流和组内选择。先找到问题发生的位置，再考虑改参数。
06 最后留下常用节点和一个备选
对免费节点来说，实用的选择是：当前任务能完成、连续使用没有明显停顿，再从中挑响应更合适的线路。保留一个经过同样操作验证的备选，比反复追逐列表里最低的毫秒数更方便。
普通浏览看页面与操作是否完整；下载看持续速度和停顿；通话则直接检查声音是否连贯。不同用途可以有不同选择，无需给一条节点评出适用于所有场景的总分。
如果不清楚节点为什么会失效、订阅更新又能改变什么，可以接着看免费节点的用途与限制。订阅里有多少条、测试时某一条多快，都不能保证你下一次使用时仍有同样表现。