◎
域名路由
后缀、关键字、通配符、完整匹配，四种写法覆盖从整站到单页的粒度。
内部测试域名写成 DOMAIN-SUFFIX 直接放行，广告联盟用关键字拦截，出口策略跟着域名走，改动只落在一行上。
6+可组合的匹配维度
4命中后自动执行的动作
0订阅更新时需要重启的次数
顺序即优先级，先命中先执行
Multi-Dimension
一次请求，可以被六个角度同时审视
单看域名会漏掉 IP 直连，只看 IP 又分不清同一台服务器上的不同服务。 引擎把判定拆成多个维度，让它们互相补位——组合起来，才是一张完整的流量地图。
◫
IP 与网段分流
当请求里只有地址没有域名，IP-CIDR 与 GeoIP 归属就成了主要依据。
把机房段、办公网段、公开 DNS 段分别归入不同策略，境外请求与本地服务不再挤在同一条通道上。
▤
端口判定
同一个 IP 上的 443 和 8080，含义可能完全不同。 按目标端口分流，可以把管理后台、调试接口、镜像源拆开处理，避免一条宽泛规则把所有服务一起带走。
⌥
应用级代理
进程名与应用包名可以成为匹配条件。 让下载器走大带宽出口、让版本控制走稳定出口、让浏览器跟着策略组自动测速——同一台机器，各走各的路。
◨
规则集引用
大块规则不必塞进主文件。RULE-SET 把外部规则集当成一个可复用的判断单元，
域名表、广告表、地区表独立维护，主配置保持清爽。
◩
逻辑组合
维度之间可以叠加：先看域名、再看端口，或者为某个进程单独指定地区判断。 规则顺序本身就是一套逻辑，写下来就是可被复现的分流方案。
Match Matrix
把判定条件摊开来看
下面这张表不是文档摘录，而是一份思路清单：先确定用什么判断，再决定命中之后做什么。
| 判定维度 | 适合处理的场景 | 典型动作 |
|---|---|---|
| 域名后缀 / 关键字 | 整站放行、广告过滤、常用服务固定出口 | 直连 / 拦截 / 代理 |
| IP-CIDR 网段 | 机房段、内网段、公开 DNS、无域名请求 | 直连 / 代理 |
| GeoIP 地区 | 按归属地决定是否绕行，减少无效中转 | 直连 / 代理 |
| 目标端口 | 同主机多服务拆分、调试接口单独处理 | 直连 / 中继 |
| 进程 / 应用包名 | 工具链、下载器、浏览器各用各的出口 | 代理 / 中继 |
| 规则集引用 | 成规模的域名表、广告表、地区表统一维护 | 按集合内策略执行 |
| 兜底匹配 | 未命中任何规则的请求，给出明确归属 | 代理 / 直连 |
顺序即优先级。引擎自上而下逐条比对，第一条命中的规则说了算。
因此，越具体的判断越应该靠前，越宽泛的兜底越应该留到最后——这既是性能上的优化，也是逻辑上的清晰。
Traffic Dispatch
命中之后，四种动作各司其职
匹配解决「是谁」，调度解决「去哪儿」。四种动作共用同一套判定结果，切换由规则自动完成，不需要手动点选节点。
直连 DIRECT
代理 PROXY
拦截 REJECT
中继 RELAY
直连：不绕远路
内网接口、本地服务、本来就在近处的请求，直接发出。少一次转发，就少一段等待。
代理：交给策略组挑选
请求不直接绑定某个节点，而是进入策略组。测速、故障转移、负载分担在组内完成，出口随时可换，规则不必跟着改。
拦截：在本地终止
广告域名、追踪脚本、已知无效请求，在离开设备之前就被终止。既省流量，也省一次往返的时间。
中继：接上另一段链路
需要多段转发的场景下，先交给指定链路再继续。路径更长了，但换来了可达性上的补充。
发起请求
→
规则引擎
↓ 顺序匹配
域名
IP-CIDR
GeoIP
端口
进程
↓ 命中即执行
DIRECT
PROXY
REJECT
RELAY
整条链路在请求发出前完成判定。策略组的内部变化——节点增删、测速结果更新——都不会影响规则的写法， 规则描述的是「意图」，出口负责实现「意图」。
Live Update
订阅换了，服务不用跟着停
规则库在更新，节点在增删，但使用体验不该被一次刷新打断。 配置重载在后台完成，已有连接按新规则继续判定，进程始终在线。
⇅
一键导入
主流订阅格式直接贴入即可识别，节点、策略组、规则一并对齐，不必逐条手抄。
↻
热重载
更新后重新载入配置，服务不中断。切换的瞬间你大概只会察觉策略组里的数字变了。
✎
自定义并存
订阅给的是公共基线，本地可以追加自己的规则。两者共存，更新订阅不会覆盖你的私人条目。
Performance
规则多，不等于响应慢
匹配发生在毫秒级的时间窗口里，但它对整体体验的影响并不小。 引擎在配置载入阶段完成索引与预编译，把逐条扫描的成本压到很低； 真正决定访问速度的，仍然是节点质量与链路状况。
- 载入时预编译：规则结构提前整理，运行期只做必要的比对
- 常见规模从容应对：数千条规则下，判定耗时仍在可忽略的范围
- 开销与规模解耦：常驻内存不随订阅条数线性膨胀
- 空闲时收敛：没有流量就没有额外活动，把资源让给正在做的事
# 让判定更高效的常见做法
rules:
- DOMAIN,api.internal.dev,DIRECT # 具体在前
- DOMAIN-SUFFIX,internal.dev,DIRECT
- RULE-SET,ads,REJECT # 成块引用
- GEOIP,CN,DIRECT
- MATCH,PROXY # 兜底在后
Recipes
几个可以直接照搬的组合思路
规则的价值在于可复用。下面这些组合并不复杂，但足以覆盖大多数日常场景。
①
办公与内网优先
内网域名后缀与私有网段全部直连，其余请求再进入策略组。 结果是内部系统访问不经过任何中转，外部请求该绕行的照旧绕行。
②
按用途拆分工具链
版本控制、包管理器、容器镜像各自绑定合适的出口， 浏览器留给自动测速策略组。开发机上的流量从此各归其位。
③
减负型过滤
广告与追踪域名统一拦截，常用静态资源域名直连。 页面加载少了几次无谓往返，速度提升往往来自「少发了几个请求」。
④
按地区分流
用 GeoIP 与地区规则把请求分开：就近的直连，需要绕行的交给对应地区策略组， 避免所有流量都挤在一条出口上。
Notes
几点需要说清楚的边界
把能力讲清楚，也把不做什么讲清楚——这比堆砌形容词更有用。
◐
它是客户端，不是服务
Clash 自身不提供任何节点与线路。规则和出口都来自你的配置，引擎只负责把两者接起来。
◑
规则需要被维护
域名会变、服务会迁。订阅可以省去大部分精力，但一份完全不管的配置，迟早会与现实脱节。
◒
速度取决于链路
分流能减少无效中转，却不能凭空提升带宽。判定很快，但快不过物理距离和线路质量。
Q & A
关于核心能力，常被追问的几件事
规则匹配支持哪些维度？
常见维度包括域名后缀与关键字、IP-CIDR 网段、GeoIP 地区归属、目标端口、进程名或应用包名、规则集引用等。它们可以单独使用，也可以在同一份配置里组合出现，由引擎按顺序依次判定。
直连、代理、拦截、中继分别是什么？
它们是规则命中后可以执行的动作：直连表示不经过代理出口直接发出；代理表示交由策略组挑选节点；拦截表示在本地终止该请求；中继表示先交给另一段链路再转发。四种动作共用同一套匹配结果，不需要手动切换。
订阅导入后需要重启服务吗？
不需要。规则与节点订阅更新后，引擎重新载入配置即可生效，已有连接按新规则继续判定，服务进程无需中断。
规则很多时会不会变慢？
引擎对规则做了索引与预编译处理，常见规模下匹配开销保持在较低水位。真正影响速度的往往是节点质量，而不是规则条数本身。
能按应用分别走不同出口吗？
可以。在支持的平台上，进程名或应用包名可以作为匹配条件，让浏览器、开发工具、下载器各自使用不同的策略组。
拦截动作会不会误伤正常请求？
拦截遵循规则顺序，只有明确命中的请求才会被终止。建议把拦截规则放在合适的位置，并为未命中请求保留兜底策略，避免出现无归属流量。