Clash Verge如何配置策略组实现节点自动切换？

功能定位与版本演进：从手动选择到智能切换

Clash Verge 作为一款跨平台代理客户端，其核心价值在于通过规则化流量管理，实现高效、稳定的网络访问。策略组（Proxy Group）是 Clash 配置体系中实现节点自动切换的关键组件，它允许用户定义一组代理节点，并基于预设的逻辑（如延迟、故障转移、负载均衡）自动选择最优节点。过去，用户需要手动切换节点或依赖第三方脚本，而现在 Clash Verge 内置了多种策略组类型，使自动化成为标准功能。

截至当前的最新版本，Clash Verge 的策略组配置界面已趋于成熟，支持 YAML 直接编辑与可视化图形编辑两种方式，降低了新手门槛。版本演进方面，早期 Clash 内核仅支持简单的 select 手动选择，后来引入 url-test、fallback 等自动策略，Clash Verge 则进一步将这些选项整合到 GUI 中，并提供了实时延迟测试、节点健康度监控等辅助功能。理解这一变化脉络，有助于用户根据自己的需求选择最合适的策略类型，避免盲目使用“万能”配置。

核心概念：策略组与自动切换的关系

策略组本质上是一个代理节点容器，它包含多个节点（或子策略组），并定义了一个“选择器”——即如何从这些节点中选出一个用于当前请求。自动切换正是通过策略组内置的“选择器”逻辑实现的，而非由外部脚本或定时任务驱动。常用的自动切换策略有：

url-test：定期对组内所有节点进行 HTTP 延迟测试（基于指定的 URL），选出延迟最低的节点。适用于对延迟敏感的场景，如网页浏览、视频流媒体。
fallback：按节点顺序尝试，若当前节点不可用（如连接超时），则自动切换到下一个可用节点，直到找到可用节点为止。适用于强调连接稳定性的场景，如跨国办公、远程会议。
load-balance：将请求轮询或按权重分配给组内节点，常用于带宽叠加或降低单节点负载。但需注意，多数节点服务商不允许滥用，且可能影响会话一致性，建议仅在特定场景（如下载）使用。

选择哪种策略，取决于你的核心诉求：追求速度选 url-test，追求稳定选 fallback，追求带宽聚合选 load-balance。但实际应用中，常将不同策略组组合使用，形成多层自动切换体系。例如，你可以将 url-test 作为日常流量的默认策略，同时为关键业务单独配置 fallback 策略，从而兼顾速度和可靠性。

操作路径：桌面端配置步骤（以 Windows 为例）

以下步骤基于截至当前的最新版本 Clash Verge 桌面客户端（Windows/macOS/Linux 界面基本一致）。移动端（Android）路径类似，但界面布局可能略有差异，请以实际应用为准。

打开配置文件：启动 Clash Verge，点击左侧“配置”选项卡，在“代理”部分点击“编辑”按钮（或直接按 Ctrl+E 快捷键）。
进入策略组编辑区：在 YAML 配置中，找到 proxy-groups: 字段。如果使用可视化编辑，可在“策略组”面板中（通常位于“代理”页面下方）点击“添加”按钮。
添加策略组条目：以 url-test 为例，在 YAML 中添加如下块：

proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies:
      - "节点1"
      - "节点2"
      - "节点3"
    url: "http://www.gstatic.com/generate_204"
    interval: 300

其中 name 自定义，proxies 列表需与 proxies: 中定义的节点名一致，url 建议使用稳定且快速的测试地址，interval 为测试间隔（秒），经验性观察建议 300–600 秒，避免频繁测试影响节点性能。

平台差异提示：在 Android 端 Clash Verge，配置文件编辑入口通常在“配置”标签内的“编辑”按钮，路径与桌面端一致；但图形化编辑可能不支持所有策略组类型，需手动编辑 YAML。iOS 端因政策限制无官方 Clash Verge，请使用其他兼容客户端。

策略组类型决策树：如何选择自动切换策略

面对多种策略组类型，新手常感到困惑。以下决策树可以帮助你快速定位：

你的主要需求是低延迟？ → 选择 url-test。它持续监测节点延迟，始终使用当前最快节点。但需注意，延迟测试本身会增加少量开销，且节点可能因负载波动而频繁切换，导致会话中断。
你的主要需求是连接不中断？ → 选择 fallback。它按照你设定的顺序尝试节点，当前节点不可用时自动切换，切换后不会自动回退，直到下次启动或手动触发。适合访问被限制地区资源或使用不稳定节点场景。
你需要多节点带宽叠加？ → 选择 load-balance。但需谨慎：多数机场禁止用户同时使用多个节点，且负载均衡可能导致登录状态漂移。建议仅用于下载任务，且配合规则使用。

此外，还可以组合使用：例如，一个 select 策略组作为外层，内部包含多个子策略组（如一个 url-test 用于日常浏览，一个 fallback 用于关键业务），让用户手动切换模式，既保留自动能力又提供灵活性。

YAML 配置实战：以 url-test 实现自动切换

假设你有一个订阅节点列表，希望实现“自动选择延迟最低的节点”。完整配置示例如下（仅展示关键部分）：

proxies:
  - name: "HK-01"
    type: ss
    server: x.x.x.x
    port: 443
    cipher: aes-256-gcm
    password: "yourpassword"
  - name: "JP-01"
    type: ss
    server: y.y.y.y
    port: 443
    cipher: aes-256-gcm
    password: "yourpassword"

proxy-groups:
  - name: "Auto-LowLatency"
    type: url-test
    proxies:
      - "HK-01"
      - "JP-01"
    url: "http://connectivitycheck.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Auto-LowLatency

关键参数说明：tolerance 表示延迟容差（毫秒），当节点延迟差在容差范围内时，不会切换节点，避免频繁抖动。经验性观察建议设置 50–100 ms。如果未设置，一旦检测到更低延迟的节点就会立即切换，可能导致会话频繁中断。

如何验证生效：保存配置后，在主界面点击“代理”选项卡，查看“Auto-LowLatency”策略组的当前节点。该节点应显示为延迟最低的节点。你可以手动触发一次延迟测试（策略组右键菜单中“测试延迟”），观察节点是否根据结果变化。

进阶：多策略组组合与自动切换逻辑

真实场景中，往往需要同时处理多种流量。例如：流媒体需要低延迟，但传输重要文件需要稳定连接。你可以创建多个策略组，并通过规则将不同流量指向不同策略组。

proxy-groups:
  - name: "Streaming"
    type: url-test
    proxies:
      - "HK-01"
      - "JP-01"
    url: "http://www.gstatic.com/generate_204"
    interval: 300

  - name: "Work"
    type: fallback
    proxies:
      - "US-01"
      - "HK-01"

rules:
  - DOMAIN-SUFFIX,netflix.com,Streaming
  - DOMAIN-SUFFIX,office.com,Work
  - MATCH,Direct

这样，Netflix 流量走低延迟策略组，Office 连接走稳定策略组。注意：MATCH 规则应放在最后，作为兜底。如果未匹配到任何规则，则走 Direct 策略组（直接连接）。

自动切换的“切换”动作发生在策略组内部，而非规则层面。当规则命中某个策略组后，该策略组会按照其类型选择节点。因此，自动切换的粒度是“策略组”，而非“全局”。

验证与优化：如何测试自动切换效果

配置完成后，需要通过实际测试确认自动切换是否按预期工作。以下是可复现的验证步骤：

查看策略组状态：在 Clash Verge 主界面“代理”选项卡中，找到配置的策略组，观察其当前节点。如果节点显示为“未选择”，可能需要手动触发一次测试。
手动触发延迟测试：右键点击策略组名称，选择“测试延迟”。所有节点将依次进行延迟测试，完成后自动选择最优节点。注意，此操作可能消耗数十秒（因节点数量和网络状况而异）。
模拟节点故障：对于 fallback 策略组，可以临时关闭某个节点，观察是否自动切换。例如，在节点配置中将服务器地址改为无效 IP，然后发起请求，查看策略组是否切换到下一个节点。经验性观察：切换通常需要 10–30 秒（取决于超时设置）。
长期监测：使用“日志”选项卡（级别设为 info 或 debug），查看策略组切换记录。日志中会出现类似 [Proxy] Auto-LowLatency switch to HK-01 的信息。

优化建议：根据实际使用情况调整 tolerance 和 interval。如果发现节点频繁切换导致连接中断，可适当增大 tolerance 或延长 interval；如果发现长时间未切换导致延迟偏高，可缩短 interval。

常见问题与边界（FAQ）

为什么 url-test 策略组没有自动切换？

可能原因：1）节点名称在 proxies 和 proxy-groups 中不一致；2）测试 URL 不可达（如被墙或解析异常）；3）interval 设置过大，尚未触发下次测试。建议先手动执行一次“测试延迟”确认节点可达，并检查日志是否有错误提示。

fallback 策略组切换后如何恢复？

fallback 策略组不会自动回退到之前的节点，除非当前节点再次不可用或手动触发切换。如果需要恢复，可以手动执行“测试延迟”或重启 Clash Verge。经验性观察：某些第三方配置启用了“健康检查”脚本，但 Clash 内核本身不支持自动回退，这是设计使然，以避免频繁切换造成的抖动。

负载均衡（load-balance）策略组会导致网站登录异常吗？

是的，因为不同请求可能分配到不同节点，导致会话状态（如登录 token）丢失。Clash 的 load-balance 默认基于源 IP+端口做哈希，同一会话大概率分配到同一节点，但并非绝对。建议仅在非交互式流量（如下载、更新）中使用，或结合规则仅对特定域名启用。

策略组能否嵌套使用？

可以。Clash 支持策略组嵌套，即一个策略组的 proxies 列表中可以包含另一个策略组名称。例如：外层的 select 策略组包含内层的 url-test 和 fallback 策略组，用户可通过手动切换外层来改变自动行为。但注意嵌套层数不宜过多，以免影响性能。

如何让特定域名不走自动切换，直接使用固定节点？

在 rules 中为该域名添加一条规则，指向一个 select 策略组（手动选择）或直接写节点名称。但节点名称不能直接用于 rules，需先创建一个只包含该节点的 select 策略组。例如：定义一个名为“Fixed”的策略组，proxies 只包含一个节点，然后在 rules 中使用 DOMAIN-SUFFIX,example.com,Fixed。

适用与不适用场景清单

适用场景：

多节点代理订阅，需要自动选择最优节点进行日常浏览。
跨国办公，需要确保连接稳定，即使某个节点故障也能快速切换。
流媒体观看，需要持续低延迟以避免卡顿。
技术爱好者，希望深度定制代理策略，实现精细化流量管理。

不适用场景：

单节点用户：无需策略组，直接使用 select 即可。
对节点稳定性要求极高且不接受任何切换抖动：可考虑固定节点，并定期手动切换。
使用机场自带订阅分流功能：一些机场在订阅端已实现自动切换，Clash 侧再配置可能造成冲突，建议评估后使用。
法律或合规要求必须使用特定节点：如公司 privacy tool，不应配置自动切换。

最佳实践与取舍建议

综合以上内容，以下是配置策略组实现自动切换的最佳实践检查表：

明确需求优先级：延迟优先选 url-test，稳定优先选 fallback。避免两种策略混用在一个策略组内。
合理设置容差和间隔：tolerance 建议 50–100 ms，interval 建议 300–600 秒。避免频繁测试导致节点被滥用或性能下降。
使用可靠的测试 URL：推荐使用 Google 或 Cloudflare 的连通性检测地址（如 connectivitycheck.gstatic.com），避免使用自定义 HTTP 服务。
日志监控：开启 info 级别日志，定期检查切换记录，确认策略组工作正常。
备份配置：在修改 YAML 前，先备份原配置文件，以便回退。
组合使用：对于复杂需求，采用“外层 select + 内层自动策略组”的嵌套结构，兼顾灵活性与自动化。

最后，需要提醒的是：自动切换并非万能。如果所有节点质量都不好，任何策略组都无法创造奇迹。建议定期检查节点订阅的有效性，结合机场提供的节点状态信息，做出合理配置。持续优化，才能获得最佳体验。