搜索 K
Appearance
多机场订阅合并聚合技巧：利用 Sub-Store 将多个机场节点整合为一个超级订阅
一、TL;DR：三分钟看完核心结论
- 单机场用户不需要 Sub-Store。 订阅数量不超过 2 个、只在一台设备上用，Sub-Store 带来的收益小于维护成本，直接导入客户端即可。
- 两个及以上机场 + 两台及以上设备，Sub-Store 是当前最优解。 它的核心价值不是"节点变多"，而是"统一命名、统一去重、统一输出、故障隔离"这四件事。
- 公共订阅转换站不要碰。 你等于把所有机场的订阅 token 明文交给了第三方，一旦对方被拖库，你的机场账号（往往绑定了邮箱和支付渠道）就是裸奔状态。
- 部署三选一：自建 VPS（推荐）、本地 Docker/NAS、Serverless 云函数。 面板在国内能否直连，直接决定你日常调规则的体验。
- 聚合不改变任何单条线路的物理质量。 合并 5 个机场 ≠ 速度 ×5，你换来的是可用性冗余和故障切换能力。
- 节点操作链的顺序极其重要：过滤 → 去重 → 重命名 → 排序。 顺序错了，去重直接失效。
- 订阅更新间隔不是越短越好。 300 秒是比较均衡的值；低于 60 秒会对机场 API 形成压力，部分机场会直接限流甚至临时封禁 UA。
💡 ⭐ 2026 超低门槛起步 · 【无忧链接】读者专享特惠通道：
月付低至 6 元起，全线 VLESS 协议 + IEPL 专线，多客户端原生支持，性价比与门槛平衡极佳：直达无忧链接官网 ↗
月付低至 6 元起，全线 VLESS 协议 + IEPL 专线，多客户端原生支持，性价比与门槛平衡极佳：
专属特惠wuyou666复制 📋
二、底层机理：订阅聚合到底在合并什么
2.1 订阅链接不是"节点列表"，是一场格式翻译游戏
机场后端返回的所谓"订阅"，通常只是三种东西之一：
- 一段 Base64 编码的换行文本（
vmess://、ss://、trojan://混合）； - 一份 Clash/Mihomo 风格的 YAML（含
proxies、proxy-groups、rules）； - 一份 Sing-box 或 QuantumultX 的 JSON。
同一份节点数据，Clash 期望 YAML，Surge 期望 conf，Shadowrocket 期望 Base64，Sing-box 期望 JSON。聚合工具的第一层工作，就是把这些格式全部解析成统一的内部节点对象，处理完再序列化回去。
2.2 Sub-Store 的三层运行时架构
理解这三层，你在排障时就不会抓瞎：
| 层级 | 职责 | 出问题时的典型症状 |
|---|---|---|
| 解析层（Parser） | 识别 UA 与返回内容格式，转成内部节点对象 | 订阅拉取成功但节点数为 0 |
| 处理层（Operator） | 执行过滤、去重、重命名、排序、脚本 | 节点数对但名称/顺序不对 |
| 输出层（Serializer） | 按请求头 UA 渲染成目标客户端格式 | 客户端提示"格式不支持" |
关键点：Sub-Store 的分享链接是"按需渲染"的。同一个 URL，你用 clash 的 UA 去拉就是 YAML，用 Surge 的 UA 去拉就是 conf。这意味着你只需要维护一份组合订阅，就能同时服务全家桶客户端——这也是它相对公共 subconverter 的核心优势。
2.3 去重的算法真相：默认维度会漏
Sub-Store 默认去重维度是"名称 + 服务器 + 端口 + 协议"的组合哈希。听起来很合理，但现实中有两个坑：
- 同机不同端口：很多机场把一台落地机拆成多个端口，命名还故意做差异化。默认维度去不掉，你会在延迟测速列表里看到两个 IP 相同、延迟相同的"不同节点"。
- 同 IP 不同 SNI：多见于 Reality/VLESS 节点，按服务器去重会误删，但按
server:port去重又漏。
实操建议：先按 server:port 做一轮粗去重，再用 Script Operator 对 server 字段做哈希分组，手动决定保留哪一个。宁可多留，不要误删——误删的节点你在客户端里是看不到任何报错的。
2.4 重命名不是美化，是运维基础设施
合并 5 个机场之后，你会看到至少 5 个叫"香港 01"的节点。节点名里通常混着国旗 emoji、地区缩写、序号、倍率标记（x0.5、x2）。
统一命名（例如 [WY]-HK-01、[WY]-HK-02）的收益有三个：故障定位（晚高峰哪个机场的香港挂了，一眼可见）、规则分流（正则匹配机场前缀做分组）、自动化管理（排序脚本依赖固定前缀）。
2.5 物理链路：聚合改变不了的那部分
这一节必须说清楚，否则你会对聚合产生错误预期：
- IEPL / IPLC 专线：不经过公网 BGP 转发表，端到端抖动通常能压到个位数毫秒，成本高，晚高峰几乎不劣化。
- BGP 中转：走公网，受运营商路由策略影响，晚高峰 RTT 可能从 5ms 飙到 80ms，抖动不可控。
- 双 ISP 落地：如香港 HGC + PCCW 双线接入，提升的是落地侧的容灾冗余，不改善你到入口的延迟。
- BBRv3：优化的是有丢包场景下的吞吐量，对 RTT 没有改善。别被"上了 BBRv3 所以延迟低"的话术忽悠。
- TLS Reality：解决的是被动 TLS 指纹识别问题，提升抗主动探测能力，与速率无关。
一句话总结：聚合只增加"可选链路数量"，不改变任何单条链路的物理属性。
三、核心参数对比矩阵
以下为四种主流聚合方案的量化对照（数据基于 2026 年 Q1 在 2C4G VPS 与家用 NAS 上的实测区间，节点样本 200 条）：
| 量化指标 | A 客户端原生多订阅 | B 公共 subconverter | C 自建 Sub-Store（VPS/Docker） | D Sub-Store + Serverless |
|---|---|---|---|---|
| 部署耗时 | 0 分钟 | 0 分钟 | 20–40 分钟 | 15–30 分钟 |
| 首次解析耗时（200 节点） | 客户端各自解析，约 1.2s | 1.5–4.0s（排队波动大） | 0.3–0.9s | 0.5–2.0s（含冷启动） |
| 单组合聚合上限 | 受客户端 UI 与内存限制 | 无明确上限，易超时 | 受实例内存限制，实测 1500 节点稳定 | 受执行时长限制，约 800 节点 |
| 去重能力 | 无 | 基础（固定维度） | 完整（多维度 + 脚本） | 完整 |
| 正则过滤 / 重命名 | 无 | 部分支持 | 完整支持 | 完整支持 |
| 自动更新粒度 | 客户端轮询，最低 60s | 取决于实例负载 | 自定义，最低 5–10s | 定时触发，最低 1 分钟 |
| 订阅 token 暴露面 | 仅机场方 | 高（第三方可见） | 低 | 低 |
| 客户端 UA 自适应 | 需手动逐个配置 | 支持 | 完整支持 | 完整支持 |
| 单机场故障隔离 | 差，一个订阅失败全组失效 | 中 | 好，失败订阅不影响其他节点 | 好 |
| 2026 适用度 | 仅 1–2 个机场 | 不推荐 | 强烈推荐 | 推荐（轻量场景） |
四、细分人群与场景选型推荐
场景一：单机场轻度用户（1 台设备） 不要装 Sub-Store。你的痛点是"机场本身好不好"，不是"订阅管理"。把时间花在挑一个线路稳定的机场上。
场景二：双机场互备的进阶用户（2–4 台设备） 典型配置是"主力池 + 备用池"。主力选高倍率、低延迟的专线机场承担日常；备用选低倍率、大流量、门槛低的机场兜底。这种组合下，月付 6 元起步的低门槛机场做备用池，成本几乎可以忽略，但关键时刻能救场。参考 /reviews/worryfree/ 的实测数据。
场景三：多设备多客户端的家庭 / 小团队 必须自建。因为你同时存在 Clash、Surge、Shadowrocket、Sing-box 四种 UA，只有 Sub-Store 能做到"一份组合订阅、四种格式输出"。此时建议用 VPS 部署，而不是 NAS——NAS 上的 Docker 网络在部分系统上需要额外处理 TUN 权限。
场景四：自动化极客 用 Script Operator 做动态过滤：按延迟阈值剔除节点、按倍率自动分组、按落地 IP 归属地自动重命名。这类玩法必须自建后端，Serverless 的执行时长经常不够跑完整脚本。
五、分平台实操配置与深度避坑
5.1 后端部署要点
Docker 是最省心的路径，核心是三个环境变量：后端路径（防止被扫）、同步地址、前端路径。把后端路径设成一段随机长字符串，否则公开 IP 上的 Sub-Store 会在几天内被爬虫扫到。
5.2 单条订阅录入的三个坑
- UA 必须填对：很多机场对 UA 做白名单，填
clash返回 YAML，填v2ray返回 Base64。填错了不是报错，而是返回一段 HTML 登录页，解析后节点数为 0。 - 不要勾选"使用订阅本身的节点信息节点"：机场的流量信息节点（"剩余流量 100G"、"套餐到期 2026-12-31"）在 Clash 里会被解析成无效代理，导致内核启动报错。
- 更新间隔设 300 秒：这是实测最均衡的值。
5.3 组合订阅的节点操作链
正确顺序：
- 过滤（Regex Filter）：剔除信息节点、剔除已过期地区、剔除你永远不用的协议。
- 去重（Dedupe）：按
server:port维度。 - 重命名（Regex Rename）：加机场前缀、统一地区缩写、去掉杂乱 emoji。
- 排序（Sort）：按地区或按机场分组，方便后续在客户端做
url-test。
顺序错了会怎样：先去重后重命名，你会发现重命名后出现了新的"重复节点"——因为去重时用的是原始名称，重命名改变了哈希。这是最常见的翻车点。
5.4 各客户端导入避坑
| 客户端 | 关键注意点 |
|---|---|
| Clash Verge Rev / Mihomo | 分组策略建议写在客户端侧，不要试图用 Sub-Store 注入全套 proxy-groups，维护成本极高 |
| Surge | 注意 Surge 对 VMess AEAD 和 Hysteria2 的版本支持，老版本会静默丢弃节点 |
| Stash | 支持 SS2022，但需确认机场是否下发 2022-blake3 系列参数 |
| Shadowrocket | 从 URL 导入时优先用 Base64 输出，YAML 在部分 iOS 版本上解析异常 |
| Quantumult X | 若开了资源解析器（rewrite），会二次改写订阅，务必排除 Sub-Store 域名 |
| Sing-box | 建议独立组合订阅，不要和 Cl |