Clash 策略组类型怎么选:url-test、fallback、load-balance 的区别与配置思路

Clash 配置中的策略组决定一条连接最终交给哪个节点。规则只负责把流量送入某个组，组内的 type 才决定节点如何选择。手动组 select 由用户指定节点；自动组则根据健康检查、排列顺序或分配算法作出选择。

url-test、fallback 与 load-balance 都会利用健康检查，但目标完全不同。前者追求较低探测延迟，第二种强调固定优先级与故障接替，第三种把新连接分散到多个可用节点。选错类型时，常见结果不是配置报错，而是频繁切换、访问出口变化，或备用节点没有按预期接管。

三种自动策略组的核心差别

判断类型时，可以先回答一个问题：这个组更需要“选择响应较快的节点”“按业务优先级兜底”，还是“让多个节点共同承接新连接”。三种需求分别对应 url-test、fallback 和 load-balance。

健康检查不是持续占用业务连接测速

自动组会按照 interval 指定的秒数访问测试 URL，记录成员是否可用以及响应时间。以 interval: 300 为例，常规周期是 300 秒，也就是 5 分钟。周期过短会增加节点与本地网络的探测请求；周期过长则会延迟发现线路恢复或故障。

测试 URL 通常选择返回内容很小、响应稳定的地址，例如 https://www.gstatic.com/generate_204。如果该地址本身被目标网络限制，所有节点可能同时显示失败。此时应更换成能够稳定返回的轻量地址，而不是立即判断全部节点失效。

url-test：按探测延迟自动择优

url-test 会周期性测试组内成员，并选择探测延迟较低的可用节点。它适合网页浏览、即时通信、代码托管等对响应时间较敏感的日常流量。选择发生在策略组层面，并不意味着每个请求都重新测速。

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

tolerance：减少几毫秒差距造成的切换

tolerance 的单位是毫秒。上例设置为 50，表示新结果只有在差距达到容差范围时才值得切换，具体选择细节由所用内核实现决定。它的实际价值是避免两个延迟接近的节点来回成为优选项。

例如节点 A 实测 82 ms，节点 B 实测 106 ms，两者相差 24 ms。在 50 ms 容差下，没有必要仅因一次探测波动就切换。若节点 A 升至 178 ms，而节点 B 保持 103 ms，差距扩大到 75 ms，重新选择才更有意义。家庭 Wi-Fi 延迟波动明显时，可从 50 至 100 ms 试起；稳定有线网络可以使用 20 至 50 ms。

lazy：有流量时再维持检查

lazy: true 适合不常使用的策略组。组长期没有连接时，内核可以减少不必要的周期测试；再次产生匹配流量后恢复检查。需要快速感知备用线路状态的关键业务组，则应结合所用 mihomo 版本与客户端行为评估是否启用。

url-test 适合与不适合的情况

• 适合多个用途相近、套餐与线路质量接近的节点。
• 适合希望自动避开高延迟节点，又不要求固定出口地址的场景。
• 不适合必须长期保持同一地区或同一出口地址的登录会话。
• 不适合仅凭一次 204 测试判断视频带宽，延迟测试不能替代持续吞吐测试。

fallback：按顺序使用首个可用节点

fallback 的重点不是谁延迟最低，而是谁排在前面且当前可用。列表中的第一个成员是主线路；主线路健康检查失败后，组才会尝试后面的备用成员。主线路恢复并通过检查后，通常会重新回到更靠前的成员。

proxy-groups:
  - name: 工作线路
    type: fallback
    proxies:
      - 企业专线
      - 香港备用
      - 日本备用
    url: https://www.gstatic.com/generate_204
    interval: 180
    lazy: false

这段配置表达了明确的业务顺序：先使用“企业专线”，不可用时切换到“香港备用”，两者都不可用时再使用“日本备用”。即使日本节点实测只有 45 ms，而企业专线为 92 ms，只要企业专线保持可用，它仍然位于首选位置。

“可用”只代表测试 URL 能完成

节点能够访问 204 测试地址，不代表它一定能访问规则对应的业务域名。某条线路可能通过健康检查，却无法正常访问特定服务。遇到这种情况，可以为业务组选择更接近实际目标的测试地址，但不宜使用需要登录、会重定向多次或返回大文件的页面。

故障切换也不会把已经建立的 TCP 连接无缝搬到另一个节点。主线路断开时，原有下载、SSH 或 WebSocket 连接通常会中断；应用重连后，新连接才会经过备用成员。对长连接业务，应同时检查应用自身的重试机制。

fallback 的典型场景

1. 固定主线路：主节点具备稳定出口或特定地区，其他节点只承担故障接替。
2. 成本优先：优先使用流量充足的线路，昂贵或限量线路排在后面。
3. 地区顺序：先使用香港区域，全部不可用时再切换到日本或新加坡区域。
4. 远程连接：远程开发、管理面板等业务更重视出口连续性，而不是几十毫秒的延迟差。

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

load-balance 会在多个可用成员之间分配连接。它不是带宽叠加器：单个 TCP 下载通常仍通过一个节点，不能把三条 100 Mbps 线路自动合并成一条 300 Mbps 连接。它更适合大量独立请求、多域名访问或多个并发任务。

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

consistent-hashing：相近目标保持相对稳定

consistent-hashing 会根据连接目标计算分配结果，使相同或相近目标倾向于落到同一成员。与完全轮转相比，它更适合网站登录、接口调用和需要一定出口连续性的场景。节点列表发生变化时，部分目标仍可能重新映射，因此它不能替代真正的固定出口。

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

mihomo 支持的 round-robin 策略会让新连接依次使用可用成员。假设组内有 A、B、C 三个节点，连续建立的连接可能按 A、B、C、A 的顺序分配。一个网页往往同时连接多个域名，因此同一次页面加载可能出现多个出口地址。

轮询适合并发抓取、分散连接数等不依赖单一出口的任务。账号登录、支付、网银或对 IP 变化敏感的接口不宜使用这类组。若服务端把短时间内的多出口视为异常，应改用 select、fallback，或使用具有稳定映射特征的策略。

组合策略组：先在区域内优选，再做区域兜底

复杂配置不必在一个组里解决所有目标。策略组可以引用其他策略组，因此更清晰的写法是先按区域建立 url-test，再由上层 fallback 决定地区优先级。这样既能在同一区域选择低延迟节点，也能在整个区域不可用时切换。

proxy-groups:
  - name: 香港自动
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 日本自动
    type: url-test
    proxies:
      - 日本-01
      - 日本-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 默认出口
    type: fallback
    proxies:
      - 香港自动
      - 日本自动
    url: https://www.gstatic.com/generate_204
    interval: 180

rules:
  - DOMAIN-SUFFIX,example.net,默认出口
  - MATCH,默认出口

在这套结构里，“香港自动”先从两个香港节点中选择合适成员；上层“默认出口”优先使用香港组，香港组无法完成检查时才使用日本组。组名必须完全一致，包括大小写、空格和符号。YAML 缩进建议统一使用两个空格，不要混用 Tab。

手动组与自动组并存

实际配置通常还会保留一个 select 组，便于临时指定节点。可以把“自动优选”“工作线路”“并发分流”和具体节点一起放进手动组，再让规则指向该手动组。日常选择自动策略，需要固定出口时切换到具体节点。

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动优选
      - 工作线路
      - 并发分流
      - 香港-01

这种结构比让所有规则直接指向底层自动组更容易维护。客户端界面中只需操作“节点选择”，底层组继续负责测试与故障判断。修改配置后，应在客户端执行“配置”→“重新载入”，并查看日志是否出现策略组名称不存在、YAML 解析失败或节点引用错误。

与规则模式、系统代理和 TUN 模式的关系

策略组负责选出口，规则负责决定进入哪个组。规则模式下，连接从上到下匹配 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等规则，命中后进入指定策略组。全局模式则通常把流量统一交给全局策略选择，不再按普通规则逐条决定去向。

系统代理与 TUN 模式决定哪些流量能够进入内核，不会改变 url-test、fallback 或 load-balance 的基本选择逻辑。浏览器通过系统代理进入 Clash，或游戏流量通过 TUN 进入 mihomo，只要最终命中同一个策略组，就按该组类型选择节点。

TUN 模式下需要额外观察 UDP

游戏、语音和部分 HTTP/3 流量会使用 UDP。节点协议、服务端与客户端内核都需要支持对应 UDP 转发。一个节点通过 TCP 测试 URL，不代表 UDP 一定可用。出现网页正常但语音或游戏失败时，应在连接面板确认网络类型，并检查节点的 UDP 能力、TUN 设置和防火墙规则。

DNS 结果会影响规则与连接目标

启用 Fake-IP 时，DNS 模块返回映射地址，内核再依据映射关系恢复域名并匹配规则。启用 Redir-Host 时，域名解析结果更直接参与连接。策略组本身不负责修复 DNS；如果域名解析超时，三个自动组都可能没有机会建立正常业务连接。

参数怎么调：从稳定配置开始

自动策略组参数没有适合所有网络的固定答案。家庭宽带、移动热点、跨境专线和云服务器的波动幅度不同。更可靠的方法是先采用保守值，记录切换与失败情况，再按问题调整。

1. 先确认测试 URL 能通过每个节点稳定访问，连续检查至少 3 次。
2. 记录节点延迟，而不是只看一次结果。82 ms、91 ms、87 ms 属于接近；82 ms 与 260 ms 才是明显差距。
3. 观察客户端连接面板中的实际策略链，确认规则命中的组与预期一致。
4. 调整后重新载入配置，并建立新连接测试。旧连接可能继续使用调整前的出口。
5. 出现全组失败时先检查本地网络与测试地址，再检查订阅节点，不要同时改动多个参数。

常见误区与排查顺序

误区一：url-test 会把每次请求都发给最低延迟节点

它依据最近的健康检查结果维护当前选择，不会在每个 HTTP 请求前重新跑完整测速。节点延迟在两个检测周期之间发生变化时，当前结果可能暂时滞后，这是正常的周期检测特征。

误区二：fallback 会选择备用列表中最快的节点

fallback 首先尊重排列顺序。只要第一个成员可用，就不会因为第二个成员延迟更低而主动切换。需要按延迟选择时，应改用 url-test，或在 fallback 内引用一个 url-test 子组。

误区三：load-balance 能提升单文件下载速度

单个连接通常绑定一个节点。只有下载器把文件拆分为多个独立连接，并且这些连接被分配到不同成员时，才可能看到总吞吐变化。最终速度仍受源站限速、节点带宽、线路拥塞和分配策略影响。

固定排查顺序

1. 在客户端的“配置”页面确认当前加载的是刚修改的配置文件。
2. 打开日志，检查策略组类型、成员名称和 YAML 缩进是否正确。
3. 在“代理”或“策略”页面执行一次延迟测试，记录失败成员。
4. 查看“连接”面板，确认目标连接实际命中的规则和策略链。
5. 关闭并重新打开目标应用，排除旧 TCP 连接仍在复用原出口。
6. 如果系统代理流量正常而 TUN 流量异常，再检查 TUN、DNS 与防火墙，不要反复更换策略组类型。

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

• 希望自动使用探测延迟较低的节点，选择 url-test。
• 希望主线路优先、故障后按顺序接替，选择 fallback。
• 希望多个节点分散新连接，且业务允许出口变化，选择 load-balance。
• 希望既保留人工控制又使用自动判断，在外层使用 select，把自动组作为成员。
• 需要区域优先级时，先建立区域内 url-test，再由上层 fallback 组合。

多数个人配置从“手动选择 + 自动优选”两层结构开始即可。只有明确存在主备线路时再加入 fallback；只有确实拥有大量独立连接，并能接受出口分散时再使用 load-balance。类型越多不代表配置越有效，组与规则之间的职责清楚，才更容易验证和排错。