多机场负载均衡与自动切换方案：告别单点故障，永不掉线的代理架构

如果你同时订阅了 2-3 家机场，大概率遇到过这样的场景：

晚高峰机场 A 的香港节点崩了，手忙脚乱切到机场 B
机场 B 的日本线路稳定性好但流媒体解锁不行
机场 A 跑路后用机场 C，发现节点命名乱七八糟
每次换机场都要重新改所有规则，烦不胜烦

这不是你的问题——单机场架构本身就存在天然瓶颈。多机场负载均衡正是为了解决这个问题：不再依赖单一服务商的节点池，而是将多个机场的节点组合成一个”虚拟超级机场”，通过策略组自动分配流量、故障时无缝切换、甚至同时使用多个节点分摊负载。

本文不讲基础概念，假定你已经熟悉 Clash/Mihomo 的基本配置。如果你还在入门阶段，建议先读Clash 配置文件详解再回来看。

一、多机场场景：什么情况下你需要这样做#

多机场不是”越多越好”。每多一个机场，订阅更新、节点命名、协议兼容的维护成本就翻倍。先判断自己属于哪个场景：

1.1 四类典型多机场需求#

场景	核心矛盾	对应方案
可靠性冗余	担心机场跑路/被打/临时维护	fallback 故障切换
性能最大化	不同时段不同机场表现不同	url-test 自动选优
功能互补	机场A解锁好，机场B延迟低	分流规则 + 多策略组
流量分摊	月流量不够用或避免单节点被打满	load-balance 负载均衡

1.2 典型用户画像与架构#

画像一：重度流媒体用户

1
机场A（专线机场，Netflix/Disney+ 解锁稳定）
2
机场B（中转机场，延迟低但解锁不稳定）
3
机场C（廉价机场，流量大但晚高峰拥堵）
4

5
→ 架构：流媒体走 A 固定节点，日常流量走 B(url-test 自动选优)，C 做 fallback

画像二：跨境办公/开发

1
机场A（IEPL/IPLC 专线，延迟<50ms）
2
机场B（普通中转，带宽大）
3
自建 VPS（WireGuard，绝对可控）
4

5
→ 架构：关键业务（API/SSH）走专线 A，大流量下载走 B 的 load-balance，自建做最后兜底

画像三：成本敏感型

1
机场A（大流量套餐，20元/100GB/月）
2
机场B（小流量精品套餐，5元/10GB/月）
3

4
→ 架构：日常浏览走 A（url-test），关键网站走 B 的固定节点。B 用完切 A

1.3 单机场 vs 多机场：横向对比#

维度	单机场	多机场
可靠性	⭐⭐ 跑路=全挂	⭐⭐⭐⭐⭐ 互为冗余
速度	⭐⭐⭐ 看时段	⭐⭐⭐⭐⭐ 自动选最优
维护成本	⭐⭐⭐⭐⭐ 几乎为零	⭐⭐ 需要 Sub-Store
成本	⭐⭐⭐ 可高可低	⭐⭐⭐⭐ 组合性价比
流媒体解锁	⭐⭐⭐ 单一IP池	⭐⭐⭐⭐⭐ 互补
配置复杂度	⭐ 傻瓜式导入	⭐⭐⭐⭐ 需要理解策略组

二、Clash/Mihomo 策略组：负载均衡的核心引擎#

多机场负载均衡的所有魔法，都发生在 Clash/Mihomo 的 proxy-groups 里。说白了就四种类型：

2.1 四种策略组全景对比#

类型	行为	适合场场景	缺点
url-test	定时测速，永远用延迟最低的那个	日常浏览、对延迟敏感的网页	所有流量挤在一个节点上
fallback	按优先级列表，选第一个可用的	主备切换、可靠性优先	不会自动回到更优节点
load-balance	将连接分散到多个节点上	大流量下载、并发请求	可能破坏登录态
select	手动选择	调试、临时指定节点	需要手动操作

这四种不是”该用哪个”的关系，而是组合使用。一个成熟的多机场配置，至少同时用到其中 2-3 种。

2.2 url-test：自动选优，适合日常流量#

url-test 会定期（interval 秒）对所有候选节点做一次 HTTP 探测，然后把延迟最低的那个作为当前活跃节点。所有流量都走这个冠军节点，直到下次探测发现另一个节点更快。

1
proxy-groups:
2
  - name: "🚀 自动选择"
3
    type: url-test
4
    proxies:
5
      - "机场A-香港01"
6
      - "机场A-香港02"
7
      - "机场B-香港01"
8
      - "机场B-香港02"
9
      - "机场B-日本01"
10
      - "机场C-新加坡01"
11
    url: "https://www.gstatic.com/generate_204"
12
    interval: 300          # 每 300 秒（5分钟）测一次
13
    tolerance: 50          # 容差 50ms，避免频繁抖动切换
14
    lazy: true             # 没有流量时不测，省资源

关键参数详解：

参数	推荐值	说明
`interval`	120-600	太短浪费资源且触发机场限速；太长感知故障慢
`tolerance`	30-100	新节点需要比当前节点快至少 X ms 才会切换，防止”乒乓效应”
`lazy`	`true`	没有流量时停止探测，合租路由器的场景建议 `false`
`url`	`https://www.gstatic.com/generate_204`	Google 的 204 空响应端点，轻量可靠。也可用 `http://cp.cloudflare.com/generate_204`

url-test 的”冠军困境”：所有请求都走一个节点，即便其他节点质量相近也在闲置。因此 url-test 最适合”只想要一个最好的出口”的场景。如果想把 3 个香港节点都用起来，需要 load-balance。

2.3 fallback：故障切换，适合关键链路#

fallback 维护一个优先级列表。探测失败（超时/拒绝连接/HTTP 非 2xx）时，自动跳到下一个。它不会回到更高优先级的节点——一旦 Fall 下去了，就在当前位置停留，直到当前节点也挂掉。

1
proxy-groups:
2
  - name: "🛡️ 故障切换"
3
    type: fallback
4
    proxies:
5
      - "机场A-IEPL-香港"      # 首选：专线，延迟最低
6
      - "机场B-中转-香港"       # 第一备用
7
      - "机场B-中转-日本"       # 第二备用
8
      - "机场C-新加坡"          # 兜底
9
    url: "https://www.gstatic.com/generate_204"
10
    interval: 60               # 更短的探测间隔，快速感知故障
11
    lazy: false                # 必须一直探测

fallback 的策略设计原则：

首选节点是”最优”而不是”最快”：稳定性 > 延迟。一个偶尔 30ms 但不稳定的节点，不如长期 50ms 的稳定节点
同地区堆叠优于跨地区：香港备用比日本备用好（延迟更接近，用户体验一致）
兜底必须有：最后一个节点可以是”凑合用”级别的，但不能为空

url-test vs fallback 的实际选择：

场景	用 url-test	用 fallback
日常网页浏览	✅	—
视频会议/直播	—	✅
游戏加速	—	✅
大文件下载	✅	—
API 开发调试	—	✅

一个常见组合：url-test 处理普通流量 + fallback 保护关键链路。在 rules 里按域名分流，关键业务走 fallback 组，其他走 url-test 组。

2.4 load-balance：同时使用多个节点分摊负载#

这是 Mihomo（Clash Meta）特有的能力，原版 Clash 不支持。如果你用 Clash Verge Rev 或 Mihomo Party 等基于 Meta 内核的客户端，可以玩这个。

load-balance 把连接分散到多个节点上，而不是只选一个冠军。Mihomo 支持三种分发策略：

1
proxy-groups:
2
  # 策略一：轮询（round-robin）
3
  - name: "⚖️ 轮询分摊"
4
    type: load-balance
5
    strategy: round-robin
6
    proxies:
7
      - "机场A-香港01"
8
      - "机场A-香港02"
9
      - "机场B-香港01"
10
    url: "https://www.gstatic.com/generate_204"
11
    interval: 300
12

13
  # 策略二：一致性哈希（consistent-hashing）
14
  - name: "🔗 哈希粘滞"
15
    type: load-balance
16
    strategy: consistent-hashing
17
    proxies:
18
      - "机场A-香港01"
19
      - "机场A-香港02"
20
      - "机场B-香港01"
21
    url: "https://www.gstatic.com/generate_204"
22
    interval: 300

策略	行为	优点	缺点	适用场景
round-robin	新连接轮流分配到各节点	流量最均匀	同网站请求可能走不同IP，登录态容易丢	下载、无状态 API
consistent-hashing	同一目标域名始终走同一节点	访问同一网站保持同一出口IP	节点质量不均时部分节点被”困住”	网页浏览、大多数日常场景
sticky-sessions	源IP+目标IP组合哈希	局域网多设备场景更精细	需要更新的 Mihomo 版本	软路由/网关

load-balance 的正确使用姿势：

只放入质量相近的节点：延迟 50ms 的节点和延迟 200ms 的节点放在同一个 load-balance 组里，体验会变成”一半时间快，一半时间慢”
consistent-hashing 是默认首选：避免登录态丢失，同时实现分流
不要把所有流量都走 load-balance：重要业务（支付、银行）走固定节点，普通浏览走 load-balance

1
# 推荐的分层策略组架构
2
proxy-groups:
3
  # 第一层：各类流量入口
4
  - name: "🌐 日常浏览"
5
    type: load-balance
6
    strategy: consistent-hashing
7
    proxies:
8
      - "机场A-香港01"
9
      - "机场A-香港02"
10
      - "机场B-香港01"
11
      - "机场B-香港02"
12
    url: "https://www.gstatic.com/generate_204"
13
    interval: 300
14

15
  - name: "📺 流媒体"
16
    type: url-test
17
    proxies:
18
      - "机场A-美国01"
19
      - "机场A-日本01"
20
      - "机场B-美国01"
21
    url: "https://www.gstatic.com/generate_204"
22
    interval: 300
23
    tolerance: 100
24

25
  - name: "🔒 关键业务"
26
    type: fallback
27
    proxies:
28
      - "自建VPS-WireGuard"
29
      - "机场A-IEPL-香港"
30
      - "机场B-中转-日本"
31
    url: "https://www.gstatic.com/generate_204"
32
    interval: 60
33

34
  # 第二层：总出口
35
  - name: "🚀 最终出口"
36
    type: select
37
    proxies:
38
      - "🌐 日常浏览"
39
      - "📺 流媒体"
40
      - "🔒 关键业务"
41
      - "DIRECT"
42

43
rules:
44
  # 国内直连
45
  - GEOSITE,cn,DIRECT
46
  # 流媒体走流媒体组
47
  - GEOSITE,netflix,📺 流媒体
48
  - GEOSITE,disney,📺 流媒体
49
  - GEOSITE,youtube,📺 流媒体
50
  # 银行/支付走关键业务组
51
  - DOMAIN-SUFFIX,paypal.com,🔒 关键业务
52
  - DOMAIN-SUFFIX,wise.com,🔒 关键业务
53
  # 其余走日常浏览
54
  - GEOSITE,geolocation-!cn,🌐 日常浏览
55
  - MATCH,🚀 最终出口

2.5 如何将多个机场的节点放进策略组#

这是多机场配置的第一个坑：不同机场的订阅格式不同，节点名可能冲突。直接用订阅链接导入 Clash，两个机场的节点被放在各自的 proxies 列表里，策略组引用时必须用节点在各自机场订阅中的完整名称。

方法一：订阅 merge（简单但不够灵活）

大多数 Clash 客户端支持”合并”多个订阅。在客户端添加两个订阅链接，它会自动把两个订阅的 proxies 合并，然后你在 override/mixin 里写策略组引用这些节点名即可。

问题：节点名不可控。机场A叫”香港01”，机场B也叫”香港01”，合并后两个重名节点不可区分。

方法二：Sub-Store 统一管理（推荐）

这正是下一节要讲的内容。Sub-Store 让你在节点进入 Clash 之前就完成重命名、过滤、分组。

三、Sub-Store：多订阅的中央厨房#

Sub-Store 是 GitHub 10K+ stars 的开源订阅管理工具。你可以把它理解为”代理节点的中间件”——多机场的原始订阅进去，经过过滤、重命名、排序、组合，输出一个你完全可控的统一订阅。

3.1 Sub-Store 核心能力#

1
机场A订阅（Clash格式，100个节点）
2
机场B订阅（sing-box格式，50个节点）
3
机场C订阅（V2Ray格式，30个节点）
4
自建节点（ss:// 链接）
5
          ↓
6
      Sub-Store 中央处理
7
  ┌───────┼───────┬──────────┐
8
  正则过滤  批量重命名  格式转换  脚本操作
9
          ↓
10
   统一订阅 URL（目标格式：Clash / sing-box / Surge）

3.2 部署 Sub-Store（Vercel 方式，5分钟）#

Fork 仓库：github.com/sub-store-org/Sub-Store
用 Vercel 账号 Import 你 Fork 的仓库
Environment Variables 添加：
- SUB_STORE_FRONTEND_BACKEND_PATH = 一个随机字符串（如 mybackend2026）
Deploy。完成后访问 https://your-name.vercel.app/mybackend2026

Docker 部署（推荐自托管）：

1
docker run -d \
2
  --name sub-store \
3
  -p 3001:3001 \
4
  -e SUB_STORE_FRONTEND_BACKEND_PATH=/mybackend \
5
  -v ./sub-store-data:/opt/app/data \
6
  xream/sub-store

3.3 多机场订阅配置实战#

进入 Sub-Store Web UI 后，操作流程分三步：

步骤一：添加上游订阅

在”订阅”页面添加每个机场的原始订阅链接。Sub-Store 自动识别格式（Clash / sing-box / V2Ray 等）。对于自建节点，可以用”手动输入”模式粘贴 ss:// 或 vless:// 链接。

步骤二：创建组合订阅

新建一个”组合订阅”，把步骤一里所有的上游订阅拖入。关键在于节点操作：

1
// 脚本操作：批量重命名节点
2
// 把机场杂乱的节点名统一为"机场名-地区-序号"格式
3

4
const airportPrefix = {
5
  'https://sub.airport-a.com': 'A',
6
  'https://sub.airport-b.com': 'B',
7
  'https://sub.airport-c.com': 'C',
8
};
9

10
// 正则重命名
11
// 将"香港 01 | 1x IEPL" → "A-HK-01"
12
// 将"Japan-Tokyo-Node3" → "B-JP-03"

Sub-Store 支持的节点操作：

操作类型	功能	多机场场景应用
正则过滤	保留/剔除匹配的节点	只保留香港/日本/美国节点，滤掉低质量地区
正则重命名	按规则批量改名	统一”机场A-香港01”的格式，消除命名混乱
排序	按名称/延迟排序	把延迟低的节点排前面，url-test 候选列表更合理
旗帜操作	添加/移除国旗 Emoji	🇭🇰 🇯🇵 🇺🇸 可视化更友好
脚本操作	自定义 JS 处理	复杂的节点筛选和重命名逻辑

步骤三：生成输出订阅

选择目标格式（Clash.Meta / sing-box / Surge / Shadowrocket），Sub-Store 生成一个订阅链接。把这个链接导入你的客户端，就拿到了一个整合多机场的干净节点列表。

3.4 覆写配置：把 Sub-Store 输出变成完整配置#

Sub-Store 生成的订阅只包含节点信息（proxies），不包含规则（rules）和策略组（proxy-groups）。你需要自己写覆写配置：

1
# override.yaml — 你的覆写配置
2
# 这段配置会和 Sub-Store 输出的节点列表合并，生成完整 Clash 配置
3

4
proxy-groups:
5
  - name: "🚀 自动选择"
6
    type: url-test
7
    # 使用正则匹配 Sub-Store 重命名后的节点
8
    use:
9
      - "订阅组合名"
10
    filter: "HK|JP"
11
    url: "https://www.gstatic.com/generate_204"
12
    interval: 300
13
    tolerance: 50
14

15
rules:
16
  - GEOSITE,category-ads-all,REJECT
17
  - GEOSITE,cn,DIRECT
18
  - GEOSITE,geolocation-!cn,🚀 自动选择
19
  - MATCH,DIRECT

社区现成的覆写脚本（直接引用，省去自己写）：

powerfullz/override-rules：支持 JS 动态覆写，自动识别节点国家地区生成对应策略组，参数化开启 load-balance/landing/IPv6
使用方式：在 Sub-Store 的脚本操作中填入 https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#loadbalance=true

3.5 Sub-Store 多端分发#

Sub-Store 最大的价值之一是不同设备输出不同格式：

设备	客户端	目标格式	特殊要求
Windows/macOS	Clash Verge Rev / Mihomo Party	Clash.Meta	全协议支持
iOS	Shadowrocket	Shadowrocket	过滤 iOS 不支持的协议
iOS	Stash	Clash.Meta	Stash 兼容 Meta 格式
iOS	Surge	Surge	用 Sub-Store 转换
路由器	OpenClash	Clash.Meta	精简节点数

关键是：同一个组合订阅，针对每个设备生成不同格式的订阅链接。机场换节点了？Sub-Store 刷新就行，所有设备的订阅链接自动更新。

四、Sing-box 多出站负载均衡#

如果你已经从 Clash 迁移到 Sing-box（参考 Sing-box 1.12+ 迁移指南），多机场的玩法略有不同但同样强大。

4.1 Sing-box 的策略出站类型#

Sing-box 在 outbounds 里支持以下类型实现多节点管理：

类型	行为	对应 Clash 策略组
`urltest`	定时测速选最优	url-test
`selector`	手动选择	select
`direct`	直连	DIRECT

注意：截至 Sing-box 1.14，原生不支持 fallback 和 load-balance。但可以通过”selector + 手动”或借助第三方工具实现。

4.2 Sing-box urltest 配置#

1
{
2
  "outbounds": [
3
    {
4
      "type": "urltest",
5
      "tag": "auto-select",
6
      "outbounds": [
7
        "机场A-香港01",
8
        "机场A-香港02",
9
        "机场B-香港01",
10
        "机场B-日本01"
11
      ],
12
      "url": "https://www.gstatic.com/generate_204",
13
      "interval": "5m",
14
      "tolerance": 50,
15
      "idle_timeout": "30m"
16
    },
17
    {
18
      "type": "selector",
19
      "tag": "final-out",
20
      "outbounds": ["auto-select", "机场A-IEPL-香港", "direct"],
21
      "default": "auto-select"
22
    }
23
  ]
24
}

Sing-box urltest 参数：

参数	推荐值	说明
`interval`	`3m` ~ `10m`	时间格式字符串
`tolerance`	`50`	容差（ms）
`idle_timeout`	`30m`	空闲多久后停止探测
`interrupt_exist_connections`	`false`	切换后是否断开已有连接

4.3 模拟 fallback：嵌套 urltest#

Sing-box 不支持原生 fallback，但可以变通：

1
{
2
  "outbounds": [
3
    {
4
      "type": "selector",
5
      "tag": "primary",
6
      "outbounds": ["机场A-IEPL-香港", "机场A-中转-香港"],
7
      "default": "机场A-IEPL-香港"
8
    },
9
    {
10
      "type": "urltest",
11
      "tag": "fallback-auto",
12
      "outbounds": [
13
        "机场B-香港01",
14
        "机场B-日本01",
15
        "机场C-新加坡"
16
      ],
17
      "url": "https://www.gstatic.com/generate_204",
18
      "interval": "3m"
19
    },
20
    {
21
      "type": "selector",
22
      "tag": "backup",
23
      "outbounds": ["机场C-香港", "机场C-日本"],
24
      "default": "机场C-香港"
25
    }
26
  ]
27
}

逻辑：日常用 auto-select urltest；如果 urltest 里的节点全挂了，切到 backup selector。不过 Sing-box 的 urltest 在全部候选节点不可用时会 fallback 到第一个节点（可能也挂了），不是真正意义上的”自动 skip 到备用组”。

4.4 Easy Proxies：基于 Sing-box 的节点池管理工具#

如果你需要真正的故障转移 + 负载均衡，可以上 Easy Proxies（GitHub 开源）。它在 Sing-box 之上封装了：

Pool 模式：统一入口端口，自动故障转移、黑名单管理
多端口模式：每个节点分配独立端口
Web 管理面板：实时延迟、连接数、失败次数、一键导出
订阅自动刷新：支持 Base64 / Clash YAML / 纯文本订阅

1
# Easy Proxies config.yaml
2
mode: pool
3
listener:
4
  address: 0.0.0.0
5
  port: 2323
6
pool:
7
  mode: sequential
8
  failure_threshold: 3      # 连续失败3次拉黑
9
  blacklist_duration: 24h   # 拉黑24小时后自动恢复
10
nodes:
11
  - uri: "vless://[email protected]:443#A-HK-01"
12
  - uri: "hysteria2://[email protected]:443#B-HK-01"
13
subscription_refresh:
14
  enabled: true
15
  interval: 1h

客户端统一连接 http://127.0.0.1:2323，Easy Proxies 自动在节点池中分配健康的节点。

五、自动故障检测与健康检查#

负载均衡和故障切换都依赖健康检查。如果检查机制不可靠，策略组再漂亮也是空中楼阁。

5.1 故障检测的三个层级#

层级	检测方式	检测时间	适用
TCP 连接	`connect()` 是否成功	秒级	基础可用性
HTTP 探测	HTTP GET 是否返回 2xx	需完整握手	代理链路是否通畅
应用层验证	实际流量成功	分钟级	最终兜底

Clash/Mihomo 和 Sing-box 的 urltest/fallback 都是在**第二层（HTTP 探测）**工作。通过向 url 指定的端点发送 HTTP GET，验证代理链路是否正常工作。

5.2 探测端点选择#

端点	优点	缺点
`https://www.gstatic.com/generate_204`	Google 服务，全球就近	部分地区不可达
`http://cp.cloudflare.com/generate_204`	Cloudflare 全球网络	可能被机场误伤
`http://www.apple.com/library/test/success.html`	Apple CDN	部分机房 Apple 走特殊路由
自建端点	完全可控	需要维护

建议：至少准备两个探测端点。如果在 Mihomo，可以创建两个 url-test 组分别探测不同端点，然后取交集。

5.3 Mihomo 健康检查的高级参数#

1
proxy-groups:
2
  - name: "auto"
3
    type: url-test
4
    proxies: [...]
5
    url: "https://www.gstatic.com/generate_204"
6
    interval: 300
7
    tolerance: 50
8
    lazy: true
9
    # Mihomo 特有参数
10
    max-failed-times: 5     # 连续失败N次后标记为不可用
11
    # 注意：此参数在不同版本位置可能不同，以 Mihomo 官方文档为准

5.4 避免”探头风暴”#

如果你有 3 个策略组，每个有 20 个候选节点，每 300 秒探测一次，那就是每分钟 12 次 HTTP 请求。这在流量计费的机场上累积成可观的消耗。

优化建议：

lazy: true：没有活跃流量时不探测
增大 interval：日常浏览 600 秒就够了
减少候选节点：url-test 里放 5-10 个精品节点，不需要把 50 个全放进去
探测端点用 HEAD 而非 GET：减少响应体传输

六、分流策略：三维智能分配#

多机场的真正威力不在于”有更多节点可选”，而在于按场景匹配最优节点。

6.1 延迟维度：url-test 基础分流#

最简单的自动路由。所有流量走当前延迟最低的节点。

1
日常浏览 → url-test（所有可用节点的延迟冠军）

这适合 80% 的日常场景，但不够精细。

6.2 地区维度：GEOIP/GEOSITE 规则分流#

1
rules:
2
  # 国内直连
3
  - GEOSITE,cn,DIRECT
4
  - GEOIP,CN,DIRECT
5

6
  # 日本服务走日本节点
7
  - GEOSITE,jp,🇯🇵 日本节点
8

9
  # 美国服务和流媒体走美国节点
10
  - GEOSITE,netflix,🇺🇸 流媒体
11
  - GEOSITE,disney,🇺🇸 流媒体
12
  - GEOSITE,hbo,🇺🇸 流媒体
13

14
  # Google/YouTube 走最优节点
15
  - GEOSITE,google,🚀 自动选择
16
  - GEOSITE,youtube,🚀 自动选择
17

18
  # OpenAI/Anthropic 走专线
19
  - GEOSITE,openai,🔒 关键业务
20

21
  # 其余海外走自动选择
22
  - GEOSITE,geolocation-!cn,🚀 自动选择
23

24
  - MATCH,DIRECT

6.3 协议维度：UDP/TCP 分流#

某些机场的 UDP 转发很差（影响 QUIC/HTTP3 和游戏），可以配置：

1
proxy-groups:
2
  - name: "🎮 游戏加速"
3
    type: url-test
4
    proxies:
5
      - "机场A-UDP-香港"
6
      - "机场B-UDP-日本"
7
    url: "https://www.gstatic.com/generate_204"
8
    interval: 120
9
    tolerance: 30

Mihomo 支持按端口或应用分流：

1
rules:
2
  # 游戏端口走游戏加速组
3
  - DST-PORT,27015-27050,🎮 游戏加速
4
  - DST-PORT,25565,🎮 游戏加速
5
  # Discord 语音
6
  - DST-PORT,50000-65535,🎮 游戏加速

6.4 三段式分流架构#

结合以上三个维度，推荐的成熟架构：

1
                     ┌────────────────────────┐
2
                     │     DNS 解析层           │
3
                     │  (fake-ip 或 redir-host) │
4
                     └───────────┬────────────┘
5
                                 │
6
                     ┌───────────▼────────────┐
7
                     │   规则匹配层             │
8
                     │  GEOSITE/GEOIP/DOMAIN   │
9
                     └───┬───────┬───────┬────┘
10
                         │       │       │
11
              ┌──────────▼┐ ┌────▼──┐ ┌──▼──────────┐
12
              │ 流媒体组    │ │日常组  │ │ 关键业务组    │
13
              │ url-test   │ │load-  │ │ fallback     │
14
              │ 美国/日本   │ │balance│ │ 自建→专线→备用│
15
              └────────────┘ └───────┘ └──────────────┘

6.5 完整多机场配置模板#

下面是一份可以直接套用的 Mihomo 多机场配置模板：

1
# Mihomo 多机场配置模板
2
# 将节点名替换为 Sub-Store 统一格式化后的名称
3

4
mixed-port: 7890
5
allow-lan: false
6
mode: rule
7
log-level: info
8
external-controller: 127.0.0.1:9090
9

10
dns:
11
  enable: true
12
  prefer-h3: true
13
  nameserver:
14
    - https://dns.alidns.com/dns-query
15
    - https://doh.pub/dns-query
16
  fallback:
17
    - https://1.1.1.1/dns-query
18
    - https://8.8.8.8/dns-query
19
  fallback-filter:
20
    geoip: true
21
    geoip-code: CN
22

23
proxy-groups:
24
  # ====== 第二层：功能分组 ======
25
  - name: "🌐 日常浏览"
26
    type: load-balance
27
    strategy: consistent-hashing
28
    proxies:
29
      - "A-HK-01"
30
      - "A-HK-02"
31
      - "B-HK-01"
32
      - "B-HK-02"
33
    url: "https://www.gstatic.com/generate_204"
34
    interval: 300
35

36
  - name: "📺 流媒体"
37
    type: url-test
38
    proxies:
39
      - "A-US-LAX"
40
      - "A-JP-Tokyo"
41
      - "B-US-01"
42
      - "B-JP-01"
43
    url: "https://www.gstatic.com/generate_204"
44
    interval: 300
45
    tolerance: 100
46

47
  - name: "🤖 AI服务"
48
    type: url-test
49
    proxies:
50
      - "A-US-LAX"
51
      - "B-US-01"
52
      - "C-US-01"
53
    url: "https://www.gstatic.com/generate_204"
54
    interval: 120
55
    tolerance: 30
56

57
  - name: "🔒 关键业务"
58
    type: fallback
59
    proxies:
60
      - "自建VPS-WG"
61
      - "A-IEPL-HK"
62
      - "B-IEPL-JP"
63
      - "C-DIRECT"
64
    url: "https://www.gstatic.com/generate_204"
65
    interval: 60
66

67
  - name: "🎮 游戏加速"
68
    type: url-test
69
    proxies:
70
      - "B-JP-01"
71
      - "B-SG-01"
72
      - "C-JP-01"
73
    url: "https://www.gstatic.com/generate_204"
74
    interval: 120
75
    tolerance: 20
76

77
  # ====== 第一层：总入口 ======
78
  - name: "🎯 策略总入口"
79
    type: select
80
    proxies:
81
      - "🌐 日常浏览"
82
      - "📺 流媒体"
83
      - "🤖 AI服务"
84
      - "🔒 关键业务"
85
      - "🎮 游戏加速"
86
      - "DIRECT"
87

88
rules:
89
  # 广告屏蔽
90
  - GEOSITE,category-ads-all,REJECT
91

92
  # 国内直连
93
  - GEOSITE,cn,DIRECT
94
  - GEOIP,CN,DIRECT
95

96
  # AI 服务
97
  - GEOSITE,openai,🤖 AI服务
98
  - GEOSITE,anthropic,🤖 AI服务
99

100
  # 流媒体
101
  - GEOSITE,netflix,📺 流媒体
102
  - GEOSITE,disney,📺 流媒体
103
  - GEOSITE,hbo,📺 流媒体
104
  - GEOSITE,youtube,📺 流媒体
105
  - GEOSITE,spotify,📺 流媒体
106

107
  # 关键业务（支付/银行/开发工具）
108
  - DOMAIN-SUFFIX,paypal.com,🔒 关键业务
109
  - DOMAIN-SUFFIX,wise.com,🔒 关键业务
110
  - DOMAIN-SUFFIX,github.com,🔒 关键业务
111
  - DOMAIN-SUFFIX,gitlab.com,🔒 关键业务
112
  - DOMAIN-SUFFIX,docker.com,🔒 关键业务
113

114
  # Google/Microsoft 服务走日常浏览
115
  - GEOSITE,google,🌐 日常浏览
116
  - GEOSITE,microsoft,🌐 日常浏览
117

118
  # 其余海外
119
  - GEOSITE,geolocation-!cn,🌐 日常浏览
120

121
  - MATCH,DIRECT

七、iOS 平台多机场方案#

iOS 生态的多机场玩法和桌面端略有不同。四大客户端的支持情况：

7.1 各客户端支持对比#

客户端	url-test 等价	fallback 等价	load-balance	多订阅原生支持
Surge	`url-test` 策略组	`fallback` 策略组	❌	✅ 多个 policy-path
Quantumult X	`url-latency-benchmark`	`available`	`round-robin`	✅ 多个 server_local
Loon	`url-test`	`fallback`	❌	✅ 多个订阅
Shadowrocket	`url-test`	❌	❌	❌ 需 Sub-Store 合并
Stash	`url-test`	`fallback`	`load-balance`	✅ (兼容 Clash)

7.2 Surge 多机场配置#

Surge 支持 policy-path 引入外部策略文件，多机场场景用多个 policy-path 分别引入，然后在策略组中引用。

1
[Proxy]
2
# 机场A
3
#!include = https://sub.airport-a.com/surge
4
# 机场B
5
#!include = https://sub.airport-b.com/surge
6

7
[Proxy Group]
8
# URL测试：选延迟最低的
9
Auto = url-test, policy-path=https://sub.airport-a.com/surge, policy-path=https://sub.airport-b.com/surge, url=https://www.gstatic.com/generate_204, interval=300, tolerance=50
10

11
# 故障转移：主→备→兜底
12
Fallback = fallback, A-IEPL-HK, B-IEPL-JP, C-SG-01, url=https://www.gstatic.com/generate_204, interval=60
13

14
# 手动选择（兜底）
15
Final = select, Auto, Fallback, DIRECT
16

17
[Rule]
18
# 使用 Final 或具体策略组
19
GEOIP,CN,DIRECT
20
FINAL,Final

7.3 Quantumult X 多机场配置#

1
[server_local]
2
# 机场A节点
3
# 机场B节点
4

5
[policy]
6
# URL 延迟测试
7
url-latency-benchmark=Auto, server-tag-regex=(A-HK|B-HK), check-interval=300, alive-checking=false, tolerance=50
8

9
# 故障转移（available）
10
available=Fallback, A-IEPL-HK, B-IEPL-JP, img-url=system
11

12
# 负载均衡（round-robin）
13
round-robin=LB, A-HK-01, A-HK-02, B-HK-01, B-HK-02
14

15
# 静态策略组
16
static=Final, Auto, Fallback, LB, direct, reject
17

18
[filter_remote]
19
# 分流规则
20
https://raw.githubusercontent.com/.../China.list, tag=China, force-policy=direct, enabled=true
21
https://raw.githubusercontent.com/.../Global.list, tag=Global, force-policy=Final, enabled=true

Quantumult X 的优势是原生支持 round-robin 负载均衡，在 [policy] 中用 round-robin= 声明即可。

7.4 Loon 多机场配置#

Loon 与 Surge 语法接近，url-test 和 fallback 直接支持：

1
[Proxy]
2
# 从多个订阅导入
3

4
[Proxy Group]
5
# URL 测试
6
Auto = url-test, select=0, include-all, include-other-group=HK-Nodes, url=https://www.gstatic.com/generate_204, interval=300, tolerance=50
7

8
# 故障转移
9
Fallback = fallback, A-IEPL-HK, B-IEPL-JP, url=https://www.gstatic.com/generate_204, interval=60

7.5 统一方案：Sub-Store 作为 iOS 多机场中枢#

不管用哪个 iOS 客户端，最省心的方案都是 Sub-Store 预处理 + 各客户端订阅：

Sub-Store 整合所有机场 → 输出多个目标格式的订阅
每个 iOS 客户端用 Sub-Store 生成的专属订阅
机场变动 = Sub-Store 刷新一次，所有设备自动同步

Shadowrocket 用户尤其需要 Sub-Store，因为它不支持多订阅直接合并。

八、成本优化：花最少的钱获得最好的体验#

多机场的目的不是多花钱，而是花合理的钱获得更好的体验。

8.1 机场类型搭配策略#

搭配方案	组合	月费	适合人群
高低搭配	1个精品专线 + 1个廉价中转	¥15-40	日常用户
双保险	2个同档次中转机场	¥20-50	对可靠性要求高的用户
全能型	1专线 + 1中转 + 1流媒体专用	¥30-80	重度流媒体+办公
自建兜底	1机场 + 自建VPS	¥15-30 + VPS费	有技术能力的用户

8.2 流量分配策略#

若机场A每月100GB（¥20）、机场B每月50GB（¥10）：

1
# 70GB 给机场A（日常浏览），30GB 给机场B（关键业务）
2
# 当机场A快用完时，切换更多流量到机场B
3

4
# 可以通过 Mihomo 的"流量统计"面板监控各节点用量
5
# 配合手动切换控制流量分配

8.3 避坑指南#

不要同时订阅3家以上廉价机场：维护成本远超省下的钱
同一家机场的多个套餐不是”多机场”：底层是同一条线路
注意协议兼容性：有的机场只提供 SS/V2Ray，你的客户端用的是 Sing-box/Hysteria2，协议不匹配
订阅刷新频率不要太快：每 6-12 小时刷新一次足够，频繁请求可能被机场封 IP
自建 VPS 当最后兜底：花 ¥30/月在 BandwagonHost 上搭一个 WireGuard，所有机场都挂了还能用

九、常见问题与调试方法#

9.1 “设了 url-test 为什么还是不会自动切换？”#

检查清单：

rules 里的 MATCH 或对应规则是否指向了策略组名称，而不是具体节点名？
策略组名称拼写是否大小写完全一致？（YAML 大小写敏感）
lazy: true 时，当前没有流量就不会触发探测——手动访问一个网页触发
探测 URL 在节点上是否能正常访问？（换 http://cp.cloudflare.com/generate_204 试试）

9.2 load-balance 导致登录态丢失#

原因：strategy: round-robin 下，每次请求可能走不同节点（不同 IP），服务器识别为”异常登录”，触发二次验证。

解决：改用 strategy: consistent-hashing，同一域名始终走同一节点。

9.3 策略组嵌套导致”迷路”#

1
# ❌ 错误：Fallback 嵌套在 url-test 里
2
- name: "outer"
3
  type: url-test
4
  proxies: ["inner-fallback"]
5

6
- name: "inner-fallback"
7
  type: fallback
8
  proxies: ["node1", "node2"]

url-test 只做延迟探测，不会递归探测嵌套策略组里的节点。策略组嵌套时，外层只把内层策略组当作”一个整体”。

9.4 查看实际流量走向#

Mihomo（Clash Verge Rev）提供了详细的连接日志：设置 → 连接 面板。每条连接显示：

目标域名/IP
匹配到的规则
实际使用的节点
上行/下行速度

如果发现”设置了规则但流量还是走了不期望的节点”，先看连接面板确认命中的是哪条规则，再调整规则顺序。

十、总结：从单点到多机场的进化路线#

阶段	架构	可靠性	复杂度	何时升级
Level 1	单机场默认订阅	★★	极低	—
Level 2	单机场 + url-test	★★★	低	想要自动选节点
Level 3	双机场 + url-test + fallback	★★★★	中	开始担心单点故障
Level 4	Sub-Store + 多策略组分层	★★★★★	中高	3个以上机场/设备
Level 5	Sub-Store + Sing-box/Easy Proxies + 自建兜底	★★★★★	高	追求极致可控

Level 3 是性价比最高的阶段：2个机场，一个 url-test 处理日常，一个 fallback 保护关键业务。零额外维护成本，体验提升显著。

如果再往前——Sub-Store 统一管理 + 策略组分层——就能实现”换机场像换袜子一样简单”：新机场加到 Sub-Store，所有设备的订阅自动更新，规则不需要改一行。

多机场不是目的，永不掉线的体验才是。希望这篇指南能让你的代理架构从”能用”进化到”稳如老狗”。

本文配置模板在 Mihomo v1.18+、Sing-box v1.14+、Sub-Store v2.23+ 验证。如果你用的是更早的版本，部分参数名可能有差异，请参考对应版本的官方文档。