Clash 策略组详解：手动选择、自动测速、故障切换与负载均衡

策略组决定“规则说走代理之后，具体用哪个节点”

策略组是一组节点加一种挑选方式：手动选择组由你来挑，自动测速组按延迟挑最低的，故障切换组按顺序挑第一个可用的，负载均衡组把连接分摊到多个节点。 规则只需指向策略组，节点的增减和切换都在组内完成，不必改动规则。选择哪种类型，关键看三件事：你是否愿意手动管理、能否接受自动换节点、出口 IP 是否需要固定。

本文只讲客户端里的策略组配置。服务器侧的调度、入口与落地的分配属于网络专题，见 节点、负载均衡与三网优化。以下配置为通用示意，字段名称与默认值以所用内核文档为准。

四种常用类型一览

类型	配置名	谁挑节点	何时换节点	出口 IP
手动选择	select	你	只在你操作时	固定
自动测速	url-test	内核按延迟	定期测试后，差距超过容差时	可能变化
故障切换	fallback	内核按列表顺序	当前节点测试失败时	平时固定，故障时变化
负载均衡	load-balance	内核按策略	每条新连接都可能不同	经常变化

此外还有用于链式转发的 relay 类型，在机场订阅中较少见，本文不展开。

手动选择：最可控的一层

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动测速
      - 故障切换
      - 节点A
      - 节点B
      - DIRECT

手动选择组的列表里不仅可以放节点，也可以放其他策略组和 DIRECT。机场下发的配置通常把一个手动选择组作为“总开关”，其他分组挂在它下面。这种嵌套让你可以在界面上一键决定“用自动测速”还是“固定某个节点”。

适合：需要固定出口、经常登录账号、对地区识别敏感的场景。

自动测速：省心，但出口会变

  - name: 自动测速
    type: url-test
    url: https://www.example.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 节点A
      - 节点B
      - 节点C

三个关键参数：

• 测试地址：内核向它发起请求来计算延迟，应是一个响应极轻、稳定可达的地址；地址本身不可达时，所有节点都会显示超时。
• 测试间隔：单位为秒，太短会产生大量无意义请求，太长则对节点变化反应迟钝。
• 容差：新节点比当前节点快多少毫秒才切换，用来避免在几个延迟接近的节点间反复横跳。

需要注意，测得的是到测试地址的往返延迟，不等于下载速度，也不反映晚高峰的拥堵程度。

适合：节点多、不想手动挑选、对出口 IP 变化不敏感的浏览类用途。

故障切换：平时固定，出事才换

故障切换组按列表顺序检查节点，始终使用第一个测试通过的节点。只要第一个节点正常，出口就不会变；它失效时才轮到第二个。配置字段与自动测速相近，但没有容差的概念，列表顺序就是优先级。

适合：有明确首选节点、希望出口尽量稳定、同时需要自动兜底的场景。把常用节点放第一位，同地区的备用节点放第二、第三位，可以在切换时尽量维持同一地区出口。思路层面的讨论见 节点失效后怎么办。

负载均衡：分摊连接，代价是出口不固定

负载均衡组把不同连接分配到组内多个节点。常见的分配策略有两种：

• 一致性哈希：同一目标域名尽量走同一节点，出口相对稳定；
• 轮询：每条新连接依次换节点，分摊最均匀，出口变化最频繁。

对于大文件分段下载、多任务并发，负载均衡能分摊压力；但打开一个网页会产生多条连接，它们可能从不同出口发出，对会校验会话与 IP 一致性的网站可能触发重新验证。出口变化对固定地区网站的影响，见 出口 IP 为什么会变。

按需求挑类型

你对出口 IP 的要求？
├─ 必须固定（登录账号、地区敏感服务）
│   ├─ 愿意手动管理 → 手动选择
│   └─ 想要自动兜底 → 故障切换（同地区节点排前）
├─ 无所谓，只想省心浏览 → 自动测速（适当调大容差）
└─ 下载、多连接任务 → 负载均衡（优先一致性哈希）

一个常见的组合是：用手动选择组作为入口，里面挂一个自动测速组、一个故障切换组和若干单独节点；日常用自动测速，遇到需要固定出口的任务时切到单独节点。

测试地址与测试间隔怎么定

自动测速组与故障切换组都依赖一个测试地址来判断节点是否可用，它选得不好，后面的一切判断都会失真：

• 选轻量地址：常见做法是使用专门返回空内容的检测地址，响应小、不受页面内容影响；
• 选稳定可达的地址：测试地址自身偶发故障时，组内全部节点都会被判定为失败，故障切换组会误以为“全都坏了”；
• 地址要与用途相关：如果你主要访问某一地区的服务，测试地址的服务器位置会影响延迟排序，排序结果只代表到测试地址的距离；
• 间隔与节点数相乘：每个间隔周期内，组里每个节点都会被测一次，节点很多时，过短的间隔会带来可观的请求量。

可以把测试间隔设在几分钟量级，再根据实际切换频率调整，具体默认值以内核文档为准。

配置策略组时的四个坑

1. 分组名称与规则不一致：规则引用的名称必须与分组名逐字一致，否则配置加载失败或连接被拒。规则写法见 Clash 规则怎么写。
2. 订阅更新后节点名变化：若分组里手写了节点名，机场改名后该节点会从分组中消失。可以使用按名称筛选或自动包含订阅节点的写法，具体支持情况以内核文档为准。
3. 测试地址被规则拒绝：测试请求同样经过内核，若被拒绝或被分流到直连，延迟结果会失真。
4. 多层嵌套形成循环：A 组包含 B 组、B 组又包含 A 组，会导致配置无法加载。

小结

策略组的选择本质上是在“省心”和“出口稳定”之间权衡。更多规则、DNS 与排错主题，回到 规则分流与故障排查专题页 查看；涉及登录与账号的使用，请遵守所在地法律法规与相关平台条款。