Clash策略组类型对比：url-test、fallback与load-balance怎么选

先分清策略组、节点与代理规则

Clash 与采用 mihomo 内核的 Clash Verge Rev 会把代理节点组织进策略组，再由规则决定某一条连接应交给哪个策略组。策略组不是新的代理服务器，也不会改变节点原有的协议、传输方式或出口位置。它负责的是“从组内成员中如何选出本次连接使用的成员”。

例如，规则可以把视频网站域名交给“流媒体”组，把办公域名交给“稳定线路”组，把其余流量交给“默认代理”组。每个组内部又可以使用不同类型：url-test 根据探测结果倾向选择延迟更低的可用成员，fallback 按配置顺序使用第一个可用成员，load-balance 则把不同连接分配给多个可用成员。

因此，三者的差异不能只用“哪个速度快”概括。选择时至少要核对四个维度：

• 成员选择依据：按照延迟、固定优先级，还是分配算法选择。
• 故障后的行为：重新测速、顺序后移，还是继续在其余成员之间分配。
• 出口一致性：同一目标或同一会话是否需要尽量维持相同出口地址。
• 设备成本：定时探测会消耗少量网络请求、电量和后台资源，移动设备尤其需要合理设置间隔。

健康检查测到的是什么

自动策略通常会访问配置中的测试地址，并在设定的时间间隔内更新可用性或延迟结果。常见测试地址返回一个很小的 HTTP 响应，用于判断 DNS、TCP、TLS 和代理链路能否完成一次请求。该结果能反映基本连通性，但不能等同于所有网站的实际下载速度。

测试目标的位置、节点到目标站点的路由、短时拥塞以及运营商网络都会影响结果。某节点对测试地址延迟最低，不代表它访问另一个地区的业务服务也一定最快。若特定服务有明确的区域和稳定性要求，更合适的做法是先按用途筛选节点，再在较小范围内使用自动策略。

url-test：按探测延迟选择可用成员

url-test 会对组内成员执行连通性测试，并在可用成员中选择探测延迟较低的一项。它适合成员功能相近、出口区域相同，而用户主要关心交互延迟的场景。例如，同一地区有多条普通线路时，可以先用 url-test 自动完成基础筛选，减少频繁手动切换。

一个常见配置结构如下。字段支持情况与具体内核版本有关，导入前应以当前 mihomo 配置文档和客户端日志为准：

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval 表示测试间隔，通常以秒为单位。间隔过短会增加后台探测频率，却未必改善体验；间隔过长则可能无法及时识别线路状态变化。桌面常驻设备可以根据网络波动设置为数分钟，移动设备则可适当延长。

tolerance 用于减少延迟差异很小时的频繁切换。假设当前成员延迟为 95 毫秒，另一个成员测试为 80 毫秒，两者差距较小，继续保留当前成员往往比立刻切换更稳定。容差并非越低越好；设置为零可能让轻微的测量抖动反复改变选中项。

lazy 开启后，内核可在策略组实际被使用时再进行相应测试，有助于减少长期未使用策略组的后台请求。不过，惰性检查的具体触发和缓存行为取决于内核实现，判断结果时应以日志和客户端显示的最后测试时间为准。

url-test 的适用与限制

• 适合网页浏览、代码仓库访问和需要较低响应时间的日常连接。
• 适合同区域、同用途、质量接近的一组节点，不适合把功能差异明显的出口混在一起只按延迟选择。
• 探测延迟不直接代表带宽。大文件下载更受出口带宽、服务端限速和长时间拥塞影响。
• 选中项改变后，新连接可能使用新的出口地址。对出口一致性敏感的登录会话需要谨慎。

fallback：按顺序使用第一个可用成员

fallback 的核心是优先级，而不是比较谁的延迟最低。内核会检查组内成员是否可用，并优先选择列表中排在前面的可用项。首选成员不可用时，才会使用后续成员；首选成员恢复后，后续新连接通常会重新回到优先级更高的成员。

proxy-groups:
  - name: 稳定线路
    type: fallback
    proxies:
      - 主线路
      - 备用线路-一
      - 备用线路-二
    url: http://www.gstatic.com/generate_204
    interval: 300
    lazy: true

这种逻辑特别适合线路之间存在明确等级的情况。例如，主线路出口固定、兼容目标服务且长期稳定，备用线路只在主线路故障时启用。即使备用线路的探测延迟偶尔更低，fallback 也不会因此越过仍然可用的主线路。

“可用”需要结合测试地址理解。测试成功只能证明节点可以访问该测试目标，不能保证所有目标服务都能访问。如果主线路能正常返回连通性测试，但某个业务域名受到路由、区域或服务端策略影响，策略组可能仍把主线路视为可用。此时应调整业务规则、拆分策略组或使用更有代表性的测试目标，而不是单纯缩短检查间隔。

fallback 更适合哪些任务

远程办公、固定区域服务、家庭网关和长时间运行的设备通常更看重“首选线路不变，故障时才后移”。这类需求与 fallback 的顺序语义一致。配置时应把真正希望长期使用的成员放在最前面，并确保备用成员具备相同的业务访问能力。

如果列表顺序没有明确含义，所有成员都可随意替换，那么 url-test 往往更贴近日常自动选择需求。反过来，如果用户希望手动决定当前节点，则应使用 select 类型，而不是期待 fallback 记住一次临时选择。

load-balance：把连接分配到多个可用成员

load-balance 不以选出唯一“最快节点”为主要目标，而是按照策略把不同连接分配给组内多个可用成员。它适用于大量彼此独立的请求、并发下载任务或多设备共享网关，但不能把一条已经建立的单连接带宽直接叠加为多个节点带宽。

proxy-groups:
  - name: 并发分配
    type: load-balance
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

常见的 consistent-hashing 会依据目标信息进行一致性映射，让相同或相近目标在成员列表稳定时倾向使用同一成员。这有助于减少同一站点在连续请求间频繁改变出口。成员故障或列表变化时，一部分映射仍会调整，因此它不是永久固定出口。

round-robin 则更接近轮流分配新连接。它能让成员获得更均匀的连接机会，但同一应用访问多个域名或建立多条连接时，可能出现不同出口地址。具体可用的 strategy 值会随 Clash 分支和 mihomo 版本变化，使用前应查看当前内核文档，不能把其他实现的字段直接复制进配置。

负载均衡不等于单连接聚合

浏览器下载一个文件时，如果服务端只建立单条连接，该连接通常只经过一个成员。只有下载器、浏览器或应用建立多条独立连接，并且这些连接被分配到不同成员时，整体吞吐才可能利用多条线路。最终速度仍受本地网络上限、节点限速、目标服务器和协议行为影响。

负载均衡还会带来出口一致性问题。部分网站会把短时间内频繁变化的来源地址视为异常，登录状态、验证码频率或区域内容也可能受到影响。对于此类服务，可以通过规则把域名交给 fallback、url-test 或固定的 select 组，而把静态资源、软件更新等并发请求交给负载均衡组。

UDP 流量同样需要关注会话映射和节点支持情况。语音、游戏或 QUIC 连接对路径变化较敏感，不应仅为了“均衡”而让相关流量在出口之间频繁变化。配置后应使用实际应用测试丢包、延迟抖动与重连情况，而不是只看健康检查数值。

按设备与场景选择策略组

桌面日常浏览：优先考虑 url-test

Windows、macOS 或 Linux 桌面设备通常会同时处理网页、代码下载和即时通信。如果节点来自同一区域、访问能力接近，可以使用 url-test，并设置合理容差避免抖动。对于必须固定区域或需要稳定出口的域名，再通过规则分流到单独的 fallback 或手动选择组。

远程办公与固定业务：优先考虑 fallback

企业系统、远程桌面、管理后台和长期登录服务更重视可预测性。把最符合要求的线路放在第一位，再按实际可靠程度排列备用成员，比单纯按毫秒延迟排序更合适。备用成员应事先验证目标服务、DNS 解析和 UDP 支持，不能等主线路故障后才发现备用线路不兼容。

家庭网关与多设备并发：谨慎使用 load-balance

路由器或旁路网关同时承载多台设备时，连接数量较多，负载均衡更容易体现连接分配作用。建议使用规则把对出口一致性敏感的服务单独分组，再让系统更新、静态资源和普通并发请求进入 load-balance。网关硬件性能有限时，还要观察健康检查、TUN 转发和大量连接跟踪产生的资源占用。

移动设备：延长测试间隔并缩小成员范围

笔记本和移动终端会在 Wi-Fi、热点及蜂窝网络之间切换。网络环境变化本身就会导致探测结果失效，过于频繁的健康检查意义有限。可以减少自动组中的成员数量、延长间隔，并启用适当的惰性检查。若设备只偶尔使用代理，手动选择组也可能比复杂自动策略更直观。

TUN 模式不改变策略组语义

TUN 模式负责接管更多系统流量，包括部分不遵循系统代理设置的程序；它不会把 url-test 变成负载均衡，也不会改变 fallback 的成员顺序。流量进入 mihomo 后，仍然按照规则匹配到策略组，再由策略组选择成员。

启用 TUN 后连接范围扩大，DNS、局域网流量和 UDP 应用也可能进入内核，因此策略组配置问题会表现得更明显。排查时要区分“流量是否被 TUN 接管”“规则命中了哪个策略组”和“策略组最终选中了哪个成员”三个阶段。

策略组未按预期切换的排查顺序

1. 确认实际运行的配置。

   订阅更新后可能生成新的策略组，配置覆写也可能改变组名、成员和测试参数。先在 Clash Verge Rev 的配置页确认当前启用配置，再核对运行中的策略组内容。

2. 查看规则命中结果。

   连接没有进入目标策略组时，调整组内算法不会产生效果。打开连接或日志页面，确认域名、目标地址、规则类型以及最终命中的策略名称。

3. 检查健康测试状态。

   观察各成员的最后测试时间、延迟与可用状态。全部超时通常需要检查测试地址、DNS、节点本身和本地网络；只有个别成员失败，则应单独验证对应线路。

4. 核对名称与缩进。

   YAML 对缩进敏感，proxies 中的名称还必须与节点或其他策略组名称准确对应。名称包含特殊字符时可使用引号包裹，避免解析产生歧义。

5. 使用新连接复测。

   关闭测试应用中的现有会话，或等待连接结束后重新访问。只刷新界面上的策略状态，不能让所有已建立连接立即迁移。

6. 区分 DNS 与代理故障。

   域名无法解析时，策略组可能尚未获得可连接的目标。应先检查 DNS 日志、nameserver 配置和劫持设置，再判断节点选择是否异常。直接使用 IP 能连接而域名失败，通常更值得先排查解析链路。

三类策略的快速结论

• 需要自动选择低延迟成员：使用 url-test，并通过容差减少频繁切换。
• 需要固定主线路与顺序备用：使用 fallback，按真实业务优先级排列成员。
• 需要把大量独立连接分散到多个成员：使用 load-balance，同时处理出口一致性问题。
• 需要用户明确指定节点：使用 select，不要用自动策略模拟手动控制。

实际配置可以组合使用：顶层策略组提供手动选择，内部再放入自动测速组、故障转移组和负载均衡组。规则只引用具有明确用途的组名，组内成员保持同类，测试地址与间隔则根据设备和业务调整。这样既方便在 Clash Verge Rev 中查看状态，也能在出现故障时快速定位是规则、健康检查还是节点本身的问题。