策略组类型详解：url-test、fallback、load-balance 的区别与选用

策略组在规则与节点之间做什么

策略组（Proxy Group）负责把规则指向的策略，转换成实际使用的节点。例如，规则将某个域名交给“日常代理”，该组再根据手动选择、延迟测试或故障转移逻辑确定出口。规则回答“这次连接交给谁”，策略组回答“交给这个组后用哪个节点”。

本文以 Clash Verge Rev 使用的 mihomo 内核配置为例。界面负责展示和切换，proxy-groups 中的 type 才决定组的行为。系统代理和 TUN 模式影响流量如何进入内核，不会把 select 自动变成测速组，也不会改变负载均衡算法。

类型	选择依据	典型用途	关键限制
`select`	用户手动指定成员	固定地区、手动入口	不会自行改选其他成员
`url-test`	探测延迟与切换容差	同类线路自动选低延迟	探测快不等于下载快
`fallback`	成员顺序与可用性	主线路故障后启用备份	不是选择延迟最低者
`load-balance`	指定的连接分配算法	多个连接分散到多个出口	不是单连接带宽叠加

select：手动入口与固定出口

select 适合需要明确出口的场景。在 Clash Verge Rev 的「代理」页展开对应策略组，点击节点或子组即可选择。若选中的节点失效，手动组不会仅因其他成员可用就自动换过去；但如果选中的成员本身是自动策略组，子组仍会执行自己的自动选择。

把自动策略放进手动入口

常见做法是让最外层使用 select，内部同时放入“自动低延迟”“主备线路”和具体节点。日常选自动组，遇到地区限制或需要固定出口时，再手动选定节点。这样规则始终引用同一个入口，不必为了临时换线路修改整张规则表。

账号登录、支付或后台管理：优先选择地区稳定、出口明确的节点。
普通网页浏览：可以选择自动测速子组，减少手工切换。
排查故障：直接固定一个节点，避免自动切换干扰观察。

“固定节点”不等于“固定公网 IP”。服务端可能更换出口或采用多出口架构。若业务要求固定 IP，需要确认服务提供方的线路属性，不能仅靠客户端策略组保证。

url-test：按探测延迟选节点，tolerance 控制切换幅度

url-test 会通过候选节点访问指定的测试 URL，记录探测结果，并结合当前节点状态与容差选择节点。它适合同地区、用途接近的线路。把不同地区混在一起时，延迟较低的地区可能持续获选，但未必符合目标网站的地区要求。

interval、timeout 与 tolerance 的单位

interval: 300：以秒为单位，表示健康检查的周期设置，即 5 分钟。
timeout: 5000：以毫秒为单位，单次探测超时预算为 5 秒。
tolerance: 50：以毫秒为单位，抑制小幅延迟波动带来的切换。
lazy: true：启用惰性检查，组未被使用时可能不按周期持续探测；不是“所有候选每 300 秒必测一次”。

以示意数据说明：当前节点为 105ms，另一个节点为 80ms，差值只有 25ms。在 tolerance: 50 的设置下，这样的小幅优势通常不足以触发换线；若当前节点升至 180ms，候选仍为 80ms，则差距已经明显超过容差。节点不可用时仍会依据可用性重新选择，容差不是要求继续保留故障节点。

测速结果不能替代吞吐量测试

测试 URL 返回的小响应主要用于判断链路可达性与请求延迟。80ms 的节点不一定比 120ms 的节点更适合下载大文件；带宽、拥塞、目标站点路由和服务端负载都可能改变结果。也不要把客户端显示的探测延迟直接当成 ICMP ping 值，它们的测量路径和工作方式不同。

fallback：按列表顺序实现主备切换

fallback 从成员列表前端寻找可用节点。只要首选节点被检测为可用，就优先使用它，而不是比较所有节点谁延迟最低。因此，主线路必须写在前面，备用线路依次排在后面。列表顺序是业务优先级，不是备注顺序。

例如，节点 A 为 160ms、节点 B 为 70ms，只要 A 可用且排在 B 前面，主备组仍优先使用 A。当 A 的健康检查失败后，才会选择后面的可用成员。后续探测发现 A 恢复，新的连接可重新优先走 A。

故障切换不等于连接迁移

已经建立的 TCP 连接绑定了原有链路。策略组换成备用节点后，旧连接不会无损搬到另一个出口。网页可能通过新请求恢复，但下载、远程终端或会议连接可能需要重连。检查间隔、单次超时、惰性检查和故障发生时机共同影响发现速度，不能把 interval: 300 理解为严格的 300 秒恢复承诺。

主备线路尽量选择不同故障域，例如不同入口或不同服务端，而不只是同一服务器的两个名称。
主备组适合“优先保留指定线路”，不适合“始终选择最低延迟”。
若备用线路按量计费，应结合流量统计检查实际用量，健康检查本身也会产生少量请求。

load-balance：分配多条连接，而非合并单条带宽

load-balance 按策略把连接分配给候选节点。它不会把同一条 TCP 连接拆开，分别交给两个节点传输，也不等同于多链路聚合。一个单连接下载任务通常仍受所选节点的带宽限制；多连接业务才可能在不同出口之间分散负载。

常见 strategy 的区别

strategy	主要行为	选用注意
`consistent-hashing`	按目标信息做一致性哈希映射	相同目标倾向同一出口，成员变化仍可能改变映射
`round-robin`	在可用成员之间轮流分配连接	同一网站的不同连接可能来自不同出口 IP
`sticky-sessions`	按源地址与目标地址组合保持一段时间的映射	属于 mihomo 的会话黏性策略，不是永久锁定出口

目标是域名还是 IP、DNS 模式是否保留域名信息，都可能影响实际分配。不要据此推断“一个浏览器永远只走一个节点”。账号服务可能同时访问登录域名、静态资源域名和 API 域名，即便使用一致性哈希，也可能落到不同出口。

完整组合示例：一个手动入口，三种自动策略

下面是加入现有 mihomo 配置的策略组与规则片段，不是包含节点凭据的完整订阅。HK-A、HK-B 和 SG-A 必须已在当前配置的 proxies 中定义，名称需逐字一致。若节点来自 proxy-providers，应根据实际 provider 名称使用 use 引入，不能只把提供器名称当作节点名称填入列表。

proxy-groups:
  - name: 日常代理
    type: select
    proxies:
      - 自动低延迟
      - 主备线路
      - 多连接分配
      - HK-A
      - HK-B
      - SG-A

  - name: 自动低延迟
    type: url-test
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: true

  - name: 主备线路
    type: fallback
    proxies:
      - HK-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true

  - name: 多连接分配
    type: load-balance
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,日常代理
  - MATCH,日常代理

合并配置时要检查的三处位置

合并组列表：将新组加入原有 proxy-groups，不要在同一层再写第二个同名键。组名应唯一，子组之间不能相互循环引用。
保留原有分流：示例中的 example.com 是演示匹配域名。现有配置若已有直连、拦截和地区规则，应保留它们，并让兜底 MATCH 位于规则末尾。规则按顺序匹配，不能把兜底插到业务规则前面。
确认修改层级：在 Clash Verge Rev 的「配置」页确认当前启用的配置。远程订阅刷新可能覆盖直接修改的内容，长期修改应使用当前客户端支持的合并配置或脚本机制，并检查最终生效配置。

上述三种自动组都使用 lazy: true，适合未使用时减少探测的场景。若确实需要后台持续检查，可评估改成 false，同时关注节点数量和检查频率。例如一个组包含 20 个节点、间隔 300 秒，单轮就有 20 次探测；多个组重复引用这些节点时，实际检查开销还要结合内核调度与 provider 健康检查一起观察。

按使用场景选型，并验证真实命中结果

三种常见配置取舍

网页浏览、日常办公：外层 select，默认选择同地区的 url-test；先以 300 秒检查周期、50ms 容差观察，再按波动情况调整。
主线路优先、备用线路兜底：选择 fallback，将希望长期使用的线路放第一位。故障时允许重连，并实际测试主线路恢复后的行为。
大量可接受多出口的连接：考虑 load-balance；先尝试一致性哈希，再判断是否真的需要轮询。不要为了提高一个下载任务的速度直接改成负载均衡。

在 Clash Verge Rev 中的验证顺序

打开「配置」页，确认目标配置已启用。若应用时报错，先到「日志」页查找组类型、节点名称或 YAML 缩进错误，不要带着配置加载失败继续测试。
打开「代理」页，在“日常代理”中选中要测试的子组。使用「规则」模式验证规则分流；「全局」模式使用的是全局策略入口，结果可能与业务规则不同。
执行一次组测速，记录测试时间、当前节点和延迟。不要只看某个节点的绿色数值，要确认外层入口实际选中了哪个组。
访问一个确定应走代理的站点，再到「连接」页按域名筛选，查看命中规则与代理链。仅有“组已选中”不能证明该请求命中了它。
关闭旧页面连接或新开请求后再比较。若需要测试主备失效，应在可恢复的测试环境中临时停用主线路，并记录何时检测失败、何时建立备用连接。

若“测速正常但网站打不开”，先区分探测目标可达与业务目标可达：检查业务域名的 DNS 解析、规则命中、节点地区限制及日志报错。若“切换后出口没变”，优先检查旧连接复用、规则是否直连、全局入口是否选错，以及两个节点是否本来就共享同一公网出口。

选择策略组的核心不是自动化程度，而是选择依据是否符合需求：需要人工控制用 select，希望按延迟选路用 url-test，需要有顺序的主备切换用 fallback，需要分散多条连接再考虑 load-balance。规则、策略组和节点各自分工明确，排查时才能逐层定位。配置字段还可结合协议手册核对，相关概念可查阅术语表。