从入门到进阶：Clash 策略组完全解析 · select/url-test/fallback/load-balance

🧩 什么是策略组？

策略组 (proxy-groups) 是 Clash 分流系统的核心，它把多个代理节点组合成一个逻辑单元，并定义选择这些节点的策略。当一条规则引用了某个策略组，该组就会按照你设定的方式（手动选、自动测速、故障转移或负载均衡）挑选出一个节点来完成请求。

简单说：节点是原材料，策略组是调度算法。 合理使用策略组，可以让你在多个服务器之间无缝切换，始终保持最佳的网络体验。

💡 基础概念： 每个策略组需要一个名称、一个类型 (type) 和一个节点列表 (proxies)。类型决定了选点逻辑，节点列表可以是具体的节点名称，也可以是其他策略组的名称（实现嵌套）。

🖱️ 手动选择：select

最基础的策略组类型，由用户手动指定当前使用的节点或策略。它不会自动切换，适合需要固定出口的场景，例如：

需要固定某个 IP 访问特定网站（如银行、内部系统）
临时调试某个节点时，不希望自动跳转

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - "日本节点"
      - "新加坡节点"
      - "美国节点"
      - DIRECT

客户端界面会显示为一个下拉菜单，你可以随时手动切换。常作为顶级策略组，让其他自动策略组引用它。

⚡ 自动延迟测试：url-test

这种策略组会定期向指定的 URL 发送请求，测量每个节点的延迟，然后自动选择延迟最低的那个。非常适合对响应速度敏感的场景，比如浏览网页、看视频。

proxy-groups:
  - name: "自动低延迟"
    type: url-test
    proxies:
      - "日本节点"
      - "新加坡节点"
      - "美国节点"
    url: 'http://www.gstatic.com/generate_204'
    interval: 300   # 每300秒测试一次

注意，url 必须填写一个能快速返回 HTTP 204 或 200 的地址。Google 的 generate_204 页面是目前最常用的测试目标。

🔄 故障转移：fallback

按顺序尝试节点，当第一个节点不可用（连接失败或超时）时，自动切换到下一个。这实现了高可用性，确保只要有一个节点在线，代理就不会中断。

proxy-groups:
  - name: "高可用组"
    type: fallback
    proxies:
      - "主节点"
      - "备用节点1"
      - "备用节点2"
    url: 'http://www.gstatic.com/generate_204'
    interval: 300

fallback 策略在任意时刻只使用一个节点（按顺序），不会因为延迟高低而切换，仅因故障切换。它与 url-test 的区别在于：url-test 选延迟最低的，fallback 优先用列表中的第一个。

⚖️ 负载均衡：load-balance

将请求轮流或随机分配到多个节点上，充分利用多条线路的带宽。适合下载大文件、多线程任务等需要分摊流量的场景。Clash 目前支持 load-balance 类型，可选算法为 round-robin (轮询) 或 consistent-hashing (一致性哈希)。

proxy-groups:
  - name: "下载组"
    type: load-balance
    proxies:
      - "节点A"
      - "节点B"
      - "节点C"
    url: 'http://www.gstatic.com/generate_204'
    interval: 300
    strategy: round-robin   # 轮询分配

需要注意的是，负载均衡可能导致同一会话的不同请求走到不同节点，某些网站可能会因为 IP 频繁变化而触发安全验证。建议仅为支持断点续传的下载或 API 请求使用。

🔗 组合策略实战

单个策略组往往无法满足复杂需求，真正的威力在于嵌套和组合。以下是一个典型的“多级调度”配置，可同时兼顾手动控制、自动低延迟和高可用：

proxy-groups:
  - name: "顶级选择"
    type: select
    proxies:
      - "自动低延迟"
      - "高可用组"
      - "下载组"
      - DIRECT

  - name: "自动低延迟"
    type: url-test
    proxies:
      - "日本节点"
      - "新加坡节点"
      - "美国节点"
    url: 'http://www.gstatic.com/generate_204'
    interval: 300

  - name: "高可用组"
    type: fallback
    proxies:
      - "主节点"
      - "备用节点1"
      - "备用节点2"
    url: 'http://www.gstatic.com/generate_204'
    interval: 300

  - name: "下载组"
    type: load-balance
    strategy: round-robin
    proxies:
      - "大带宽节点A"
      - "大带宽节点B"

然后在规则中引用“顶级选择”，即可在客户端界面快速切换整体策略，无需反复修改规则。进一步结合自定义代理规则，可以对不同流量使用不同策略组，例如视频流量走自动低延迟，下载流量走负载均衡。

🚫 常见误区与最佳实践

误区	正确做法
所有流量都用一个策略组	根据应用场景拆分：网页用 url-test，下载用 load-balance，重要服务用 fallback
url-test 测试间隔太短	建议 300 秒以上，太频繁会增加服务器负担且消耗流量
负载均衡用于访问网站	仅用于无状态的 API 或下载，避免触发目标站点的安全机制
fallback 没有配置测试 URL	务必配置 `url`，否则无法判断节点是否健康
策略组嵌套时出现循环引用	检查 proxy-groups 中不要出现 A 引用 B 同时 B 引用 A 的情况

最佳实践总结

顶层使用 select，方便在客户端快速切换全局策略。
将 url-test 用于日常浏览，保持低延迟。
为关键服务配置 fallback，确保永不掉线。
将 load-balance 仅限于下载或 API 流量，并配合规则限定域名。
定期检查节点的实际可用性，及时清理失效节点。

想要让策略组真正发挥价值，还需要与自定义规则和 TUN 模式配合使用，实现按域名、按应用分流。如果遇到订阅更新导致节点变更，可参考订阅排障手册保证节点列表准确。