策略组与规则：流量先进哪一扇门

在 Clash 里，规则负责回答「这条连接交给谁处理」：每一行规则的第三列通常是一个策略意图——可以是内置的 DIRECT（直连）、REJECT（拒绝），也可以是你自己在 proxy-groups 里命名的策略组，例如 Proxy、Auto、Fallback。策略组再向下展开：要么让用户手动选（select），要么由内核按延迟或健康状态自动挑一个具体代理节点（url-test、fallback 等）。

因此，「导入订阅后仍然感觉不会自动选最快」往往并不是节点列表没刷新，而是规则从未把你的浏览器流量指到那个带测速的组，或 url-test 的参数让切换过于保守。把「规则 → 策略组 → 具体节点」这条链路画清楚，再对照连接日志，你会很快定位问题。规则匹配的先后顺序与写法，可参考本站 规则分流最佳实践。

select、url-test、fallback 与负载均衡速览

select：纯手动。列表里选谁就用谁，不做延迟比较；适合「我就是要固定香港/日本」的场景，不负责自动优化。

url-test：自动。对 proxies 列表中的候选反复发起轻量 HTTP 测速，在健康的节点里优先选延迟更低的那个；适合「同一组里多出口，我想常年自动跟最快」的日常上网组。你看到的「延迟数字」多半就来自这里（具体展示取决于客户端）。

fallback：顺序主备。按 proxies 数组从上到下找第一个通过健康检查的节点；当前面的节点恢复后，是否切回取决于实现与健康探测节奏。它解决的是故障转移，不是「谁延迟最低」——若你把延迟差异很大的节点塞进 fallback，它仍可能长期停在列表最前的可用节点上。

load-balance（负载均衡）：把会话分散到多个出口，常见有哈希分流等策略；与「挑延迟最低」不是同一目标。若你的关键词是负载均衡，请确认自己是要分散连接还是要自动选快——前者看 load-balance，后者优先 url-test。

relay：链式代理，和测速无关；新手误把链路组当成自动选组时，也会觉得「怎么总走第一个」。链路与自动选择在配置意图上要分开。

url-test 逐字段实配：测速、间隔、容差与 lazy

下面是一段示意结构（字段名以你实际内核版本为准；Meta / Mihomo 系与经典 Clash 大多兼容这一写法，个别扩展字段见客户端文档）：

YAML example — url-test policy group 
proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - 节点A
      - 节点B
      - 节点C
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
ℹ 界面与 YAML 的对应关系：许多图形客户端把上述字段做成「测速地址」「测速间隔」「容差」「惰性测速」开关；本质仍是写回 proxy-groups。若你在 UI 里改了却无效，检查是否启用了「仅运行时配置」而未保存到订阅合并结果。

延迟测速 URL 怎么选：稳定、轻量与合规

测速 URL 不是越「大牌」越好，关键是：经你的代理链访问时，能稳定返回小响应，且不会频繁 302 到不可预期域名。社区常见的 generate_204 类地址常被用作「极小体积极快结束」的探测，但是否适合你要结合本地运营商与节点线路实测。

实操建议：准备 2~3 个候选 URL，在客户端里切换观察延迟分布是否稳定、是否大量超时；再在 连接日志里确认失败是 DNS、TLS 还是出口封锁。若测速请求本身被重定向到超大页面，延迟会失去可比性。

从隐私与合规角度，测速会产生周期性对外访问；请使用你有权使用且符合当地与服务条款的方式，避免把敏感内网地址写进 url。

fallback 主备与健康检查：顺序即意图

fallback 的典型目标：列表第一位是主出口，后面是备用。内核按顺序找到第一个「当前健康」的成员并使用；当主节点恢复可用后，是否立即切回，取决于探测与实现细节——不要把它当成「永远跟延迟最低」。

YAML example — fallback policy group 
proxy-groups:
  - name: Stable
    type: fallback
    proxies:
      - 主线路
      - 备用1
      - 备用2
      - DIRECT
    url: http://www.gstatic.com/generate_204
    interval: 300

注意：proxies 里可以出现 DIRECT，表示「代理全挂时退回直连」。这在访问仅内网或必须直连的资源时可能有用，但若兜底直连指向公网服务，要清楚真实出口已变，与「全程走代理」的预期可能冲突。

⚠ 与 url-test 的选型差异：要「自动选最快」请用 url-test；要「主挂了就换备」请用 fallback。把十几个延迟差异很大的节点丢进 fallback，却期待总用最快的，属于类型选错。

规则第三列：策略组名、DIRECT、REJECT 与 MATCH

规则的基本形状仍是「类型, 条件, 策略」；第三列策略只要是合法名字，就会去找同名策略组或内置常量。典型配合方式：

Rules snippet — bridge policy groups 
rules:
  - DOMAIN-SUFFIX,corp.internal,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Auto

再次强调：首个匹配即停止。若一条宽泛规则排在 MATCH 之前却把流量送到错误的组，后面针对自动组的调整都不会生效。需要系统梳理匹配顺序时，回到 规则分流最佳实践 中的「排序逻辑」一节对照即可。

别混淆：DNS 里的 fallback 与策略组 fallback

配置里可能出现两个都叫 fallback 的概念：dns 段落用于解析失败时的备用 DNS 服务器；proxy-groups 下的 type: fallback 是代理出口的主备切换。它们解决的是完全不同层的问题。修改 DNS fallback 不会让你的 url-test 自动选路；反之亦然。

「不自动切换」的常见原因与对照检查表

建议排障顺序：在连接日志确认命中的规则与策略组名 → 打开对应 proxy-groups 看类型是否为 url-test / fallback → 核对成员与测速配置 → 最后才怀疑节点本身。日志阅读步骤可参考 timeout 与 TLS 一文。

一份可改订阅名的最小可用示例

假设订阅已生成若干叶子代理，名称随机场商变化；你只消把下列示意中的占位符换成你真实的 name 字段即可（以下为教学拼接，非完整配置文件）：

Minimal illustration — combine with your proxies section 
proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - 日本-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 40
    lazy: true

  - name: Stable
    type: fallback
    proxies:
      - 专线主
      - 专线备
      - Auto
    url: http://www.gstatic.com/generate_204
    interval: 300

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

这里 Stable 组内嵌套了 Auto，表示「专线都不可用时的最后一层仍是自动竞速组」；是否采用这种嵌套取决于你对可预期出口的要求。嵌套过深会影响排障复杂度，保持「命名清晰 + 日志可追踪」即可。

结语：把测速与主备写进可维护的配置

Clash 策略组不是订阅的附属品，而是你把「意图」翻译成机器可执行策略的地方：url-test 负责延迟测速与自动选节点，fallback 负责顺序主备与故障转移；负载均衡另有其用，别与二者混谈。把它们写对之后，再用规则把流量准确送进组里，DIRECT 与 REJECT 才能在正确的层级发挥作用。

相比只在界面里反复切换节点，把 interval、tolerance、lazy 与测速 URL 调到适合自己网络与终端习惯，再配合清晰的规则排序，长期维护成本更低。图形客户端若能把策略组与连接日志联动展示，排障会更快；选型时可对照 如何选择适合自己的 Clash 客户端。更多通用问题见 常见问题。

相比零散复制配置片段，理解「规则 → 策略组 → 节点」这一链条后，你能自行判断该改规则还是改组类型，而不是盲目重装订阅。

→ 立即免费下载 Clash，开启流畅上网新体验，在图形界面里对齐策略组、测速与规则，再按本文字段逐项核对。