Clash Verge 如何配置分流规则实现国内外流量自动分流？

分流规则在 Clash Verge 中的定位与演进

Clash Verge 的分流规则本质上是一套基于域名、IP 段与规则集的流量调度系统：跨境请求自动进入代理通道，国内服务则直连落地，在访问效率与带宽成本之间取得平衡。得益于 Clash Meta（mihomo）内核对多层策略组与远端规则集的原生支持，现代配置已告别早期全局代理或手动切换的粗放模式——客户端只需按设定间隔拉取更新，即可持续保持规则时效性，用户无需逐条维护成千上万条记录。

需要明确的是，分流规则只负责「把哪部分流量送往哪个出口」，并不决定节点本身的线路质量。即便规则编排得天衣无缝，若节点存在高延迟或握手失败，目标网站依然无法顺畅打开。因此，规则配置应当与节点健康检查、DNS 解析策略视为一个整体工程，而非孤立操作。下文将以当前主流发行版的通用能力为基准，带你走完从配置骨架搭建到观测验证的完整路径。

分流规则的核心逻辑与匹配顺序

Clash 系内核采用「自上而下、命中即停」的规则链设计。当网络请求进入客户端，它会按序遍历规则列表：先精确域名（DOMAIN），再匹配后缀（DOMAIN-SUFFIX）与关键词（DOMAIN-KEYWORD），随后进入 IP 段（IP-CIDR）与地理库（GEOIP），最终被 MATCH 兜底规则捕获。理解这一顺序至关重要——示例：若将 GEOIP,CN,DIRECT 置于 DOMAIN-SUFFIX,google.com,Proxy 之前，而 Google 的某些国内 CDN 节点又恰好落在 CN 段内，本应代理的流量便会被意外直连，造成访问异常。

为了避免这类误判，最佳做法是将语义最明确的规则前置，把最宽泛的兜底规则后置。在实际编排中，通常先声明局域网与大陆顶级域名直连，再处理已知被封锁的境外域名代理，最后用 GEOIP 与 MATCH 收纳剩余流量。对于使用规则集（RULE-SET）的场景，需特别注意：规则集在内部会被展开为多条独立规则，其优先级由主配置中引入 RULE-SET 的先后顺序决定，而非规则集文件内部的排列。经验性观察表明，一套覆盖日常中外流量分流的配置通常由 5 到 8 个策略组与 10 余个规则集共同构成，这一规模能在延迟表现与可维护性之间取得较好平衡。理清匹配顺序后，下一步便是找到正确的配置入口。

Clash Verge 配置入口与多平台差异

在 Clash Verge 的图形界面中，分流规则主要通过 Profiles（配置文件）或配置编辑入口进行管理。导入订阅链接后，客户端会自动拉取远端配置；若想在订阅基础上追加自定义规则，建议使用 Merge（合并）覆写功能，或直接在本地新建配置文件，以防订阅更新时覆盖手动修改。Windows 用户通常可在主界面左侧导航栏找到「订阅」与「规则」标签页；macOS 与 Linux 版本因采用相同前端框架，界面结构基本一致，但快捷键与托盘菜单位置会随系统主题略有差异。已导入的订阅配置通常提供「只读预览」与「本地覆写」两种视图——在只读模式下直接修改将在下次更新时丢失，因此持久化自定义规则的关键，在于切换至本地配置或在 Merge 层中追加内容。

平台差异更多体现在权限与系统集成层面。Windows 端若需开启 TUN 模式或自动设置系统代理，建议至少以管理员身份运行客户端一次，否则可能因权限不足而无法写入系统代理设置；macOS 用户在首次安装后若遭遇「已损坏」警告，需在「系统设置 - 隐私与安全性」中手动放行，并执行终端命令移除隔离属性。Linux 发行版分支众多，若使用 Wayland 会话，经验性观察发现部分全局热键可能无法被正确捕获，此时通过系统托盘图标切换配置更为可靠。无论你通过何种入口修改，最终生效的都是经 Clash Meta 内核解析后的完整配置文件，因此熟悉 YAML 缩进规范与关键字拼写，是避免启动失败的必要前提。完成入口确认后，接下来应解决规则的规模化维护难题。

规则集托管与自动更新机制

面对数以万计的境内外域名与 IP 段，手写规则显然不具备可维护性。规则集（Rule Provider）机制允许你将规则片段托管在远端（如 GitHub、jsDelivr），由 Clash 内核按设定间隔自动拉取并缓存到本地。以社区维护的 Loyalsoldier 规则集为例，其提供了 direct、proxy、reject、cncidr 等多个分类文件，分别对应大陆白名单、境外代理名单、广告拦截与国内 IP 段。在配置中引入这些规则集后，日常维护便从「逐条编写规则」降级为「定期检查规则集源是否可访问」，工作量大幅缩减。

在 Clash Verge 中启用规则集，本质上是在 YAML 配置中声明 rule-providers 字段，随后在 rules 列表中以 RULE-SET,名称,策略组 的形式引用。经验性观察表明，将更新间隔（interval）设为 86400 秒（24 小时）是较为均衡的选择：既能及时同步最新域名信息，又不会对上游服务器造成频繁请求。若你的网络环境对 GitHub 原站访问不稳定，可将 URL 替换为镜像站或私有 CDN 地址，但需自行承担镜像内容被篡改的潜在风险。此外，规则集的行为类型（behavior）必须与远端文件格式严格一致：domain 类型适用于纯域名列表，ipcidr 类型适用于 IP 段，classical 类型最为灵活但解析开销最大，引用前务必核对上游文档，避免因类型不匹配导致内核初始化失败。掌握自动更新机制后，便可着手搭建一套可落地的配置骨架。

实战：搭建国内外分流配置骨架

以下提供一份经过简化的通用配置骨架，适用于「大陆直连、境外代理」的典型场景。该骨架涵盖 DNS、策略组、规则集引用与兜底匹配，可直接粘贴至 Clash Verge 的配置编辑器中作为起点。示例：其中节点与策略组名称均为占位符，你需要将其替换为实际订阅中的真实节点名称，否则内核将无法找到可用出口。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

proxy-groups:
  - name: 默认代理
    type: select
    proxies:
      - 自动选择
      - DIRECT
  - name: 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 节点A
      - 节点B

rule-providers:
  direct:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400
  proxy:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
    path: ./ruleset/proxy.yaml
    interval: 86400
  cncidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cncidr.txt"
    path: ./ruleset/cncidr.yaml
    interval: 86400

rules:
  - DOMAIN-SUFFIX,baidu.com,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT
  - RULE-SET,direct,DIRECT
  - RULE-SET,proxy,默认代理
  - GEOIP,CN,DIRECT
  - MATCH,默认代理

在此示例中，DNS 模块启用了 fake-ip 模式，其目的在于避免部分国内应用在遇到解析延迟时出现卡顿；nameserver 仅保留国内 DoH（如 DNSPod、阿里 DNS）用于国内解析，而 fallback 中的 Cloudflare 与 Google DoH 则专门负责境外域名。规则链自上而下依次放置：最上方是精确的大陆域名直连规则，中间通过 RULE-SET 引入大规模列表，最后由 GEOIP 与 MATCH 兜底。具体场景示例：当你同时访问公司内网 OA 与 GitHub 时，OA 域名命中顶部的直连规则后即刻本地落地，而 GitHub 经 fallback DNS 解析后进入默认代理策略组，整个过程无需手动切换。这套骨架的核心价值在于将 DNS 与规则链解耦，让解析与分流各司其职。

DNS 解析与分流协同：防止泄露与劫持

分流规则能否生效，很大程度上取决于 DNS 配置是否合理。如果所有域名都走国内 DNS，某些已被污染的境外域名（如部分 Google 服务）可能返回错误 IP，导致规则尚未匹配就被内核拒绝连接；反之，若所有查询一律发往海外 DoH，国内 CDN 调度可能将你导向延迟较高的海外节点，造成「开了代理反而更慢」的体验。因此，DNS 分流是规则体系的前置条件，两者必须协同设计。

在 Clash Meta 内核中，enhanced-mode: fake-ip 会在本地生成虚拟 IP 应答给应用程序，真正的域名解析推迟到代理出口侧完成，这能有效防止 DNS 泄漏。然而，fake-ip 并非万能：部分网银客户端、企业 privacy tool 或局域网管理后台可能对 198.18.x.x 等虚拟 IP 段产生兼容性异常。此时应回退至 redir-host 模式，并配合 fallback-filter.geoip: true 确保国内域名不被发往国外 DNS。工作假设认为，对于普通网页浏览与视频流媒体场景，fake-ip 的响应速度通常优于 redir-host；而在需要与本地硬件、内网证书系统或企业准入客户端交互时，redir-host 的兼容性往往更佳。用户应根据自身网络环境进行二选一，而非盲目跟风默认设置。

对于需要固定解析结果的内网域名（如公司 OA、NAS、私有 GitLab），可使用 nameserver-policy 强制指定 DNS 服务器，绕过 fallback 逻辑。这在企业远程办公场景中尤为关键，能防止内网域名被错误发往公共 DNS 而无法解析到私有 IP。经验性观察表明，将 *.corp.example.com 指向公司内部 DNS，可显著减少因 DNS 超时导致的网页白屏问题。完成 DNS 层设计后，接下来需要选择合适的流量接管机制，让规则真正生效。

TUN 模式与系统代理的取舍与边界

规则写好后，还需要一个流量接管机制将其落地。Clash Verge 提供两种主流方式：系统代理（System Proxy）与 TUN 模式。系统代理通过修改操作系统级别的 HTTP 代理设置，让遵循系统代理变量的应用（如浏览器、多数下载工具）自动将流量送入 Clash 端口；TUN 模式则创建一个虚拟网卡，在网络层直接拦截所有 IP 包，无论应用程序本身是否支持代理。对于仅需浏览器与常规软件分流的用户，系统代理开销更小、部署更快，是首选的轻量方案。

然而，当你需要代理未配置代理变量的命令行工具（如 curl、wget）、UWP 应用或游戏主机流量时，TUN 模式几乎成为唯一选择。需要警惕的是，TUN 模式不应与同类虚拟网卡软件（如公司 privacy tool、VMware 虚拟网络、部分杀毒软件的网络驱动）同时开启，否则极易产生路由环路或网络闪断。经验性观察发现，在 Windows 平台同时运行企业级 privacy tool 与 Clash TUN 时，路由表优先级冲突会导致国内网页间歇性无法打开；此时最稳妥的做法是关闭 TUN，改用「系统代理 + 需要代理的应用手动指向该代理」的轻量方案，以避开底层驱动冲突。

若配置中手动编写了 PROCESS-NAME 规则（进程级分流），还需注意不同操作系统的进程标识差异。Windows 通常以可执行文件名（如 chrome.exe）匹配，而 macOS 与 Linux 往往要求完整路径或 Bundle ID。这类规则在桌面端可实现「指定游戏客户端直连、浏览器走代理」的精细化效果，但由于进程名可能随软件更新而变化，维护成本较高，仅建议在确有进程级例外需求时引入。选定接管模式后，接下来必须通过可观测指标验证规则是否按预期工作。

验证分流是否生效的可复现方法

配置完成后，必须通过可观测指标验证规则是否按预期工作，而非仅凭「感觉」。第一种方法是查看 Clash Verge 的 Connections（连接）面板：在浏览器中打开 baidu.com，若面板中该连接的 Rule（规则）字段显示为 DIRECT，且策略指向国内出口，则大陆直连生效；随后访问 ip.sb 或 ifconfig.co，若连接被标记为 Proxy 且出口 IP 与节点所在地一致，则境外分流逻辑运行无误。

第二种方法针对 DNS 防泄漏验证。在浏览器中访问公开的 DNS 泄漏检测页，若结果仅显示代理节点所在国家的 DNS 服务器，而无国内运营商 DNS，则说明 fake-ip 或 redir-host 的回退策略运行正常。第三种方法更适用于开发者：在终端执行 curl -v https://github.com 时，观察解析到的 IP 是否为 fake-ip 段（通常为 198.18.x.x）。若是，则表明 Clash 内核已接管解析并准备按规则转发。建议以上步骤在「仅开启系统代理」与「开启 TUN」两种模式下分别复现，以确认不同接管机制下的行为一致性。验证通过后，仍需掌握常见故障的排查与回退手段，以应对日常变数。

常见故障排查与回退策略

国内网站打开缓慢或图片加载失败，是最常见的分流副作用之一。排查时应首先审视规则顺序：检查是否有过于宽泛的 RULE-SET 或 GEOIP 规则被提前放置，导致国内 CDN 节点被错误代理。其次查看 DNS 日志，确认国内域名是否意外进入了 fallback DNS 通道。若排查后确认是远端规则集本身将某个国内域名误判为境外，可在配置顶部手动插入一条 DOMAIN-SUFFIX,问题域名,DIRECT 作为临时补丁，同时向规则集社区提交反馈，以便上游长期修正。

另一类常见现象是「境外网站漏过代理直接连接」，通常表现为特定被封锁网站无法打开。此时应在 Clash Verge 日志中过滤该域名，观察其匹配到的规则名称。若日志显示 MATCH,DIRECT，说明没有任何前置规则命中该域名，且兜底规则设置过于保守；解决方法是将该域名或其所属规则集前移至更高优先级，或更换覆盖更全面的规则集源。回退方案方面，当规则调试导致全网断连时，可点击客户端托盘图标选择「全局直连」，或临时关闭系统代理与 TUN，迅速恢复上网后再逐项排错。保留一个「全局直连」的应急入口，是生产环境配置的基本纪律。

当客户端启动失败并提示配置文件错误时，常见原因包括 YAML 缩进混用 Tab 与空格、RULE-SET 引用时遗漏策略组名称，或在 rule-providers 中写错 behavior 类型。此时应复制配置到支持 YAML 校验的编辑器中先行排查，或直接查看内核日志定位具体行号。经验性观察表明，大多数启动失败与上述三类语法问题有关，修正后即可正常加载。掌握排查思路后，还需明确这套规则体系适合与不适合的边界，避免在不恰当的场景过度依赖。

适用场景与不适用清单

基于上述机制，Clash Verge 分流规则最适用于以下场景：日常跨境办公（如访问 GitHub、Docker Hub、AWS 控制台）、高校学术资源下载（如 IEEE、Nature 等域名自动走教育网优惠或代理节点）、流媒体与社交媒体的智能解锁，以及游戏平台流量需要低延迟入口时的定向转发。这些场景的共同特征是「流量目的地明确、国内外服务边界清晰」，规则集能够长期稳定地发挥调度作用，用户无需频繁手动干预。

然而，以下场景不宜过度依赖精细化分流规则：第一，对匿名性要求极高的敏感活动（如需要多层跳板的极端隐私操作），此时应使用 Tor 网络而非基于单一代理节点的 Clash 分流；第二，企业强制网络准入环境（如需要 802.1X 证书或特定 privacy tool 才能接入内网），额外的 TUN 网卡可能与准入策略冲突，导致无法通过企业网关认证；第三，网络环境极度受限的公共 Wi-Fi（如仅允许 80/443 端口且存在深度审计），复杂的规则与 DNS 查询特征反而容易触发防火墙的异常检测。在这些边界条件下，退回到简化代理方案或干脆直连，往往是更稳妥的选择。

最佳实践检查表

为便于快速落地，以下检查表汇总了配置国内外分流时的核心决策点。在每次新建或修改配置后，逐项核对可显著降低故障概率，避免因疏忽导致的间歇性断网或 DNS 泄漏。

规则顺序：精确 DOMAIN 规则是否位于宽泛 GEOIP 与 MATCH 规则之前？
规则集源：引用的 HTTP URL 是否可在浏览器中直接访问？是否设置了合理的更新间隔？
DNS 隔离：国内域名是否仅由国内 DNS 解析，境外 fallback 是否仅在非 CN IP 时触发？
模式选择：若仅需浏览器代理，优先使用系统代理；若需全局接管游戏或命令行，再启用 TUN。
兜底策略：MATCH 规则的目标是 Proxy 还是 DIRECT？确保其符合你的默认安全假设。
回退验证：修改后是否检查了百度、GitHub、银行网银三类代表性站点的连接日志？

这份检查表的价值在于将隐性经验显性化。许多用户容易忽视「银行网银」这一类特殊目标，其往往对 fake-ip 或境外 DNS 极为敏感，提前在规则中将其设为 DIRECT 可避免后续紧急排错。建议将检查表保存为配置备注，或在团队内部共享，以保持多设备间的配置一致性。养成「修改后逐项核对」的习惯，远比事后抓包排查更高效。

常见问题（FAQ）

导入订阅后自定义规则被覆盖怎么办？

在 Clash Verge 中，远端订阅更新时会重写对应的本地配置文件副本。若要持久化自定义规则，建议使用 Merge（覆写）功能，或在「本地配置」中新建文件，将订阅作为 proxy-providers 引用，而非直接修改订阅本体。这样每次更新只会同步节点信息，不会覆盖你的规则链。

TUN 模式开启后设备无法联网或国内网站极慢？

首先检查是否有其他 privacy tool 或虚拟网卡（如 VMware、公司隐私工具）同时运行，路由冲突是首要原因。其次进入配置确认 DNS 模块已启用（dns.enable: true），且国内 nameserver 可用。经验性观察表明，Windows 端若未以管理员身份运行，TUN 网卡可能无法正确写入路由表；此时彻底退出客户端并以管理员身份重启，通常即可恢复。

如何确认某个网站走了正确的分流策略？

在 Clash Verge 的 Connections（连接）面板中实时过滤该域名，查看其 Rule（规则）与 Policy（策略）列。若面板显示该连接命中了 DIRECT 却理应代理，说明规则顺序有误或规则集未覆盖该域名；若显示代理但网页仍无法打开，则问题大概率出在节点链路而非规则层。

规则集更新失败或显示红色报错如何处理？

先在浏览器中直接访问规则集 URL，确认远端地址可访问且返回纯文本列表。若 GitHub 原站不通，可更换 CDN 镜像链接。其次检查本地配置目录（具体路径因安装方式而异，请以实际为准）是否具备写入权限，因为内核需要将下载的规则集缓存到本地磁盘。最后核对 rule-providers 中的 behavior 是否与远端文件格式一致，类型不匹配将直接导致内核初始化失败。

纵观全文，一套可靠的 Clash Verge 分流方案并非孤立地堆砌规则，而是规则顺序、DNS 策略、接管模式与持续验证的闭环工程。随着 Clash Meta（mihomo）内核的持续迭代，未来版本预期会进一步细化规则集的增量更新与行为类型自动探测，降低新手在 behavior 匹配上的试错成本；同时，图形客户端对连接日志与策略命中路径的可视化也有望更加直观。在可预见的演进中，「自动分流」与「低感知运维」仍是核心方向——用户只需关注业务目标（访问谁、走哪条路），而将繁琐的列表维护交给社区规则集与客户端自动化能力。保持对内核 Release Note 的关注，定期回顾你的配置骨架，便是让这套体系长期稳定运行的最佳实践。