Clash 配置文件(Profile)结构解析:字段含义与多订阅管理方法
拆解 Profile 的核心字段:端口、代理组、规则段各自负责什么,订阅更新时哪些内容会被覆盖;并说明多个配置文件如何切换、去重与备份,避免改动被更新掉。
Profile 到底是什么
在 Clash 生态里,“配置文件”(Profile)指的是一份 YAML 格式的文本,里面记录了本地端口、出站节点列表、代理组的分组逻辑,以及一整套分流规则。客户端界面上看到的策略组、延迟测速、规则匹配结果,归根结底都是这份 YAML 被解析后渲染出来的。无论是手动填写一个订阅链接,还是导入本地文件,客户端做的事情本质上都是把远端或本地的这份文本抓取下来、校验格式、再交给内核(Clash Premium 或 mihomo)加载运行。
理解 Profile 的结构,好处不只是排查故障更快,更重要的是能判断“哪些改动是安全的、哪些改动会在下次刷新订阅时被冲掉”。这是本文要讲清楚的核心问题。
字段拆解:一份 Profile 里都写了什么
一份完整的 Profile 大致可以分成四个区块,顺序不强制,但客户端界面通常按下面的逻辑分组展示。
1. 基础运行参数
这部分决定内核监听哪些端口、以什么模式工作,常见字段包括:
| 字段 | 作用 |
|---|---|
| port | HTTP 代理监听端口 |
| socks-port | SOCKS5 代理监听端口 |
| mixed-port | HTTP 与 SOCKS5 合用的混合端口,多数客户端默认启用这个而不是分开两个端口 |
| allow-lan | 是否允许局域网内其他设备接入该代理 |
| mode | 运行模式,取值 rule / global / direct |
| log-level | 日志详细程度,排查问题时通常临时调到 debug |
| external-controller | RESTful API 监听地址,客户端图形界面通过它读取运行状态 |
这些字段大多有默认值,客户端图形界面里的“端口设置”“混合端口”“局域网连接”等开关,改的其实就是这一区块的内容。
2. proxies:节点列表
proxies 是一个数组,每一项描述一个出站节点,常见字段有 name(节点显示名)、type(协议类型,如 ss、vmess、trojan、hysteria2)、server、port,以及协议特有的加密方式、UUID、密码等参数。这一段几乎从不需要手动编辑——它由订阅服务商生成,你要做的是保证订阅链接本身有效。
3. proxy-groups:策略组
proxy-groups 决定节点如何被“打包”成一个可选择的分组,每一项常见字段:
- name:分组名称,规则段会引用这个名字
- type:分组类型,常见的有 select(手动选择)、url-test(自动测速切换)、fallback(失败自动切换)、load-balance(负载均衡)
- proxies:该分组包含哪些节点或其他分组的名称
- url / interval:url-test 与 fallback 类型使用,指定测速地址与检测间隔(秒)
客户端界面上那一排排“选择节点”的下拉列表,对应的就是这里每一项 select 类型的分组。
4. rules:分流规则
rules 是一个从上到下按顺序匹配的列表,格式通常是 类型,匹配内容,目标策略。常见类型包括 DOMAIN-SUFFIX(域名后缀匹配)、DOMAIN-KEYWORD(域名关键词)、IP-CIDR(IP 段匹配)、GEOIP(按地理位置库判断)、RULE-SET(引用外部规则集合)。最后一般会有一条 MATCH,策略名 作为兜底,凡是前面规则都没命中的流量,统一交给这条规则处理。规则列表越靠前优先级越高,一旦某条命中,后面的规则不再继续判断。
补充说明
较新的 Clash Meta(mihomo)内核还支持 rule-providers 字段,用来声明外部规则集(比如按域名分类打包好的规则文件),规则段里通过 RULE-SET,规则集名称,策略 引用,这样规则文件可以独立更新,不用把几千条域名硬编码进主配置里。
订阅更新时,哪些内容会被覆盖
这是最容易踩坑的地方。订阅链接指向的是服务商托管的一份完整 YAML,客户端“更新订阅”这个动作,本质是重新下载这份文件并整体替换本地缓存。也就是说,proxies(节点列表)、proxy-groups(策略组结构)、rules(规则列表)这三块内容,只要订阅服务商的原始文件里有,更新后就会被整体覆盖为服务商提供的最新版本——你手动加的自定义规则、调整过的分组顺序,大概率都会随之消失。
而端口、局域网开关、模式这类基础运行参数,情况因客户端而不同:多数图形客户端会把这些参数单独存成一份“运行时覆盖”,不写回订阅文件本身,所以刷新订阅通常不影响端口设置;但如果你是直接编辑本地 YAML 文件、再把它当作“本地配置”导入使用,而不是走订阅链接刷新机制,那就完全没有覆盖问题——因为压根不存在“重新下载”这个动作。
需要特别注意的一种情况是:部分订阅服务商支持在生成链接时附加参数,插入自定义规则或强制指定某些分组,这类内容同样会在每次更新时被重新写入,和你本地的修改无法共存。判断的关键只有一句话:只要内容来自“下载”而不是“手动输入”,它就会在下次更新时被重新下载覆盖。
多个配置文件如何管理:切换、去重与备份
大部分图形客户端(Clash Verge Rev、FlClash、ClashX Meta 等)都支持同时保存多份 Profile,通过界面上的列表在不同订阅或本地文件之间切换,互不影响。管理多份配置时建议遵循以下几个原则。
按用途分开保存,而不是反复改同一份
如果你同时使用多个订阅服务商,或者一份用于日常、一份用于测试新节点,应该把它们作为独立的 Profile 分别保存,而不是在同一份文件里来回粘贴替换。这样切换时只需要在客户端列表里点选,不涉及任何文本编辑,出错概率最低。
本地覆写规则,避免被订阅更新冲掉
如果确实需要长期保留一些自定义规则(比如给某个内部服务加白名单直连),更稳妥的做法是使用客户端提供的“覆写”或“合并”功能——大多数现代客户端支持在订阅之外单独维护一份本地覆写文件,更新订阅时只替换服务商原始内容,本地覆写部分保持独立,不会被一起冲掉。如果客户端没有这个功能,退一步的办法是每次更新前手动备份当前生效的 YAML,更新后再把自定义规则段落粘贴回去。
定期清理重复与失效节点
长期使用同一个订阅账号,时间久了容易出现节点列表冗余、部分节点已下线但仍留在分组里的情况。养成定期检查的习惯:
- 打开当前生效 Profile,查看 proxies 数量是否与订阅商后台展示的节点数一致
- 对 url-test 类型分组做一次手动测速,剔除长期不可用的节点(部分客户端支持在界面直接移出分组)
- 确认 proxy-groups 里没有重复引用同一节点导致的分组混乱
备份的最小可用集合
如果需要迁移到新设备或者重装客户端,只要保留以下两类内容,基本就能完整还原此前的使用状态:订阅链接本身(用于随时重新拉取最新节点与规则),以及本地覆写或自定义规则文件(如果有)。不需要额外备份客户端缓存的临时文件,那些内容下次拉取订阅时会自动重新生成。
注意
不要把包含节点密码、UUID 等敏感信息的 Profile 文件上传到公开仓库或分享给不信任的第三方,订阅链接本身也应当视为敏感信息保管,泄露后建议第一时间在服务商后台重置。
常见排查场景与对应字段
结合前面讲的字段划分,几类常见问题基本都能对应到具体区块去定位:
- 连不上网、代理无法生效:先检查基础运行参数区块的端口设置和 mode 是否为预期值
- 某个网站走了不该走的节点:回到 rules 区块,按顺序检查是否有更靠前的规则提前命中,规则列表是自上而下短路匹配的
- 切换节点后不生效:确认对应 proxy-groups 的 type 是否为 select,并确认客户端界面选中的分组和规则里引用的分组名称一致
- 更新订阅后自定义规则消失:这属于本文第三部分讲的覆盖机制,是预期行为,需要改用本地覆写方式保存自定义内容
把 Profile 当作一份结构化的配置说明去理解,而不是一堆看不懂的 YAML 文本,大多数排查工作会明显变得有据可依。遇到界面上某个开关的效果和预期不一致时,回头看它对应的字段值,通常比反复重装客户端更有效。