Clash Verge 分流配置示例
本文通过一份配置示例，将代理节点、策略组和分流规则组合起来，讲清不同请求如何匹配规则、选择出口，以及如何检查实际分流结果。
节点定义怎么连接代理服务器，策略组决定使用哪个出口，分流规则决定请求交给谁处理。
1. 分流要求
假设已经有两个 AnyTLS 节点，分别命名为“直连美国”和“直连日本”，希望实现以下效果：
| 请求目标 | 分流要求 |
|---|---|
baidu.com 及其子域名 | 使用本地网络直连 |
google.com 及其子域名 | 默认自动选择节点，也可以手动切换到美国或日本节点 |
claude.com 及其子域名 | 固定使用美国节点 |
ads.example.com | 拒绝连接 |
| 其他未匹配到的请求 | 默认使用美国节点，也可以手动切换出口 |
本案例只针对表中列出的域名，不代表覆盖相关服务使用的全部域名。ads.example.com 是用于演示拒绝规则的示例域名。
以下分流针对已经进入 Clash 的请求，使用时需要通过系统代理、TUN 或软件自己的代理设置，将请求交给 Clash。
2. 解决方案
配置思路
| 配置部分 | 解决什么问题 |
|---|---|
| 美国、日本两个节点 | 提供两个代理出口 |
Auto [自动选择] | 根据测试结果，在两个节点之间自动选择 |
Google [谷歌服务] | 提供自动选择、美国节点、日本节点三个选项 |
Default [默认代理] | 为未匹配前面规则的请求提供可切换的出口 |
| 分流规则 | 将请求交给指定节点、策略组、DIRECT 或 REJECT |
完整 YAML 配置
下面的服务器地址和密码都是占位信息，需要替换为实际节点参数。
# 本地代理混合端口，支持 HTTP 和 SOCKS
mixed-port: 7890
# 使用规则模式
mode: rule
# 日志级别
log-level: info
# 代理节点：填写实际服务器地址、端口、密码和 SNI
proxies:
- name: 直连美国 # 自定义节点名称
type: anytls
server: us-proxy.example.com
port: 443
password: "填写美国节点密码"
sni: us-proxy.example.com
udp: true
skip-cert-verify: false # 验证服务端证书
- name: 直连日本
type: anytls
server: jp-proxy.example.com
port: 443
password: "填写日本节点密码"
sni: jp-proxy.example.com
udp: true
skip-cert-verify: false
# 策略组：组织可选出口，决定如何选择
proxy-groups:
# 根据测试延迟，在美国、日本节点之间自动选择
- name: "Auto [自动选择]"
type: url-test
proxies:
- 直连美国
- 直连日本
url: https://www.gstatic.com/generate_204 # 测试网址
interval: 300 # 每隔 300 秒检查一次
tolerance: 50 # 50 毫秒切换容差，减少轻微波动引起的切换
lazy: false # 未使用该组时，也按间隔检查
# 手动选择自动选择组，或者直接指定节点
- name: "Google [谷歌服务]"
type: select
proxies:
- "Auto [自动选择]" # 由这个组继续选择节点
- 直连美国
- 直连日本
# 为未匹配前面规则的请求选择出口
- name: "Default [默认代理]"
type: select
proxies:
- 直连美国
- 直连日本
- "Auto [自动选择]"
# 分流规则：从上到下匹配
rules:
# 精确匹配示例广告域名，拒绝连接
- DOMAIN,ads.example.com,REJECT
# 百度及其子域名，使用本地网络直连
- DOMAIN-SUFFIX,baidu.com,DIRECT
# Google 及其子域名，交给 Google 策略组
- DOMAIN-SUFFIX,google.com,Google [谷歌服务]
# Claude 及其子域名，固定使用美国节点
- DOMAIN-SUFFIX,claude.com,直连美国
# 前面未匹配到的请求，交给默认策略组
- MATCH,Default [默认代理]3. 配置加载与请求处理
启用配置：内核准备好节点、策略组和规则
将 YAML 配置导入 Clash Verge 并启用后，由 Mihomo 内核加载最终生效的配置。
| 配置部分 | 内核根据它准备什么 |
|---|---|
proxies: | 节点名称及其服务器地址、端口、认证信息等 |
proxy-groups: | 策略组的候选出口和选择方式 |
rules: | 请求的匹配条件和对应的处理目标 |
导入并启用配置
→ Mihomo 内核加载配置
├─ 节点：有哪些代理服务器，怎么样连接
├─ 策略组：有哪些候选出口，怎么样选择
└─ 分流规则：请求符合条件时，交给谁处理这里说明的是三个部分的作用，不表示内核内部的加载先后顺序。
节点、策略组和规则在启用配置时加载。请求进入后，内核使用这些已经加载的配置进行处理。
请求怎么样匹配规则并确定出口
示例一：Claude 固定使用美国节点
下面以访问 claude.com 为例，说明请求进入 Mihomo 内核后，怎么样按顺序匹配规则并找到节点。
访问 claude.com，请求进入 Mihomo 内核
↓
第一条：DOMAIN,ads.example.com,REJECT
→ 不是 ads.example.com，不匹配
↓
第二条：DOMAIN-SUFFIX,baidu.com,DIRECT
→ 不属于 baidu.com 及其子域名，不匹配
↓
第三条：DOMAIN-SUFFIX,google.com,Google [谷歌服务]
→ 不属于 google.com 及其子域名，不匹配
↓
第四条：DOMAIN-SUFFIX,claude.com,直连美国
→ 匹配成功，处理目标是“直连美国”
↓
在已加载的 proxies 中找到“直连美国”节点
→ 使用该节点的服务器地址、端口、密码等连接信息
→ 通过美国代理服务器访问 claude.com匹配第四条后，本次请求不再检查最后的 MATCH。
示例二：Google 根据策略组选择出口
再以访问 www.google.com 为例。假设在 Clash Verge 中，Google 组当前手动选择了“直连美国”。
访问 www.google.com，请求进入 Mihomo 内核
↓
第一条广告规则：不匹配
↓
第二条百度规则：不匹配
↓
第三条：DOMAIN-SUFFIX,google.com,Google [谷歌服务]
→ 匹配成功，处理目标是 Google [谷歌服务]
↓
在已加载的 proxy-groups 中找到 Google 策略组
→ 当前选项是“直连美国”
↓
在已加载的 proxies 中找到“直连美国”节点
→ 使用该节点的连接信息
→ 通过美国代理服务器访问 www.google.com如果将 Google 组切换为“直连日本”，后续由该组处理的新连接就使用日本节点。
规则指定节点，就使用该节点；规则指定策略组，就继续根据组内选择确定最终出口。
4. 主配置 + 独立规则文件
前面的示例将分流规则直接写在主配置中。规则较多时，可以按类别将匹配条件放进独立规则文件，通过主配置中的 rule-providers: 登记文件，再通过 RULE-SET 引用规则集合并指定处理目标。
4.1 文件结构
拆分后，配置由一个主配置文件和四个独立规则文件组成：
配置工作目录/
├── main.yaml
└── ruleset/
├── ads.yaml
├── direct.yaml
├── google.yaml
└── claude.yamlmain.yaml 保存节点、策略组、规则集合的登记信息和处理目标。ruleset/ 下的四个文件分别保存广告、直连、Google 和 Claude 的匹配条件。
重要
在 Clash Verge 中导入主配置，不代表独立规则文件也会自动导入，需要确保这些文件位于 path 对应的位置。
这里的“配置工作目录”指 Mihomo 的配置工作目录，下面的 ./ruleset/ 相对于该目录解析。
4.2 主配置 main.yaml
下面是拆分后的完整 main.yaml。节点和策略组沿用前面的示例，通过 rule-providers: 登记四个独立规则文件，再在 rules: 中引用。
服务器地址和密码是占位信息，需要替换为实际节点参数。四个规则文件需要放在前面目录结构对应的位置。
# 本地 HTTP 和 SOCKS 代理端口
mixed-port: 7890
# 使用规则模式
mode: rule
# 日志级别
log-level: info
# 代理节点：沿用前面的美国、日本节点
proxies:
- name: 直连美国
type: anytls
server: us-proxy.example.com
port: 443
password: "填写美国节点密码"
sni: us-proxy.example.com
udp: true
skip-cert-verify: false
- name: 直连日本
type: anytls
server: jp-proxy.example.com
port: 443
password: "填写日本节点密码"
sni: jp-proxy.example.com
udp: true
skip-cert-verify: false
# 策略组：沿用前面的定义
proxy-groups:
# 根据测试延迟自动选择节点
- name: "Auto [自动选择]"
type: url-test
proxies:
- 直连美国
- 直连日本
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: false
# Google 请求的可选出口
- name: "Google [谷歌服务]"
type: select
proxies:
- "Auto [自动选择]"
- 直连美国
- 直连日本
# 未匹配前面规则时的可选出口
- name: "Default [默认代理]"
type: select
proxies:
- 直连美国
- 直连日本
- "Auto [自动选择]"
# 登记独立规则文件，供下面的 RULE-SET 引用
rule-providers:
AdRules: # 自定义集合名称
type: file # 从本地文件读取规则
behavior: classical # 条目带规则类型，例如 DOMAIN、DOMAIN-SUFFIX、IP-CIDR
format: yaml # 文件使用 YAML 格式
path: ./ruleset/ads.yaml # 这个集合对应的规则文件
DirectRules: # 直连规则集合名称
type: file
behavior: classical
format: yaml
path: ./ruleset/direct.yaml
GoogleRules: # Google 规则集合名称
type: file
behavior: classical
format: yaml
path: ./ruleset/google.yaml
ClaudeRules: # Claude 规则集合名称
type: file
behavior: classical
format: yaml
path: ./ruleset/claude.yaml
# 格式：RULE-SET,规则集合名称,处理目标
# 集合名称必须与上面 rule-providers 中定义的名称一致
rules:
# 匹配 AdRules 集合中的条件，处理目标为 REJECT
- RULE-SET,AdRules,REJECT
# 匹配 DirectRules 集合中的条件，处理目标为 DIRECT
- RULE-SET,DirectRules,DIRECT
# 匹配 GoogleRules 集合中的条件，处理目标为 Google 策略组
- RULE-SET,GoogleRules,Google [谷歌服务]
# 匹配 ClaudeRules 集合中的条件，处理目标为美国节点
- RULE-SET,ClaudeRules,直连美国
# 兜底规则，继续放在最后
- MATCH,Default [默认代理]其中，rule-providers: 登记集合名称、文件位置和读取格式；rules: 使用集合名称引用匹配条件，并指定处理目标。
4.3 四个独立规则文件
独立规则文件使用 payload: 保存匹配条件。本例使用 behavior: classical，所以条目中需要包含 DOMAIN、DOMAIN-SUFFIX 等规则类型。
ruleset/ads.yaml
payload:
# 精确匹配示例广告域名
- DOMAIN,ads.example.comruleset/direct.yaml
payload:
# 匹配 baidu.com 及其子域名
- DOMAIN-SUFFIX,baidu.comruleset/google.yaml
payload:
# 匹配 google.com 及其子域名
- DOMAIN-SUFFIX,google.comruleset/claude.yaml
payload:
# 匹配 claude.com 及其子域名
- DOMAIN-SUFFIX,claude.com提示
payload: 下面可以添加多条匹配条件，每条条件不填写处理目标。
5. 总结
启用配置时，内核加载节点、策略组和规则。请求进入后，按规则顺序匹配，再根据处理目标确定出口：直连、拒绝、指定节点，或者通过策略组选择出口。
版权所有
版权归属：念宇