Clash Verge 如何通过规则组实现按域名分流？

一、问题起点：为什么“全部走代理”和“全部直连”都不好用

Clash Verge 规则组域名分流，解决的其实是一个朴素但绕不开的问题：同一台电脑上，有些域名必须走代理，有些域名必须直连，还有些域名最好直接拒绝。把所有流量一股脑交给代理，局域网设备、内网办公系统、部分国内接口会变慢甚至失败；反过来全部直连，需要访问的服务又打不开。规则组（配置文件中写作 proxy-groups，中文社区也常称“策略组”或“代理组”）就是夹在这两者之间、负责做取舍的那一层。

举一个具体的场景：一台开发机需要同时访问公开代码托管平台与公司内网的代码仓库。如果整机走代理，内网仓库的请求会被送到境外节点再绕回来，登录态容易失效；如果整机直连，公开仓库的克隆速度又难以接受。此时合理的做法是让公开代码托管域名走代理、让内网域名走 DIRECT，这两条判定写在 rules 里，而出口由 proxy-groups 提供。也就是说，判断与出口是分开的两件事。

这里有一个必须先厘清的边界：规则组本身不做匹配，它只是“可用出口的集合”；真正决定走哪个出口的是 rules 中的匹配条目。不少首次配置失败的案例，根因正是把两者混为一谈——在规则组里加了一堆域名，却没有在 rules 里引用这个组，结果规则组整段空转。

提示：本文提到的菜单名称与页面位置，以截至当前的最新版本为例，不同版本或不同语言设置下可能略有差异，请以实际界面为准。

二、概念澄清：规则组、规则、规则集是三件不同的事

在 Clash 的配置语义里，这三者构成一条完整的链路。rule-providers 是规则的“外部数据源”，它把一个远端或本地的列表文件拉下来缓存；rules 是判定顺序表，从上往下逐条比对，命中即停；proxy-groups 则是命中之后要去的出口。三者缺一，分流就不成立。下面的表格把各自的职责与常见故障并列出来，便于对照。

配置块	扮演的角色	典型出错表现
proxy-groups	出口容器，定义“有哪些选择”	rules 里引用了不存在的组名，整份配置解析失败
rules	判定顺序表，决定“谁走谁”	顺序写反，宽泛规则吃掉精确规则
rule-providers	规则列表的外部来源，按周期刷新	地址不可达或格式不匹配，规则整段失效

理解这条链路后，很多“改了没反应”的问题会立刻有解释。比如你在规则集文件里追加了域名，但 rules 中引用该规则集的条目排在 MATCH 之后，那么新增条目永远不会被读到——因为 MATCH 是兜底项，一旦命中就终止匹配，后面的内容形同不存在。

三、选型对比：直写规则、规则集、规则组，什么时候用哪个

先从成本最低的做法说起。如果只有三五个域名要处理，直接写在 rules 里是最省事的做法，改完保存即生效，不需要引入外部依赖。代价是条目会随着时间膨胀，而订阅更新时如果直接改的是订阅生成的配置文件，你的改动会被下一次更新覆盖。

当域名数量上升到几十条以上，尤其是需要跟随社区维护的名单时，规则集更合适。它把长列表从主配置中剥离出去，主配置只保留一行 RULE-SET 引用，可读性和维护成本都会明显改善。经验性观察：在规则总条数较大的配置中，把分散的域名归并为若干规则集，重新加载配置时的等待时间通常会有可见缩短，不过具体幅度因设备与条数而异。

至于规则组，它并不是“另一种写法”，而是上面两种方案都需要的出口定义。一个可用的判断顺序是：先问“我有没有多个出口需要切换”（有→建规则组），再问“我的域名列表会不会增长”（会→拆规则集），最后才落到具体条目怎么写。

临时排查、单一域名：直接写 DOMAIN-SUFFIX，不进规则集。
长期维护、成规模的名单：拆成 rule-providers，用 RULE-SET 引用。
需要在多个节点或直连之间手动切换：至少建一个 select 类型的规则组。

这三条不是互斥选项，而是逐层递进的关系：先确定有没有可切换的出口，再决定名单放在哪里，最后才动手写条目。

四、规则组的四种常见类型：各自适合什么场景

select（手动选择）是最常用的一种。它把若干候选出口列成一个列表，由你在客户端界面里手动点选。适合对出口稳定性有明确要求的场景，比如需要固定某个地区的出口来维持登录态。它的边界也很清楚：节点失效时不会自动切换，需要你自己发现并处理。

url-test（自动测速）会按固定周期向一个探测地址发起请求，选出延迟最低的出口。它适合“我只要求快、不要求固定地区”的日常浏览。探测地址与探测间隔是可配项，间隔设得过短会带来额外的周期性请求开销，设得过长则切换迟钝，需要按自己的网络波动情况权衡——这也是它与手动选择组最本质的分工差别。

fallback（故障转移）按列表顺序依次尝试，只有当前一个不可用时才切到下一个。它适合对“出口位置一致性”要求高、但对延迟不敏感的场景。与 url-test 的区别在于：fallback 是“能用就一直用”，url-test 是“谁快用谁”。

load-balance（负载均衡）把请求分散到多个出口上。是否可用、支持哪些调度策略取决于当前内核实现，建议在配置前先确认内核类型。对需要维持会话的服务来说，请求被分散到不同出口反而可能导致异常，因此它更适合无状态的大流量场景。

注意：以上类型名称来自 Clash 配置的公开字段定义。不同内核对其支持范围不完全一致，部分扩展类型仅在特定内核中可用。请在配置前确认当前使用的内核。

五、匹配类型与优先级：为什么顺序比内容更重要

Clash 的规则是“从上到下、命中即停”。这意味着同一个域名可能同时满足多条规则，最终生效的永远是位置最靠前的那条。理解这一点，比记住所有匹配类型更有价值。下面这张表汇总了常见匹配类型的含义与使用风险。

匹配类型	含义	适用与风险
DOMAIN	完全匹配某一域名	最精确，但子域名不覆盖
DOMAIN-SUFFIX	匹配域名后缀	日常主力；写太宽会误伤同后缀站点
DOMAIN-KEYWORD	域名含关键词即命中	灵活但极容易误伤，建议最少使用
RULE-SET	引用规则集文件中的列表	维护性好；依赖外部文件可获取
GEOSITE	按内置站点分类匹配	需内核支持，写一行即可覆盖大批域名
IP-CIDR / GEOIP	按目标 IP 段匹配	作用于连接建立后，与域名类规则层级不同
MATCH	兜底，匹配所有剩余流量	必须放最后，否则后面全部失效

一条稳妥的排序原则是：越精确的越靠前。把 DOMAIN 放在 DOMAIN-SUFFIX 之前，把自定义的例外条目放在聚合规则集之前，把 MATCH 放在最后一行。反过来，如果先写了一条宽泛的 DOMAIN-KEYWORD,cloud，后面所有包含 cloud 的精确域名都会被这句吃掉，排查时很难第一眼看出原因。

六、桌面端操作路径：两条可用路线与各自代价

6.1 路线 A：直接编辑配置文件

在“订阅”（Profiles）页找到当前启用的配置卡片，通过卡片的更多菜单打开文件编辑（不同版本可能是右键菜单或“…”按钮）。这条路线最直观，改完保存、重新加载即可生效。代价前面已经提过：如果这张卡片是订阅生成的文件，下一次更新订阅时改动会被覆盖。

6.2 路线 B：使用扩展文件合并配置

另一种做法是使用配置卡片的扩展能力，把自定义内容写成独立的合并片段或脚本，由客户端在加载时叠加到订阅配置之上。这样一来订阅照常更新，你的改动始终保留。常见的合并字段包括 prepend-rules、append-rules、prepend-proxy-groups 等，用于在规则表或规则组列表的头部、尾部插入内容。不同版本对字段的支持范围可能不同，请以保存后配置的实际生效情况为准。

选择哪条路线，取决于你多久更新一次订阅。如果订阅是长期固定不动的，路线 A 足够；如果订阅每周甚至每天更新，路线 B 会显著减少重复劳动。两条路线并不互斥，常见的做法是用合并片段维护自己的例外规则，而订阅文件保持只读。

6.3 平台差异说明

Clash Verge 是面向桌面系统的客户端，通常运行在 Windows、macOS 与 Linux 上。移动端（Android、iOS）通常使用其他客户端，界面路径与本文描述并不通用。但值得强调的是：规则组、规则、规则集的字段语义由内核决定，因此本文的配置片段在支持同类内核的移动端客户端上通常可以通用，只是“在哪里粘贴这段 YAML”需要按各自客户端查找。

配置文件本身的存放位置因操作系统与安装方式而异。桌面端一般在设置页提供了打开应用目录或配置目录的入口，具体名称随版本变化，请以实际界面为准，不建议手动猜测路径。

七、一份可复制的配置片段与逐段解读

下面这段配置演示了一个最小可用的结构：一个手动选择组、一个自动测速组、一个规则集来源，以及若干条分流规则。其中的节点名称、规则集地址均为占位示例，请替换为你自己的实际值。

rule-providers:
  custom-ai:
    type: http
    behavior: classical
    format: yaml
    url: 'https://example.com/rules/custom-ai.yaml'
    path: ./ruleset/custom-ai.yaml
    interval: 86400

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - 自动选择
      - DIRECT
      - REJECT
  - name: 自动选择
    type: url-test
    url: 'http://www.gstatic.com/generate_204'
    interval: 300
    tolerance: 50
    proxies:
      - 节点A
      - 节点B

rules:
  - DOMAIN,internal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - RULE-SET,custom-ai,手动选择
  - GEOIP,CN,DIRECT
  - MATCH,手动选择

逐段来看。rule-providers 里声明了一个名为 custom-ai 的规则集，behavior: classical 表示它内部使用完整的规则语法（而不是纯域名列表），interval 是刷新周期，单位通常为秒。这个数值是示例值，可按自己的更新频率调整。

接着看 proxy-groups：其中定义了两层结构，外层“手动选择”是给用户点的，内层“自动选择”负责在多个节点之间测速。把 DIRECT 和 REJECT 放进候选列表，是为了在排查时能快速把某个组整体切到直连或拒绝，而不必改配置。

最后是规则部分，它的顺序体现了前面说的原则：先精确的 DOMAIN，再后缀匹配，然后才是规则集和兜底。最后两行要注意，GEOIP,CN,DIRECT 让国内 IP 直连，MATCH 兜住剩余流量。如果你的网络环境对 IP 归属判断不敏感，这一行也可以省去，但 MATCH 不建议省略——没有兜底项时，未匹配的流量行为将取决于内核的默认处理方式。

八、为什么建议不要直接改订阅文件

订阅的本质是一份由服务方下发的、会被定期覆盖的文件。你在上面做的任何手工修改，都只是暂时有效。真正的问题还不是“改动丢了”，而是丢失时往往没有提示——某天早上发现某个站点又走错了出口，你会误以为是节点故障，而不是配置被覆盖。

用合并片段维护自己的部分，可以把这个风险降到最低。它的工作假设很简单：订阅负责提供节点和基础规则，你的片段负责提供个性化例外，两者在加载时叠加。要验证这一点，可以按下面的步骤做一个可复现的检查：先在合并片段里加入一条自定义规则，保存并重新加载；再手动触发一次订阅更新；更新完成后回到“规则”（Rules）页搜索该域名，如果仍然能看到你自定义的那条规则，说明合并生效且未被覆盖。

提示：验证时建议同时打开“日志”（Logs）页。命中规则时通常会有对应输出，可以直观看到匹配到了哪一条。

九、验证与观测：怎么确认分流真的生效了

配置写完之后，最忌讳的是“看起来没报错就当成功”。有三处界面可以做交叉验证，建议按顺序使用。

规则页：搜索目标域名，查看它最终命中的是哪一条规则、被分配到了哪个组。这是最直接的证据。
连接页：发起一次访问后观察该连接所属的链路。如果链路中出现了你自定义的组名，说明规则组被正确引用了。
日志页：观察实时输出，可以看到流量被逐条匹配的过程，适合排查“为什么这条没命中”。

这三处的信息互为补充：规则页回答“应该走哪条”，连接页回答“实际走了哪条”，日志页则把中间过程摊开给你看。三者结论一致，才算真正验证完成。

还有一个容易被忽略的观测点：修改配置后是否真的重新加载过。部分界面操作只是保存文件，需要手动触发一次配置重载才会生效。如果你发现改动“没有反应”，先确认这一步，再怀疑规则本身。

另外要接受一点现实：DNS 缓存、浏览器连接复用、系统级代理切换等因素，都可能让你的验证结果出现短暂延迟。比较稳妥的做法是换一个此前未访问过的域名做测试，或者重启一次相关应用再观察。

十、故障排查：五类常见现象与处置思路

现象一：配置无法加载。可能原因是 YAML 缩进错误，或规则中引用了不存在的组名。验证方式是检查日志页的报错行，通常会给出行号或字段名。处置思路是把新增内容先注释掉，确认基础配置可用后再逐段恢复。

现象二：某个域名始终走直连。可能是它同时命中了一条更靠前的 DIRECT 规则，也可能是该域名本身就解析到了国内 IP。验证方法是在规则页直接搜索这个域名，看命中结果。经验性观察：不少“规则不生效”的案例，实际是被更靠前的宽泛规则提前截获了。

现象三：规则集不更新。可能是源地址不可达，也可能是格式与 behavior 声明不匹配（例如声明为 domain 却提供了一份完整规则语法的文件）。验证方式是查看客户端是否给出了下载失败的提示，或直接访问该地址确认可获取性。

现象四：全局变慢。常见原因是自动测速的探测间隔设置得过于频繁，或规则条目数量过多导致匹配开销上升。可以先临时把相关组切成手动选择，观察是否恢复。DOMAIN-KEYWORD 这类宽泛匹配如果数量很大，也值得优先清理。

现象五：切组后没有立即生效。已建立的连接通常不会被强制迁移，新连接才会使用新的出口。这是预期行为，不是故障。处置方式是断开重连或等待原连接自然结束。

十一、适用与不适用场景清单

规则组加分流的方案，适合有明确分流诉求、且愿意花一点时间维护配置的人。它的收益随域名数量的增加而放大；如果只是偶尔用一次代理，投入产出比并不高。

场景	是否推荐	理由
个人电脑，长期稳定的订阅	推荐	一次配置长期受益
团队共用一份配置模板	推荐，但需版本管理	例外条目需要评审与记录
只需访问单个站点	不推荐	直接写一条规则即可，无需引入规则组
有严格合规审计要求的网络	需先确认合规边界	分流策略应与所在组织的网络规范一致

还有一类容易被忽略的不适用情形：当你无法确认某个规则集的来源与更新机制时，贸然引用它等于把网络行为的控制权交给了一份你读不懂的名单。这种情况下，宁可先用少量手工规则，也不要一次性引入大规模外部列表。

十二、最佳实践检查表

把下面这份清单当成配置完成前的自检项，可以规避大部分反复出现的问题。

所有在 rules 中引用的组名，都能在 proxy-groups 中找到对应定义。
MATCH 位于规则表最后一行，且未被任何后续条目跟随。
精确匹配（DOMAIN）排在宽泛匹配（SUFFIX、KEYWORD）之前。
自定义例外放在订阅自带的聚合规则之前，避免被提前截获。
所有外部规则集地址均可访问，且文件格式与 behavior 声明一致。
自定义内容存放在合并片段或独立文件中，而非订阅生成的文件里。
修改后执行过一次完整的配置重载，并在规则页确认命中结果。
为每个自定义规则组写一句注释，说明它存在的理由，便于日后清理。

前七条针对的是“这次能不能跑通”，最后一条针对的是“以后还读不读得懂”。它经常被跳过，却决定了这份配置半年后的可用性。规则文件是会腐化的，没有注释的例外条目，三个月后连你自己都想不起为什么加。

十三、常见问题

规则组改名之后需要同步改哪里？

凡是引用了该组名的地方都要改，包括 rules 中每条以组名结尾的条目，以及其他规则组的 proxies 列表中对该组的嵌套引用。任何一个遗漏都会导致配置解析失败或流量走向兜底项。建议改名前先在配置中全局搜索一次该名称。

为什么我加了规则，流量还是走默认出口？

按三个方向排查：一是新规则的位置是否排在 MATCH 之前；二是是否有更靠前的宽泛规则已经命中该域名；三是配置是否真的重新加载过。这三项都能在规则页与日志页中得到验证，不必凭猜测调整。

规则集和直接写规则，在效果上有区别吗？

匹配结果没有区别，差别在维护方式与加载方式。规则集需要额外获取与缓存文件，首次加载依赖网络可用；直接写规则则全部内联在主配置中，不依赖外部文件，但会让主配置变长。条数少时前者更省事，条数多时后者更易维护。

自动测速组和手动选择组可以嵌套吗？

可以。常见做法是把自动测速组作为一个候选出口放进手动选择组，这样既能一键切换到自动模式，也能随时锁定某个具体出口。嵌套层数不宜过多，否则排查链路时会变得困难。

这套配置能直接搬到手机客户端吗？

字段语义通常可以通用，前提是目标客户端使用同类内核。但界面路径、文件存放位置、扩展机制都可能完全不同，需要按各自客户端的方式导入。GEOSITE 等依赖内核实现的匹配类型尤其要先确认目标内核是否支持。

十四、结论与下一步

把整篇文章压缩成一句话：规则组提供出口，规则表决定走向，规则集负责把长名单从主配置里搬走；三者串联的前提是顺序正确、引用一致、改动不被订阅更新覆盖。掌握了这套结构，你面对的大多数分流问题都可以拆解成“哪一条先命中”和“这个组是否存在”两个具体疑问。

下一步建议不要一次性铺开。先挑一个你每天都在用、走错出口会立刻察觉的域名，为它加一条精确规则和一个手动选择组，跑通“改配置—重载—在规则页验证命中”这条完整回路。回路跑通之后，再把同类域名归纳成规则集，把配置迁移到合并片段。这个顺序能让你在每一步都拿到明确的反馈，而不是在几十条规则的报错里找问题。需要提醒的是，内核与客户端的迭代会带来字段支持范围的变化，本文涉及的菜单名称与字段定义，仍请以你当前使用的版本为准。