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

Clash 配置中的策略组位于规则与具体代理节点之间。规则负责判断一条连接属于哪类流量，策略组再决定这条连接最终交给哪个节点。把策略组理解成单纯的“节点文件夹”容易产生误判：不同组类型有不同的选择条件、健康检查方式和故障处理顺序，名称相似并不代表行为相同。

url-test、fallback 与 load-balance 都能引用多个代理，但它们解决的是三类问题。前者寻找探测结果较优的节点，中者按预设优先级保留备用线路，后者把不同连接分配给多个可用节点。选择前应先明确目标是降低日常延迟、保持出口优先级，还是分散并发连接，而不是只看客户端界面中显示的延迟数字。

策略组在规则分流中的位置

一条请求进入 Clash 或 Mihomo 后，通常先经过 DNS 与入站处理，再按配置中的规则从上到下匹配。规则目标可以是具体节点，也可以是策略组。实际配置更常把规则指向组名，例如让开发服务进入“自动选择”，让工作系统进入“主备线路”，让大批独立下载任务进入“连接分散”。

策略组只处理已经被规则送入该组的连接。即使创建了多个测速组，如果规则最终指向 DIRECT，这条连接仍会直连；如果最终命中 MATCH 并进入另一个组，也不会调用前面的测速组。因此，排查“节点明明可用但流量没有经过它”时，应同时查看规则命中记录与策略组当前选择，不能只盯着节点列表。

自动组与手动 select 组的关系

select 是常见的手动选择组，可以把自动组作为其中的选项。这样既能保持日常自动选择，也能在目标网站对某个出口有限制时临时切换到固定节点。自动组本身也可以被其他组引用，但嵌套层级过多会增加排查成本。配置时最好让组名表达功能，例如“网页自动”“工作主备”“下载分散”，不要只写“组一”“组二”。

url-test：按探测结果自动选择

url-test 会让内核对组内候选代理执行指定 URL 的探测，并根据结果选择表现较优的节点。它适合网页浏览、代码托管、软件更新等希望自动避开高延迟线路的日常流量。这里的“较优”主要来自探测请求的响应时间和可用性，并不是对带宽、丢包、晚高峰稳定性进行完整评估。

探测 URL 应当稳定、响应体小，并且能返回明确的成功状态。很多配置使用返回空内容的 HTTP 端点，是为了减少测试流量。若测试地址在某些网络环境中被重定向、限流或单独优化，测出的排序就可能偏离真实业务。更换测试地址时，应确认所有候选线路都能公平访问该端点。

proxy-groups:
  - name: 网页自动
    type: url-test
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

interval 表示周期探测间隔，单位通常为秒。间隔过短会增加请求数量，也容易让选择结果随轻微网络抖动变化；间隔过长则可能在节点故障后较晚更新状态。对普通终端而言，数分钟一次通常比十几秒一次更稳妥，具体值还要结合节点数量与设备性能。

tolerance 用于给切换设置容差。当前节点与候选节点的差距没有超过容差时，维持现状可以减少频繁切换。假设当前结果为 125 毫秒，另一节点为 90 毫秒，若容差为 50 毫秒，两者差值不足以触发切换；如果差距持续扩大并越过阈值，自动组才更有理由更新选择。不同内核版本与客户端可能对选项展示略有差异，应以实际使用的 Mihomo 或 Clash 内核文档为准。

lazy 启用后，健康检查通常会更偏向在组被实际使用时执行，减少闲置组的周期探测。它适合配置里存在许多地区组、但日常只使用其中少数组的情况。若某组承担必须快速发现故障的关键连接，则需要权衡延迟发现与后台探测开销。

fallback：按顺序保留主备线路

fallback 的核心不是“选择最快”，而是“选择列表中第一个可用项”。排在前面的节点具有更高优先级，只要健康检查仍认为它可用，就会继续使用；只有当前优先项失败，才会向后寻找可用节点。这个行为适合出口身份、地区或线路稳定性比几毫秒延迟更重要的场景。

例如，工作服务要求长期使用固定地区出口，可以把主节点放在第一位，把同地区备用节点放在第二位，再把跨地区应急节点放在最后。备用节点即使探测延迟更低，也不会越过仍然可用的主节点。这样能减少出口变化，但也意味着主节点处于“能连通但体验较差”的状态时，组可能不会自动切换。

proxy-groups:
  - name: 工作主备
    type: fallback
    proxies:
      - 主线路
      - 同区备用
      - 异地应急
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

“可用”取决于健康检查，而健康检查只能观察指定端点。某节点能访问探测 URL，却无法访问特定业务域名时，fallback 仍可能保留它。遇到这种情况，应先检查目标域名是否命中了正确规则，再检查 DNS 解析、目标站点限制以及线路对特定协议的支持。不能仅通过缩短探测间隔解决业务端点不一致的问题。

主线路恢复后，组可能重新回到列表中靠前的节点。若线路在可用与不可用之间反复变化，就会形成回切抖动。可从三个方向缓解：选择更稳定的探测端点、延长合理的检查间隔、重新评估不稳定节点是否适合担任最高优先级。若目标是始终保持当前可用出口直到人工切换，手动 select 组往往比自动回退更符合要求。

错误回退常见原因

• 列表顺序与实际主备意图相反，低优先级线路被放在最前面。
• 健康检查地址对某条线路不可达，但真实业务地址可以访问，导致节点被提前判定为不可用。
• 订阅更新后节点名称改变，静态组引用失效或指向了不同节点。
• 规则没有进入该 fallback 组，观察到的出口来自另一组或最终兜底规则。
• 客户端界面缓存了旧状态，内核实际选择与页面显示更新不同步，需要查看连接记录确认。

load-balance：在多个节点间分配连接

load-balance 面向的是多条独立连接。内核依据负载均衡策略，为不同连接选择组内可用节点。它不是把几个节点的带宽合并成一条更粗的通道，也不会把单个 TCP 连接的数据包随意拆到多个出口。单文件下载如果只有一条连接，通常仍由一个节点承载；多连接下载、多个并发请求或多台设备同时访问时，才更容易观察到分配效果。

Mihomo 常见的负载均衡策略包括 consistent-hashing 与 round-robin。一致性哈希倾向于让相同目标持续落到同一节点，有利于减少同一站点在短时间内频繁更换出口。轮询则按连接依次选择可用节点，分散更直接，但同一服务的不同连接可能来自不同出口。

proxy-groups:
  - name: 下载分散
    type: load-balance
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

对登录态敏感、会校验出口地址的服务，一致性哈希通常比轮询稳妥。某些网站会把登录会话、风控状态或区域内容与出口地址关联，如果页面资源和接口请求分别走到不同节点，可能出现重复验证、区域跳变或会话失效。即使采用一致性哈希，域名不同的资源仍可能被分配到不同节点，因此金融、企业登录和需要固定出口的业务更适合固定节点或 fallback。

轮询适合大量彼此独立、能够容忍出口变化的连接。例如多个软件包下载任务、分散的公开资源请求，或局域网中多台设备产生的大量非敏感连接。是否能提高整体吞吐，还取决于本地接入带宽、远端服务器限制、节点上游容量和并发模型。若瓶颈在家庭宽带或目标服务器，增加节点数量不会突破该瓶颈。

订阅节点与健康检查如何配合

节点来自订阅时，常见做法是通过 proxy-providers 管理远程提供者，再让多个策略组通过 use 引用同一提供者。这样订阅更新后，新节点可以进入相应的动态组，不必在每个组里逐项复制名称。提供者的更新周期与健康检查周期是两件事：前者决定何时拉取节点列表，后者决定何时检测已有节点状态。

proxy-providers:
  provider-main:
    type: http
    url: https://example.com/clash-provider.yaml
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 订阅自动
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

提供者健康检查与策略组探测可能同时存在。配置大量节点时，应留意重复探测带来的网络请求与设备负载。移动设备、低性能路由器和节点数量较多的订阅尤其明显。可以统一检查周期、启用按需检查，或只让真正参与选择的组进行必要测试。减少探测不等于关闭所有检查，而是让检查频率与故障发现需求匹配。

订阅更新还可能改变节点名称、排序或标签。使用 filter 筛选地区时，应确认正则表达式没有误收测试节点或漏掉名称格式变化后的节点。若 fallback 通过提供者动态引用节点，提供者返回顺序也可能影响优先级；对必须固定顺序的主备线路，显式列出节点通常更易控制，但节点改名后也要更新配置。

按业务目标选择策略组

日常网页与通用应用

优先考虑 url-test，设置适中的探测周期与容差，并保留一个手动选择入口。它能在多个功能相近的节点中进行日常自动选择。节点之间如果地区差异明显，可以先按地区建立自动组，再用上层 select 选择地区，避免自动测试把出口切到不符合业务要求的区域。

固定地区、工作系统与远程访问

优先考虑 fallback，把最符合出口要求的线路排在前面，把同地区备用线路放在其后。若服务严格绑定出口地址，直接使用固定节点或手动组可能更合适。自动回退能够提高故障时的连续性，但出口变化本身也可能触发目标服务的安全验证。

并发下载与多设备共享

可考虑 load-balance，并根据业务对出口一致性的要求选择一致性哈希或轮询。不要把登录、支付、企业身份认证等敏感连接混入轮询组。更稳妥的做法是通过规则将下载域名、更新服务或特定设备流量导入负载均衡组，其他流量继续使用稳定出口。

TUN 模式下的选择

TUN 模式扩大了能够被内核接管的流量范围，但不会改变三类策略组的基本决策逻辑。进入 TUN 的连接仍需匹配规则，再进入相应策略组。启用 TUN 后若发现访问结果变化，应分别检查系统路由、DNS 劫持或重定向设置、规则命中和策略组选项，不要把所有异常都归因于自动测速。

频繁切换与错误回退的排查顺序

1. 确认规则命中。在客户端连接记录中找到目标域名，检查它实际进入哪个策略组。若规则目标错误，调整健康检查不会改变流量去向。
2. 确认组类型与目标一致。需要主备顺序却使用 url-test，或需要固定出口却使用轮询，都会得到看似异常但符合配置逻辑的结果。
3. 查看探测端点。确认测试 URL 在所有节点上都能稳定返回成功状态，避免地区限制、重定向或服务端限流影响判断。
4. 检查间隔和容差。url-test 频繁变化时先增加容差；故障发现过慢时再评估检查周期，而不是直接设为极短间隔。
5. 核对节点顺序。fallback 从前向后选择可用项，第一项必须是真正希望优先使用的线路。
6. 检查订阅更新结果。确认节点名称、筛选规则和提供者状态，避免组内实际候选与预期不一致。
7. 观察真实连接而非只看首页数字。延迟面板是探测结果，连接日志才说明某项业务最终使用了哪个节点。

选择策略组的关键，是把“速度排序”“主备优先级”和“连接分散”分开处理。url-test 适合从功能相近的节点中自动挑选，fallback 适合保持明确的线路优先级，load-balance 适合多个独立连接之间的分配。配置完成后，应使用目标业务验证规则命中、节点选择和出口稳定性，而不是仅以一次延迟测试作为结论。