策略组是Clash配置的大脑与调度中心。本文通过分层拓扑模型，详细拆解手动选择策略组的语法逻辑、嵌套引用关系以及分流规则的映射机制，并指出三种常见的循环引用配置陷阱。
在许多初学者的认知中，网络代理往往被理解为简单的“选一个节点然后所有流量都走它”。但在现代规则型分流客户端中，决定流量走向的核心并非节点本身，而是位于中枢调度地位的“策略组”（Proxy Groups）。理解策略组的工作原理，是掌握网络流量精细化分流的必经之路。
从架构设计上看，策略组本质上是一个“带调度算法的出口代理池”。在 YAML 配置文件中，每一个策略组都有自己的名字（name）、调度类型（type）以及候选出站列表（proxies）。其中，最常见且最直观的类型便是手动选择组（select）。手动选择组允许用户在客户端图形界面上自由点击切换当前生效的节点，赋予了用户对流量出口的直接控制权。
策略组之所以强大，在于它具备极其灵活的“嵌套引用”能力。一个策略组的候选池中，不仅可以包含物理节点（如“香港 01”、“东京 02”），还可以包含另一个策略组的名字，甚至可以包含内核内置的特殊出站动作（如 DIRECT 直连、REJECT 拒绝）。通过这种嵌套，用户可以构建出极其清晰的层级流量拓扑：
最底层是“物理出口层”，即随便云服务中心提供的具体服务器节点；
中间层是“区域或功能组”，例如我们可以建立一个名为“亚洲区域”的策略组，里面放入香港、日本、新加坡等节点；
再上一层是“场景分流组”，例如专门为视频流媒体、AI 办公工具或代码托管平台建立的特定策略组；
最顶层则是“全局兜底组”（如 PROXY 或漏网之鱼 FINAL）。
当下游的规则引擎（rules）匹配到一个请求时，规则本身并不直接指向某个具体服务器，而是指向某个策略组。例如，规则中写明将特定代码托管网站指派给“开发者专用”策略组，而“开发者专用”策略组内部被用户手动选中了“日本 01”节点。此时，整个请求就会顺着这条清晰的链路完成转发。
为了帮助大家理清策略组与分流规则的衔接，请参考如下典型的分流映射结构：
| 策略组名称 | 策略组类型 | 候选出站成员 (Proxies) | 绑定的典型规则示例 |
|---|---|---|---|
| 节点选择 (PROXY) | select (手动选择) | [自动选择, 区域分组, DIRECT] | 兜底规则 MATCH, 节点选择 |
| 流媒体服务 | select (手动选择) | [香港节点, 台湾节点, 新加坡节点] | DOMAIN-KEYWORD,netflix,流媒体服务 |
| 海外办公与AI | select (手动选择) | [日本节点, 美西节点, 故障回退] | DOMAIN-SUFFIX,openai.com,海外办公与AI |
| 国内直连 (DIRECT) | 内置出站 | 无需配置成员，内核直接放行 | GEOIP,CN,DIRECT |
在配置策略组时，初学者常常踩入以下几类典型陷阱，排查时可对照核对：
第一，循环引用死锁。如果策略组 A 的成员列表中包含了策略组 B，而策略组 B 的成员列表中又包含了策略组 A，内核在初始化解析依赖树时就会陷入死循环并直接崩溃报错。
第二，名称大小写不匹配。YAML 语言对字符串严格区分大小写。如果在 rules 中写的是指向“Proxy”，而在 proxy-groups 中命名的却是小写的“proxy”，客户端将因找不到目标出站而拒绝加载。
第三，引用了不存在的空集合。如果策略组引用的某个 proxy-provider 尚未完成初次网络拉取，或者本地缓存损坏导致可用节点数为零，部分严格校验的内核会抛出“group has no valid proxies”的异常。
通过建立逻辑严密的分层策略组，不仅能让界面的选项井然有序，还能在节点发生调整时，仅需改动底层关联，而无需重写庞杂的分流规则。