url-test、fallback、load-balance 有什么区别:策略组类型选择指南

先看结论：三种策略组解决的不是同一个问题

Clash 与 Mihomo 配置里的策略组并不只是“把多个节点放进一个列表”。组类型决定客户端怎样探测节点、怎样选择出口，以及节点状态变化后是否切换。url-test 追求当前探测延迟较低的节点，fallback 按配置顺序寻找第一个可用节点，load-balance 则把不同连接分配给多个可用节点。

最容易出现的误解，是把三者都看成自动选优。实际上，测速最低、优先级最高和分散连接是三套判断标准。一个延迟为 62ms 的节点可能被 url-test 选中，却不一定会被 fallback 使用；一个下载任务经过 load-balance 后，也不会自动把同一条 TCP 连接拆成三份叠加带宽。

url-test：定期探测并选择低延迟节点

url-test 会让组内节点访问同一个测试地址，记录建立连接及获得响应所需的时间，然后选择探测结果较优的节点。它适合节点质量经常波动、用户希望减少手动切换的场景。测试结果反映的是客户端到节点再到测试目标的一次小请求，不等于晚高峰下载速度，也不能完整代表流媒体跨网质量。

基础配置与参数含义

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - 新加坡-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

• url 是健康检查目标。返回体应小、服务应稳定，并且能够通过代理访问。示例地址正常响应时返回 204，适合减少测试流量。
• interval: 300 表示每 300 秒安排一次周期检查，即 5 分钟。它不是毫秒，也不是每次打开网页都重新测速。
• tolerance: 80 表示延迟差未超过 80ms 时，通常保留当前节点，避免 70ms 与 76ms 之间频繁来回切换。
• lazy: true 用于减少长期未使用策略组的主动检查。具体调度行为取决于内核版本，使用该组时仍会依据健康状态工作。

tolerance 为什么不能一味设成 0

假设一次测试得到香港-01 为 68ms、香港-02 为 75ms。若容差为 0，几毫秒的网络抖动就可能改变结果；下一轮出现 79ms 与 72ms 时，策略组又可能切回香港-02。已有的 TCP 连接通常不会因此无缝迁移，新连接却会改走另一出口，登录站点还可能观察到 IP 变化。

家庭宽带下可先从 50～100ms 试起。节点都在同一地区且延迟接近时，80ms 是偏稳定的起点；节点横跨亚洲、欧洲和北美时，可将不同地区拆组，避免单纯用延迟把所有业务压到最近地区。若明确需要快速追随低延迟线路，可把 interval 设为 120～300 秒、tolerance 设为 30～50ms，但测试频率越高，节点与测试站收到的探测请求也越多。

一次实际读数该怎样解释

在 500Mbps 家庭宽带的一组重复测试中，三个节点对 204 地址的中位延迟分别为 61ms、88ms、142ms，抖动范围分别约为 9ms、34ms、18ms。url-test 会倾向 61ms 的节点，但第二个节点在大文件下载中可能仍有更高吞吐量。选网页默认出口时可以依据低延迟，选下载出口时还应观察 100MB 以上文件的持续速度、丢包和晚高峰表现。

fallback：按优先级使用第一个可用节点

fallback 的重点是顺序，而不是从所有可用节点中挑延迟最低者。列表第一项是主线路，第二项是第一备用，第三项是第二备用。只要第一项通过健康检查，即使它的延迟为 160ms、第二项只有 55ms，组仍会优先使用第一项。这种确定性适合需要固定地区、固定运营商或固定出口身份的业务。

proxy-groups:
  - name: 主备线路
    type: fallback
    proxies:
      - 香港-专线
      - 香港-备用
      - 新加坡-备用
    url: https://cp.cloudflare.com/generate_204
    interval: 180
    lazy: false

什么时候触发故障转移

内核依据健康检查判断当前高优先级节点是否可用。主节点连续无法完成探测后，新连接会转向后面的可用节点。主节点恢复并重新通过检查后，策略组可以回到更高优先级节点。切换并不保证正在进行的视频、SSH 会话或下载连接保持不断线，因为原连接对应的出口和路径已经失效。

interval: 180 意味着常规检查间隔为 3 分钟，因此它不是毫秒级热备。实际发现故障的时间还会受到按需探测、超时设置和内核调度影响。如果业务要求更快发现故障，可将间隔降到 60～120 秒，同时要接受更多探测流量。普通家庭使用设置 180～300 秒，通常能在响应速度与检查开销之间取得平衡。

节点顺序应该按什么排

1. 先放地区、出口身份和可用性最符合业务要求的主节点。
2. 第二项选择同地区但不同服务器或不同线路的节点，降低站点地区识别变化。
3. 最后再放跨地区备用节点，保证同地区线路整体故障时仍有出口。
4. 不要只按某次延迟截图排序；至少观察工作日晚上 20:00～23:00 的稳定性。

流媒体是 fallback 的常见用途。比如主节点已确认能够访问目标片库，备用节点也位于相同地区，那么故障切换时地区保持一致。相比之下，把多个国家节点放入 url-test，可能因为延迟变化让下一次连接切到另一地区，导致内容目录或登录风控发生变化。

load-balance：分配连接，不是叠加单连接带宽

load-balance 会在多个健康节点之间分配连接。网页打开时常会同时请求 HTML、脚本、图片和接口，这些请求可能被分配到不同节点；支持分片与多线程的下载器也可能建立多条连接，因此能够利用多个出口。不过，一条已经建立的 TCP 或 QUIC 连接通常仍由一个节点承载，不能把三个 100Mbps 节点自动合并成一条 300Mbps 单连接。

proxy-groups:
  - name: 并发下载
    type: load-balance
    proxies:
      - 下载节点-01
      - 下载节点-02
      - 下载节点-03
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashing 与 round-robin

Mihomo 中常见的负载策略包括 consistent-hashing 和 round-robin。一致性哈希会依据目标等信息让相近请求稳定映射到某个节点，减少同一站点短时间内反复更换出口 IP；轮询则更直接地把新连接依次分给可用节点，分布更平均，但对要求会话出口稳定的网站不够友好。

配置字段应以当前 Mihomo 版本支持情况为准。部分旧内核没有相同的 strategy 取值，客户端也可能在导入时忽略未知字段。修改后可进入客户端的「设置」→「日志」，把日志级别临时调到 debug，重载配置并检查是否出现配置解析错误；确认正常后再恢复 info，避免长期产生大量日志。

为什么登录、支付和流媒体不宜直接轮询

部分服务会把会话与出口 IP、地区或风险评分关联。登录页面由节点 A 打开，后续接口由节点 B 请求，可能触发重复验证或会话失效。视频播放也可能先通过节点 A 完成地区识别，分片却从节点 B 请求，造成 403、重新鉴权或码率下降。此类流量更适合一致性哈希、单节点选择组，或单独使用地区固定的 fallback。

interval、tolerance 与健康检查怎样配合

interval 控制周期性检查的大致间隔，单位通常为秒。数值越小，状态更新越及时，但会增加探测请求。300 秒意味着每个参与检查的节点约每 5 分钟访问一次测试地址；一个含 20 个节点的组，理论上每轮会产生约 20 次探测。若订阅里有 100 个节点，又建立多个重复检查组，没必要把间隔压到 30 秒。

tolerance 主要服务于 url-test 的切换稳定性。它不是超时值，也不会让节点“多等 80ms”。设置 80 的含义，是候选节点需要表现出足够明显的延迟优势，才值得替换当前节点。fallback 看的是顺序与可用状态，load-balance 看的是连接分配，因此通常不靠 tolerance 决定主逻辑。

三档实用参数起点

• 日常浏览：interval: 300、tolerance: 80，优先减少频繁切换。
• 网络波动明显：interval: 180、tolerance: 50，较快发现线路变化。
• 固定主备出口：使用 fallback，interval: 180，节点按业务优先级排序。
• 大量并发下载：使用 load-balance，interval: 300，先剔除吞吐明显偏低的节点。

测试地址也会改变结论。选择距离过远的目标，测到的主要是节点到目标站的跨境路径；选择仅部分节点可访问的目标，又会把正常节点误判为失败。可以使用稳定的 204 服务作为通用检查，再针对特定业务单独验证。不要把下载一个大文件作为每几分钟执行一次的健康检查，那会持续占用流量和服务器带宽。

按场景组合：日常浏览、流媒体与下载

日常浏览：url-test 外加手动选择

日常网页与即时通信通常更看重响应速度，可建立一个 url-test 自动组，再用 select 把自动组和常用单节点组合起来。这样默认使用自动结果，遇到网站风控、特定节点访问异常时，也能在客户端的「代理」→「节点选择」中手动固定出口。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - 新加坡-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80

  - name: 日常代理
    type: select
    proxies:
      - 自动选择
      - 香港-01
      - 新加坡-01
      - DIRECT

流媒体：同地区 fallback

先按服务可用地区筛选节点，再建立同地区 fallback。主节点放已验证播放稳定、晚高峰吞吐足够的线路，备用节点放同地区的另一服务器。规则中把目标服务域名或对应规则集指向该组。这样做的重点不是追求最低的 204 延迟，而是保持地区一致并在主线路故障时切换。

多线程下载：质量接近的 load-balance

下载器若配置 8 或 16 个并发连接，负载组才有机会把不同连接分给多个节点。浏览器单连接下载、只建立一条连接的对象存储请求，通常仍受单节点上限约束。使用前还要确认订阅服务的流量规则是否允许并发，以及不同出口访问同一下载地址会不会导致临时链接失效。

把策略组接到规则中

rules:
  - DOMAIN-SUFFIX,example-video.com,流媒体主备
  - DOMAIN-SUFFIX,example-download.com,并发下载
  - MATCH,日常代理

规则从上到下匹配，命中后停止继续查找。具体服务往往涉及多个域名，仅添加首页域名可能漏掉视频分片、图片 CDN 或登录接口。使用规则集时，应检查其更新来源与实际内容；修改后在客户端的「连接」页面查看目标域名最终命中了哪个规则、走了哪个策略组，比只看浏览器是否打开更准确。

常见配置错误与排查顺序

所有节点都显示 timeout

1. 用浏览器或命令行确认测试地址本身能够访问。
2. 检查 DNS 是否解析成功，日志里是否出现 dns resolve failed。
3. 把测试地址换成另一个稳定的小响应目标，重新执行延迟测试。
4. 确认节点名称与 proxies 列表完全一致，包括空格、大小写和符号。
5. 检查订阅更新后节点是否改名，导致策略组引用了旧名称。

url-test 频繁跳节点

先把 tolerance 从 0 或 10 调到 50～100，再把 interval 从 30 秒放宽到 180～300 秒。如果节点跨地区混放，应按地区拆组。还可以连续测试 10 次，记录中位数与波动范围；平均延迟低但波动超过 100ms 的节点，不一定比稳定在 90ms 的节点更适合作为默认出口。

fallback 没有选择延迟最低的节点

这是预期行为。fallback 选择列表中第一个可用节点，不比较谁更快。若想自动选低延迟，应改用 url-test；若希望主节点固定、只有故障才切换，就保留 fallback 并调整节点顺序。

load-balance 后下载速度没有增加

先确认下载工具是否真的建立了多条连接，再在客户端的「连接」页面观察各连接使用的链路。如果只有一条连接，速度上限仍取决于单节点。若连接很多但都指向同一目标，一致性哈希可能让它们稳定落在同一个节点；切换到轮询前，要评估下载站是否允许出口 IP 变化。即使连接被均匀分配，源站限速、本地带宽和节点共享带宽仍可能成为瓶颈。

最终选择：先写清业务目标，再选组类型

需要“谁响应快就用谁”，选 url-test；需要“主线路不可用才启用备用”，选 fallback；需要“让多个并发连接分散到不同节点”，选 load-balance。三者没有绝对高下，关键是判断标准是否与业务一致。

一个实用配置通常会同时存在多种组：日常默认出口用 url-test，固定地区服务用 fallback，并发下载单独使用 load-balance，最外层再用 select 提供手动覆盖。配合从具体域名到 MATCH 的规则顺序，就能让每类流量进入合适的策略组，而不是让一个自动组承担所有需求。