1. 策略组架构模型：为什么需要抽象层？
如果把机场提供的 100 个节点比作 100 名士兵，那么规则（Rules）就是交战防守手册，而**策略组（Proxy Groups）就是这支军队的小队长**。
**传统直连客户端的痛点：**
所有的规则只能硬编码绑定某一个具体的服务器 IP。一旦这个服务器 IP 发生故障或被封锁，你必须手动去修改几十条规则的配置。
**Clash 策略组的革命性解耦：**
1. **面向逻辑编程**：规则条目只关心「谁去处理」（例如 `DOMAIN-SUFFIX,netflix.com,流媒体专属组`）；
2. **策略组内部自由调度**：具体这个组里是用香港节点、新加坡节点，还是自动挑选最低延迟，完全由策略组的内在逻辑自治；
3. **高可用容灾**：当底层节点成批更替时，上层的业务规则纹丝不动。
💡 策略组不仅可以包含具体的节点，还可以包含其他策略组，形成多层嵌套的高级调度拓扑树。
2. 四大核心策略组类型深度拆解与算法对比
深入理解不同策略组的内部算法机制，才能根据业务场景做出最科学的选型：
### 1. select（手动选择模式）
- **调度算法**：纯静态指向。由用户在界面上最后点击的那一个节点作为当前路由目标。
- **优点**：IP 绝对稳定，绝不会因为偶发的网络波动而胡乱跳变地区。
- **缺点**：无容灾能力，该节点一旦故障，流量就会中断，直到用户手动切换。
- **黄金场景**：炒股交易、海外网银登录、ChatGPT 账号防止频繁切 IP 触发风控。
### 2. url-test（自动测速优选模式）
- **调度算法**：内核按照指定的 `interval`（如 300 秒），并发向 `url`（如 `http://www.gstatic.com/generate_204`）发起 HTTP 探测。测量往返时间（RTT），将流量自动调度给延迟最低的节点。
- **容差机制（tolerance）**：当新节点的延迟比当前节点低出超过阈值（如 50ms）时才会切换，防止毫秒级微小波动导致连接频繁跳变。
- **黄金场景**：日常海量网页搜索、YouTube 视频播放。
### 3. fallback（故障转移模式）
- **调度算法**：**严格优先级队列**。组内排在第一位的节点是主力。只要第一位节点探针存活，所有流量 100% 走它；只有当第一位节点探针连续失败时，流量才降级切给第二位；一旦第一位恢复，流量立刻切回！
- **优点**：兼具「IP 稳定性」与「无人值守高可用性」。
- **黄金场景**：企业远程办公、长期挂机服务器、家庭软路由网关。
### 4. load-balance（负载均衡模式）
- **调度算法**：
- `round-robin`（轮询）：连接依次均摊给每个节点；
- `consistent-hashing`（一致性哈希）：同一目标域名或来源 IP 始终路由到同一节点。
- **黄金场景**：多线程下载器并发拉取巨型文件。
yaml
# 生产级四大策略组 YAML 配置代码示范
proxy-groups:
# 1. 手动选择组
- name: "节点选择"
type: select
proxies:
- "香港-IEPL-01"
- "日本-IEPL-01"
- "自动优选"
- "容灾备份"
# 2. 自动测速组
- name: "自动优选"
type: url-test
proxies:
- "香港-IEPL-01"
- "香港-IEPL-02"
- "日本-IEPL-01"
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
# 3. 故障转移组
- name: "容灾备份"
type: fallback
proxies:
- "香港-IEPL-01"
- "新加坡-IEPL-01"
- "美国-备用-01"
url: "http://www.gstatic.com/generate_204"
interval: 1803. 推荐架构：工业级「黄金容灾分流拓扑」
许多新手的配置之所以容易断网，是因为全盘依赖了单一的 `url-test`。
以下推荐经过大型团队实战验证的**「两层高可用分流架构」**：
1. **底层构造两组 Fallback**：
- 组 A：`HK-容灾组`（包含 3 个香港节点，按质量排序）；
- 组 B：`SG-容灾组`（包含 3 个新加坡节点，按质量排序）；
2. **上层构造业务 Select 组**：
- `OpenAI 策略组`：锁定 `SG-容灾组`；
- `默认海外流量`：设为 Select，选项包括 `HK-容灾组` 与 `SG-容灾组`。
**这样设计的极致优势**：
平时你的出口 IP 始终固定在香港 01 节点，IP 绝不跳变；一旦香港 01 机房发生光缆故障，底层 Fallback 在 3 秒内悄无声息切换到香港 02，你甚至连网页刷新都不会察觉，达到金融级的平滑容灾。
💡 tolerance（容差）参数是 url-test 的灵魂，务必设置在 50ms 以上，否则节点会像神经质一样在两三个节点之间来回横跳。
4. 经典策略组异常与死锁排障
### 故障 1：url-test 组全部显示 Timeout
- **根因**：测速探针 URL 设为了 Google 或 Cloudflare，而本地网络对该特定域名的 HTTP 探针存在阻断；或者 `interval` 设置过短（如 5 秒），被探针服务器封禁了 IP。
- **解决**：将 `url` 更换为国内直连友好的可用探针地址，并将 `interval` 放大至 300 秒以上。
### 故障 2：玩游戏时频繁掉线重连
- **根因**：游戏流量被分配给了 `url-test` 自动测速组。在游戏过程中，节点延迟只要发生几毫秒的浮动，策略组就会切断原有 TCP 会话并换用新 IP，导致游戏服务器将你踢下线。
- **解决**：在分流规则中将游戏流量单独分配给一个固定的 `select` 策略组。
text
# 推荐的高稳定性低开销公共测速探针清单
url: "http://cp.cloudflare.com/generate_204"
# 备用探针 1: http://www.gstatic.com/generate_204
# 备用探针 2: http://connectivitycheck.platform.hicloud.com/generate_2045. 策略组的调度上限由后端物理质量决定
策略组是高明的调度算法，但**巧妇难为无米之炊**。
如果你的机场订阅里全部都是廉价直连节点：
- 当晚高峰公网发生整体大拥堵时，组内所有的节点延迟全线飙红，即使 `url-test` 测出延迟最低的一个，丢包率也可能高达 35%，怎么调度都是卡；
- 只有当策略组池子里的节点都是由 **IEPL 物理专线** 构成时，每个备用节点都具备极低丢包和高带宽底线，容灾策略才能发挥出 1+1>2 的震撼威力。
💡 挑选拥有多地独立入口机房的专线机场，能让 Fallback 策略组跨越地域级机房断网风险。
6. 专家级策略组维护准则
1. **组内节点不宜过多**：单个 url-test 组内的节点建议控制在 5~8 个以内，节点过多会导致并发测速时本地瞬时网络拥塞；
2. **区分业务独立设组**：至少将「ChatGPT/AI」「流媒体」「常规浏览」拆分为三个独立策略组；
3. **善用 DIRECT 直连选项**：在海外策略组中保留 DIRECT 选项，方便在节点偶发全挂时一键切换为直连排查。
❓ 常见疑问与排查步骤
自动测速（url-test）会实时消耗很多电脑电量吗？
完全不会。探针测试本质上只是每隔 5 分钟发送几个微小的 HTTP 数据包，耗时不足几十毫秒，CPU 唤醒开销微乎其微，即便在笔记本电池模式下也几乎检测不到电量消耗。
为什么我手动选择了某个节点，过一会儿它自己跳回去了？
检查你的规则是不是命中了包含「url-test」类型的策略组。如果是自动测速组，它的优先级高于手动选择，会周期性覆盖。想完全固定，必须在类型为「select」的策略组中选择。
策略组可以跨多个机场的节点混合调度吗？
完全可以。在 Clash Verge 的规则覆写（Merge）中，可以把机场 A 的专线节点与机场 B 的备用节点放进同一个 Fallback 组中，实现跨服务商的终极冗余容灾。
为什么策略组里有的节点后面带一个锁的图标？
部分客户端主题用锁图标表示该节点属于配置锁定的静态节点，或者属于不允许通过 GUI 修改的外部导入 Provider。
负载均衡（load-balance）玩游戏体验好吗？
极差，严禁在游戏场景使用负载均衡！因为在线游戏依赖单一长连接与固定公网 IP，负载均衡会将数据包散列到不同服务器，导致游戏服务器判定连接异常直接掉线。