搜索 K
深色模式
Clash 策略组配置完全指南：select / url-test / fallback / load-balance 核心机制全解
直接答案：Clash 的策略组（
proxy-groups）是整个路由分流架构的决策大脑。它不负责定义单一连接协议，而是将散落的基础代理节点（Proxies）或外部节点集（Proxy Providers）进行逻辑编排，提供手动切换（select）、最低延迟自动优选（url-test）、可用性故障倒换（fallback）、**多链路负载均衡（load-balance）与多跳链式代理（relay）**五种调度能力。通过自顶向下的分层嵌套，可以构建零感故障自愈与场景精细化路由的高可用网络底座。
一、策略组在 Clash 架构中的核心定位
在 Clash 的分流模型中，流量的处理链路遵循： 入站流量 (Inbound) -> 规则引擎 (Rules) -> 策略组 (Proxy Groups) -> 物理代理节点 (Proxies) -> 出站连接 (Outbound)
如果把规则（Rules）比作路标，把具体节点（Proxies）比作车辆，那么策略组就是调度中枢。配置策略组的核心优势在于：
- 解耦流量类型与物理节点：规则层只需指定分流给
🚀 节点选择或🎬 国际流媒体，无需关心背后具体使用的是香港还是新加坡节点。 - 自动化可用性自愈：利用周期性心跳探测，当某条跨国专线或落地 VPS 发生阻断时，策略组可在数秒内无感切换至备用链路。
- 性能与带宽聚合：结合特定哈希算法，在多个同质节点之间均衡分摊并发连接，榨干本地宽带上限。
二、六大策略组类型深度拆解与参数规范
在 Clash 及 Mihomo（Clash.Meta）生态中，proxy-groups 支持以下核心类型：
策略组类型 (type) | 决策核心机制 | 测速开销 | 典型适用场景 |
|---|---|---|---|
select | 客户端 UI 或 API 纯手动切换 | 无 | 核心出口总控、特殊用途指定节点 |
url-test | 定期并发探测，始终选取延迟最低节点 | 中（并发探测） | 网页轻量浏览、即时通讯工具 |
fallback | 顺序保活探测，仅首选节点宕机才下移 | 低（顺序单探） | 关键长连接业务、API 接口调用 |
load-balance | 基于策略算法将流量分流到多个健康节点 | 中 | 多线程大文件下载、BT/PT、分块拉取 |
relay | 将请求按数组顺序进行流量嵌套链式转发 | 视链长而定 | 落地机前置中转、双重混淆隐藏真实 IP |
pass (Mihomo) | 穿透当前策略组，直通父级或继承行为 | 无 | 动态逻辑分流中间件 |
1. 手动选择组 (select)
最基础也是最核心的交互型组。用户可以在图形客户端界面随时单击切换出站出口。
yaml
- name: "🚀 节点选择"
type: select
proxies:
- "♻️ 自动优选"
- "🇭🇰 香港 IEPL 01"
- "🇯🇵 日本 BGP 01"
- "🇺🇸 美国 4K 01"
- DIRECT- 核心特性：支持将其他策略组（如
♻️ 自动优选）以及内置保留动作（DIRECT,REJECT）作为成员。 - 配置注意：
proxies列表的第一项将作为默认选中项。
2. 最优延迟自动测试组 (url-test)
后台根据配置的测试地址和周期发起并发 HTTP HEAD/GET 探测，根据返回的 RTT 延迟动态指定出口。
yaml
- name: "♻️ 自动优选"
type: url-test
proxies:
- "🇭🇰 香港 IEPL 01"
- "🇭🇰 香港 IEPL 02"
- "🇹🇼 台湾 Hinet 01"
- "🇯🇵 日本 BGP 01"
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
lazy: true关键参数深度说明：
url：测速目标端点。必须是高可用、低开销的全球 CDN 端点，推荐generate_204，避免使用大体积 HTML 页面。interval：心跳探测时间间隔（单位：秒）。常规推荐300（5分钟）。切忌设置为低于 60 秒，否则若节点包含 50 个，将产生巨大的高频握手流量，容易被服务端触发限流甚至封禁。tolerance：延迟容差门限（单位：毫秒）。核心防抖参数！ 设为50意味着如果当前节点延迟为 120ms，而新节点探测为 105ms，由于差值（15ms）小于容差 50ms，系统不会频繁切换连接。这有效防止了因公网链路几十毫秒的自然抖动引发频繁 TCP 重建。lazy：惰性测速。设为true后，仅当该策略组在规则中实际匹配并承载活跃流量时才触发测速，闲置时挂起心跳，大幅节省移动设备电量与节点闲置流量。
3. 故障转移切换组 (fallback)
按 proxies 声明的列表顺序逐级保活。始终优先选用排名最靠前且状态健康的节点；只有当头部节点测速超时或握手失败时，才无缝降级到第二个节点。
yaml
- name: "🛡️ 故障倒换"
type: fallback
proxies:
- "🇭🇰 香港 IEPL 01" # 主线路：低延迟优质专线
- "🇯🇵 日本 BGP 01" # 备用线路 1：高带宽通用节点
- "🇺🇸 美国 4K 01" # 备用线路 2：兜底兜底节点
url: "https://www.gstatic.com/generate_204"
interval: 180
lazy: true- 适用场景：金融交易、远程 SSH 会话、网银登录。这类业务要求 IP 绝对稳定，不能因
url-test几十毫秒的波动而切换出口 IP 导致安全风控强制登出。
4. 负载均衡组 (load-balance)
将匹配到该组的 TCP/UDP 连接依据既定算法分配至多个可用节点，实现带宽的并发叠加。
yaml
- name: "⚖️ 负载均衡"
type: load-balance
strategy: consistent-hashing
proxies:
- "🇭🇰 香港 IEPL 01"
- "🇭🇰 香港 IEPL 02"
- "🇭🇰 香港 IEPL 03"
url: "https://www.gstatic.com/generate_204"
interval: 300strategy 调度算法对比实测：
consistent-hashing（一致性哈希，推荐）：根据请求的目标域名或目标 IP 计算哈希值。相同目标的请求始终走同一个节点。极力推荐此算法，可以避免同一网站的资源请求频繁变换出口 IP 引发账号风控或跨域鉴权失效。round-robin（轮询）：按连接数轮流分发。适合纯大文件下载与无状态抓包爬虫，不适合日常网页浏览。
5. 链式中继代理组 (relay)
将流量按照数组定义的顺序进行顺序握手封装。流量路径为：本地 -> 节点 A -> 节点 B -> 节点 C -> 目标网站。
yaml
- name: "🔗 链式中继"
type: relay
proxies:
- "🇭🇰 香港 IEPL 01" # 第一跳：国内优化的入口跳板
- "🇦🇷 阿根廷 VPS 01" # 第二跳：目标国家本土纯净住宅 IP- 核心价值：突破流媒体锁区或原生 IP 限制。前置节点提供极速国内入口隧道，落地节点提供纯净本土机房 IP，两者优势结合。
三、生产级多层策略组嵌套设计方案 (一手实测数据)
优秀的高可用配置绝不是单一扁平策略组，而是采用四层架构模型：
+-------------------------------------------------------------+
| 第一层：业务分流组 (Business Routing Groups) |
| [PROXY] [OpenAI] [YouTube] [Telegram] [Direct/Domestic] |
+-------------------------------------------------------------+
|
v
+-------------------------------------------------------------+
| 第二层：区域聚合组 (Regional Groups) |
| [香港流量] [日本流量] [美国流量] [台湾/新加坡流量] |
+-------------------------------------------------------------+
|
v
+-------------------------------------------------------------+
| 第三层：调度策略组 (Dispatched Strategy Groups) |
| [HK-自动优选 (url-test)] [HK-故障倒换 (fallback)] |
+-------------------------------------------------------------+
|
v
+-------------------------------------------------------------+
| 第四层：实体节点集 (Proxy Providers / Physical Proxies) |
| [Provider A 节点] [Provider B 节点] |
+-------------------------------------------------------------+完整 YAML 策略组配置实操模板
yaml
proxy-groups:
# ==========================================
# 第一层：业务与总控层
# ==========================================
- name: "🚀 节点选择"
type: select
proxies:
- "♻️ 自动优选"
- "🇭🇰 香港节点"
- "🇯🇵 日本节点"
- "🇺🇸 美国节点"
- "🌐 全部节点"
- DIRECT
- name: "🤖 人工智能"
type: select
proxies:
- "🇺🇸 美国节点"
- "🇯🇵 日本节点"
- "🇸🇬 新加坡节点"
- "🚀 节点选择"
- name: "🎬 国际流媒体"
type: select
proxies:
- "🇭🇰 香港节点"
- "🇹🇼 台湾节点"
- "🇯🇵 日本节点"
- "🚀 节点选择"
# ==========================================
# 第二层：区域聚合与自动优选层 (结合 use 引用 provider)
# ==========================================
- name: "♻️ 自动优选"
type: url-test
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
use:
- default-provider
- name: "🇭🇰 香港节点"
type: url-test
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 30
use:
- default-provider
filter: "(?i)港|hk|hongkong"
- name: "🇯🇵 日本节点"
type: url-test
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 30
use:
- default-provider
filter: "(?i)日|jp|japan"
- name: "🇺🇸 美国节点"
type: url-test
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
use:
- default-provider
filter: "(?i)美|us|united states"
- name: "🌐 全部节点"
type: select
use:
- default-provider四、策略组常见陷阱与故障排查实战
在实机排错过程中，策略组配置错误往往会导致内核静默解析失败或客户端无响应。以下为 4 种典型致命错误与修复对照：
1. 策略组循环引用引发内核死锁 (Fatal Crash)
- 错误表现：Clash 内核启动瞬间退出，日志报错
proxy group cycle detected或陷入死递归栈溢出。 - 错误原因：A 策略组包含了 B 策略组，而 B 策略组的
proxies列表中又声明了 A 策略组。 - 排查方式：检查所有
type: select组，确保层级是严格自顶向下的单向无环图（DAG），严禁相互嵌套。
2. 节点列表为空 (proxies or use is empty)
- 错误表现：内核加载配置时直接抛出
proxy-groups[x]: at least one proxy required异常。 - 错误原因：在定义
filter: "(?i)韩国"时，订阅源中没有任何匹配到“韩国”字样的节点，导致该策略组实际挂载的节点数等于 0。 - 防护方案：在策略组中除了
use以外，显式追加一个兜底节点，例如：yaml- name: "🇰🇷 韩国节点" type: url-test proxies: - "🚀 节点选择" # 当 filter 未命中任何节点时的保底回退 use: - default-provider filter: "(?i)韩|kr|korea"
3. 高频心跳探测风暴与服务风控
- 错误表现：机场账号被服务商封禁，日志提示“短时间内频繁向测速点发起握手”。
- 实测数据对比： 若机场提供 60 个节点，配置了 5 个
url-test策略组，若将interval均设为30且未开启lazy: true：- 测速频次：
60 节点 * 5 策略组 * (3600 / 30) = 36,000 次连接/小时 - 极易触发机场安全风控降速！
- 测速频次：
- 优化方案：开启
lazy: true，将全局测速间隔调整为300秒以上，容差调整为50ms。
五、常见问题解答 (FAQ)
Q1: url-test 与 fallback 策略组有什么本质区别？
A: 核心差异在于触发切换的时机与逻辑：
url-test是比优模式：只要备选节点的延迟比当前节点低（且超出tolerance门限），就会立刻切过去。fallback是保活模式：哪怕备用节点的延迟只有 10ms，而排在第一位的主节点延迟高达 200ms，只要主节点能连通（未超时），系统就绝不切换。仅在主节点断网报错时才降级。
Q2: 为什么我的 load-balance 开启后，网页经常提示“登录失效，请重新登录”？
A: 这是由于采用了默认的 round-robin（轮询）模式。网页前端同时拉取多个图片、API 与静态资源，每次 TCP 请求被分发到了不同的国家或节点 IP，服务端检测到同一个 Session 在数秒内由香港、日本和美国 IP 并发访问，判定为会话劫持并强制踢出。解决方案：将策略组的 strategy 改为 consistent-hashing。
Q3: 策略组中的 proxies 和 use 可以同时存在吗？
A: 完全可以。proxies 用于显式挂载硬编码的单节点或其它策略组（如 DIRECT, REJECT），而 use 用于挂载来自外部订阅的 proxy-providers。在最终运行时，Clash 会将两者的节点集合自动合并。
六、延伸阅读与相关资源
- Clash 配置文件结构详解：宏观七大模块组织规范
- Clash Proxy Provider 配置详解：利用外部 Provider 彻底解耦订阅
- Clash 路由规则字段完全解读：将流量精准命中至目标策略组
- 自建与商业节点配置优选指南：高可用专线节点在多层策略组中的部署实战