Clash 策略组配置详解:url-test、fallback 与 load-balance 区别

先分清策略组解决什么问题

Clash 或 mihomo 读取订阅后，通常会得到一批代理节点。策略组位于节点与分流规则之间：规则把请求交给某个策略组，策略组再决定实际使用哪一个节点。手动选择组由用户指定节点，自动策略组则按照延迟、可用状态或分配算法持续作出选择。

url-test、fallback 与 load-balance 都会对组内节点执行健康检查，但三者的选择目标不同。把它们简单理解成“都能自动选节点”容易造成配置偏差。例如，备用线路需要稳定的主备顺序，却配置成了最低延迟优先；下载任务想分散连接，却误以为负载均衡可以叠加单连接带宽。

策略组类型	主要目标	选择方式	适合场景
`url-test`	降低访问延迟	选择健康节点中测速结果较低者	网页、搜索、交互式应用
`fallback`	保持线路可用	按列表顺序使用第一个健康节点	主线路加备用线路、远程办公
`load-balance`	分散多个连接	按一致性哈希或轮询算法分配	多连接下载、并发请求、批量任务

url-test：以响应延迟为主要选择依据

url-test 会通过组内各节点访问指定测试地址，记录响应耗时，并从可用节点中选择较快者。它适合网页浏览、即时通信、远程终端等对交互延迟敏感的流量。测速得到的 68 ms、115 ms 或 240 ms 是测试请求的往返表现，不等于下载速度，也不能直接代表节点的可用带宽。

可直接使用的基础配置

proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies:
      - "香港 01"
      - "香港 02"
      - "日本 01"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80
    lazy: true

rules:
  - DOMAIN-SUFFIX,example.com,自动选择
  - MATCH,自动选择

这段配置每 300 秒安排一次健康检查，测试地址正常时会返回空响应。tolerance: 80 表示当前节点与候选节点的延迟差距未明显超过 80 毫秒时，尽量避免频繁切换。假设当前节点为 92 ms，新结果为 54 ms，两者只差 38 ms，继续保持当前节点通常比立即切换更平稳；若新节点为 55 ms、当前节点升至 190 ms，切换就更有意义。

参数怎样设置更稳妥

url：测试地址应返回小体积、稳定且可预测的响应。测速目标自身如果发生限流或区域阻断，所有节点都可能被误判为异常。
interval：单位为秒。日常使用可从 300 秒开始；网络变化频繁时可缩短至 120 秒；固定家庭网络设为 600 秒也较合理。
tolerance：单位为毫秒。设为 0 会让细小延迟变化也影响选择，容易在数值接近的节点间来回切换。常用范围是 50 至 150 毫秒。
lazy：启用后，未被实际使用的策略组可减少不必要的主动测试。需要持续监测备用组时，可以结合核心行为与实际需求决定是否关闭。
proxies：节点名称必须与配置中定义的名称完全一致，包含空格、地区符号或数字时建议加引号。

延迟最低也不一定体验最好。一个节点测试为 48 ms，但晚间可用带宽只有 8 Mbps；另一个节点测试为 86 ms，却能稳定达到 120 Mbps。网页打开可能更适合前者，大文件下载则可能更适合后者。因此，url-test 的正确定位是延迟导向选择，而不是综合性能评分。

fallback：按优先级保持可用性

fallback 同样执行健康检查，但不会在所有健康节点中寻找最低延迟。它按照 proxies 列表顺序检查，优先使用排在前面且当前可用的节点。第一项失效后才会切换到第二项；第一项恢复并通过检查后，策略组可重新回到优先线路。

这种行为适合“主线路优先、备用线路兜底”的明确需求。例如，公司业务需要固定地区出口，主节点应保持在首位；只有主节点连接失败，才允许切到同地区备用节点。此时即使备用节点延迟低 30 ms，也不应主动抢占主节点。

主备线路 YAML 示例

proxy-groups:
  - name: "办公线路"
    type: fallback
    proxies:
      - "新加坡 专线"
      - "新加坡 备用"
      - "日本 备用"
    url: "http://www.gstatic.com/generate_204"
    interval: 180
    lazy: false

rules:
  - DOMAIN-SUFFIX,corp.example,办公线路
  - DOMAIN-SUFFIX,meeting.example,办公线路

这里的排序就是优先级：先使用“新加坡专线”，不可用时切换到“新加坡备用”，两者都失败后才使用“日本备用”。interval: 180 表示大约每 3 分钟重新检查一次。故障发生在两次检查之间时，正在建立的连接仍可能先经历超时，因此对恢复时间要求高的业务不宜把间隔设得过长。

哪些情况不适合 fallback

希望始终选择当前最低延迟节点时，应使用 url-test。
希望多个节点同时承担大量独立连接时，应考虑 load-balance。
多个节点没有明确优先级，只是名称排序不同，使用 fallback 不会自动比较它们的速度。
需要固定出口地址的登录会话，不应随意放入跨地区备用节点，否则故障切换后出口地区会变化。

load-balance：把多个连接分配给不同节点

load-balance 的目标是让组内多个健康节点共同承担连接，而不是选出唯一的“最快节点”。它比较适合网页中包含大量独立资源、分段下载、并发接口请求或批量任务。具体连接分配方式由 strategy 决定，mihomo 常用策略包括 consistent-hashing 与 round-robin。

一致性哈希配置

proxy-groups:
  - name: "并发分流"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "香港 01"
      - "香港 02"
      - "香港 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

rules:
  - DOMAIN-SUFFIX,download.example,并发分流
  - DOMAIN-SUFFIX,static.example,并发分流

consistent-hashing 会根据目标信息进行稳定映射，使相同目标在节点集合没有明显变化时倾向于落到同一代理。它能减少同一站点的多个请求频繁更换出口地址，适合登录状态、CDN 资源和对出口一致性有一定要求的场景。

轮询配置

proxy-groups:
  - name: "轮询节点"
    type: load-balance
    strategy: round-robin
    proxies:
      - "日本 01"
      - "日本 02"
      - "日本 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

round-robin 按轮询方式把新连接依次分配给健康节点，更直接地分散连接数量。它适合目标服务允许出口变化的并发任务。若同一网站对 IP 变化敏感，轮询可能让登录、验证码或会话校验出现额外问题，此时优先采用一致性哈希，或者直接使用单节点策略。

健康检查参数与节点来源

三个策略组都依赖健康检查。测试结果显示超时或负数时，不要立刻判断订阅节点全部失效。先确认测试 URL 可访问、系统时间正确、DNS 能解析目标域名，并检查本地防火墙是否拦截了核心进程。若某个测试地址在特定网络中不稳定，可以换成另一个返回小响应的 HTTPS 或 HTTP 地址，再对比结果。

现象	优先检查	建议操作
所有节点同时超时	测试 URL、DNS、本地网络	浏览器直接访问测试地址，并检查核心日志
单个节点持续超时	节点参数、服务端状态	手动选择该节点测试实际连接
url-test 频繁切换	`tolerance` 太小	从 80 ms 或 100 ms 开始调整
fallback 没选最低延迟	节点排列顺序	按业务优先级重排，或改用 url-test
负载均衡后登录失效	出口地址频繁变化	改用一致性哈希或单节点组

订阅节点较多时使用代理提供者

节点由订阅动态更新时，逐个填写 proxies 不便维护。mihomo 可以通过 proxy-providers 定义订阅来源，再在策略组中使用 use 引用提供者。订阅更新后，符合条件的节点会进入对应策略组。

proxy-providers:
  main-subscription:
    type: http
    url: "https://subscription.example/profile.yaml"
    path: "./providers/main.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "http://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: "香港自动"
    type: url-test
    use:
      - main-subscription
    filter: "(?i)香港|港|HK"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

filter 使用正则表达式筛选节点名称。示例保留名称中含“香港”“港”或“HK”的节点，(?i) 表示英文匹配忽略大小写。不同订阅的命名方式可能是“Hong Kong”“HKG”或地区旗帜符号，实际使用前应查看节点列表，再按真实名称调整表达式。

提供者层和策略组层都可能执行健康检查。前者用于维护节点可用状态，后者用于策略选择。节点数量达到 100 个以上时，把多个检查间隔都设为 30 秒会产生较多探测请求。日常配置通常使用 300 秒；订阅更新间隔可设为 21600 秒，也就是 6 小时。

在 Clash Nyanpasu 中应用配置

先确认当前运行核心支持配置中的策略类型和参数。在 Clash Nyanpasu 中可进入「设置」→「Clash 核心」查看核心类型与版本；使用 mihomo 核心时，可在日志开头确认实际加载的版本。本文示例采用 mihomo 常见语法，较早的 Clash 分支可能不识别部分负载均衡策略或提供者筛选参数。

进入「配置」页面，找到当前启用的订阅配置。
打开配置编辑入口，定位顶层的 proxy-groups 段。
把新策略组加入 proxy-groups，注意每一级使用一致的空格缩进，不要使用 Tab。
在 rules 中把需要处理的域名、规则集或兜底规则指向新组名。
保存并重新加载配置，随后打开「日志」检查是否出现 YAML 解析错误或找不到代理节点的提示。
在代理组界面执行一次延迟测试，确认节点状态和自动选择结果符合预期。

组合使用三种策略组

复杂配置不必只选一种类型。可以先按地区建立 url-test 组，再把地区组用于手动选择；也可以为关键业务建立 fallback，为大批量下载建立 load-balance。需要注意，策略组嵌套应保持目标清晰，避免形成循环引用。

proxy-groups:
  - name: "香港低延迟"
    type: url-test
    proxies:
      - "香港 01"
      - "香港 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "日本低延迟"
    type: url-test
    proxies:
      - "日本 01"
      - "日本 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "关键业务"
    type: fallback
    proxies:
      - "香港低延迟"
      - "日本低延迟"
    url: "http://www.gstatic.com/generate_204"
    interval: 180

  - name: "节点选择"
    type: select
    proxies:
      - "香港低延迟"
      - "日本低延迟"
      - "关键业务"
      - DIRECT

这个结构先在各地区内部选择低延迟节点，再让“关键业务”按照香港优先、日本备用的顺序运行。最外层“节点选择”保留手动控制入口。若香港节点整体不可用，fallback 才会转向日本组；若香港组内仅一个节点异常，内部的 url-test 会先尝试切换到另一个香港节点。

常见配置错误与排查顺序

组名或节点名不一致

YAML 中的名称按完整字符串匹配。“香港 01”和“香港01”是两个不同名称，全角空格、半角空格也可能造成引用失败。日志出现 proxy not found 一类信息时，应复制节点原名，而不是重新手输。

缩进正确但层级放错

proxy-groups、proxy-providers 和 rules 都是顶层字段。把策略组误放进 proxies 节点内部，即使文本看起来整齐也无法正确加载。列表项前使用两个空格只是常见写法，真正重要的是同一层级保持一致。

测速正常，实际网站仍无法访问

先把策略切到全局或手动节点测试，区分规则问题与节点问题。如果手动节点可访问，而规则模式失败，应检查规则顺序。Clash 规则由上到下匹配，较早出现的 DOMAIN、DOMAIN-SUFFIX、规则集或 GEOIP 可能已经把请求送往其他策略组。

TUN 模式下结果与系统代理不同

系统代理只接管遵循系统代理设置的应用；TUN 模式通过虚拟网络接口接管更广泛的流量。切换到 TUN 后，终端程序、游戏或独立更新器可能开始进入 Clash，策略组负载随之变化。排查时应记录当前模式、DNS 设置和目标进程，避免把流量入口变化误判成策略组故障。

修改订阅后配置被覆盖

直接编辑远程订阅生成的配置，下一次更新时可能恢复为订阅原始内容。长期使用的自定义策略应放进客户端支持的覆写、合并或脚本处理机制中。调整前可先复制一份本地配置测试，确认策略组、规则引用和提供者筛选都能正常加载，再迁移到持续维护方案。

选择结论：按目标而不是名称决定

网页浏览、搜索与远程交互优先考虑 url-test，并用 50 至 150 ms 的 tolerance 减少抖动。
主线路必须优先、故障时才切备用线路，使用 fallback，节点排列顺序就是业务优先级。
任务包含大量独立连接，希望分散到多个节点，使用 load-balance；登录状态敏感时优先选择一致性哈希。
单连接速度慢时，不要依赖负载均衡叠加带宽，应分别检查节点容量、协议开销、本地网络与目标服务器限速。
无论采用哪一种自动组，都要同时检查规则指向、健康检查地址、核心兼容性和订阅更新后的节点名称。

实际配置可以从一个包含 3 个节点、300 秒检查间隔的简单组开始，观察一天内的延迟、切换次数与日志，再逐步调整。先明确是追求最低延迟、优先可用，还是分散并发连接，通常就能在三种策略组之间作出准确选择。