Network Kernel · 规则优先
Clash Meta 是以规则为中心的流量分流内核，把「这条连接走哪条线路」写成一读就懂的逻辑。
它不制造节点，也不负责加密。它做的是更关键的事：在每一次连接发生的瞬间，依据可读的规则，从一堆代理与直连中给出唯一的答案。
01它真正解决的问题，是把选择写成可维护的句子
多数分流工具把配置做成一长串判断：条件、动作、例外、再例外。规则一多，谁也不敢改动，因为没人能确定改了会不会牵动别处。Clash Meta 反过来组织：先把出口整理成组，再把判断依据写成规则，最后让规则指向组。三段各自独立，改一处不会波及全局。
这种拆分的价值在于，逻辑从此可以被人读懂，而不只是被内核读懂。你把 GEOSITE 指向「海外媒体」组，而不是指向某个节点的名字，节点换了、订阅更新了，判断依然成立。
规则描述条件，策略描述去向，代理组描述能力。顺序一旦固定，配置就从玄学变回书写。
代理组：可用线路的集合
把同一用途的节点收进一组：自动测速、手动切换、按地区回退。上层只认组的名字，不认具体节点。
规则：判断的唯一依据
DOMAIN、IP-CIDR、GEOSITE、PROCESS-NAME 只是条件的不同写法。规则的先后即优先级，先命中先决定。
策略：命中之后的选择
在某个组、DIRECT 与 REJECT 之间做选择。「不用代理」和「不连接」同样是一等公民，而不是临时例外。
02常见问答
Clash Meta 和原版 Clash 有什么区别？
它是由社区维护的增强分支，通常以 mihomo 之名发布。核心配置逻辑与原版一致，但规则匹配器更丰富、协议支持更广、内存与并发表现更好，并持续跟进上游内核的更新节奏。
规则是不是写得越多越好？
不是。每条规则都有匹配成本，也会增加理解成本。更稳妥的做法是先写少量通用规则，再用日志观察实际走向，只把真正需要的例外补进去。能用一个组解决的问题，不必用十条规则承担。
订阅里的节点总在变，配置怎么应对？
关键是不要在规则里写节点名。规则只指向代理组，节点由订阅填充进组内。这样节点增删、改名、换地区，逻辑层都不需要改动。
手机上能直接用吗？
可以。移动端客户端普遍基于同一内核，配置文件格式通用。为了在手机上更省电，建议把自动测速的间隔调长，并减少大体积规则集的加载。
从一条规则开始，而不是从一百条开始
先让最小的逻辑跑通：一个组、一条规则、一个策略。等你读得懂自己的配置，再考虑规模。