Clash 策略组 url-test、fallback、load-balance 怎么选:参数与适用场景

三种策略组：按延迟、顺序或连接分配

Clash 策略组解决的是“规则命中后，具体使用哪个出口”。规则负责把连接交给某个组，组再从候选节点中作出选择。把策略组改成自动测速，不会自动修改域名规则，也不会让原本走 DIRECT 的连接进入代理。

url-test 适合自动选择探测延迟较低的出口；fallback 适合保留明确的主备顺序；load-balance 适合将不同连接分配到多个出口。三者不是性能等级，选择依据应当是业务对延迟、出口稳定性和多线路利用率的要求。

url-test：用 tolerance 控制切换频率

url-test 通过候选节点请求指定的检测地址，再根据探测结果选择出口。这不是 ICMP ping，也不是带宽测试。检测耗时受代理连接、目标站点响应和网络状况共同影响，因此应当用同一个检测地址比较候选节点。

基础配置与参数单位

下列示例是配置片段，不是完整订阅。假设当前配置的 proxies 已经定义了“香港-01”“香港-02”“日本-01”三个节点；应用时须换成现有节点的准确名称。不要再创建第二个顶层 proxy-groups，应把条目合并到已有列表。

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

• url：用于健康检查的 HTTP 或 HTTPS 地址。此处使用返回小响应的检测端点，不要换成需要登录的业务页面。
• interval: 300：定期探测间隔为 300 秒，即 5 分钟；不是 300 毫秒。
• tolerance: 50：切换容差为 50 毫秒，用于避免候选节点只有小幅优势时频繁切换。
• lazy: false：即使该组暂时未被使用，也保留定期检测，便于观察和比较；代价是产生更多检测请求。

容差不是延迟上限

用一组假设数据说明：当前节点延迟为 180 毫秒，另一节点为 155 毫秒，差值只有 25 毫秒。设定 50 毫秒容差后，不应期待每次都切换到后者。若另一节点降到 100 毫秒，差距扩大，才更符合切换条件。实际选择还取决于该轮检测结果及节点可用状态。

tolerance 不表示“超过 50 毫秒就不可用”，也不能保证线路始终低于某个延迟。对日常浏览，可先用 300 秒间隔、50 毫秒容差观察；如果出口仍然频繁变化，先检查节点质量与检测目标，再考虑增大容差，不要只把检测间隔压到几秒。

fallback：按列表顺序保留主备关系

fallback 优先使用列表中靠前且健康检查可用的节点。它不在所有节点中寻找最低延迟。即使第二个节点测得 80 毫秒，而第一个节点为 160 毫秒，只要第一个节点仍被判定可用，主备组仍应优先使用第一个。

proxy-groups:
  - name: 主备出口
    type: fallback
    proxies:
      - 香港-01
      - 日本-01
      - 香港-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

这里“香港-01”是首选，“日本-01”是第一备用，“香港-02”是第二备用。若业务需要固定地区，就应当只放入符合地区要求的节点。将不同地区混在备用列表里，虽然可能提高可用性，却可能导致服务区域、语言或登录风控状态变化。

故障切换不等于会话迁移

• 检测有时间窗口：300 秒间隔不代表故障发生后立刻切换；实际发现时间还受检测时机、超时和连接触发行为影响。
• 主节点可能回切：排在前面的节点恢复可用后，后续连接可能重新使用它，并非永久停留在备用节点。
• 已建立连接不会搬家：原节点失效后，正在传输的连接可能中断，由应用重新连接；策略组不提供 TCP 会话迁移。

远程管理、持续上传等任务更关注固定出口，可以优先考虑手动 select 或顺序明确的 fallback。但如果任务不能接受任何出口变化，自动主备也不能替代应用自身的重连、断点续传和会话恢复机制。

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

load-balance 让多个候选出口参与连接分配。它不会把一个 TCP 连接切成两半交给两个节点，因此一个单连接下载不会因为放入三条线路就自动获得三倍速度。多任务、多目标访问是否受益，还要看分配策略、各线路容量以及目标站点限制。

proxy-groups:
  - name: 多线分配
    type: load-balance
    proxies:
      - 香港-01
      - 香港-02
      - 日本-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing 与 round-robin

一致性哈希的映射依据通常涉及目标域名的主域部分，目标为 IP 时则按相应地址信息处理；具体行为应以所用内核实现为准。它不保证一个账户关联的所有域名都走同一出口。登录域名、支付域名和接口域名可能分别映射，节点列表变化也可能改变映射结果。

若要轮询，将示例中的策略改为 strategy: round-robin。不要把轮询理解成“每个请求平均分配”：多个 HTTP 请求可能复用同一条 TCP 或 QUIC 连接，而连接分配并不等于请求级分配。支付、账户管理等业务更适合使用固定出口，不宜仅为利用多条线路而强行负载均衡。

规则接入：让连接实际进入自动策略组

定义策略组只是第一步。若规则仍指向旧组，新增组不会处理对应连接。下面用手动选择组作为总入口，保留三种自动策略与直连选项，方便在客户端中对照行为。

proxy-groups:
  - name: 代理入口
    type: select
    proxies:
      - 自动低延迟
      - 主备出口
      - 多线分配
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,代理入口
  - MATCH,代理入口

此处只展示入口条目与规则，须与前面的自动组定义合并使用。example.com 是演示规则匹配的保留示例域名，不承担实际业务。MATCH 会接收此前未匹配的连接；正式配置中应保留已有的局域网、直连和业务规则，并将兜底规则放在末尾，不要用这个精简片段覆盖整份分流配置。

1. 先在客户端的配置编辑入口或覆写功能中合并配置，检查 YAML 缩进；列表条目使用空格，不使用 Tab。
2. 重新加载配置，确认三个自动组与“代理入口”均出现，且没有“代理不存在”或策略组循环引用错误。
3. 在代理组页面展开“代理入口”，选择需要测试的自动组，而不是停留在原来的手动节点。
4. 发起一次新连接，在连接列表中查看命中的规则与代理链，确认最终出口符合预期。

检测偏差：延迟、DNS 与 TUN 的边界

测速正常，业务仍然失败

检测地址可达，只能说明这条线路对该检测目标的请求成功，不能证明所有网站都可访问。业务可能因出口地区、目标封锁、证书问题或 DNS 解析异常失败。遇到这种情况，先将入口固定到单个节点，重试目标业务，再查看连接日志，不要直接认定自动组算法错误。

HTTPS 检测还可能包含连接建立和 TLS 交互耗时。在 mihomo 中，顶层 unified-delay 可用于减少不同代理握手差异对延迟比较的影响；它不是策略组内的字段。比较数据时应保持该设置、检测 URL 和测试网络一致，不能把不同测试条件下的数字直接排序。

TUN 不改变策略组的选择算法

系统代理或 TUN 决定流量如何进入内核，规则决定交给哪个组，策略组决定出口。开启 TUN 不会让 fallback 自动按最低延迟选择，也不会让 load-balance 具备带宽聚合能力。如果某个应用没有进入内核连接列表，应该先排查接管路径，而不是修改 tolerance。

使用 Fake-IP 时，内核可通过地址映射保留域名匹配信息，但这同样不替代策略组健康检查。若节点服务器本身使用域名，还需确保其解析链路可用，避免代理连接依赖代理自身才能完成的 DNS 请求。DNS 故障可能表现为所有自动组节点超时，应结合 DNS 日志定位。

参数落地：从保守配置开始验证

初次配置可以统一使用 interval: 300，排查时设置 lazy: false，确认行为后再按设备续航和节点数量调整。若一个组有 12 个节点，按每个节点每轮至少一次探测估算，5 分钟一轮约为每小时 144 次检测；实际请求数量还会受额外探测、重试和手动测速影响，不能当作流量账单。

• 低延迟优先：选 url-test，先用 50 毫秒容差，观察新连接的出口是否过于频繁变化。
• 主线路优先：选 fallback，把真正希望优先使用的节点放在第一位，并确认备用节点的地区与用途。
• 多线路参与：选 load-balance，先试一致性哈希；仅在业务允许出口变化时使用轮询。
• 固定会话优先：保留 select 手动入口，为登录、支付和长时间任务指定稳定节点。

验证时一次只改一个变量：先固定节点与检测地址，再改策略类型，最后调整间隔和容差。观察至少两个完整检测周期，并分别测试新连接、持续下载和实际业务页面。选择结果、业务成功率与连接稳定性，比单次测速列表中最小的数字更能说明配置是否适合当前网络。