两个节点重名会怎样？校验器为什么把「重名」当问题

一句话结论：Clash 用 name 作为节点的唯一标识，两个节点同名时，引用这个名字的地方只会拿到其中一个——而你无法预期是哪一个。

配置通常还能启动，这正是它容易被放过的原因。问题会以「某个节点选了却不生效」「切换之后延迟对不上」这类形式，在很久之后才浮出来。

报错长什么样

配置校验器会指出重复出现的那个名字，并说明：

Clash 用 name 作为节点的唯一标识，重名会导致策略组引用到非预期的那一个。

注意它和「同一层出现了重复的键名」不是一回事。后者是 YAML 层面的语法问题（同一个映射里写了两次同样的键），前者是 proxies 数组里两个不同的元素恰好取了同样的 name——在 YAML 看来完全合法，所以 YAML 解析器不会报错。

为什么后果不容易被察觉

节点名在配置里被引用的地方不止一处：策略组的成员列表、规则的目标、以及客户端界面上你手动点选的那一项。这些引用全部按字符串匹配。

当两个节点叫同一个名字时，实现通常取先出现的那个，但这属于未定义行为——不同内核、不同版本的处理方式可能不同，而且订阅每次生成的顺序也可能变化。于是就出现了最难排查的一类现象：同一份配置，昨天和今天的行为不一样，而你什么都没改。

三种常见来源

合并了两份订阅。 两家机场都有「香港 01」这种通用名，直接拼在一起就重了。这是最常见的一种。

手动加了一个节点，名字照抄了模板。 模板里的示例名往往就是「香港节点」「测试」这类，和订阅里的撞上。

订阅本身就有重复。 机场后台配置失误时会出现同名节点，这种情况下你改配置也没用，下次更新又会回来。可以把订阅内容粘进订阅内容解码器确认——它会把服务器与端口重复的条目单独标出来，如果连服务器加端口都一样，那多半是订阅里的同一个节点被输出了两次。

怎么改

改名就行，关键是改完要同步引用它的地方。

proxies:
  - name: "香港 01 · A家"
    type: vmess
    server: a.example.com
    port: 443
  - name: "香港 01 · B家"
    type: vmess
    server: b.example.com
    port: 443

加后缀区分来源比加序号好，因为序号在下次订阅更新后可能对不上，而来源是稳定的。

改完之后，配置里所有按旧名字引用的地方都要跟着改，否则会变成另一个报错：引用了不存在的节点。把改后的配置整份粘进配置校验器再跑一遍，它会把引用不到的名字列出来。

一个例外情况

如果你是故意让两个节点同名的（比如想让客户端界面上只显示一项），那不会按你预期工作——Clash 不会把同名节点合并成一个可切换的组，它们仍是两条独立的记录，只是引用时会撞车。要达到「一个入口、多个节点」的效果，应该用策略组，而不是让节点重名。

相关

• Clash 报错「proxies 必须是数组」是什么意思
• 「策略组引用了不存在的节点」——名字对不上的四种情况