节点池怎么去重：先看重复到底出在哪一层
节点池去重不是简单“删掉一样的行”。手工维护时，重复往往出现在三层：一是同一节点被多个来源同时采集，比如公开订阅链接和 Clash YAML 都收录了同一个落地 IP；二是同一服务器换了端口或备注名，看起来是新节点，实际是老节点的马甲；三是协议层字段不同但连接目标一致，例如同一 VMess 节点在两份订阅里 UUID 相同但别名不同。
判断方法：先看 IP+端口+协议三元组是否重复，这是最基础的判重维度；再看认证字段（VMess 的 UUID、Trojan 的密码、SS 的 method+password）是否一致，避免只按名字判断误删有效节点。如果两条记录三元组相同但认证字段不同，通常是同一机器开了多套配置，不能直接去重，需要保留并标注来源。第三方节点的稳定性、速度、流量限制不由插件保证，去重逻辑本身不改变来源质量。
手工去重的可执行步骤
如果节点来源不多（比如 3-5 个订阅或几份 YAML），可以先用脚本做第一轮机械去重，再人工复核边界情况。步骤如下：
1. 汇总所有来源，统一转成同一种中间格式，建议用 YAML 或 JSON 数组，每条记录至少包含 protocol、server、port、uuid/password、remark。 2. 按 server+port+protocol 生成一个 key，用 Python 的 dict 或 shell 的 sort | uniq -c 找出出现次数大于 1 的 key，这些是候选重复项。 3. 对候选重复项，进一步比对认证字段是否一致。一致则合并为一条，保留信息最完整的那条；不一致则保留两条并加注来源标签。 4. 合并完成后，用 wc -l 对比合并前后的节点总数，确认去重比例是否合理，比例异常说明判重逻辑有问题，需要回头检查 key 的生成规则。
看到日志里同一 server 出现 5 次以上 → 通常是采集脚本重复抓取同一订阅源导致 → 应先检查采集频率和缓存策略，而不是急着写去重规则。
去重规则会遇到的边界情况
手工规则在来源少、更新频率低时够用，但会在几种情况下失效。第一种是同一物理服务器对外提供多个协议（比如同时开 VLESS 和 Hysteria2），三元组不同但实际是一台机器，简单去重会漏判，需要额外维护一张“服务器指纹”表，通常用证书信息或 IP 归属做关联，手工维护成本很高。
第二种是节点来源本身会滚动换 IP，比如落地 IP 每天轮换，导致今天判重有效的规则，第二天因为 IP 变了又把同一节点当成新节点收录，去重结果不稳定。第三种是多个 Clash YAML 之间字段命名不统一（有的用 name，有的用 remarks），直接用文本比对会漏掉本该合并的记录，需要先做字段归一化再判重。这几类情况靠脚本规则打补丁能应付一时，但来源一旦超过 5-6 个、更新频率提高，人工复核的时间成本会明显上升，且这些问题都发生在插件处理逻辑之外，与第三方节点自身的稳定性、速度和流量限制无关，插件不对这些外部因素做保证。
去重结果怎么验证才算真正生效
去重脚本跑完不代表结果可信，必须做二次校验。先看节点池总数变化：去重前后数量差如果接近零，说明匹配规则太严格，很多重复节点没被识别；如果降幅超过五成，往往是规则太松，把配置不同的独立节点误判成重复。可以抽样验证，从去重后的池子里随机取十几个节点，人工比对 server、port、协议参数是否真的一致，避免误删。
订阅层面的验证同样重要：用 Clash 或 sing-box 加载去重后的订阅文件，检查是否报解析错误，节点数量是否与后台记录一致。日志里如果出现"duplicate node id"或客户端拒绝加载部分条目，说明去重脚本生成的节点标识存在冲突，需要回头检查命名和 ID 生成逻辑，而不是继续往下游硬塞。
自建去重脚本会在哪些场景失灵
手工或简单脚本做去重，边界很清晰。当节点来源只有两三个、格式统一（比如都是标准 Clash YAML）时，按 server+port+protocol 做字段比对基本够用。但一旦来源变多，问题就会暴露：不同采集源对同一节点的字段命名不一致，有的用 ps 标注备注，有的用 remarks，脚本如果只认一种字段，就会漏掉大量重复项。
另一类边界是加密参数层面的重复。两个节点 server、port 相同，但 UUID、密码或 ws-path 不同，这种情况下不能简单判定为重复，但如果脚本只比对 IP 和端口，会误删掉实际有效的独立节点。VLESS ECH、Hysteria2 这类协议还带有额外的证书或混淆参数，字段结构比 SS、Trojan 更复杂，通用去重逻辑很容易在这里出错。当节点池规模上到百级以上、来源超过三四个、协议种类混杂时，靠手工维护规则基本跟不上变化速度。
长期节点池架构与何时该用专业方案
长期看，去重不该是一次性脚本，而应该是节点入库前的固定处理环节：采集、协议解析、去重、命名、权限打标签，形成一条流水线，每次新增来源都走同一套规则，而不是每次单独写判断逻辑。这样才能保证节点池状态可追溯，出问题时能定位是哪一步出的错。
如果你已经在维护多个第三方订阅源、API 接口和公开线路采集，且需要统一处理协议解析、去重、命名和权限判断，同时还要应对节点池的持续同步和健康检查，这类工作量通常超出手工脚本能稳定支撑的范围。Manguo Labs 的 XBoard 节点扩展与采集方案，就是为这类场景提供标准化接入和维护思路，具体能力和适用边界可以参考产品页面。第三方节点自身的稳定性、速度和流量限制不由插件保证，这部分仍取决于节点来源本身的质量。
什么时候这已经不是单点配置问题
如果你已经在手工维护多个来源的节点表格，并且发现去重规则越写越复杂、还是漏检误删，说明手工阶段的边界已经到了，可以考虑看看标准化的采集与去重方案能覆盖哪些环节，同时清楚哪些环节（比如第三方节点的稳定性和速度）仍不在方案覆盖范围内。
Manguo Labs 能提供什么
Manguo Labs 为 XBoard 运营者提供第三方订阅、API、Clash 节点与节点池的标准化接入和维护方案。
当节点来源包括本地 JSON、远程 API、多个 Clash YAML 甚至公开采集线路，且协议类型混杂（SS/Trojan/VLESS/VMess/Hysteria2/AnyTLS/Mieru/VLESS ECH 等）时，XBoard 节点扩展与采集方案可以提供统一的协议解析、去重、命名和权限判断能力，配合缓存与动态注入减少人工维护负担。需要明确的是，第三方节点自身的稳定性、速度和流量限制不由插件保证，这部分仍取决于节点来源方。
适合这些情况
- 需要接入多个外部节点来源并统一去重规则
- 节点协议混杂（SS/Trojan/VLESS/VMess/Hysteria2等）导致手工比对困难
- 节点池需要持续同步、命名与权限组绑定的长期维护场景
常见问题
节点名称不同但配置完全一样，算重复吗？
算。去重应该基于协议关键字段（如 server、port、UUID/密码、传输协议），而不是节点名称。名称只是展示层，很多采集脚本会在合并时自动重命名，导致同一条线路出现多个名字。建议先按核心字段生成唯一标识（比如拼接后取哈希），再做比较。
手工用 Excel 或文本工具去重，大概能撑到多少个节点？
这取决于来源数量和更新频率。如果节点来源固定为 1-2 个、更新频率低于每周一次，手工整理通常还能应付。一旦来源超过 3-4 个，或者节点每天有变动，手工比对的漏检和误删概率会明显上升，此时更适合上脚本或成熟的采集方案。
Clash YAML 和订阅 API 格式不一样，怎么统一去重？
需要先做协议解析，把不同格式统一转换成同一套内部字段结构（协议类型、地址、端口、认证信息、传输层参数），再在这个统一结构上做去重判断，而不是直接对比原始文本或 URL。
去重后节点数量突然变少很多，是不是出问题了？
不一定是故障，先看这批来源本身重复率是否本来就高，比如同一家机场在多个订阅里都放了同一批节点。可以先抽样核对几个被判定为重复的节点，确认它们的核心字段确实一致，再决定是否需要调整去重规则的严格程度。
总结与下一步
节点池去重的关键不在工具，而在"重复"的判断标准是否统一并且贴合协议字段本身。手工方式适合节点来源少、更新慢的场景，一旦来源变多、协议混杂（SS/Trojan/VLESS/VMess/Hysteria2 等），维护成本会迅速上升，此时更依赖标准化的解析、去重和权限判断流程。第三方节点自身的稳定性、速度和流量限制不由插件保证，去重和采集方案只解决协议解析、命名与权限判断层面的问题。
需要进一步评估时，可先查看XBoard 节点扩展与采集，并参考更多技术文章。
继续阅读
了解 XBoard 节点扩展与采集 →