Clash Blog
搜索 K

深色模式

Clash 多订阅管理实战：多机场聚合、权重分配与容灾备份 ​

直接答案：在实际工程场景中，依赖单一机场订阅存在极高的单点故障风险（SPOF）。进阶玩家的黄金标准是采用**“主力品质专线（低延迟、抗抖动）+ 备用平价按量（大流量、高带宽）+ 自建住宅 VPS（极度纯净 IP）”的多源架构。管理多订阅的最高效姿态，绝不是在客户端图形界面中频繁切换独立配置文件，而是通过 proxy-providers 将多个外部订阅解耦挂载到统一主配置中**，借助正则过滤器（filter）实现跨提供商地域池聚合，并利用 fallback 策略组构建毫秒级无感容灾。

一、多订阅协同架构模型与工程痛点 ​

如果直接把两份完整的机场订阅通过文本拼接合并，将立即引发三大工程灾难：

  1. 策略组命名冲突：不同服务商预设的“🚀 节点选择”、“♻️ 自动选择”互相覆盖，导致规则树解析崩溃；
  2. 节点重名覆盖：两家服务商若都包含名为“香港 01”的节点，底层映射哈希表发生冲突，导致流量行为不可预测；
  3. 测速探针风暴：两家机场若合计包含 300+ 个节点，默认的并发 URL 测速会在瞬间产生高频并发连接，造成本地软路由 CPU 飙升并可能触发服务商的并发防御（DDoS 拦截）。

通过现代 Mihomo 的 Proxy Provider 解耦模型，主配置仅定义调度规则，节点集作为外部资源动态拉取：

+---------------------------------------------------------------+
|                      统一主配置文件 (config.yaml)               |
|                                                               |
|   [业务分流规则] -> [ChatGPT / AI 组] -> [专线优先 Fallback 组]   |
|                 -> [4K 流媒体跨区] -> [大带宽负载均衡组]          |
+-------------------------------+-------------------------------+
                                |
             +------------------+------------------+
             |                                     |
             v                                     v
+-------------------------+               +-------------------------+
| Provider A (主力专线)   |               | Provider B (备用按量)   |
| - 物理载体: IPLC/IEPL    |               | - 物理载体: BGP 多线    |
| - 特性: 0 丢包 / 超低延迟|               | - 特性: 廉价大带宽 / 兜底|
| - 自动缓存: a_cache.yaml|               | - 自动缓存: b_cache.yaml|
+-------------------------+               +-------------------------+

二、生产级双订阅/三订阅聚合 YAML 编排规范 ​

以下是一套经过生产环境长周期检验的多订阅聚合工程模板：

yaml
# 1. 外部订阅提供商定义 (数据与逻辑彻底解耦)
proxy-providers:
  Provider-Premium:
    type: http
    url: "https://sub.primary-airport.com/api/v1/client/subscribe?token=SecretTokenA"
    path: ./providers/premium_nodes.yaml
    interval: 43200 # 每 12 小时静默拉取更新一次
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 180 # 3分钟健康心跳检查
      timeout: 2500
      lazy: true # 关键参数：仅在使用该节点时发起测速，大幅节省资源

  Provider-Budget:
    type: http
    url: "https://sub.backup-airport.com/api/v1/client/subscribe?token=SecretTokenB"
    path: ./providers/budget_nodes.yaml
    interval: 86400 # 备用源每 24 小时检查一次更新
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 3000
      lazy: true

# 2. 策略组编排：实现按地域跨机场聚合与分级容灾
proxy-groups:
  # 顶层总控选择器
  - name: "🚀 PROXY"
    type: select
    proxies:
      - "🛡️ 跨机场高可用容灾"
      - "🇭🇰 香港-全源优选"
      - "🇯🇵 日本-全源优选"
      - "🇺🇸 美国-主力专线"
      - DIRECT

  # 容灾核心：主力专线优先，故障时秒级回退至平价备用
  - name: "🛡️ 跨机场高可用容灾"
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 60
    proxies:
      - "🇭🇰 主力专线池"
      - "🇭🇰 备用平价池"

  # 跨提供商地域池：同时注入 Provider A 和 B 的节点并执行正则清洗
  - name: "🇭🇰 香港-全源优选"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 35 # 延迟差小于 35ms 时不频繁跳点，保障连接平稳
    use:
      - Provider-Premium
      - Provider-Budget
    filter: "(?i)港|hk|hongkong"
    exclude-filter: "(?i)官网|流量|重置|到期|通知" # 剔除机场公告等非节点垃圾条目

  - name: "🇭🇰 主力专线池"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 20
    use:
      - Provider-Premium
    filter: "(?i)港|hk"

  - name: "🇭🇰 备用平价池"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    use:
      - Provider-Budget
    filter: "(?i)港|hk"

三、关键性能与内存优化法则 ​

在挂载多个订阅时，若不进行精细化调优，会导致客户端内存占用成倍增加。建议实施以下三项治理措施：

1. 开启 lazy: true 懒惰健康检查 ​

默认情况下，health-check 会对 Provider 内所有节点按时间周期无脑发送探测包。设置 lazy: true 后，内核仅会对当前正在被活跃策略组引用或当前选中的节点进行存活探测。当挂载上千个多源节点时，可将后台常驻带宽与 CPU 开销降低 80% 以上。

2. 精准运用 exclude-filter 清洗倍率陷阱 ​

很多平价机场包含 3x、5x 甚至 10x 高倍率节点，如果不加区分混入自动优选组（url-test），极易因为该节点延迟稍低而被内核选中，导致数小时内几十 GB 流量被意外消耗殆尽：

yaml
exclude-filter: "(?i)2x|3x|5x|10x|高倍|体验"

3. 本地缓存持久化避免离线断网 ​

path: ./providers/premium_nodes.yaml 确保了即使在本地网络暂时断开或机场 API 遭到 DDOS 攻击时，Clash 内核仍能直接读取上次保存在本地磁盘上的节点快照继续启动工作，绝不因远程拉取失败而阻塞启动。

四、多订阅运维常见故障与排错指南 ​

Q1：为什么更新配置后，两个机场的节点名字发生重叠甚至丢失？ ​

  • 排查：检查策略组的 use: 字段中是否正确包含了对应的 Provider 名称。如果需要在 UI 上直观区分不同服务商，建议在分流工具中使用重命名规则，或通过不同策略组进行物理隔离（例如设立 [专线-香港] 与 [备用-香港]）。

Q2：Provider 文件显示 download failed: context deadline exceeded？ ​

  • 排查：机场的订阅拉取域名可能本身已被公网阻断。在主配置文件的规则块（rules）顶部，必须为该订阅域名显式放行直连或走系统代理通道：
    yaml
    rules:
  - DOMAIN,sub.primary-airport.com,DIRECT # 订阅域名直连放行

五、延伸阅读与相关方案 ​