Clash YAML 配置深度解析：规则分流、策略组与 Fake-IP 实战

为什么值得花时间读懂 YAML？

Clash 系列客户端（含基于 mihomo 内核的 Clash Verge Rev 等）本质上都是在解析同一份结构化配置：YAML。无论你使用图形界面还是纯文本编辑，最终落到内核上的仍是 proxies、proxy-groups、rules 与 dns 等字段。读懂这些字段的含义与优先级，你就能在订阅异常、分流错误、DNS 泄漏等问题出现时快速定位，而不是反复「恢复默认」或盲目换节点。

本文面向已经能导入订阅、但希望理解「背后发生了什么」的读者：先梳理配置文件的整体骨架，再分别说明节点与订阅、策略组类型、规则匹配顺序、远程规则集，最后集中讲解 Fake-IP 与 DNS 防泄漏的实战写法。需要查阅字段速查时，可同步打开本站文档中的 YAML 配置章节对照阅读。

配置文件骨架：端口、模式与日志

一份典型的 Clash 配置顶层会包含 port / socks-port、mixed-port（混合端口）、mode、log-level 等通用项。mode 常见取值为 rule（按规则分流）、global（全局走代理组默认链）、direct（全部直连）。日常科学上网场景几乎总是使用 rule，否则你在 rules 里写的分流逻辑不会生效。

log-level 建议在排错时设为 info 或 debug，稳定使用后改回 warning 或 error 以减少磁盘写入。若你使用 TUN 模式，配置中还会出现 tun 段，它与 YAML 分流规则配合实现系统级流量接管，这部分与本文的「规则 + DNS」主线并列，可在掌握基础后再单独加深。

proxies 与 proxy-providers

proxies 列出每一个具体节点：类型（如 ss、vmess、trojan 等）、服务器地址、端口、加密与认证信息。proxy-providers 则用于从远程 URL 或本地文件批量拉取节点，适合机场订阅场景：机场更新节点时，你只需刷新订阅，而无需手工改 proxies 列表。

实践中常见误区是：在图形界面里改了分组名或节点名，却与 YAML 里的 proxy-groups 引用不一致，导致「选了策略组但没有节点」。解决办法是保持「策略组引用的名称」与「proxies 里定义的 name」完全一致，或在客户端中使用统一的配置源，避免双轨修改。

proxy-groups：策略组到底怎么用

proxy-groups 定义了「用户可选的策略入口」以及「自动调度逻辑」。常见类型包括：

select：手动选择，适合「主代理 / 备用线路」这类需要人眼决策的场景。
url-test：按延迟自动选最快节点，可配置测速 URL、间隔与容忍值（tolerance），适合追求低延迟的通用出口。
fallback：按顺序检测可用性，前一个挂了再切下一个，适合稳定性优先。
load-balance：在多个节点间分配连接（具体算法依内核与版本而定），需注意与部分网站的会话一致性要求是否冲突。
relay：链式代理，流量依次经过多个节点，延迟叠加但可组合不同地区能力。

策略组可以互相引用：例如「国外流量」组引用「自动选择」组，而「自动选择」组再引用具体节点列表。嵌套过深会增加排错难度，建议用清晰的命名（如 PROXY、Auto、HK）并保持层级不超过二到三级。若你使用 mihomo，还可结合子规则（Sub-Rule）为某一策略组单独指定规则，使大配置文件更模块化。

rules：从上到下，先匹配先生效

rules 是分流的核心：内核按从上到下的顺序逐条匹配，命中第一条后就会停止。因此「更具体、更优先」的规则必须写在前面，「兜底」规则放在最后。常见写法包括基于域名的 DOMAIN / DOMAIN-SUFFIX、基于地理的 GEOIP、基于 IP 段的 IP-CIDR、以及基于进程名的 PROCESS-NAME（桌面端常用）等。

最后几条通常是 MATCH，将剩余流量导向某个策略组或直连。很多用户遇到「国内网站也走了代理」或「国外站点走了直连」，第一反应是去改节点，实际上应先检查 rules 顺序是否被某条过于宽泛的规则提前命中。配合日志中的匹配记录，可以快速看出命中的是哪一条规则。

小提示

若你从网上复制规则集，请留意其中是否包含针对局域网或内网域名的直连条目；误删这些条目可能导致局域网设备或公司内网访问异常。

rule-providers：远程规则集与更新策略

当规则数量达到成千上万条时，全部写在主配置里会难以维护。rule-providers 允许你从 URL 或本地文件加载规则集，并在 rules 里用 RULE-SET 类型引用。配置时需关注 behavior（域名类、IP 段类或 classical）是否与规则文件内容一致，否则会出现「规则存在但不生效」的现象。

建议为规则集设置合理的更新间隔，并保留可访问的镜像或本地备份，避免上游链接失效导致启动失败。若你使用 mihomo，还可以使用内联 rule-set 等新特性，在性能与可维护性之间做权衡。

DNS 与 Fake-IP：防泄漏的实战要点

仅写好 rules 并不能保证「域名级分流」一定正确：若 DNS 解析在代理隧道之外完成，仍可能出现 DNS 污染或泄漏。Clash / mihomo 通过 dns 段与 enhanced-mode 协同解决这一问题。最常用的是 Fake-IP 模式：对需要代理的域名，内核先返回一段虚拟地址（常见为 198.18.0.0/16），再在内部维护域名与虚拟地址的映射，使后续连接仍按域名走规则与策略组。

fake-ip-filter 用于排除不适用 Fake-IP 的域名（例如部分局域网域名、特定国内服务），避免兼容性故障。nameserver 与 fallback 分工：前者通常填国内或延迟较低的 DoH，后者在需要时启用境外解析；fallback-filter 可结合 GeoIP 等条件决定何时回退。这样可以在「国内域名快速解析」与「敏感域名不被污染」之间取得平衡。

下面是一段便于理解的 Fake-IP 配置示例（请按你的网络环境替换 DoH 地址与过滤列表）：

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '+.stun.*'
  nameserver:
    - https://doh.pub/dns-query
  fallback:
    - https://dns.cloudflare.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

注意

Fake-IP 与 TUN、系统 DNS 设置之间存在交互；若你发现个别应用解析异常，可尝试将该域名加入 fake-ip-filter，或检查是否与其他本地 DNS 软件冲突。

把碎片拼成一张图：最小可读模板思路

将上述模块串联后，一份「可维护」的配置通常遵循以下顺序：proxies / proxy-providers → proxy-groups → rule-providers（如有）→ rules → dns。编写时建议先保证策略组名称与规则引用一致，再逐步加入远程规则集与 DNS 细节，每改一步都在客户端日志中验证命中情况。

若你希望从图形界面管理订阅与分组，同时保留核对 YAML 的能力，可以选择内置 mihomo 的客户端，在「配置」视图中查看最终合并结果。更多安装与入门步骤可参考本站博客首页中的其他教程文章。

结语

Clash YAML 并不神秘：它只是把「节点」「策略」「规则」「DNS」四件事用结构化语法写清楚。真正容易踩坑的是优先级与命名一致性——规则自上而下匹配、策略组层层引用、Fake-IP 与过滤列表相互配合。当你建立起这套心智模型后，大部分「为什么走了直连」「为什么 DNS 泄漏」的问题都可以在半分钟内从配置中找到答案。

相比依赖零散教程四处拼凑，使用一款内核新、界面清晰、能直接验证规则命中与 DNS 行为的客户端，会显著降低学习成本。若你尚未安装或正准备换用更省心的桌面端方案，不妨前往客户端下载页获取适合你系统的版本；在可视化界面中对照本文调整 YAML，往往比纯手搓配置更稳、更快见效。→ 立即免费下载 Clash，开启流畅上网新体验