进阶配置 预计阅读 12 分钟

Clash 策略组 url-test、fallback、load-balance 怎么选:参数与适用场景对比

逐项拆解三种自动策略组的工作方式,讲清 url、interval、tolerance、strategy 等参数含义,并给出按使用场景挑选策略组类型的思路与 YAML 写法。

三种自动策略组：先确定选择目标

Clash 的策略组不是新的代理服务器，而是对已有节点进行选择的配置层。规则先决定请求进入哪个策略组，策略组再决定使用哪个节点。配置里出现了自动组，并不代表所有流量都会进入它；只有规则或上层选择组引用了它，自动选择才会影响相应请求。

三种类型都可以结合健康检查使用，但选择标准不同：url-test 关注探测延迟，fallback 关注预设顺序，load-balance 关注连接分配。日常浏览优先考虑前两者；只有确实需要让多个出口承担不同连接时，再考虑负载均衡。

策略组类型 选择依据 适合的需求 主要边界
url-test 探测延迟与切换容差 在同类节点中自动选择较低延迟出口 低延迟不等于高下载速度
fallback 列表中第一个健康节点 主线路优先，故障时使用备用线路 不会因为备用线路更快就主动选它
load-balance 哈希或轮询等分配策略 让不同连接使用不同可用节点 不把单条连接的带宽叠加

url、interval 与 lazy：健康检查如何执行

url 是探测目标，不是订阅地址

url 指定健康检查请求访问的地址。内核通过候选节点向该地址发起 HTTP 探测，记录成功与否及耗时。它不是订阅下载链接，也不是用来下载大文件的测速地址。示例使用 https://www.gstatic.com/generate_204，这是常见的轻量探测端点，但是否适合仍要看你的线路与目标网络。

为了公平比较，同一组应使用同一个探测地址。节点访问探测站很快，不代表访问视频站或办公系统也很快；反过来，探测域名被限制也可能让可用线路被标记为异常。排查时应把“探测失败”和“业务访问失败”分开验证。

interval 用秒计，不是毫秒

interval: 300 表示按 300 秒，也就是 5 分钟的周期安排检查。它不是每个请求的超时时间，也不保证故障一定在 300 秒内被所有应用感知。懒检测、调度时机、检测耗时以及现有连接状态都会影响实际表现。

  • 日常浏览可先从 300 秒开始，观察一段时间后再调整。
  • 需要更快发现主线路故障时，可以评估 60 秒，但检查请求会增加。
  • 若有 20 个节点，每 60 秒完整检查一轮，理论上每小时约有 1200 次探测；每 300 秒一轮则约为 240 次，实际数量还受懒检测等机制影响。

lazy 决定闲置组是否继续周期检测

在支持该字段的内核中，lazy: true 用于减少未被使用策略组的检测开销；lazy: false 则允许闲置组继续按周期检查。如果希望备用组在尚未被选中时也保持较新的健康状态，可以考虑关闭懒检测，但节点多、自动组多时要关注额外开销。它不会让一次已经失败的业务请求自动重放。

url-test：自动选低延迟，tolerance 控制切换

url-test 会对候选节点进行探测，并依据结果自动选择节点。它适合节点用途相近、允许出口变化的场景，例如几条同地区普通浏览线路。若候选节点在地区、账号风控或可访问服务上差异很大，单纯比较延迟往往不是合适的筛选条件。

proxy-groups:
  - name: 自动低延迟
    type: url-test
    proxies:
      - 香港线路 A
      - 香港线路 B
      - 日本线路 A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

这里的三个节点名必须已经存在于配置的 proxies 中，并且逐字一致。示例只是策略组片段，不包含服务器地址、凭据或完整规则，不能单独当成可连接的订阅使用。

tolerance 的单位是毫秒

tolerance: 50 表示切换容差为 50 毫秒，用来降低节点因小幅延迟波动而频繁切换的概率。举例来说，假设当前节点测得 120 毫秒，另一节点测得 100 毫秒，相差只有 20 毫秒，通常没有必要仅为这点差距切换；如果另一节点降到 60 毫秒，改善达到 60 毫秒，就可能满足切换条件。这里的数值是说明性示例，不是本站实测。

容差不是延迟上限，也不是失效阈值。把它写成 50 不代表超过 50 毫秒的节点都会被排除。当前节点不可用时，也不能依靠一个很大的容差强行保留它。具体边界比较与首次选择行为应以所用内核实现为准。

  • 频繁切换：先检查节点是否反复超时，再考虑适当增大容差。
  • 测速快但下载慢：另做实际业务测试，检查吞吐量、丢包和线路拥塞。
  • 账号要求固定地区：先限定候选节点地区，或改用手动选择，避免把不同地区混在一起。

fallback：主线路优先，故障后切备用

fallback 按 proxies 列表顺序寻找可用节点。第一项健康时，后面的节点即使延迟更低，也不会因此成为首选。它适合“主线路的出口更稳定，备用线路只用于应急”的需求，而不是“任何时候都选最快”。

proxy-groups:
  - name: 主备线路
    type: fallback
    proxies:
      - 香港线路 A
      - 日本线路 A
      - 新加坡线路 A
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false

这个顺序表示：优先使用香港线路 A；其健康检查失败后，才考虑日本线路 A；前两项都不可用时，再使用新加坡线路 A。后续检查确认优先级更高的节点恢复后，新连接可以重新回到靠前的可用节点。因此，主节点反复恢复又失败时，也可能出现出口来回变化。

故障切换不等于现有连接迁移

一次视频播放、SSH 会话或长文件下载，通常已经建立了连接。策略组换了节点，不会把同一条 TCP 连接平滑搬到另一台服务器。旧连接可能失败，应用需要自行重连；新的连接才会按新的选择建立。对实时通话或远程终端而言，备用线路能减少恢复成本，但不能承诺完全不中断。

load-balance：分配连接，不是合并带宽

load-balance 会在可用节点之间分配流量。它的收益通常来自多个连接分散到不同出口，而不是让一条下载连接同时拥有两条线路的速度。即使应用支持并发下载，是否受益也取决于服务器限制、分配策略、线路带宽和应用自身行为。

proxy-groups:
  - name: 多线分配
    type: load-balance
    proxies:
      - 香港线路 A
      - 香港线路 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

consistent-hashing：让同类目标的出口较稳定

在 mihomo 中，consistent-hashing 通常按目标域名的主域部分进行一致性哈希；没有可用域名时会涉及目标 IP。它倾向于让同一目标落到同一节点，但这不是“一个账号永久绑定一个出口”。节点可用集合变化、目标域名变化或其他分配条件变化，都可能改变结果。

一个网页往往会访问登录、接口、图片和静态资源等多个域名，因此“打开同一网站”并不天然意味着所有请求都走同一出口。对登录会话、支付或地区敏感业务，更稳妥的方式是让相关域名规则指向固定节点或受控的专用组。

round-robin：按轮次分配新连接

在支持该策略的内核中，把 strategy 改为 round-robin，即可按轮询方式在可用候选间分配新连接。它不是按每个数据包轮流发送，也不保证字节量平均：一个连接可能传输 2 GB，另一个只传输 2 KB，连接数接近不代表流量接近。

旧版 Clash 内核对 strategy 的支持范围可能不同，不应把 mihomo 的全部策略值直接复制到归档客户端。遇到字段不识别或行为不符，先确认内核名称与版本，再查对应文档；不要仅凭界面成功保存就认定字段已经生效。

把自动组接入规则：select 入口与完整引用

仅添加 proxy-groups 不会自动替换现有规则。比较方便的做法是在上层放一个 select 手动选择组，把三种自动组都列为选项，再由需要代理的规则引用这个入口。这样可以在界面中切换方案，而不必每次重写规则。

proxy-groups:
  - name: 代理入口
    type: select
    proxies:
      - 自动低延迟
      - 主备线路
      - 多线分配
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,代理入口
  - MATCH,DIRECT

这段也是合并片段，需要和前面的自动组处在同一份配置中。example.com 只是规则语法演示域名，不是测速站。该规则只把它及其子域名交给“代理入口”，剩余请求通过最后的 MATCH,DIRECT 直连；请不要把这个演示误当成覆盖日常业务的完整分流规则。

  1. 先保留原订阅配置，在测试副本中添加策略组，避免更新订阅后丢失修改。
  2. 核对每个节点名、策略组名和规则引用，大小写、空格与中文字符都要一致。
  3. 保持全配置只有一个顶层 proxy-groups 和一个顶层 rules，把列表项合并进去，不要重复粘贴顶层键。
  4. 在 Clash for Windows 的 Profiles 中选中测试配置，随后到 Proxies 中使用 Rule 模式并展开“代理入口”，选择要测试的自动组。
  5. 如果使用 Global 模式，流量改由全局策略处理，原有规则引用不再决定去向；使用 Direct 模式也无法验证自动组的日常分流效果。

需要长期保留修改时，应采用当前客户端支持的覆写、Mixin 或配置合并机制，并检查最终生成的运行配置。不同客户端对数组是替换还是合并的处理可能不同，不能假设追加几行就一定保留订阅内的所有组。

自动策略组不生效：按四步排查

第一步：确认配置被内核接受

查看 Logs 中是否出现 YAML 解析失败、节点不存在或不支持的策略值。YAML 使用空格缩进，不使用 Tab；proxies 下每个列表项要对齐。节点名若含冒号加空格等特殊组合，使用引号包住整个名称更稳妥。

第二步：分开测试节点与探测地址

先手动选择单个节点访问实际目标，再执行组内延迟测试。如果只有某个探测地址失败，应检查该地址的可达性及 HTTPS 握手，而不是马上删除所有节点。若节点本身无法连接，调整 tolerance 或更换负载算法也无法解决认证、服务器或网络故障。

第三步：核对请求实际命中的策略

在 Connections 中查看新请求的规则与代理链，确认确实经过目标组。若请求命中了更靠前的直连规则，或者应用未经过客户端，自动组自然不会产生效果。浏览器能代理而其他应用不能时，还要检查系统代理、应用独立代理设置或 TUN 接管范围；策略组不能代替流量接入配置。

第四步：使用新连接验证变化

切换组或等待检测后，重新发起请求，避免一直观察旧连接。测试 fallback 时可在受控环境让主节点暂时不可达，记录检查时间、首次失败时间与恢复时间；测试 url-test 时记录多轮延迟，不要只比较一次结果。测试 load-balance 时观察多条连接的代理链，而不是只刷新一个可能复用连接的页面。

  • 普通浏览：同地区节点搭配 url-test，从 300 秒间隔、50 毫秒容差开始评估。
  • 固定主线：使用 fallback，按业务优先级排序，并验证主线恢复后的表现。
  • 多连接任务：在确认出口变化可接受后使用 load-balance，分别验证哈希与轮询。
  • 敏感会话：优先固定节点或专用选择组，不把出口稳定性完全交给自动延迟比较。

选择策略组的关键不是哪种“更高级”，而是需要优化什么：延迟、主备顺序，还是连接分配。先限定候选节点，再设置检测参数，最后用真实业务验证，通常比不断缩短检测间隔更有效。

Clash 下载