Clash 配置文件是什么?Profile 结构入门与多配置切换管理
从 config.yaml 的端口、代理组、规则三大块讲起,解释订阅链接与本地配置的关系,演示在客户端里导入、更新、切换多份 Profile 的正确姿势与常见误区。
刚接触 Clash 的用户常把"配置文件"和"订阅链接"混为一谈,遇到规则不生效、节点切换后没反应、更新完配置反而失效等问题时无从下手。实际上 Clash 系客户端(包括使用 mihomo 内核的 Clash Verge、Clash for Windows 衍生版、ClashX 等)运行的核心就是一份 YAML 格式的配置文件,业内通常称作 config.yaml 或者客户端里的 Profile。理解它的结构、来源与更新机制,是排查绝大多数使用问题的前提。
config.yaml 的三大结构块
一份完整的 Clash 配置文件本质上是纯文本,按功能可以拆成三大部分:基础端口与运行参数、代理组(proxy-groups)、规则(rules)。三者配合出站节点定义(proxies)共同决定流量最终走哪条路径。
port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
proxy-groups:
- name: 自动选择
type: url-test
proxies: [香港01, 日本01, 新加坡01]
url: http://www.gstatic.com/generate_204
interval: 300
rules:
- DOMAIN-SUFFIX,googlevideo.com,自动选择
- GEOIP,CN,DIRECT
- RULE-SET,reject,REJECT
- MATCH,自动选择第一部分是端口与运行模式:port / socks-port 分别开放 HTTP 与 SOCKS5 本地代理端口,mixed-port 则是两者合一的混合端口,大多数现代客户端默认只用这一个;allow-lan 决定是否允许局域网内其它设备接入这台机器的代理;mode 常见取值有 rule(按规则分流)、global(全局走同一节点)、direct(直连,不走代理)。
第二部分是代理组,决定"选哪个节点"。select 类型是手动选择,客户端里点一下就切换;url-test 会按设定的 interval 周期自动测速并选出延迟最低的节点;fallback 是主节点不可用时按顺序回退;load-balance 则把请求按哈希或轮询分摊到多个节点上,常用于需要稳定会话保持的场景。
第三部分是规则,决定"什么流量走哪个组"。规则从上到下逐条匹配,命中即停止,常见规则类型有:
DOMAIN-SUFFIX:按域名后缀匹配,比如googlevideo.com命中所有子域名;GEOIP:按目标 IP 所属国家/地区匹配,常用GEOIP,CN,DIRECT让国内流量直连;RULE-SET:引用外部规则集文件,方便维护大量域名而不用堆在主配置里;MATCH:兜底规则,必须放在最后一行,决定"以上都不命中时怎么办"。
订阅链接与本地配置文件的关系
订阅链接本质上是一个可以直接被客户端 fetch 的 URL,服务端返回的内容就是上面说的那份 YAML 文本(或者是需要客户端再转换一次的通用订阅格式)。客户端拿到这段文本后,并不是每次都重新请求,而是把它保存成本地文件,这份本地保存的文件就是 Profile。换句话说,订阅链接是"配置的来源",Profile 是"配置在本机的落地形式"——即便断网,客户端依然能用上一次同步下来的 Profile 正常工作。
一份 Profile 不一定来自订阅,也可以是完全手写或从别处下载的本地文件,两者在客户端里的地位是一样的,都会出现在配置列表里供切换。区别只在于订阅类型的 Profile 带有一个远程地址,客户端可以按设定的 update-interval(通常以小时为单位)自动重新拉取最新内容并覆盖本地文件;本地文件类型的 Profile 则没有这个自动更新的动作,改动只能手动重新导入。
不少订阅服务会在返回头里带上 subscription-userinfo 字段,包含已用流量、总流量、到期时间,客户端解析后会显示在 Profile 列表旁边,这也是为什么有些订阅导入后能看到流量进度条,有些却只显示一个纯粹的文件名——取决于服务端有没有提供这段信息,与客户端本身无关。
在客户端中导入、更新与切换 Profile
不同客户端的界面用词略有差异,但导入配置的方式基本分两类:粘贴订阅链接,或者选择本地文件。以下是通用操作流程,具体菜单位置请以各客户端实际界面为准。
- 打开客户端的"配置""Profiles"或"订阅管理"页面;
- 点击新增按钮,选择"从 URL 导入",粘贴订阅链接后确认,客户端会自动下载并解析为一份新 Profile;
- 如果是本地配置文件,选择"从文件导入",指向已下载好的
.yaml文件即可; - 导入完成后,在列表中点选该条目将其设为当前生效配置,大多数客户端会用勾选标记或高亮边框表示"正在使用"的那一份;
- 如需更新,点击该条目旁的刷新图标即可重新拉取远程内容,不必删除重建。
关于自动更新,建议把间隔设置在 12~24 小时之间,不要设得过短。频繁请求订阅接口不仅没有必要(节点列表通常不会一天变化多次),部分服务商还会对高频请求做限速甚至临时封禁处理。
| 操作 | 适用对象 | 说明 |
|---|---|---|
| 从 URL 导入 | 订阅链接 | 保存远程地址,可后续手动或自动更新 |
| 从文件导入 | 本地 .yaml | 无远程地址,更新需重新手动导入覆盖 |
| 手动更新 | 订阅类型 Profile | 立即拉取一次最新内容,不等待自动周期 |
| 切换生效 | 所有类型 | 只有被选中的一份 Profile 会驱动当前代理行为 |
值得强调的是,客户端里保存多份 Profile 并不会互相干扰——同一时刻只有被选中的那一份在真正生效,其它未选中的配置只是静态存放,不会占用运行中的端口或消耗额外资源。这也是为什么"多配置管理"是刚需:出差时切一份低延迟的国内中转配置,平时切回主订阅,测试新规则时再切一份临时草稿,互不影响。
多配置管理的常见误区
掌握了导入和切换,接下来这几个误区是实际使用中最容易踩坑的地方。
手动改动会被订阅更新覆盖
如果直接在订阅类型 Profile 的本地文件里手写了额外规则,下一次自动更新会用远程返回的新内容整份覆盖,手改的部分随之消失。需要长期自定义规则又不想失去订阅内容,应使用客户端提供的"覆写""Override"或"补丁配置"功能——它在订阅原始内容之上叠加一层独立保存的自定义规则/代理组,更新订阅时只替换基础部分,叠加层不受影响。
多个订阅的代理组命名冲突
不同服务商的订阅里可能都用了"香港节点""自动选择"这类通用命名,如果尝试把两份订阅内容手动合并到一份配置里,规则引用的代理组名称容易对不上,导致规则匹配后却找不到对应分组,流量会走进兜底的 MATCH 分支而不是预期节点。跨订阅合并配置前,建议先统一检查代理组命名是否唯一。
误以为切换 Profile 等于切换节点
切换 Profile 切换的是整份配置——包括端口、规则、代理组定义;而日常"换个节点线路"通常只需要在当前 Profile 内的某个代理组里重新选择节点,不需要切换整份配置。混淆这两个操作会导致规则和分流逻辑跟着一起变,排查问题时定位不到真正原因。
更新间隔设置过短
前面提到过,把自动更新间隔设成几分钟一次看似"更及时",实际上多数订阅节点列表并不会短时间内频繁变化,过高频率的请求反而增加被限流的风险,合理区间是 12~24 小时,重要变更前手动点一次更新即可。
常见问题
Profile 和订阅链接可以有多份吗?会互相冲突吗?
可以同时保存任意数量的 Profile,它们只是列表里的独立条目,彼此不会冲突。冲突只发生在把多份内容手动合并进同一份配置文件时,命名或规则顺序处理不当才会出问题。
为什么更新订阅后规则突然失效了?
大概率是订阅服务端更新了规则集或代理组结构,原有的自定义手改内容被整份覆盖。使用覆写/补丁功能保存自定义部分,可以避免这个问题反复出现。
本地文件类型的 Profile 能设置自动更新吗?
不能。自动更新依赖一个可请求的远程地址,纯本地文件没有这个地址,内容变化只能通过重新手动导入来同步。
获取 Clash 客户端
准备好配置文件后,先获取一个支持 Profile 管理的客户端,再按上文步骤导入订阅或本地配置即可开始使用。