Clash 规则分流深度教程：自定义规则组

为什么规则分流值得认真写

很多人第一次用代理工具时，会习惯「开全局」：所有流量统一走隧道，简单直观，但代价也明显——国内视频、网银、政务站点可能被无谓地绕路，延迟与风控体验都会变差。Clash 家族（含基于 Mihomo 的客户端）真正吸引人的地方，在于它把「策略」与「规则」拆开：策略决定走哪条链路，规则决定什么时候启用哪条策略。

当你把规则写清楚，本质上是在给网络流量做一张「路由表」：哪些域名必须直连，哪些 IP 段要走代理，哪些应用或站点需要固定节点。它比单纯依赖系统代理更细，也比手工切换节点更稳，因为规则一旦生效，行为是可重复、可版本化的。

ⓘ 读完本文你能做什么

你将理解规则匹配的先后顺序，能组合 DOMAIN、IP-CIDR、GEOIP、RULE-SET 等类型搭建分层规则；会用 proxy-groups 把「自动选最快」「故障回落」「手动指定」分开；会用 rule-providers 让规则集可更新、可回滚，并在出问题时快速定位是 DNS、规则顺序还是策略组配置导致的异常。

第一条命中的规则赢：顺序比「写得多」更重要

Clash 的规则列表是自上而下顺序匹配的：一旦某条规则命中，后面的规则不会再参与判断（除非你使用的是少数特殊能力，例如部分内核特性对脚本或子规则另有约定）。这意味着「把更具体、更确定」的规则放在前面，「更宽泛」的兜底规则放在后面。

一个常见错误，是把 GEOIP,CN,DIRECT 放在很靠前的位置，却在它后面才写某些必须代理的域名；如果前面已经命中了直连，后面的代理规则永远不会触发。反过来，如果把过于宽泛的代理规则放在顶部，也会导致国内流量被误送代理。

推荐的思维模型是三层：第一层处理局域网与私有地址；第二层处理你明确知道要直连或要代理的对象（域名、IP、进程在某些客户端里也可配合）；第三层才是 GEOIP 或 MATCH 这类大范围兜底。把「确定性强」的写前面，把「统计型」的写后面，维护成本会低很多。

常用规则类型怎么选

不同规则类型解决不同信息维度的问题：有的看域名，有的看完整主机名，有的看 IP，有的看国家地区。组合起来，才能覆盖「DNS 还没解析」与「已经拿到 IP」两个阶段。

域名类

DOMAIN 精确匹配单个主机名；DOMAIN-SUFFIX 匹配后缀，适合一整类站点；DOMAIN-KEYWORD 做关键词包含匹配，威力大但容易误伤，建议谨慎使用。对于公开服务，优先使用更明确的 DOMAIN / DOMAIN-SUFFIX，再考虑关键词规则。

IP 与网段

IP-CIDR 与 IP-CIDR6 适合处理已知网段，例如 CDN 边缘节点、企业出口或某些必须直连的地址。它们通常在域名规则之后发挥作用：当连接目标已经是 IP，或者命中了「no-resolve」场景时，直接用 IP 规则会更稳定。

地理分流

GEOIP 适合作为兜底：把「来自某国家/地区」的 IP 归并到统一策略。它的前提是 GeoIP 数据库与解析路径可靠；若 DNS 或 fake-ip 配置不当，可能出现「判断依据不是你以为的那个 IP」。若你发现 GEOIP 行为怪异，优先回溯 DNS 与连接日志，再考虑调整规则顺序。

规则集合

RULE-SET（或旧式 GEOIP 数据库文件）让你把大量条目从主配置中拆出去，便于更新与复用。把「广告拦截」「隐私追踪」「常用境外站点合集」做成独立规则集，可以显著减轻主文件的噪音。

类型	典型用途	注意点
`DOMAIN-SUFFIX`	整站或整类域名分流	后缀越短，覆盖面越大，误伤越高
`IP-CIDR`	固定网段直连或代理	与 DNS 模式联动，排查时看真实连接 IP
`GEOIP`	国家/地区兜底	适合放列表后段，避免遮挡更精细规则
`RULE-SET`	大规模、可更新规则	关注更新源可信度与本地缓存策略
`MATCH`	最终兜底	必须存在，明确默认策略，避免未定义行为

自定义策略组：让「节点」变成「方案」

规则行的末尾并不是直接写节点名，而是指向 proxy-groups 里的一个组。这样做的意义是：规则只负责分流到「方案」，方案内部再决定具体节点。你可以把组理解成产品的「套餐」，规则是「谁可以买哪个套餐」。

常见的组类型包括：select（手动选择）、url-test（按延迟测速自动选）、fallback（按顺序故障转移）、load-balance（分散负载）。其中 url-test 适合「只要能上网就行」的默认出境；fallback 适合「稳定性优先」；select 适合「我必须指定某个地区出口」。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO-BEST
      - HK
      - JP
      - DIRECT

  - name: AUTO-BEST
    type: url-test
    proxies:
      - Node-A
      - Node-B
      - Node-C
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: HK
    type: select
    proxies:
      - Node-HK-1
      - Node-HK-2

rules:
  - DOMAIN-SUFFIX,corp.internal,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

把 DIRECT 放进可选手动组里是一个实用技巧：当你遇到「只有某一个站点异常」时，不必改规则，先在组里切到直连验证路径问题，确认后再回头收紧规则。

rule-providers：让规则集可更新、可分层

当规则数量上升到几百上千行，继续全部堆在 config.yaml 里会变得难以合并与审阅。rule-providers 可以把规则集拆成外部文件或远程 URL，由内核按间隔拉取或本地引用。你可以按主题拆分：广告与追踪、流媒体、办公软件、开发者常用域名等。

维护时建议遵循三个原则：第一，来源可信与变更有记录；第二，为不同集合设置合理的更新间隔，避免频繁拉取；第三，主文件保留「个人绝对规则」小段，专门放你公司内网、家庭 NAS、特定 API 域名，这段永远放在规则顶部，避免被远程集合覆盖优先级。

rule-providers:
  reject-ads:
    type: http
    behavior: classical
    url: https://example.com/rules/reject.txt
    path: ./ruleset/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject-ads,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

⚠ 远程规则不是「越全越好」

过大的规则集会带来加载时间与内存占用，也可能引入你不需要的匹配行为。更务实的做法是：先保证自己的「硬规则」正确，再逐步引入远程集合；每次引入后观察连接日志与 CPU 占用，确认收益大于成本。

场景模板：工作、娱乐与开发可以共用一套骨架

下面这套骨架不是唯一正确答案，但它容易扩展：顶部处理内网与明确直连；中部用 RULE-SET 处理已知列表；尾部 GEOIP 把中国境内流量交给直连；最后 MATCH 走默认代理组。你可以把「开发」相关域名单独接到 DEV 组，把「流媒体」接到 STREAM 组，而默认组仍保持通用。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - DOMAIN-SUFFIX,company.example,DIRECT
  - DOMAIN-SUFFIX,github.com,DEV
  - DOMAIN-SUFFIX,openai.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

娱乐场景里，流媒体往往对地区与出口 IP 敏感；开发场景里，包管理器、容器镜像站、API 文档站点的域名更杂。把它们分别固化成策略组，而不是全部塞进同一个「自动选最快」，能显著减少「今天能拉包、明天又超时」的随机感。

DNS 与 fake-ip：规则世界的「地基」

规则再漂亮，如果 DNS 解析路径与连接目标不一致，你看到的日志会与直觉相悖。启用 fake-ip 时，应用拿到的可能是内核分配的虚拟地址，真正的域名解析发生在更靠后的阶段；此时 DOMAIN 类规则与 IP 类规则的触发时机也会不同。若你正在排查「明明写了 DOMAIN 规则却不生效」，请先确认 DNS 模式、是否开启嗅探（sniffer）以及该域名是否走了 unexpected 的路径。

实务上建议：把 DNS 配置视为规则分流的一部分，而不是单独话题。对常用客户端而言，保持 DNS 劫持与 TUN 或系统代理协同，比在规则里硬写更多 IP 段更有效。若你希望系统了解不同模式下的网络行为，可结合阅读站内的文档总览，把 DNS、TUN 与规则三块一起校准。

排错清单：从日志把问题缩到三步内

先看命中哪条规则：打开连接面板或日志，确认最终策略与匹配规则名称。若看不到期望的规则名，十有八九是顺序问题或被更靠前规则截胡。
再核对解析结果：看域名解析到的地址是否为预期网段，是否出现了本不该直连的国内 CDN 或反之。此时应回头检查 DNS 与 fake-ip 相关设置。
最后验证策略组：同一规则下切换 select 的不同出口，观察延迟与可用性变化。若规则不变而仅切换节点就恢复，说明问题在节点而不在规则。

如果你需要快速对照各类代理协议与端口行为，也可以浏览协议说明页，避免把「规则写错」误判成「协议不支持」。

把分流写成「可维护的配置」，而不是一次性脚本

规则分流的终极目标，不是把配置文件写得眼花缭乱，而是让日常网络行为稳定、可解释、可回滚。把个人规则与远程集合分层，给策略组起可读的名字，保持 GEOIP 与 MATCH 的职责清晰，你会少掉大量「昨天还能用」的玄学问题。

相比「一刀切的全局代理」，这种写法让国内流量继续享受本地网络的低延迟与内容分发优势，只在需要出境时启用对应策略；整体体验往往更顺滑。若你正在挑选客户端，可以优先考虑规则编辑体验成熟、能可视化展示命中规则、并持续跟进 Mihomo 内核的项目——这类工具会把「写规则」从折腾变成工程化流程。

立即免费下载 Clash，开启流畅上网新体验 →