Clash 本身不预设任何走向，它只是忠实地执行一份配置文件：proxies 列出所有可用节点，proxy-groups 把这些节点编成可切换的线路组，rules 则逐条判断一个连接该去哪里。规则自上而下匹配，第一条命中的规则立即决定出口，全部落空时由末尾的 MATCH 兜底。换句话说，你看到的每一条连接路径，都是自己写下的结果。
配置的三层：先定节点，再编组，最后写规则
- 01proxies 节点清单。每个条目包含类型、服务器地址、端口与认证信息。这一层只负责"有哪些可用线路"，不关心谁去用。
- 02proxy-groups 线路编组。把节点按用途归类，并决定组内是手动切换、自动测速还是按条件回退。组名是后续规则引用的唯一凭据。
- 03rules 分流规则。以 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP 等类型描述匹配条件，并指定目标组、DIRECT 直连或 REJECT 拦截。
匹配是一次有序扫描，不是择优
很多人以为 Clash 会挑一条"最合适"的规则，实际上它只做一件事：从上往下读，读到第一个满足条件的就停下。所以规则的书写顺序本身就是策略——把高频访问的直连域名放在前面，能减少不必要的判断；把范围过宽的 DOMAIN-SUFFIX 放在前面，则会遮蔽后面所有更精确的条目。写得越具体越靠前，写得越宽泛越靠后，是稳妥的排列习惯。
规则决定方向，分组决定质量
方向与质量是两件事。规则说"这个连接交给「自动选择」组"，而该组内部用什么方法挑节点，由 proxy-groups 的 type 决定：select 完全听你手动拨动，url-test 按延迟自动择优，fallback 则在前者失联时才换下一个。想让关键业务稳定走固定出口，用手动组；想日常浏览省心，用测速组。配置的主动权，就体现在这两层的组合里。
改动之后，记得重载
编辑保存并不等于已经生效，客户端需要重新载入配置文件才会应用新结构。若出现整份配置加载失败，通常不是逻辑写错，而是缩进用了制表符、冒号后缺少空格、或某个组名被规则引用却并不存在。YAML 对格式相当敏感，逐层核对比反复重启更省时间。