Clash Profile 是什么:配置文件基础概念与多配置切换管理入门
Profile 是 Clash 客户端加载的完整配置单元,与订阅、节点、规则是包含关系。本文讲清配置文件的来源、存放位置、更新机制,以及多个配置并存时如何切换与管理。
Profile 到底是什么:一份 YAML,装了四类东西
在 Clash 及其衍生内核(Clash Premium、Clash Meta、mihomo)的语境里,Profile(配置文件)指客户端实际加载并生效的那一份完整 YAML 文件。它不是"订阅"的同义词,也不是"节点列表"的同义词——订阅只是获取配置文件的一种渠道,节点只是配置文件里的一段内容。理解清楚这层包含关系,后面的存放位置、更新逻辑、多配置切换才不会混着讲。
一份典型的 Clash 配置文件通常按顺序包含以下几段:
- 通用运行参数:端口(port / socks-port)、局域网访问开关(allow-lan)、运行模式(mode: rule / global / direct)、日志级别(log-level)、外部控制器地址(external-controller)等,决定客户端启动后的基础行为。
- DNS 配置段:是否启用内置 DNS、上游服务器地址、是否走 fake-ip 模式、是否针对特定域名走 DoH/DoT,直接影响域名解析速度与分流准确性。
- proxies 节点列表:每一个代理服务器的连接参数——协议类型(如 Shadowsocks、VMess、Trojan、Hysteria2)、服务器地址、端口、加密方式与密钥等。这是"能不能连上"的基础。
- proxy-groups 策略组:把 proxies 里的节点按用途归类,定义选择方式(select 手动选择、url-test 自动测速切换、fallback 故障转移、load-balance 负载均衡),这是"怎么用节点"的逻辑层。
- rules 规则段:按域名、IP 段、GEOIP、进程名等条件,把流量匹配到某个策略组或直连/拦截,这是"什么流量走哪条路"的调度层。
这五段合在一起,才构成一份完整可用的 Profile。少了 proxies 段,策略组无从选择;少了 rules 段,客户端只能按 mode 里的全局默认行为处理所有流量,谈不上"分流"。
注意 NOTICE
订阅链接下发的内容本质上也是一份 Profile(或是可以被客户端解析、补全成 Profile 的节点数据),客户端把它保存为本地文件后才会加载。也就是说,订阅是"配置文件的一种自动化来源",不是脱离配置文件存在的独立实体。
配置文件的三种来源:订阅、本地导入、手动编写
按获取方式,Profile 大致分三类,日常使用中经常混用:
1. 订阅链接自动生成
这是最常见的方式。服务方提供一个 HTTP(S) 链接,客户端请求该链接后,服务端返回节点信息(有的直接是完整 YAML,有的是 Base64 编码的节点列表)。多数 Clash 系客户端(Clash Verge、FlClash、ClashX Meta 等)会在拿到节点数据后,结合内置或自定义的规则模板,拼装成一份完整可用的 Profile,再保存到本地。这也是为什么同一条订阅链接,在不同客户端里导入后,策略组结构、规则数量可能不完全一样——拼装模板不同。
2. 导入本地文件
如果已经有别人分享的或自己整理的 YAML 文件,可以通过客户端的"从文件导入"功能直接加载,不经过网络请求。这类 Profile 不会自动更新,内容完全固定,适合调试和离线场景。
3. 手动编写/在线编辑器修改
进阶用户会直接用文本编辑器或客户端内置的配置编辑面板,手写或修改 proxy-groups、rules 段,常见场景包括:给某个策略组加自定义节点、给某类 App 单独指定出口、屏蔽特定域名。这类修改建议先备份原文件,避免语法出错导致客户端加载失败后无法回退。
配置文件存放在哪:不同客户端的路径差异
Profile 是本地文件,具体存放路径因客户端而异,排查问题时经常需要手动去目录里确认文件是否真的更新了。常见客户端的大致存放规律如下:
| 客户端 | 配置文件存放规律 | 说明 |
|---|---|---|
| Clash Verge / Clash Verge Rev | 应用数据目录下的 profiles 文件夹,每个订阅对应一个以哈希/UUID 命名的 .yaml 文件 | 由 config.yaml 记录当前激活的是哪一份 |
| ClashX Meta(macOS) | 用户目录下的 .config/clash/ 文件夹 | 可直接用终端或编辑器打开对应文件 |
| FlClash(跨平台) | 应用私有数据目录内的 profile 子目录 | 移动端一般不建议直接改文件,走内置编辑面板更安全 |
| 纯内核(mihomo/Clash Meta core) | 启动参数 -f 指定的路径,默认读取当前目录下的 config.yaml | 没有 GUI 包装,路径完全由启动方式决定 |
需要强调的是,大多数图形化客户端并不建议用户直接去应用数据目录里手改这些自动生成的文件——因为客户端自身的更新逻辑可能会在下一次刷新时把手改内容覆盖掉。如果确实需要长期保留自定义规则,更稳妥的做法是使用客户端提供的"合并配置"或"覆写(override)"功能,把自定义片段单独存放,再叠加到订阅生成的主配置之上。
配置文件怎么更新:自动刷新与手动更新的区别
只有通过订阅链接获取的 Profile 才具备"更新"这个动作,本地导入或手写的文件不会自己变化。更新机制主要看两个字段:
- update-interval:部分客户端在订阅信息里记录这个值(单位通常是分钟),达到时间间隔后自动向订阅链接重新请求一次,拿到最新节点后覆盖旧文件对应的 proxies 段。
- 手动更新按钮:客户端订阅管理界面通常都有一个"更新"或刷新图标,点击后立即触发一次请求,不受 update-interval 限制,常用于服务方刚更换节点、需要立刻同步的场景。
更新时客户端一般只替换节点相关内容,不会动用户在本地额外添加的自定义规则(前提是用了"合并/覆写"机制,而不是直接改了自动生成的文件本体)。如果发现更新后自定义的分流规则消失了,大概率是因为改动写在了会被覆盖的主文件里,应该改为使用覆写功能重新配置。
注意 NOTICE
订阅更新依赖网络请求成功。如果客户端提示更新失败,先确认订阅链接本身能否正常访问,再检查是否触发了服务端的请求频率限制,这两类问题比软件本身故障更常见。
多个配置文件如何切换与管理
大多数用户不会只用一份配置——比如同时订阅了两个服务商,或者本地保存了一份用于流媒体分流的定制版本、一份用于日常上网的极简版本。这种情况下,配置文件的"切换"和"管理"就成了日常操作里绕不开的一环。
切换逻辑:同一时刻只有一份处于激活状态
客户端内核在运行时只会加载一份 Profile。图形界面上看到的"配置列表"本质上是多份已保存的 YAML 文件,点击某一项即把它设为当前激活配置,客户端会重新读取内核并应用新的 proxies、proxy-groups、rules。切换过程通常伴随短暂的连接中断,是正常现象。
命名与分类建议
配置数量一多,靠默认生成的文件名很难分清用途,建议在客户端里给每份配置重命名,标注清楚来源与用途,例如区分"日常订阅""临时测试""本地自定义规则"等类别,减少切错配置的概率。部分客户端支持给配置打标签或分组,可以按场景归类管理。
合并与覆写:不切换也能叠加规则
如果只是想在现有订阅基础上加几条自定义规则(比如把某个内部服务域名强制直连),不必新建一份完整配置,更推荐使用客户端的"覆写(override)"或"合并配置"功能。这类功能允许单独维护一小段 YAML 片段(通常只包含要新增或替换的规则),应用时叠加在主配置之上,主配置更新后覆写片段依然保留,不需要重复添加。
删除与清理
长期不用的测试配置建议及时删除,尤其是包含真实节点凭据的文件——即便订阅已经失效,文件里的密钥信息仍然是明文保存在本地的,清理旧配置也是基本的使用卫生习惯之一。
常见疑问快速对照
| 疑问 | 结论 |
|---|---|
| Profile 和订阅是一回事吗 | 不是,订阅是获取 Profile 的一种渠道,Profile 是最终生效的完整配置文件 |
| 手改配置文件会不会被下次更新覆盖 | 直接改自动生成的主文件会被覆盖,建议用覆写/合并功能单独保存自定义内容 |
| 多份配置能同时生效吗 | 内核同一时刻只加载一份,多配置靠切换而非同时叠加(叠加靠覆写机制) |
| 本地导入的文件会自动更新吗 | 不会,只有绑定了订阅链接的配置才具备自动/手动更新能力 |
把这几点厘清之后,再去看客户端界面上的"配置管理""订阅信息""覆写"这些标签,就能对应到本文讲的存储、更新、叠加三套机制,不容易再把 Profile、订阅、节点、规则这几个概念混着用。