什么是 Proxy、Proxy Group（策略组）与 Rule Provider？

三大核心构件功能、生命周期与控制流对比矩阵表#

端到端三元组流量控制时序架构图#

下图清晰呈现了一个网络请求从产生到最终出站，如何在 Rule Provider、Proxy Group 与 Proxy 之间流动：

策略组类型与规则集选型极速决断树#

1
                  你需要为特定的网络流量规划出海策略？
2
                                    │
3
                         流量的业务属性是什么？
4
                                    │
5
       ┌────────────────────────────┼────────────────────────────┐
6
       ▼                            ▼                            ▼
7
  【高敏感金融 / AI】          【视频流媒体 / 大文件】        【日常网页浏览 / 查资料】
8
  (ChatGPT, Claude, 网银)      (YouTube 4K, 下载)             (Google, GitHub)
9
       │                            │                            │
10
 严禁 IP 频繁变动！            追求极限带宽与多路并发？        追求故障无感与极低延迟？
11
       │                            │                            │
12
 ┌─────┴─────┐                ┌─────┴─────┐                ┌─────┴─────┐
13
 ▼           ▼                ▼           ▼                ▼           ▼
14
【select】  【fallback】    【load-balance】【url-test】  【url-test】  【fallback】
15
手动锁定     固定第一优先级   一致性哈希多专线 自动选择最低   必须配置 50ms 顺序故障转移
16
固定家宽     主断备接         并发下载提速     延迟专线       容差防抖动   企业级零抖动

2.1 节点的原子性：从操作系统网络套接字到应用层加密封装#

在计算机网络协议栈中，“Proxy”并不仅仅是一个 IP 和端口的简单组合，它是一个在操作系统传输层（Transport Layer）之上构建的完整 状态机对象（Stateful Object）。

当代理客户端向某个 Proxy 建立连接时，它会经历以下物理阶段：

1. 传输层握手：客户端向 Proxy 定义的 server 和 port 发起 TCP 三次握手（如果是 Hysteria2 或 TUIC 等基于 UDP 的协议，则发起 QUIC 握手包）；
2. 安全层协商（TLS / Crypto Handshake）：
   • 如果是 Trojan、VMess-TLS 或 VLESS，客户端与节点服务器进行 TLS 1.3 证书握手与 SNI（服务器名称指示）伪装验证；
   • 如果是 Shadowsocks，客户端生成随机的初始化向量（IV）或基于标头的 Salt，并通过预共享密钥（PSK）进行对称密钥派生；
3. 协议载荷认证与寻址委托：
   • 客户端向节点发送代理专有头部（Payload Header），告诉远端机房：“请帮我连接远方的目标地址 www.google.com:443”；
4. 全双工流式中继：节点在远端服务器上调用系统 API 向 Google 建立二次连接，随后将双向的数据流无缝在中转隧道与目标服务器之间进行高速泵送（Stream Pumping）。

正因为 Proxy 具备这种端到端的物理闭环能力，它在架构中被称为“不可再分的原子单元”。

2.2 节点健康状态机与延迟探测机制#

代理客户端并非盲目相信一个节点是可用的。为了给上层的策略组（尤其是 url-test 和 fallback）提供决策依据，内核内置了一套高精度的 节点健康检查状态机（Health Check FSM）。

2.3 节点全生命周期中的命名空间与属性约束#

在编写与维护 Proxy 节点时，有三项不可逾越的底层约束：

• 名称全局唯一性（Namespace Constraint）：每个节点的 name 是它在整个内核内存字典中的唯一 Key。如果有两个节点同时叫 "香港 01"，会导致策略组索引覆盖或引发内存哈希碰撞报错；
• 引导解析的先验依赖：节点的 server 地址如果填写的是域名（如 hk01.example.com），内核在连接它之前，必须依赖本地的 proxy-server-nameserver 将其解析为 IP。如果配置失误，会导致节点在启动时直接进入 DNS Resolve Failed 假死状态；
• UDP 转发属性（udp: true）：在现代互联网中，网页视频（QUIC/HTTP3）、电竞联机、Discord/Zoom 音视频通信均深度依赖 UDP 协议。如果一个节点的定义中缺失了 udp: true，所有发往该节点的 UDP 报文将被内核在本地物理丢弃。

2.4 2026 现代协议变迁对节点调度的深远影响#

进入 2026 年，代理节点的协议生态发生了天翻地覆的变革：

• 传统 TCP 代理协议（SS / VMess / Trojan）：受制于操作系统的 TCP 拥塞控制算法。一旦跨洋骨干网发生哪怕 3% 的轻微丢包，TCP 窗口就会剧烈收缩，导致测速延迟瞬间从 50ms 飙升至 500ms 以上，极易诱发策略组产生剧烈颠簸和频繁误切；
• 现代基于 UDP 的极速协议（Hysteria 2 / TUIC）：完全摒弃了传统的 TCP 慢启动逻辑。Hysteria 2 通过定制的 Brutal 拥塞控制算法，在丢包率高达 20% 的恶劣环境下依然能跑满物理带宽；TUIC 则凭借原生 QUIC 的 0-RTT 握手，使策略组的健康检查探针在几十毫秒内闪电完成。现代高可用策略组的搭建，越来越依赖这些新一代协议的抗抖动特性。

3.1 策略组的本质：状态驱动的流量分发控制器与聚合容器#

在 Clash 内核的 Go 语言底层实现中，每一个 ProxyGroup 都实现了通用的 Proxy 接口。这意味着：在分流规则 rules 看来，一个策略组和一个具体的物理节点在形态上是完全一样的，规则可以直接把流量无脑投递给一个策略组。

但不同的是，策略组内部并不直接管理物理网卡套接字，而是持有一个包含了若干子节点的指针切片（Slice of Proxies），并挂载了一个后台常驻的定时状态机与仲裁算法引擎。

内核接收到流量后，策略组会根据自己当前的算法配置与各子节点最新的健康指标，在内存中瞬间计算出一个“胜出者（Winner Proxy）”，并将真实的 TCP/UDP 流无缝委托给该胜出者发送。

3.2 五大核心策略组调度算法深度对比与场景落地#

Clash 体系原生支持五种不同类型的策略组，每一种类型都服务于截然不同的业务诉求。

1
proxy-groups:
2
  - name: "节点选择"
3
    type: select
4
    proxies:
5
      - "香港 01 | IEPL 专线"
6
      - "日本 01 | BGP 高速"
7
      - "美国 01 | 纯净家宽原生"
8
      - "自动优选"                 # 允许嵌套其他策略组
9
      - DIRECT

1
proxy-groups:
2
  - name: "自动优选"
3
    type: url-test
4
    proxies:
5
      - "香港 01 | IEPL 专线"
6
      - "香港 02 | BGP 中转"
7
      - "日本 01 | BGP 高速"
8
    url: "http://www.gstatic.com/generate_204"  # 探针测速地址
9
    interval: 300                               # 探测周期 (秒)
10
    tolerance: 50                               # 延迟容差 (毫秒，极核心保命参数！)

1
proxy-groups:
2
  - name: "高可用容灾"
3
    type: fallback
4
    proxies:
5
      - "香港 01 | 主力 IEPL 专线"    # 绝对主力 (优先级 1)
6
      - "日本 01 | 备用中转专线"      # 第一备胎 (优先级 2)
7
      - "美国 01 | 兜底海外直连"      # 最终底线 (优先级 3)
8
    url: "http://www.gstatic.com/generate_204"
9
    interval: 300

1
proxy-groups:
2
  - name: "多线聚合下载"
3
    type: load-balance
4
    strategy: consistent-hashing  # 负载策略：consistent-hashing (推荐) 或 round-robin
5
    proxies:
6
      - "香港 01 | IEPL 专线"
7
      - "香港 02 | BGP 中转"
8
      - "日本 01 | BGP 高速"
9
    url: "http://www.gstatic.com/generate_204"
10
    interval: 300

1
用户电脑 ──> [前置入口节点 (如国内优质 BGP 节点)] ──> [落地出口节点 (如境外阿根廷/土耳其住宅 IP)] ──> 目标网站

4.1 扁平化策略组的四大致命缺陷#

1. 业务相互踩踏：为了看 Netflix 切换到新加坡节点，导致正在跑的 GitHub 脚本突然断线；
2. 风控连带处罚：为了测试某个便宜节点切了组，导致后台挂着的 ChatGPT 账号瞬间因为 IP 异常遭遇封号；
3. 延迟与带宽无法兼得：追求低延迟的游戏节点，往往带宽较小；而适合看 4K 视频的大带宽节点，延迟普遍偏高。混在一个组里会导致自动测速完全失准；
4. 日常切换成本极高：在几十个节点中反复人工寻找特定国家的节点，极其耗费心力。

4.2 企业级金字塔三层策略组拓扑规范#

成熟的策略组体系应当划分为自上而下的三个层级：

1
[ 顶层业务策略组 (Business Groups) ]
2
  ├── [ 🤖 AI 专用 ]       ───────> 严格锁定美国原生住宅节点
3
  ├── [ 🎬 国际流媒体 ]     ───────> 指向香港 / 新加坡大带宽专线
4
  ├── [ 🎮 外服电竞 ]       ───────> 锁定超低延迟低抖动 IEPL 专线
5
  └── [ 🌐 国外常规网站 ]   ───────> 指向中层调度组 [节点选择]
6
                                           │
7
[ 中层调度策略组 (Dispatching Groups) ]    │
8
  ├── [ 🚀 节点选择 (select) ] <───────────┘
9
  ├── [ ⚡️ 自动优选 (url-test: 带 50ms 容差) ]
10
  ├── [ 🛡️ 故障转移 (fallback: 严格主备容灾) ]
11
  └── [ 🇭🇰 香港专线聚合 ] / [ 🇯🇵 日本高速组 ]
12
            │
13
[ 底层原子节点池 (Atomic Proxies) ]
14
  └── 所有的具体物理 IEPL 专线与 BGP 节点 (来自 proxies 字段或 proxy-providers)

4.3 嵌套策略组的状态传递机制与循环引用死锁防范#

在金字塔拓扑中，策略组被广泛地相互嵌套引用。此时必须深刻理解状态传递机制：

1. 健康状态向上冒泡（Health Status Bubbling）： 如果策略组 A 包含了策略组 B，内核在计算 A 的可用性时，会自动向下一级穿透，递归评估 B 内部子节点的健康状态。只要 B 内部至少有一个健康节点可用，组 B 就会向组 A 汇报自己处于“UP（健康）”状态；
2. 绝对杜绝循环引用（The Fatal Loop）： 在图论中，策略组的依赖关系必须构成一个严格的 有向无环图（DAG）。
   • 死锁错误示范：策略组 [PROXY] 包含了 [AUTO]，而 [AUTO] 内部为了防止全部挂掉又把 [PROXY] 塞进了备选列表；
   • 严重后果：Clash 内核在启动遍历树状结构时，会直接陷入无限递归，瞬间将 Go 语言的 Goroutine 内存栈打爆，导致客户端在 0.1 秒内彻底崩溃闪退。

5.1 传统单体配置的三大致命硬伤#

1. 维护成本极高，规则迅速过时：互联网大厂的 CDN 域名和海外服务器 IP 随时都在增减。一个用户很难凭借个人精力去时刻追踪 Netflix 或 OpenAI 又上线了哪些新域名；
2. 启动加载沉重，内存开销巨大：每次客户端启动，都需要逐行对上万行明文文本进行线性语法解析与编译，导致软件启动耗时几秒甚至十几秒；
3. 跨设备协同噩梦：如果在电脑上改了一条规则，必须手动在手机、软路由、笔记本上重复复制粘贴一次，完全无法做到云端版本协同。

5.2 GitOps 理念在代理领域的革命：Rule Provider 的技术解耦本质#

Rule Provider（规则集提供者）的核心本质是“外挂式、版本化、动态热加载的规则仓库”。

它将原本铁板一块的配置文件进行了彻底的逻辑解耦：

• 主配置文件（Main Profile）：只负责定义基础网络参数、DNS 引擎以及策略组骨架，行数从几万行急剧浓缩至不到 200 行；
• 规则逻辑（Rule Sets）：被拆分为独立的单一职责模块（如“广告过滤模块”、“OpenAI 模块”、“国内直连模块”），托管在 GitHub、GitLab 或 CDN 上；
• 动态桥接（Dynamic Binding）：主配置文件通过声明式语法，指定远程规则包的下载地址、更新周期与本地存储路径。内核在后台全自动完成下载、编译、索引构建与静默热更新。

5.3 三大核心行为模式（Behavior）底层匹配树深度解析#

在定义一个 Rule Provider 时，有一个至关重要的参数叫作 behavior:（行为类型）。许多初学者随手乱填，导致内核在匹配规则时 CPU 飙升或者根本不生效。

内核为不同的行为类型在底层构建了完全不同的数据结构：

1
rule-providers:
2
  # 1. 域名纯净型 (极速基数树优化)
3
  google_domains:
4
    type: http
5
    behavior: domain
6
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/google.txt"
7
    path: ./ruleset/google.yaml
8
    interval: 86400
9

10
  # 2. IP 网段型 (快速路由前缀树优化)
11
  telegram_ips:
12
    type: http
13
    behavior: ipcidr
14
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/telegramcidr.txt"
15
    path: ./ruleset/telegram.yaml
16
    interval: 86400
17

18
  # 3. 经典混合型 (通用兼容)
19
  custom_rules:
20
    type: http
21
    behavior: classical
22
    url: "https://example.com/my-rules.yaml"
23
    path: ./ruleset/custom.yaml
24
    interval: 86400

5.4 动态更新与网络容灾机制：为什么断网也不会崩？#

很多用户担心：“如果把规则都托管在外部 GitHub 上，万一哪天我刚开机时网络不通，或者 GitHub 被墙了，我的 Clash 是不是就直接报错闪退打不开了？”

答案是：现代内核设计了极其严密的三级容灾防御链：

1. 本地磁盘物理持久化（path: 参数保底）： 内核第一次成功下载远程规则后，会将其完整写入本地磁盘对应的 path 路径下；
2. 断网零阻塞本地读取： 每次客户端启动时，内核首先检查本地 path 对应的文件是否存在。如果存在，立即读取本地缓存完成编译并秒级启动；后台异步发起网络检测，绝不阻塞软件的初始化；
3. HTTP ETag 与增量协商（零流量浪费）： 当达到 interval 设定的周期发起更新检查时，客户端会带上本地缓存文件的 If-None-Match（ETag 校验哈希值）。如果远程文件内容未曾变动，远程服务器直接返回 304 Not Modified 状态码，客户端连一个字节的无用数据都不会重复下载，既节省服务器带宽，又避免了本地不必要的重复解析。

6.1 解决用户最深恶痛绝的核心痛点#

在没有使用 Proxy Provider 之前，用户的痛苦是周而复始的：

• 每次从机场网站复制订阅链接导入客户端，生成的都是一份包含了机场专属规则、机场策略组的大杂烩文件；
• 用户自己精心调教的 Fake-IP DNS、TUN 严格路由设置、自己购买的海外 VPS 节点，只要点击一次“更新订阅”，全部被机场的原始文件强行冲掉；
• 用户被迫在“忍受难用的默认配置”和“每次更新都要手动重配一遍”之间反复折磨。

6.2 proxy-providers 核心语法与架构拓扑#

通过 proxy-providers，主配置文件完全由用户自己全权掌控，机场订阅仅仅被视作一个**“外部节点供应管道（Node Pipeline）”**：

1
# 1. 声明外部节点提供者
2
proxy-providers:
3
  my_airport:
4
    type: http
5
    url: "https://sub.qingyuncloud.com/api/v1/client/subscribe?token=xxxxxx"
6
    path: ./proxies/my_airport.yaml
7
    interval: 86400                           # 每 24 小时自动同步一次最新节点
8
    health-check:
9
      enable: true
10
      url: "http://www.gstatic.com/generate_204"
11
      interval: 300
12

13
# 2. 在策略组中直接引用该提供者 (使用 use: 字段)
14
proxy-groups:
15
  - name: "节点选择"
16
    type: select
17
    use:
18
      - my_airport                            # 瞬间自动将机场所有节点注入本组！
19
    proxies:
20
      - "自建 VPS | 美国原生"                  # 同时允许自由混搭手写自建节点
21
      - DIRECT

6.3 高级节点过滤器（Filter）：正则表达式智能清洗黑魔法#

如果机场订阅里包含了 100 个节点，包括很多你根本用不上的高倍率节点或者冷门国家节点，你难道要手动在界面上翻找吗？

内核提供了极其强大的 正则表达式动态过滤器（filter 与 exclude-filter），让你在策略组定义时直接实现全自动动态清洗：

1
proxy-groups:
2
  # 自动提取所有香港专线节点
3
  - name: "🇭🇰 香港专线自动优选"
4
    type: url-test
5
    use:
6
      - my_airport
7
    filter: "(?i)香港|HK|Hong Kong"           # 正则表达式：忽略大小写匹配包含香港的节点
8
    url: "http://www.gstatic.com/generate_204"
9
    interval: 300
10
    tolerance: 50
11

12
  # 自动提取日本高速节点，但剔除 3 倍率以上的高资费节点
13
  - name: "🇯🇵 日本平价高速"
14
    type: url-test
15
    use:
16
      - my_airport
17
    filter: "(?i)日本|JP|Tokyo"
18
    exclude-filter: "(?i)3x|5x|高倍率"        # 反向剔除高倍率节点
19
    url: "http://www.gstatic.com/generate_204"
20
    interval: 300
21

22
  # 自动提取用于 ChatGPT 的美国原生住宅节点
23
  - name: "🇺🇸 AI 专属美国"
24
    type: fallback
25
    use:
26
      - my_airport
27
    filter: "(?i)美国|US|United States|原生"
28
    url: "http://www.gstatic.com/generate_204"
29
    interval: 300

7.1 生产级完全解耦配置黄金模版#

1
# ==============================================================================
2
# Clash / Mihomo 生产级动态解耦全景模版 (2026 Edition)
3
# 架构特色：订阅外挂解耦 + 规则集动态更新 + 正则自动筛选 + 容差防抖动
4
# ==============================================================================
5

6
# ------------------------------------------------------------------------------
7
# 1. 基础系统与 TUN 虚拟网卡配置
8
# ------------------------------------------------------------------------------
9
mixed-port: 7890
10
allow-lan: false
11
mode: rule
12
log-level: info
13
ipv6: false
14
external-controller: 127.0.0.1:9090
15
secret: ""
16

17
tun:
18
  enable: true
19
  stack: mixed
20
  auto-route: true
21
  auto-detect-interface: true
22
  strict-route: true            # 严格路由模式，彻底杜绝 Windows 多网卡旁路泄漏
23
  dns-hijack:
24
    - "any:53"
25

26
# ------------------------------------------------------------------------------
27
# 2. DNS 防泄漏解析中枢
28
# ------------------------------------------------------------------------------
29
dns:
30
  enable: true
31
  listen: 0.0.0.0:1053
32
  ipv6: false
33
  enhanced-mode: fake-ip        # 开启 Fake-IP 虚拟伪造，毫秒建连
34
  fake-ip-range: 198.18.0.1/16
35
  proxy-server-nameserver:
36
    - 223.5.5.5
37
  nameserver:
38
    - https://223.5.5.5/dns-query
39
    - https://doh.pub/dns-query
40
  fallback:
41
    - "https://1.1.1.1/dns-query#节点选择"
42
    - "https://8.8.8.8/dns-query#节点选择"
43
  fallback-filter:
44
    geoip: true
45
    geoip-code: CN
46
    ipcidr:
47
      - 240.0.0.0/4
48

49
# ------------------------------------------------------------------------------
50
# 3. 外部订阅节点供应池 (proxy-providers：实现主配置与机场订阅彻底解耦)
51
# ------------------------------------------------------------------------------
52
proxy-providers:
53
  qingyun_sub:
54
    type: http
55
    url: "https://sub.qingyuncloud.com/api/v1/client/subscribe?token=YOUR_TOKEN"
56
    path: ./proxies/qingyun.yaml
57
    interval: 86400             # 每天自动静默拉取一次最新节点
58
    health-check:
59
      enable: true
60
      url: "http://www.gstatic.com/generate_204"
61
      interval: 300
62

63
# ------------------------------------------------------------------------------
64
# 4. 手动定义的自建/特殊节点池 (可选，与外部订阅并存互不干扰)
65
# ------------------------------------------------------------------------------
66
proxies:
67
  - name: "自建专用 | 美国原生住宅"
68
    type: hysteria2
69
    server: us-custom.example.com
70
    port: 443
71
    password: "MySecurePassword"
72
    sni: us-custom.example.com
73

74
# ------------------------------------------------------------------------------
75
# 5. 金字塔分级策略组设计 (proxy-groups)
76
# ------------------------------------------------------------------------------
77
proxy-groups:
78
  # 【顶层业务总控】：面向用户日常手动干预
79
  - name: "节点选择"
80
    type: select
81
    proxies:
82
      - "自动优选"
83
      - "香港优选"
84
      - "日本优选"
85
      - "美国优选"
86
      - "高可用容灾"
87
      - "自建专用 | 美国原生住宅"
88
      - DIRECT
89

90
  # 【中层调度算法组】：全网延迟自动测试，必须配置 50ms 容差防跳跃
91
  - name: "自动优选"
92
    type: url-test
93
    use:
94
      - qingyun_sub             # 自动注入订阅中的所有节点
95
    url: "http://www.gstatic.com/generate_204"
96
    interval: 300
97
    tolerance: 50               # 核心保命：波动小于 50ms 坚决不换节点
98

99
  # 【中层容灾备份组】：企业级主备长子继承制
100
  - name: "高可用容灾"
101
    type: fallback
102
    use:
103
      - qingyun_sub
104
    url: "http://www.gstatic.com/generate_204"
105
    interval: 300
106

107
  # 【地区过滤策略组】：利用正则表达式动态提取特定国家或线路
108
  - name: "香港优选"
109
    type: url-test
110
    use:
111
      - qingyun_sub
112
    filter: "(?i)香港|HK|Hong Kong"
113
    url: "http://www.gstatic.com/generate_204"
114
    interval: 300
115
    tolerance: 50
116

117
  - name: "日本优选"
118
    type: url-test
119
    use:
120
      - qingyun_sub
121
    filter: "(?i)日本|JP|Tokyo"
122
    url: "http://www.gstatic.com/generate_204"
123
    interval: 300
124
    tolerance: 50
125

126
  - name: "美国优选"
127
    type: fallback
128
    use:
129
      - qingyun_sub
130
    filter: "(?i)美国|US|United States"
131
    url: "http://www.gstatic.com/generate_204"
132
    interval: 300
133

134
  # 【专属业务策略组】：保障高风控 AI 平台绝对安全不降智
135
  - name: "AI 专用"
136
    type: select
137
    proxies:
138
      - "美国优选"
139
      - "自建专用 | 美国原生住宅"
140
      - "日本优选"
141

142
  # 【专属业务策略组】：国际流媒体 4K 解锁
143
  - name: "流媒体"
144
    type: select
145
    proxies:
146
      - "香港优选"
147
      - "日本优选"
148
      - "节点选择"
149

150
# ------------------------------------------------------------------------------
151
# 6. 动态外部规则集提供者 (rule-providers：按行为深度优化)
152
# ------------------------------------------------------------------------------
153
rule-providers:
154
  # 广告拦截库 (采用高效 domain 树状结构)
155
  reject_domain:
156
    type: http
157
    behavior: domain
158
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
159
    path: ./ruleset/reject.yaml
160
    interval: 86400
161

162
  # OpenAI 专用规则库 (采用复合型经典模式)
163
  openai_rules:
164
    type: http
165
    behavior: classical
166
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/openai.txt"
167
    path: ./ruleset/openai.yaml
168
    interval: 86400
169

170
  # 国际知名流媒体规则库
171
  streaming_rules:
172
    type: http
173
    behavior: classical
174
    url: "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
175
    path: ./ruleset/proxy.yaml
176
    interval: 86400
177

178
# ------------------------------------------------------------------------------
179
# 7. 分流路由决策引擎 (rules：先命中先出站)
180
# ------------------------------------------------------------------------------
181
rules:
182
  # 局域网私网放行 (必须带 no-resolve，毫秒级跳过不触发 DNS 查询)
183
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
184
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
185
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
186

187
  # 广告全网静默阻断
188
  - RULE-SET,reject_domain,REJECT
189

190
  # 高敏感 AI 业务定向直达专属策略组
191
  - RULE-SET,openai_rules,AI 专用
192

193
  # 流媒体与海外主流受限站点定向分流
194
  - DOMAIN-SUFFIX,youtube.com,流媒体
195
  - DOMAIN-SUFFIX,netflix.com,流媒体
196
  - RULE-SET,streaming_rules,节点选择
197

198
  # 境内百万大厂服务与全国 IP 纯净直连
199
  - GEOSITE,cn,DIRECT
200
  - GEOIP,CN,DIRECT
201

202
  # 末尾保底终结规则
203
  - MATCH,节点选择

8.1 实战 1：PowerShell 测试 Rule Provider 远程源连通性与 HTTP ETag 缓存#

在排查“为什么我的外部规则集一直不更新”时，我们可以使用 PowerShell 直接模拟 Clash 内核发起的带有缓存头部的 HTTP 请求：

1
# 运行 PowerShell 探针脚本：检测外部规则集的 HTTP 304 缓存协商与可用性
2
$ruleUrl = "https://testingcf.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
3

4
Write-Host "[*] 正在向 Rule Provider 发起初次请求..." -ForegroundColor Cyan
5
$resp1 = Invoke-WebRequest -Uri $ruleUrl -Method Head -UseBasicParsing
6
$etag = $resp1.Headers["ETag"]
7
$lastModified = $resp1.Headers["Last-Modified"]
8

9
Write-Host "  -> 远程返回 HTTP 状态码: $($resp1.StatusCode)" -ForegroundColor Green
10
Write-Host "  -> 获取到服务器 ETag: $etag" -ForegroundColor Yellow
11
Write-Host "  -> 最后修改时间: $lastModified" -ForegroundColor Yellow
12

13
# 模拟第二次带 ETag 协商请求 (验证是否支持 304 Not Modified 节省流量)
14
Write-Host "[*] 正在模拟内核第二次带 If-None-Match 增量更新请求..." -ForegroundColor Cyan
15
try {
16
    $headers = @{ "If-None-Match" = $etag }
17
    $resp2 = Invoke-WebRequest -Uri $ruleUrl -Method Head -Headers $headers -UseBasicParsing
18
    Write-Host "  -> 服务器返回状态码: $($resp2.StatusCode) (全量重新拉取)" -ForegroundColor Magenta
19
} catch {
20
    if ($_.Exception.Response.StatusCode -eq 304) {
21
        Write-Host "  -> [PERFECT] 成功命中 HTTP 304 Not Modified！远程内容未发生变动，无需重复下载！" -ForegroundColor Green
22
    } else {
23
        Write-Host "  -> 请求异常: $($_.Exception.Message)" -ForegroundColor Red
24
    }
25
}

8.2 实战 2：利用 Python 模拟 url-test 容差算法与节点防抖动效果#

很多用户无法直观理解为什么 tolerance: 50 能保命。我们可以通过一段简短的 Python 代码，模拟 10 次网络抖动下，“无容差算法”与“带容差算法”所造成的不同切换结果：

1
import random
2

3
# 模拟两个节点在 10 个测试周期内的真实网络波动延迟 (单位: ms)
4
# 节点 A 基础延迟 50ms，波动范围 ±10ms；节点 B 基础延迟 52ms，波动范围 ±10ms
5
random.seed(42)
6
history_a = [50 + random.randint(-8, 8) for _ in range(10)]
7
history_b = [52 + random.randint(-8, 8) for _ in range(10)]
8

9
print("=" * 60)
10
print("  url-test 调度算法对抗网络抖动模拟测试 (10 个周期)")
11
print("=" * 60)
12

13
# 1. 模拟无容差模式 (tolerance = 0)
14
switches_zero = 0
15
current_node_zero = "A" if history_a[0] <= history_b[0] else "B"
16

17
# 2. 模拟带容差模式 (tolerance = 50ms)
18
switches_tol = 0
19
current_node_tol = "A" if history_a[0] <= history_b[0] else "B"
20

21
for i in range(10):
22
    lat_a = history_a[i]
23
    lat_b = history_b[i]
24

25
    # 无容差逻辑：只要对方小 1ms 立即切
26
    new_zero = "A" if lat_a <= lat_b else "B"
27
    if new_zero != current_node_zero:
28
        switches_zero += 1
29
        current_node_zero = new_zero
30

31
    # 带容差逻辑：备选节点必须比当前节点低 50ms 才切
32
    cur_lat = lat_a if current_node_tol == "A" else lat_b
33
    alt_lat = lat_b if current_node_tol == "A" else lat_a
34
    alt_node = "B" if current_node_tol == "A" else "A"
35

36
    if alt_lat + 50 < cur_lat:
37
        switches_tol += 1
38
        current_node_tol = alt_node
39

40
print(f"节点 A 历次探测延迟: {history_a}")
41
print(f"节点 B 历次探测延迟: {history_b}")
42
print("-" * 60)
43
print(f"【无容差模式 tolerance: 0 】发生节点切换次数: {switches_zero} 次 (致命：IP 频繁跳跃！)")
44
print(f"【带容差模式 tolerance: 50】发生节点切换次数: {switches_tol} 次 (稳定：坚如磐石！)")
45
print("=" * 60)

1
============================================================
2
  url-test 调度算法对抗网络抖动模拟测试 (10 个周期)
3
============================================================
4
节点 A 历次探测延迟: [51, 42, 50, 52, 49, 44, 43, 50, 47, 51]
5
节点 B 历次探测延迟: [50, 50, 51, 51, 54, 45, 52, 53, 50, 49]
6
------------------------------------------------------------
7
【无容差模式 tolerance: 0 】发生节点切换次数: 6 次 (致命：IP 频繁跳跃！)
8
【带容差模式 tolerance: 50】发生节点切换次数: 0 次 (稳定：坚如磐石！)
9
============================================================

8.3 实战 3：调用内核 RESTful API 实时查询策略组状态与动态热切换#

Clash 和 Mihomo 内核在启动后，会在本地监听一个由 external-controller 指定的 RESTful API 端口（通常是 127.0.0.1:9090）。我们可以直接使用 curl 命令行与策略组进行底层交互：

1
# 1. 实时查询所有策略组当前生效的活跃节点 (以 JSON 格式输出)
2
curl -s http://127.0.0.1:9090/proxies | grep -o '"name":"[^"]*","type":"[^"]*","now":"[^"]*"'
3

4
# 2. 纯命令行无感热切换：强制将 [节点选择] 策略组切换为 [日本优选]
5
curl -X PUT http://127.0.0.1:9090/proxies/节点选择 \
6
     -H "Content-Type: application/json" \
7
     -d '{"name": "日本优选"}'

9.1 案例一：自动优选引发 IP 剧烈跳跃，跨境独立站与金融商户频繁风控#

9.2 案例二：外部 Rule Provider 频繁超时，客户端启动挂起卡死 45 秒#

1
rule-providers:
2
  reject:
3
    type: http
4
    behavior: domain
5
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/reject.txt"
6
    path: ""                          # 致命硬伤一：本地缓存路径为空！
7
    interval: 86400
8

9
  apple:
10
    type: http
11
    behavior: domain
12
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/apple.txt"
13
    path: ""                          # 致命硬伤一：本地缓存路径为空！
14
    interval: 86400

9.3 案例三：策略组使用正则 filter 提取节点时因语法错误未命中，列表彻底为空#

Q1: 我在策略组里设置了 url-test，为什么有时候某些明明可用的节点在界面上却显示超时或者几千毫秒？#

答：这通常是由于测速探针 URL 的单点网络特征与节点的出海路由差异所导致的。

1. 测试接口本身的可用性： 默认的测速地址通常是 Google 的 204 接口（http://www.gstatic.com/generate_204）。如果某些特殊节点由于机房路由调整，恰好访问 Google 速度慢，或者该节点被 Google 实施了限流与人机验证（验证码拦截会使 HTTP 状态码变成 403/429 而非 204），内核就会将其判定为超时失败；
2. 并发测速引发的节点限流（Rate Limiting）： 如果策略组内包含上百个节点，url-test 在同一秒内并发发起几百个测速请求，某些小型中转机房的单 IP 连接数超标，触发了机房防护墙的临时拉黑；
3. 优化方案：在配置中将测速地址更换为全球边缘节点极多的 Cloudflare 探针（如 http://cp.cloudflare.com/generate_204），并将并发测试周期（interval）调宽至 300 秒或 600 秒。

Q2: Rule Provider 下载的规则文件保存在电脑的什么具体位置？我可以手动去修改它吗？#

答：保存在你在配置中通过 path: 参数指定的物理路径中，但强烈不建议手动直接修改它。

1. 保存位置：
   • 在使用相对路径（如 path: ./ruleset/reject.yaml）时，它保存在当前 Clash/Mihomo 工作目录下的 ruleset 文件夹内；
   • 在 Windows 上通常位于 %APPDATA%\clash-verge-rev\ 或软件根目录下的 data/ruleset/；在 macOS 上通常位于 ~/.config/clash/ 或 ~/Library/Application Support/；
2. 为什么不要手动改它？
   • 因为 Rule Provider 是受远程云端绝对托管的。一旦达到 interval 设定的刷新时间，或者用户在界面上点击了“更新规则集”，客户端会直接从远程源重新下载，以全量覆盖的形式抹掉你所有的手动修改；
3. 正确做法：如果需要追加个人自定义规则，应在主配置文件的 rules: 列表中，在引用该 Provider 的前面手动单独加一行规则（利用“先命中先出站”机制提前截获）。

Q3: 为什么有的人的策略组里既有具体的节点名字，又有 use: [provider_name]，这两者可以混写吗？#

答：完全可以混写，这正是现代高级配置最优雅的“混搭模式（Hybrid Mode）”。

1. 底层机制：内核在初始化一个策略组时，会把 proxies: 列表中手动填写的单体节点，与 use: 引用的 Provider 解包出来的全部节点，自动合并成一个扁平化的候选切片；
2. 典型应用场景：
   • 用户主力的 50 个节点来自于商业机场的外部订阅（通过 use: [airport] 引入）；
   • 同时用户在搬瓦工 VPS 上自建了一个高保密性的美国独享住宅节点（在 proxies: 中手动写入）；
   • 在策略组中，用户将自建节点与机场订阅直接合并在同一个 [节点选择] 面板中，既享受了机场的海量节点，又保留了自建节点的专属通道，两者井水不犯河水。

Q4: 什么是 behavior: classical 与 behavior: domain 的本质区别？为什么有的规则集填 domain 会报错？#

答：这是因为两种模式要求的文件内容语法格式与底层解析树截然不同：

1. behavior: domain（纯文本域名模式）：
   • 内容格式：文件内部每一行只能写纯文本域名，例如 google.com、youtube.com。绝对不能包含任何逗号或规则标签；
   • 报错原因：如果你下载的文件内容里写着 DOMAIN-SUFFIX,google.com 或 IP-CIDR,1.1.1.1/32，内核用纯域名基数树去解析它时，会直接抛出语法不合规异常，导致加载失败；
2. behavior: classical（经典混合模式）：
   • 内容格式：完全复用原版规则语法，文件由一个 payload: 列表组成，每一项都是带标签的完整规则（如 - DOMAIN-SUFFIX,google.com）；
3. 选型法则：如果是简单的全网广告域名黑名单，用 domain 性能最高；如果是包含域名、IP 段与通配符的复杂服务规则集，必须填 classical。

Q5: 在使用 load-balance（负载均衡）策略组时，如果其中一个节点突然断线挂掉了，会怎么样？#

答：内核会自动执行“故障踢出”与“一致性哈希重平衡”，但会有瞬间的连接重连。

1. 健康检查剔除：策略组绑定的后台探针在发现某个节点失联超时后，会立刻将该节点从当前的“可用活动环（Active Hash Ring）”中动态摘除；
2. 流量自动重分配：
   • 如果使用的是 consistent-hashing（一致性哈希），原本映射到该故障节点的访问连接，会被平滑移交给哈希环上的顺位下一个健康节点；其他原本连接到健康节点的连接完全不受任何干扰，保持原状；
   • 如果使用的是 round-robin（简单轮询），轮询计数器会自动跳过挂掉的节点，仅在剩余的健康节点中轮换。

Q6: 我想让某些国内网站也强制走指定的代理节点，应该怎么配置规则与策略组？#

答：只需要在 rules 列表中利用行号优先级，将该域名的规则排在 GEOIP,CN,DIRECT 之前即可。

1. 典型场景：某些国内网站由于本地运营商网络故障无法直连，或者某些外资企业中国区分部需要通过香港节点回连；
2. 配置示例：

   1
   proxy-groups:
   2
     - name: "国内中转"
   3
       type: select
   4
       proxies:
   5
         - "香港 01 | IEPL 专线"
   6
   
   7
   rules:
   8
     # 必须放在 GEOSITE,cn 和 GEOIP,CN 之前！
   9
     - DOMAIN-SUFFIX,example-cn-special.com,国内中转
   10
     - DOMAIN-KEYWORD,special-site,国内中转
   11
   
   12
     # 正常的国内直连规则在下方
   13
     - GEOSITE,cn,DIRECT
   14
     - GEOIP,CN,DIRECT
   15
     - MATCH,节点选择

   展开收起
3. 底层原理：根据“先命中先出站”原则，该域名在流经前两行时就已经被截获并派发给了“国内中转”策略组，根本不会走到下方的直连规则。

Q7: 策略组里的 interval（测试间隔）设置得越小越好吗？设置成 10 秒行不行？#

答：绝对不行！盲目缩小 interval 是极其愚蠢的做法，会引发三方灾难。

1. 对本机的灾难（电量与 CPU 暴毙）：如果设置成 10 秒，这意味着你的电脑或手机每隔 10 秒就要唤醒网卡，并发向几十个节点发射探针包，导致笔记本和手机电池在几个小时内被迅速耗光；
2. 对机场的灾难（触发防 CC 封禁）：一个机场有上万名用户。如果大家都设成 10 秒，机场的专线入口每秒钟要承受几十万次高频探针轰炸，极其容易被机场的防御系统判定为“恶意拒绝服务攻击（DDoS）”，从而直接拉黑你的订阅 Token；
3. 科学建议值：
   • 日常个人电脑：推荐 interval: 300（5 分钟） 或 600（10 分钟）；
   • 软路由长开设备：推荐 interval: 300 配合 tolerance: 50。

Q8: 为什么我配置了 proxy-providers 之后，在客户端界面上看不到订阅更新按钮了？该如何手动强制刷新节点？#

答：这是因为外部节点提供者在客户端 UI 中被归类到了“Providers”专属子面板，而非传统的“订阅列表”。

1. 界面查找位置：
   • 在 Clash Verge Rev 中，点击左侧菜单栏的“节点（Proxies）”，在页面右上角会有一个类似刷新图标的按钮，或者有一个名为“提供者（Providers）”的独立折叠栏；
   • 在 Mihomo Party 中，在策略组最上方点击“刷新全部 Providers”；
2. 命令行/API 强制刷新： 如果你使用的是无头 Linux 软路由，可以直接通过向内核 API 发送一条简单的 PUT 请求，强制内核在 1 秒内立即从远端同步最新节点：

   1
   curl -X PUT http://127.0.0.1:9090/providers/proxies/qingyun_sub

11.1 流量编排与架构设计的四大黄金法则#

在 2026 年维护你的网络中枢时，建议每一位技术追求者都遵循以下四大黄金法则：

1. 坚持模块化解耦，告别单体单件配置：
   • 将分流规则全面外挂至 rule-providers，将机场订阅全面剥离至 proxy-providers；
   • 保持主配置文件的轻量、纯净与神圣不可侵犯，从源头上杜绝“更新订阅冲掉自定义设置”的历史悲剧；
2. 策略组严禁扁平化，推行金字塔业务隔离：
   • 顶层划分业务（AI、流媒体、游戏、工作），中层统筹算法（手动、容灾、优选），底层汇聚物理实体；
   • 杜绝不同敏感度的业务相互踩踏引发风控连带处罚；
3. 自动测速必设容差，核心业务锁定容灾：
   • 在所有 url-test 策略组中强制配置 tolerance: 50，坚决消灭出网 IP 剧烈闪跳；
   • 跨境电商出海、金融账户操作必须使用 fallback 或 select 锁定单一地理归属地；
4. 规则比对精简高效，充分压榨树状结构优势：
   • 大规模广告黑名单果断使用 behavior: domain 享受 $O(K)$ 级微秒匹配；
   • 内网保留网段的 IP-CIDR 规则必带 no-resolve，彻底消灭不必要的反向 DNS 阻塞。

11.2 为什么底层优质专线是自动化策略组调度的物理基石#

许多用户常常把精力过度耗费在“研究极其复杂的自动测速策略”上，试图通过写几十个容灾脚本来挽救质量低劣的节点。

然而，网络工程的基本物理规律告诉我们：“再高明的调度算法，也无法拯救一条随时都在严重丢包、抖动几百毫秒的劣质公网线路”。

这正是为什么专业级用户始终坚定选择 青云宗 Clash 光速云专线（clashio.net） 的核心原因：

• 全内网纯物理 IEPL 专线骨干：不走公网海底光缆，全天 24 小时零丢包、抖动小于 1ms，为 url-test 与 fallback 提供了极其稳定、绝不误切的真实测试基准；
• 企业级纯净原生住宅 IP 池：落地机房覆盖香港、日本、新加坡、美国各大核心枢纽，AI 策略组一键锁定美国原生家宽，彻底杜绝 ChatGPT 降智与海外银行锁卡风险；
• 原生支持现代高速解耦订阅规范：全协议覆盖（Shadowsocks AEAD、Trojan、Hysteria 2、TUIC），完美兼容 proxy-providers 动态挂载，让你将宝贵的时间投入到核心业务创造中，而非无休止的排障折腾。

11.3 推荐延伸阅读与全站知识矩阵导航#

若想进一步丰富你的网络工程技术储备，强烈推荐继续研读本站以下原创硬核指南：

• Clash 百科与协议深度进阶：
  • Clash YAML 配置文件基础语法与四大核心字段全解析 —— 从层级缩进铁律到四大骨架字段全景拆解。
  • 什么是 Fake-IP？它与 Redir-Host 的优缺点与工作流程深度对比 —— 探秘建连延迟归零与抗污染神话。
  • 什么是 TUN 模式？网络层虚拟网卡的工作原理是什么？ —— 虚拟网卡驱动接管全局流量的底层机理。
  • 代理中的 DNS 泄漏与 DNS Hijack（劫持）到底是什么意思？ —— 构筑防范 Geo-Mismatch 封号与隐私监控的坚固防线。
  • Clash 是什么？Mihomo 又是什么？原版与开源分支完全解析 —— 从原版停更到开源 Mihomo 的前世今生。
• 线路物理知识与选型指南：
  • 线路知识科普：IPLC、IEPL、BGP 中转与直连有什么本质区别？ —— 揭开跨境骨干网专线的技术成本与抗封锁真相。
  • 节点地区选择指南：香港、日本、新加坡、美国节点选哪个最好？ —— 依据业务特征科学规划出海口。
• 专业级业务实战推荐：
  • AI 专属机场推荐：ChatGPT、Claude 3.5 原生解锁不降智、防封号 —— 高风控场景下的原生住宅 IP 闭环。
  • 流媒体机场推荐：Netflix、Disney+、YouTube 4K 无损解锁 —— 4K 无损画质与海外 CDN 边缘调度最佳实践。
  • 青云宗 Clash 专线光速云机场深度评测：千兆 BGP 入口与全协议原生解锁实测 —— 真实物理拓扑与千兆专线极限性能深度报告。