①
兜底规则放得太靠前
MATCH 会接管所有请求。如果它出现在列表开头，后面的规则就永远不会被执行——这不是语法错误，是顺序问题。
3段式写法：类型 / 内容 / 动作
#注释随行，改动有据可查
组按用途拆分，按顺序加载
热保存重载，不必重启进程
Anatomy
把一条规则拆开来看
规则的基本单位很短：一段类型、一段内容、一个动作。把这三样写清楚，剩下的就是把它们按重要性排好队。
1
rules:
规则列表从这里开始。下面的每一行都是一条判断，引擎从上到下依次比对。
2
- DOMAIN-SUFFIX,internal.dev,DIRECT
类型决定「用什么判断」，internal.dev 是匹配内容，DIRECT 是命中之后的动作。
3
- DOMAIN-KEYWORD,ads,REJECT # 广告域名拦截
行尾可以写注释。半年后再看，也不必靠猜来回忆当初为什么加这条。
4
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
部分类型可以带附加参数。no-resolve 表示命中网段后不再反查域名，省下一次查询。
5
- MATCH,PROXY
兜底规则放在最后。所有没被前面命中的请求，都在这里得到明确归属。
Type
类型：判断的维度
域名、IP、端口、进程、规则集——类型决定了这条规则从哪个角度审视请求。 选对类型，一条规则能顶好几条。
Payload
内容：判断的取值
一个后缀、一个网段、一个关键字、一个正则表达式。 内容写得多具体，规则就管得多精确。
Action
动作：命中后去哪
DIRECT、PROXY、REJECT、RELAY，
或者一个策略组的名字。动作决定流量离开设备的方式。
Match Types
常见写法一览
同一条规则可以简单到只写一个后缀，也可以复杂到用正则覆盖一批命名有规律的目标。选择权在你手上。
DOMAIN
完整域名匹配。最精确的写法，一个取值只对应一个域名。适合固定服务、关键接口，改动频率低、要求明确的场景。
DOMAIN-SUFFIX
后缀匹配。一条规则覆盖整个域名及其所有子域。整站放行或整站绕行，通常用这条就够了。
DOMAIN-KEYWORD
关键字匹配。只要域名里含有该关键字就命中。用来抓同一类服务、同一种命名习惯，范围比后缀更宽松。
DOMAIN-REGEX
正则匹配。命名有规律但无法用后缀涵盖时使用。表达能力强，匹配成本也相对更高，适合放在更具体的规则之后。
IP-CIDR / IP-CIDR6
网段匹配。处理只有地址没有域名的请求，或按机房段、内网段、DNS 段划分策略。可附加
no-resolve 避免反查。GEOIP
地区归属匹配。按 IP 所属地区判断。常见用法是把本地流量直连、把需要绕行的交给策略组，减少无效中转。
DST-PORT / SRC-PORT
端口匹配。同一主机上的不同服务可以被拆开处理。调试接口、管理后台、镜像源，各走各的策略。
PROCESS-NAME
进程名匹配。按发起请求的程序判断。浏览器、版本控制、下载器可以绑定不同出口，同一台设备不必共享同一条链路。
RULE-SET
规则集引用。把外部规则集当成一个整体判断。域名表、广告表、地区表独立维护，主配置保持精简。
MATCH
兜底匹配。放在列表最后，接管所有未命中的请求。有它，流量就不会出现无归属的状态。
Batch & Wildcard
一条规则，覆盖一批目标
写规则的效率，很大程度取决于「一条能管多少」。后缀、关键字、正则、规则集——四种批量手段，覆盖不同规律的目标。
用后缀覆盖整站
- DOMAIN-SUFFIX,example.com
- 命中 example.com 及其所有子域
- 适合：整站策略统一的服务
- 优点：可读、好维护、不易误伤
用正则覆盖规律命名
- DOMAIN-REGEX,^cdn\d+\.example\.net$
- 命中 cdn1、cdn2、cdn3 等一批节点
- 适合：命名有规律但无法枚举的目标
- 注意：放在较具体规则之后，避免误伤
批量不是偷懒，而是把重复的判断收成一条清晰的表达。
一条写对的后缀规则，价值往往高于十条写死的完整域名——因为前者在未来更不容易过期。
Readable
写给自己看的注释，也要写
规则会被反复修改。留下注释，等于给未来的自己留下一份索引：这条为什么加、什么时候加的、有没有替代方案。
Comments
注释不是装饰，是维护成本的分摊
一份没有任何注释的配置，第一次改会觉得很快；第三次改的时候，就要靠回忆来判断每条规则存在的理由。 把理由写在旁边，问题就少了一半。
- 分组前加一行用途说明，打开就知道这块管什么
- 特殊规则注明原因，比如临时绕行、特定环境适配
- 记录修改日期，方便回看某次调整带来了什么变化
- 把注释也纳入版本管理，历史记录一目了然
# ============================
# 内网与本地服务 — 直连
# 2026-01 整理
# ============================
rules:
# 本地开发环境
- DOMAIN-SUFFIX,local,DIRECT
- DOMAIN-SUFFIX,internal.dev,DIRECT
# 私有网段不反查
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
# 广告拦截（规则集维护）
- RULE-SET,ads,REJECT
# 兜底
- MATCH,PROXY
Organize
把规则分成几块，按顺序拼回去
当规则从几十条长到几百条，主文件会开始变得难以浏览。按用途拆分、按顺序加载，是让配置长期可维护的关键一步。
01
内网与本地服务
本地域名、私有网段、开发环境。这一组通常最稳定，改动频率最低，放在列表最前面，让判断尽早命中。
02
广告与追踪拦截
通常以规则集形式引入，独立更新，主配置只留一行引用。拦截类规则放在较前位置，避免被宽泛规则抢先命中。
03
常用服务与直连
高频访问的站点、就近的公开服务。这组规则写清楚之后，日常浏览的大部分请求都不会经过不必要的转发。
04
按用途划分的代理组
浏览器、开发工具、下载器各自绑定不同的策略组。应用级判断让同一台设备上的流量不再互相干扰。
05
地区与兜底
GeoIP 与地区规则放在靠后位置，最后用兜底规则收尾。越具体的判断越靠前，越宽泛的判断越靠后，这是一条实用的排序原则。
Merged
拆开维护，合并加载
分组不是为了把文件变多，而是为了每次改动只打开一小块。 加载时按预设顺序合并，规则之间的相对位置保持不变——你的编排意图，仍然原样生效。
- 按用途拆分文件，每组只关注一类判断
- 保持加载顺序，合并后优先级与预期一致
- 团队共享时各改各的块，冲突范围被控制在局部
- 规则集独立更新，主配置不必跟着改动
# 主配置：按顺序合并各部分
rule-providers:
internal: # 内网
type: file
path: ./rules/internal.yaml
ads: # 广告
type: http
url: "https://.../ads.yaml"
interval: 86400
proxy: # 代理目标
type: file
path: ./rules/proxy.yaml
rules:
- RULE-SET,internal,DIRECT
- RULE-SET,ads,REJECT
- RULE-SET,proxy,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
Validate & Reload
改完就走，不用重启
规则写错在早期是常事。关键在于：改动的代价够不够小，试错的速度够不够快。 保存、重新载入、继续用——中间没有多余的步骤。
✓
保存即校验。引擎在载入阶段检查结构是否完整，类型与动作是否可识别，有问题会直接指出来。
↻
热重载不中断。配置重新载入后立即生效，已有连接按新规则继续判定，服务进程保持在线。
⌁
小步修改，快速验证。一次只改一小块规则，确认效果后再动下一块，问题更容易定位。
◷
订阅与本地共存。订阅提供公共基线，本地追加自己的规则；更新订阅不会覆盖你写下的私人条目。
规则可读、改动可查、重载不中断——这三点凑在一起，配置才真正具备「长期维护」的前提。
一份能持续改下去的规则，比一份一次写完美的规则更贴近实际。
Pitfalls
几个容易踩的坑，提前说在前面
规则写得不对，通常不是因为难，而是因为顺序或范围出了问题。下面这几种情况最常见。
②
用关键字覆盖了太多
DOMAIN-KEYWORD 的范围比想象中宽。一个过于通用的关键词，可能顺手把无关服务也带进同一条通道。
③
IP 规则忽略了反查成本
没有 no-resolve 的 IP 规则会触发反向查询，在高频访问下累积成额外开销。明确不需要域名的场景，建议加上这个参数。
④
把规则和节点混在一起改
规则描述「意图」，节点提供「出口」。两者分开维护，换节点时规则不必动，调整策略时也不会牵扯到线路配置。
Q & A
关于规则语法，常被问到的几件事
规则文件用什么格式写？
使用 YAML 格式。它以缩进代替括号，用短横线表示列表项，条目之间以换行分隔，天然适合承载逐条递进的规则列表，阅读与修改都不需要专门的编辑器。
一条规则通常由几部分组成？
常见写法是「类型, 匹配内容, 动作」三段：类型说明用什么维度判断，匹配内容给出具体值，动作决定命中后直连、代理、拦截还是中继。部分类型还可以带上附加参数。
支持正则表达式吗？
在域名等维度上可以使用正则写法，用来覆盖命名有规律但无法用单条后缀描述的批量目标。正则匹配成本相对更高，通常建议放在较具体规则之后。
规则多了怎么保持可维护？
常见做法是分组存放：按用途拆成多个规则片段或规则集，主配置按引用顺序加载。每组前用注释说明用途和更新时间，需要调整时只需打开对应分组。
修改规则后需要重新启动吗？
不需要。保存配置后重新载入即可生效，引擎会按新规则继续判定，服务进程保持在线。
新手从哪里开始？
建议先找一份现成的规则模板，从最熟悉的几个域名开始改：把常用服务指向直连或指定策略组，跑通后再逐步增加规则集与分组。