Clash Verge Rev 节点批量测速与自动选择配置

订阅里导入了 50 个节点，手动一个一个点测速，点到第十个就不知道自己在测什么了。更麻烦的是，测完选了一个延迟低的节点，用了一段时间发现它晚高峰掉速严重，又得重新测一遍。机场订阅里的节点是动态的，今天快的明天可能就慢了，靠手动维护节点选择不现实。Clash Verge Rev 提供了两条路解决这个问题：界面上的一键批量测速，用来看当前节点质量；配置文件里的 url-test 自动优选组，让内核按固定间隔自动切换。这篇教程针对 Clash Verge Rev 节点批量测速与自动选择配置，把界面操作和配置写法分开讲清楚。

01. 界面批量测速：一键看清节点质量

打开 Clash Verge Rev，左侧菜单点击“代理（Proxies）”。页面顶部是策略组列表，每个策略组右侧都有一个类似 Wi-Fi 信号的测速图标。点击这个图标，内核会向该策略组包含的所有节点发起延迟测试。

测速的原理是：Mihomo 内核代表你从本机经过每个候选节点，向一个预先设定的测速 URL 发起一个小型 HTTP 请求，记录往返时间。数值以毫秒显示，越小表示到测速目标的链路越轻。失败则显示为超时或 timeout。

页面左上角还有一个全局测速按钮，点击后所有策略组中的节点会依次开始测试。节点数量较多时，测速需要几十秒到几分钟，期间界面上的延迟数值会逐个刷新。

测速结果有几列需要理解：

• 延迟（ms）：到测速 URL 的往返时间。低于 100ms 通常算良好，100-300ms 一般，超过 500ms 体验会明显下降
• 丢包率：部分版本会显示，丢包率高的节点即使延迟低也不适合长期使用
• 速度：部分版本显示带宽测试结果，和延迟是两个独立指标

延迟低不等于速度快。延迟衡量的是“敲门响不响”，带宽衡量的是“门开了之后能搬多少东西”。一个延迟 50ms 但带宽只有 5Mbps 的节点，看 4K 视频照样卡。测速结果用来快速筛掉明显不可用的节点，最终选择还是要结合日常使用体感。

02. Clash Verge Rev 节点批量测速与自动选择配置：用 url-test 实现自动优选

界面测速是手动触发的，测完的结果不会自动维持。如果你想让内核持续按延迟自动选择最快的节点，需要在配置文件中定义一个 url-test 类型的策略组。

url-test 组的工作机制是：内核按照你设定的 interval（检查间隔）周期性地向 url 指定的测速地址发起请求，记录每个节点的延迟，然后自动将组内当前延迟最低的节点设为出口。你不需要手动干预，内核会随着网络状况变化自动切换。

一个基础的 url-test 配置长这样：

proxy-groups:
  - name: 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港节点A
      - 日本节点B
      - 新加坡节点C

关键字段说明：

tolerance 字段容易被忽略，但它决定了切换的“敏感度”。如果设为 0，内核会在每次测速后发现更快的节点时立即切换，可能导致连接频繁中断。设为 50 意味着新节点必须比当前节点快至少 50ms，内核才会切换，避免在延迟相近的节点之间反复横跳。

如果节点列表来自订阅且节点名经常变化，可以在 proxies 中使用 include-all-proxies: true 让内核自动包含所有可用节点，而不是逐个写死节点名。

03. fallback 与 select：两种不同的选择逻辑

url-test 不是唯一的选择。Clash 系内核还提供 fallback 和 select 两种策略组类型，它们解决的是不同的问题。

fallback（故障转移） 的逻辑是“按顺序使用，坏了才换”。你列一个节点优先级列表，内核默认使用列表中的第一个节点。只有当第一个节点测速失败或连接超时时，才会自动切换到第二个，依此类推。它不关心哪个节点延迟最低，只关心“当前用的这个还能不能用”。

proxy-groups:
  - name: 故障转移
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 主线路节点
      - 备用线路1
      - 备用线路2

fallback 适合对稳定性要求高于速度的场景，比如视频会议、SSH 长连接。它的代价是：如果第一个节点延迟很高但没坏，你就要一直用这个高延迟节点。

select（手动选择） 不自动做任何事。它把节点列表展示给你，由你手动点击选择。select 组适合需要固定出口 IP 的场景，比如登录某些对 IP 一致性敏感的账号。

三种类型的对比如下：

在实际配置中，这三种组可以嵌套使用。比如一个 select 组里同时放入一个 url-test 组、一个 fallback 组和几个单独节点，你在需要时手动切换整个组的出口逻辑。

04. 测速 URL 的选择与参数调优

测速 URL 决定了延迟数值反映的是“到哪个目标的延迟”。默认配置里最常用的是 Google 的 204 地址：

http://www.gstatic.com/generate_204

这个地址会返回一个 204 状态码，响应体为空，请求开销极小，适合快速测速。但它有一个问题：如果你的网络环境对 Google 的访问本身不稳定，所有节点的延迟都会偏高，测速结果就失去了区分度。

可以替换为其他同样返回 204 的地址，根据你的主要使用场景选择：

• Cloudflare：http://cp.cloudflare.com/generate_204，全球节点覆盖广，国内访问相对稳定。注意使用 http:// 而非 https://，避免 TLS 握手增加额外的测速开销
• Apple：http://captive.apple.com，苹果设备用于检测热点的地址
• 微软：http://www.msftconnecttest.com/connecttest.txt，微软的连通性检测地址

interval 的设置需要在“及时性”和“资源消耗”之间平衡。设得太短（比如 60 秒），内核会频繁发起测速请求，消耗节点流量；设得太长（比如 1800 秒），节点质量变化后要等很久才能切换。社区推荐的默认值是 300 秒（5 分钟），这是一个比较合理的折中。

tolerance 的调优思路是：如果你的节点之间延迟差异很小（比如都在 30-60ms 之间），把 tolerance 设大一些（比如 100ms），避免内核在几个几乎一样快的节点之间来回切换。如果节点质量参差不齐，tolerance 可以设小一些，让内核更积极地切换到明显更快的节点。

05. 配置生效与常见问题排查

修改了 proxy-groups 配置后，需要让内核重新加载配置才能生效。在 Clash Verge Rev 中，可以点击“配置”页面中对应订阅卡片的刷新按钮，或者在托盘菜单的“更多”中选择“重启内核”。重启后打开“代理”页面，url-test 组会开始第一次测速，几秒后组内节点名称旁边会显示延迟数值，被选中的节点会有标记。

“我明明选了节点，它又自己跳走了”。 这是 url-test 组的正常行为。如果你在 url-test 组里手动点击了一个节点，内核在下一次测速周期后仍然会按照延迟重新选择。url-test 组的设计就是自动调度，手动选择只是临时覆盖。如果你需要固定使用某个节点，改用 select 类型的组，或者点击代理组上的“图钉”图标取消自动选择。

所有节点都显示超时。 先检查测速 URL 是否在当前网络环境下可访问。如果测速 URL 本身被墙或响应很慢，所有节点都会超时。换一个测速 URL（比如换成 Cloudflare 的地址）再试。另外确认系统代理或 TUN 模式是否已开启——如果代理没生效，测速请求不会经过节点，自然测不出延迟。

url-test 组没有自动切换。 检查 interval 是否设置得太长，或者 tolerance 是否设得太大导致内核认为“当前节点已经够快，不需要换”。也可以手动点击一次组内的测速按钮，强制触发一轮测试。

节点列表为空或组内没有节点。 检查 proxies 列表中的节点名称是否与订阅实际提供的节点名称完全一致（包括大小写和特殊字符）。如果订阅更新后节点名变了，写死的节点名就会失效。这种情况下改用 include-all-proxies: true 更省心。

如果 url-test 组配置后内核启动报错，检查 YAML 缩进是否正确。proxy-groups 下的每一项必须以 - 开头，url 和 interval 是 type 的同级字段，不能嵌套错位。更多配置文件的调试方法，可以参考 Clash Verge Rev 使用教程；如果测速全部超时且排除 URL 问题后仍然如此，常见问题页面中有节点和订阅排查的详细步骤。