多源节点怎么合并：XBoard 多订阅、API 与 Clash YAML 统一处理思路

多源节点怎么合并：先统一结构，再去重、命名和分组

多源节点合并的关键是先把各来源解析成同一种节点结构，而不是把链接或配置文件简单拼在一起。常见来源包括本地 JSON、远程 API、多个 Clash YAML 和公开线路。统一结构至少要包含协议类型、服务器地址、端口、认证信息（UUID 或密码）以及传输参数，例如 TLS、SNI、ws/grpc 路径、Reality 公钥。结构统一后，再以“协议 + 地址 + 端口 + 认证”作为唯一键去重，然后按地区自动命名，最后分配到 XBoard 的权限组或订阅里。

很多运营者一开始会手工处理：把几份订阅的 proxies 复制进同一个 YAML，或者在 XBoard 后台逐条新建节点。来源只有一两个、更新不频繁时，这种做法可以用。来源增加后，问题会接连出现：同名节点互相覆盖，VLESS、Hysteria2 等协议的字段在转换中丢失，上游节点下线后没人察觉，用户端继续拿到失效线路。合并本身不复杂，难点在于持续维护。另外，第三方节点的稳定性、速度和流量限制取决于上游，合并流程和插件都无法保证。

合并出问题时，先按现象判断原因

合并后出现异常，先根据现象定位原因，不要直接重做配置。 看到订阅内容是一整段没有换行的字符串 → 说明这是 Base64 编码的通用订阅，不是 YAML → 先用 base64 -d 解码，再按 ss://、trojan://、vless://、vmess://、hysteria2:// 等前缀逐行解析。 看到合并后的节点数比各来源相加明显少 → 多半是同名节点被覆盖，或去重键设置过粗（例如只按 server 去重，把同一 IP 上的不同端口误删了）→ 检查名称是否重复，并把端口和认证信息加入唯一键。 看到客户端日志提示代理类型不支持或解析失败 → 通常是内核版本太旧，不认识 Hysteria2、AnyTLS、Mieru 等较新的协议，或者 VLESS 缺少 reality-opts、flow 字段 → 先确认客户端内核版本，再比对原始链接和转换结果的字段是否一致。 看到部分用户能看到某些节点、部分用户看不到 → 问题不在合并，而在 XBoard 的权限组与套餐绑定 → 检查节点所属的组以及用户套餐关联的组。

低成本自助合并的操作步骤

来源不多时，可以用 curl 和 yq（v4）在本地完成一次可检查的合并。示例文件名仅作演示，订阅地址里的 Token 不要写进脚本仓库或日志。 第一步，拉取来源：执行 curl -s "$SUB_A" -o a.yaml；如果来源是 Base64 通用订阅，改用 curl -s "$SUB_B" | base64 -d > b.txt，再逐行转换成 YAML。 第二步，合并 proxies：执行 yq ea '.proxies as $p ireduce ({"proxies": []}; .proxies += $p)' a.yaml c.yaml > merged.yaml。 第三步，查重名：执行 yq '.proxies[].name' merged.yaml | sort | uniq -d。只要有输出，就要给节点加上来源前缀或改名。 第四步，查重复地址：执行 yq '.proxies[] | .type + " " + .server' merged.yaml | sort | uniq -c | sort -rn | head。

计数大于 1 的条目，再人工核对端口和认证信息是否也相同。 第五步，在当前使用的客户端内核里导入 merged.yaml 做测试，确认没有解析错误后，再按地区录入 XBoard 并绑定权限组。

合并结果的覆盖验证：数量、协议与权限逐项核对

合并完成后，不要只确认订阅能打开，还要按来源逐项对账。每个来源记录四个数：原始条目数、解析成功数、去重剔除数、规则过滤数，这四个数应能前后对上。比如某来源原始 40 条，解析成功只有 28 条，说明有协议字段不兼容。常见原因有：Hysteria2 的 obfs 参数写法不同，VLESS 的 reality 或 ECH 字段缺失，AnyTLS、Mieru 这类较新协议的字段命名不统一。

客户端这一侧也要验证。用测试账号以 Clash 类客户端 UA 拉取订阅，例如 curl -s -A "clash-verge" "测试订阅地址" -o test.yaml，再用 grep -c "type: vless" test.yaml 统计各协议数量，和后台预期对照。然后换不同权限组、不同套餐的账号各拉一次。如果低套餐账号拿到了高级节点，说明权限匹配规则或缓存键没有按用户组区分，下一步应检查动态注入逻辑是否把用户组纳入了缓存键。流量已用尽的账号应返回空列表或提示节点，不应读到旧缓存。

失败边界：哪些问题靠合并逻辑解决不了

合并、去重、命名只处理数据层。第三方节点的稳定性、速度、流量限制不由插件保证。上游订阅到期、源站限速、公开线路被回收，都会直接影响到用户。合并系统最多能更早发现问题并下线这些节点，不能让坏节点变好。

常见的失败有四类。 第一，来源格式变化。远程 API 字段改名或 Clash YAML 结构调整后，日志里会集中出现解析失败。这时应暂停该来源的同步并保留上一版数据，不要清空整个节点池。 第二，去重误伤。只按 server:port 去重，会把同一入口下不同 UUID 或不同传输参数的节点合并成一条。去重指纹应同时包含协议、端口、认证信息和传输层参数。 第三，地区误判。按名称关键词识别，遇到"香港-日本中转"这类命名容易标错；按 IP 归属识别，又会受 CDN 或 Anycast 地址干扰。两种方式都应保留人工修正的入口。 第四，客户端兼容。部分客户端不支持 VLESS ECH、Mieru 等协议。下发前应按 UA 过滤，否则整份配置可能加载失败。

长期架构与服务适用边界

如果来源只有两三个、格式单一，一个定时脚本加手工复核通常就够用。当本地 JSON、多个远程 API、多份 Clash YAML 和公开线路采集同时存在时，建议拆成四层： 采集层：按来源独立调度，失败单独重试。 标准化层：把各协议解析为统一结构，并生成去重指纹。 策略层：负责地区识别与命名、过滤、权限组和套餐匹配。 分发层：用户拉取订阅时按用户组动态注入，以"用户组+客户端类型"作为缓存键，缓存有效期与上游同步周期对齐。 这样某一层出错只影响本层，也能回退到上一版数据。

如果团队没有精力长期维护解析规则和同步任务，可以了解 Manguo Labs 的 XBoard 节点扩展与采集方案。它适合需要接入多个外部节点来源、需要协议解析、去重、命名和权限控制，以及需要节点池持续同步与健康维护的运营者。具体兼容范围和实施边界可以先在 https://manguolabs.com/xboard-node-extension/ 确认再评估。这类方案解决的是接入与维护流程，上游节点的质量仍取决于来源本身。

什么时候这已经不是单点配置问题

如果你的来源只有两三个、格式固定，本文的脚本思路基本够用。当来源越来越多、协议越来越杂，还要按套餐和流量状态区分下发，手工维护的成本和出错率会明显上升，这时可以再考虑把采集、解析、权限和缓存交给一套标准化的节点扩展方案来做。

Manguo Labs 能提供什么

Manguo Labs 为 XBoard 运营者提供第三方订阅、API、Clash 节点与节点池的标准化接入和维护方案。

本文问题对应 Manguo Labs 的 XBoard 节点扩展与采集方案：面向需要接入多个外部节点来源（第三方订阅、API、Clash 节点），并需要协议解析、去重、命名、权限控制以及节点池持续同步与健康维护的 XBoard 运营者。

适合这些情况

• 同时接入本地 JSON、远程 API、多份 Clash YAML 或公开线路等多个节点来源的 XBoard 运营者
• 需要对 SS、Trojan、VLESS、VMess、Hysteria2、AnyTLS 等协议统一解析、去重和自动命名的场景
• 需要按权限组、套餐和流量状态动态下发外部节点的站点
• 需要节点池持续同步、缓存回退和失效节点剔除的长期运营场景

查看XBoard 节点扩展与采集 →

常见问题

总结与下一步

多源节点合并应按“采集 → 统一解析 → 去重 → 地区识别与命名 → 过滤 → 权限与套餐判断 → 缓存与动态注入”的顺序处理。少量来源可以用脚本和定时任务低成本解决；来源、协议和权限规则变多后，重点就变成持续同步和故障回退。第三方节点的质量始终取决于来源本身，合并流程只能做到标准化和及时剔除。

需要进一步评估时，可先查看XBoard 节点扩展与采集，并参考更多技术文章。