Clash Verge Rev 代理组类型完全指南：Select、URLTest、Fallback、LoadBalance 怎么选
打开 Clash Verge Rev 的「代理」页面，你会看到一堆节点被划分在不同的分组里：有的组叫「节点选择」，有的叫「自动选择」，有的叫「故障转移」，还有的叫「负载均衡」。点进去之后，每个组的行为都不一样——有的需要你手动点一个节点，有的会自动测速切换，有的会在多个节点之间轮流分发流量。
这些组就是 Clash 的代理组（Proxy Group）。代理组是 Clash 规则分流的核心执行单元：规则匹配到某个流量后，最终会把它交给一个代理组，由代理组决定具体使用哪个节点。理解不同代理组的机制和适用场景，是优化代理体验的关键一步。
本文讲解 Clash Verge Rev 支持的四种主要代理组类型——select、url-test、fallback、load-balance——的机制、配置参数和实际使用策略。
01. 代理组的基础结构
一个代理组在 YAML 配置中的基本结构如下：
proxy-groups:
- name: "节点选择"
type: select
proxies:
- 香港节点 01
- 日本节点 02
- DIRECT关键字段：
name：代理组名称，规则中引用的就是这个名字type：代理组类型，决定行为逻辑proxies：组内包含的节点或其他代理组
proxies 列表里可以放节点名称，也可以放其他代理组的名称，甚至可以放 DIRECT（直连）和 REJECT（拒绝）。这种嵌套能力是构建复杂分流策略的基础。
02. select：手动选择
select 是最简单的代理组类型。它的行为是：完全由用户手动指定使用哪个节点，不自动切换。
- name: "节点选择"
type: select
proxies:
- 香港节点 01
- 日本节点 02
- 美国节点 03
- DIRECT在 Clash Verge Rev 的「代理」页面中，select 组会显示为一个可点击的列表，你点击哪个节点，流量就走哪个节点。如果你不手动选择，它会默认使用列表中的第一个。
适用场景：
- 需要精确控制流量走哪个节点的场景
- 作为规则的目标组，让用户随时手动切换
- 作为其他自动组的「上游」，方便手动覆盖
不适用场景：
- 节点经常失效，需要自动切换
- 不想手动干预，希望自动选最优节点
大多数订阅的「节点选择」组都是 select 类型，这是最符合直觉的组类型。
03. url-test：自动测速选择
url-test 组会定期对组内所有节点进行延迟测试，自动选择延迟最低的节点使用。当当前节点延迟升高或失效时，会自动切换到下一个最优节点。
- name: "自动选择"
type: url-test
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
proxies:
- 香港节点 01
- 日本节点 02
- 美国节点 03关键参数：
url：测速使用的 URL，通常是一个返回 204 的地址。这个 URL 必须能通过代理正常访问，否则所有节点都会显示超时interval：测速间隔，单位秒。默认 300 秒tolerance：延迟容差，单位毫秒。如果新节点延迟没有比当前节点低出这个值，就不会切换，避免频繁抖动
适用场景：
- 日常浏览、视频等对延迟敏感但不需要固定节点的场景
- 节点较多，不想手动挑选
- 作为规则的默认目标组
不适用场景：
- 需要固定 IP 的场景（如某些银行、电商）
- 节点之间延迟差异不大，频繁切换反而影响体验
url-test 是大多数订阅的「自动选择」组使用的类型。它的核心价值是让用户不用关心节点状态，系统会自动选最优的。
04. fallback：故障转移
fallback 组会按顺序检查组内节点是否可用，使用第一个可用的节点。只有当第一个节点不可用时，才会切换到第二个，以此类推。
- name: "故障转移"
type: fallback
url: "http://www.gstatic.com/generate_204"
interval: 300
proxies:
- 香港节点 01
- 日本节点 02
- 美国节点 03注意 fallback 和 url-test 的关键区别：url-test 选延迟最低的，fallback 选第一个可用的。fallback 不会因为第二个节点延迟更低就切换，它只在当前节点不可用时才切换。
适用场景：
- 有明确的节点优先级顺序，希望优先使用某个节点
- 需要稳定连接，不希望频繁切换
- 作为
url-test的补充，提供更保守的切换策略
不适用场景：
- 希望始终使用延迟最低的节点
- 节点之间没有明确的优先级
fallback 适合那些「我有首选节点，但首选挂了要能自动切到备用」的场景。
05. load-balance：负载均衡
load-balance 组会将流量分散到组内多个节点上，实现负载均衡。它支持两种策略：consistent-hashing（一致性哈希）和 round-robin（轮询）。
- name: "负载均衡"
type: load-balance
strategy: consistent-hashing
url: "http://www.gstatic.com/generate_204"
interval: 300
proxies:
- 香港节点 01
- 日本节点 02
- 美国节点 03consistent-hashing：同一个目标域名始终走同一个节点，适合需要会话保持的场景round-robin：每个请求轮流使用不同节点，适合纯下载、多线程场景
适用场景：
- 大流量下载，需要充分利用多个节点的带宽
- 多线程爬虫或批量请求
- 节点带宽有限，需要分散压力
不适用场景：
- 需要固定 IP 的场景
- 对连接稳定性要求高的场景（如视频会议、游戏）
load-balance 在普通用户场景中使用较少，但在需要高吞吐的场景下非常有用。
06. 如何组合使用
实际配置中，这四种组通常不是单独使用的，而是组合成层次结构。一个常见的组合模式是：
proxy-groups:
- name: "节点选择"
type: select
proxies:
- 自动选择
- 故障转移
- 香港节点 01
- 日本节点 02
- name: "自动选择"
type: url-test
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
proxies:
- 香港节点 01
- 日本节点 02
- 美国节点 03
- name: "故障转移"
type: fallback
url: "http://www.gstatic.com/generate_204"
interval: 300
proxies:
- 香港节点 01
- 日本节点 02
- 美国节点 03规则中统一引用「节点选择」组，用户可以在「节点选择」中手动切换到「自动选择」或「故障转移」，也可以直接指定某个具体节点。这种模式兼顾了手动控制的灵活性和自动切换的便利性。
07. 测速 URL 的选择
所有自动组（url-test、fallback、load-balance）都需要一个 url 参数用于测速。这个 URL 的选择会直接影响测速结果的准确性。
推荐使用：http://www.gstatic.com/generate_204
这是 Google 提供的一个轻量级测速端点，返回 204 无内容响应，非常适合用来测试延迟。它在全球范围内可访问，且响应稳定。
不推荐使用：
- 国内网站（如百度、淘宝）：测速结果不能反映代理节点的真实延迟
- 大文件下载地址：会消耗不必要的流量
- 需要认证的地址：可能导致测速失败
如果你发现所有节点都显示超时，首先检查测速 URL 是否能正常访问。
08. 常见误区
误区一：自动组一定比手动组好。 自动组在节点多、变化快的情况下确实方便，但如果你有明确的节点偏好（比如某个节点虽然延迟稍高但更稳定），select 手动指定反而更好。
误区二：tolerance 越小越好。 tolerance 太小会导致节点频繁切换，反而影响体验。默认 50ms 是一个合理的值，除非你有特殊需求，否则不建议调整。
误区三：所有流量都走自动选择。 不同流量对节点的要求不同。视频流媒体可能需要特定地区的节点，游戏需要低延迟节点，下载需要高带宽节点。把所有流量都指向一个自动组，无法针对不同场景做优化。
误区四：load-balance 能提升所有场景的速度。 load-balance 只对多线程、大流量场景有帮助。单线程场景下，它不会比单节点更快，反而可能因为切换带来额外开销。
建议先从简单的 url-test 组开始，熟悉代理组的行为后再逐步添加 fallback 和 load-balance 组，根据实际使用体验调整配置。