Profile 到底是什么

很多人把"订阅链接"和"配置文件"当成一回事,严格说这两者不完全等同。订阅链接是一个 HTTP 地址,客户端定期向这个地址发起请求;返回的内容才是真正的配置文件,通常是一份 YAML 格式的文本,业内习惯称之为 Profile。客户端把这份文本下载到本地、解析后加载运行,你在界面上看到的节点列表、代理组切换按钮、规则匹配结果,全部来自这一份 YAML 的内容。

Profile 本质上只是一份结构化的文本配置,不神秘也不复杂,拆开来看只有三个核心段落在真正起作用:节点定义、代理组编排、规则列表。剩下的字段大多是端口、日志级别、DNS 这类运行参数,理解了三大段落,基本就理解了 Profile 的运作方式。

节点、代理组、规则:三大段落各管什么

把一份 Profile 从上到下读一遍,会发现内容基本按三个层级组织,层级之间是明确的引用关系,不理解这个引用链,后续的多配置管理和规则调整都会走弯路。

proxies:节点是什么

proxies 段落列出所有可用的代理服务器,每一条记录包含服务器地址、端口、加密方式、密码或密钥等连接参数,对应到某个具体的服务器节点。这一层是最底层的"原材料",不直接决定流量走向,只是声明"有哪些服务器可以用"。

proxy-groups:代理组是什么

proxy-groups 段落把上面声明的节点组织成逻辑分组,常见的组类型包括:

  • select——手动选择组,界面上能看到一排节点按钮,点哪个用哪个;
  • url-test——自动测速组,按延迟自动选出最优节点,通常配合定时探测周期;
  • fallback——故障转移组,主节点失效后自动切到备用节点;
  • load-balance——负载均衡组,多个节点分摊流量。

代理组之间还可以互相嵌套引用,比如一个"自动选择"的 url-test 组,可以作为另一个手动 select 组里的一个选项,这种嵌套是排查规则命中异常时最容易被忽略的一环。

rules:规则是什么

rules 段落是一份从上到下逐条匹配的清单,每条规则由匹配条件和目标策略组成,格式类似:

DOMAIN-SUFFIX,openai.com,美国节点
DOMAIN-KEYWORD,github,自动选择
GEOIP,CN,DIRECT
MATCH,自动选择

匹配条件常见的有 DOMAIN(精确域名)、DOMAIN-SUFFIX(域名后缀)、DOMAIN-KEYWORD(域名关键词)、GEOIP(按目标 IP 所属地区)、IP-CIDR(按 IP 段),最后一条通常是 MATCH,代表"以上都不满足时走这里"的兜底策略。规则从上往下逐条比对,一旦命中就立即执行对应策略,不再往下继续匹配——这个"命中即停"的特性,是后面讲规则互相覆盖问题的关键前提。

Notice / 提示

规则里填的"目标策略"必须是前面 proxy-groups 里已经存在的组名,或者是 DIRECT/REJECT 这两个内置策略,写错组名会导致该条规则直接失效或加载报错。

多个订阅配置共存时的切换逻辑

随着使用时间变长,大部分人手里不会只有一份订阅。有的机场提供多条线路分别对应不同订阅地址,有的用户会同时保留一份日常使用的订阅和一份用于特定场景的自定义规则订阅。多份配置共存时,客户端的处理方式大致遵循下面几条逻辑。

配置是互斥加载,不是叠加加载

客户端在某一时刻只会加载一份 Profile 进入运行状态,切换配置本质上是"卸载当前配置、加载另一份配置"的过程,不是把多份规则叠加在一起同时生效。这一点很容易被误解——有用户以为添加了第二份订阅之后,两份配置的规则会合并生效,实际情况是切换后原来那份配置的节点、代理组、规则全部被替换,不会保留任何交叉状态。

切换时机与生效范围

切换配置会重新建立代理组和规则表,正在进行中的连接一般不会被中断,但新发起的连接会立即按新配置的规则匹配。如果切换后发现某个网站突然连不上,大概率是新配置里对应域名的规则策略和旧配置不同,先检查新配置的规则匹配结果,而不是急着重启客户端。

自动更新与手动切换的边界

每份订阅可以单独设置自动更新间隔,自动更新只会刷新该订阅自身的内容,不会影响你当前选中的是哪一份配置。也就是说,后台可以同时保持多份订阅各自按周期更新,但界面上生效的始终是你手动选中的那一份,更新行为和切换行为是两条独立的逻辑线,互不触发。

命名习惯:让多配置不再混乱

配置一多起来,最先出问题的往往不是技术层面,而是"认错配置"这种人为失误——明明想切到工作专用的规则集,却点成了另一份内容相近的订阅。养成清晰的命名习惯,能省掉大量排查时间。

  • 按用途前缀命名:比如"日常-XX机场""办公-规则订阅""测试-自建节点",一眼能看出配置的使用场景;
  • 标注更新周期或时效:如果某份订阅是临时用来测速的短期订阅,命名里加上日期或"临时"字样,避免长期混杂在正式配置列表里;
  • 避免使用默认文件名:很多客户端导入订阅后会自动生成类似"config.yaml"这样的默认名称,多份订阅都叫这个名字时几乎无法区分,导入后第一时间重命名;
  • 记录订阅来源:如果客户端支持备注字段,把订阅对应的服务商或用途写进备注,半年后再看列表也能快速回忆起来。

避免规则互相覆盖的管理方法

"规则互相覆盖"通常不是指两份配置的规则真的合并冲突,而是指用户在同一份配置里做了手动追加或修改之后,下一次自动更新订阅时,这些手动改动被服务器返回的新内容整体覆盖,改动痕迹消失。这是多配置管理里最容易踩坑的一点。

覆盖发生的根本原因

大多数客户端在更新订阅时,会用远程返回的完整 YAML 内容整体替换本地文件,而不是逐字段合并。也就是说,如果你在本地手动往规则列表里加了一条自定义规则,而这条规则不存在于服务器返回的原始订阅里,下一次自动更新一旦触发,这条手动加的规则会随着整份文件被替换而消失,不会有任何提示。

三种规避方式

  1. 使用客户端的"覆写"或"额外规则"功能:部分客户端支持在订阅之外单独维护一份本地覆写文件,更新订阅时只替换订阅本身的内容,本地覆写部分独立保留、单独生效,这是最推荐的方式;
  2. 关闭该订阅的自动更新,手动维护:如果这份配置需要频繁手动调整规则,且服务商更新频率不高,可以直接关闭自动更新,改动只会在你主动点击更新时才被覆盖,风险可控;
  3. 把自定义规则单独存成一份配置,通过订阅转换工具合并:适合有一定动手能力的用户,把手动规则维护成独立的规则文件,再通过订阅转换服务把原始订阅和自定义规则拼接成新的订阅地址,这样每次更新拉取的就是已经合并好的内容,不需要在客户端里反复手动补规则。
Notice / 注意

不确定客户端是否支持本地覆写功能时,先做一次手动改动测试:改完立即手动触发一次"更新订阅",观察改动是否被清空。确认行为之后再决定长期用哪种方式管理,比事后丢失规则再补救省心得多。

日常维护的几个检查动作

配置数量增多之后,建议养成几个固定的检查习惯,能在问题变大之前就发现异常:

  • 定期打开规则列表,确认最后一条 MATCH 兜底策略指向的代理组符合预期,避免兜底策略被订阅更新悄悄改动;
  • 切换配置后,用客户端自带的延迟测试功能刷新一次节点状态,新配置里的节点池和旧配置往往不完全一致;
  • 如果同时维护多份配置,每隔一段时间清理一次不再使用的旧订阅,减少界面上误切的概率;
  • 手动追加的规则,养成随手记录一份本地备份的习惯,即便使用了覆写功能,也建议保留一份文本副本以防客户端数据丢失。

理清节点、代理组、规则三层结构的引用关系,再配合清晰的命名和恰当的更新策略,多配置共存并不会变成负担,反而能让不同场景的流量分流更精准、更可控。