Clash 配置文件 Profile 是什么:多配置切换与管理方法

先分清 Profile、订阅链接与 config.yaml

结论先说：Profile 是客户端管理一份代理配置的逻辑单元，订阅链接是这份配置的远程来源，YAML 文件则是客户端下载或导入后保存到本地的具体内容。三者有关联，但不是同一个东西。

在 Clash Verge Rev、Clash Nyanpasu 等图形客户端里，Profile 常被翻译为“订阅”“配置”或“配置文件”。一个 Profile 通常包含名称、来源地址、本地文件路径、更新时间和当前启用状态。用户点击某个条目时，客户端会读取对应 YAML，检查语法，再把处理后的配置交给 Mihomo 内核运行。

config.yaml 只是常用文件名

config.yaml 是 Clash 生态中常见的默认名称，并不是每个 Profile 都必须使用这个名字。图形客户端为了避免重名，可能把文件保存成随机标识，例如 7f2c8a.yaml；也可能按订阅名称建立单独目录。此时列表里显示“办公线路”，磁盘上的文件名却完全不同。

一份可运行的基础 YAML 通常包含监听端口、代理节点、策略组和规则。下面的结构只展示 Profile 中各部分的关系，不包含实际节点凭据：

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "示例节点"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "示例节点"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,节点选择
  - MATCH,DIRECT

建立多个 Profile：先命名，再导入

多个配置并存时，最实用的管理方法不是保留“配置 1”“新订阅”之类默认名称，而是在导入当天就写清用途。名称至少应回答三个问题：用于什么场景、来源是哪一组线路、是否允许自动更新。

推荐使用“场景—来源—更新方式”命名

• 日常—主订阅—自动更新：平时使用，允许客户端定时拉取。
• 办公—内部规则—手动更新：包含公司域名分流，更新前先检查规则变化。
• 移动网络—低流量：策略组优先选择较稳定、流量成本较低的节点。
• 测试—本地 YAML—禁止覆盖：用于调试规则、DNS 或 TUN 参数。
• 回退—2026-08-27：保留一份已验证可用的静态副本。

以 Clash Verge Rev 2.x 的常见界面为例，可以进入「订阅」→「新建」，粘贴订阅 URL，填写名称后保存，再点击下载或刷新按钮。导入本地文件时，使用「订阅」→「新建」→「本地文件」，选择扩展名为 .yaml 或 .yml 的文件。不同版本的按钮文字可能是“导入”“新建配置”或“添加订阅”，核心步骤相同。

1. 先记录当前正在使用的 Profile 名称。
2. 新建远程订阅或导入本地 YAML。
3. 把默认名称改成可识别的场景名称。
4. 执行一次手动更新，确认更新时间发生变化。
5. 打开配置详情，检查节点数、策略组和规则是否齐全。
6. 最后再切换到新 Profile，避免导入失败时中断当前连接。

切换 Profile：确认生效配置而不是只看选中状态

点击 Profile 后，客户端通常要完成四个动作：解析 YAML、应用覆写、把配置交给 Mihomo、刷新策略组状态。列表出现选中标记，只能说明用户发起了切换；判断是否真正生效，还要查看内核状态、当前策略组和连接记录。

切换后的四项检查

1. 检查内核状态：进入「设置」→「内核设置」或「系统设置」→「内核」，确认 Mihomo 状态为运行中。
2. 检查端口：确认当前 Profile 的 mixed-port 与系统代理端口一致。常见值是 7890，但实际应以当前配置为准。
3. 检查策略组：进入「代理」页面，确认“节点选择”“自动选择”等分组来自新配置，而不是上一份 Profile 的名称。
4. 检查连接：打开「连接」或「日志」，访问一个测试页面，查看新连接命中了哪条规则及哪个策略组。

如果两个 Profile 都使用 mixed-port: 7890，系统代理通常不需要修改，因为监听地址和端口保持不变。若新配置改成 mixed-port: 7897，系统代理也要同步指向 127.0.0.1:7897。只修改 YAML 而保留旧系统代理端口，会表现为浏览器无法连接代理。

TUN 模式切换要多检查一层

TUN 模式通过虚拟网络接口接管流量，范围比普通系统代理更广。Profile 切换后，如果修改了 tun、DNS、路由排除项或网络栈，客户端可能需要重新启动 TUN。常见操作路径是「设置」→「系统设置」→「TUN 模式」，先关闭，等待 2 至 3 秒，再重新开启。

启用 TUN 后，可检查日志里是否出现接口创建、路由写入和 DNS 监听信息。若配置使用 dns.listen: 0.0.0.0:1053，还应确认 1053 端口没有被另一份正在运行的代理程序占用。多个客户端同时开启 TUN，容易出现默认路由被反复改写的情况，因此测试切换时应只保留一个内核运行。

更新 Profile：区分远程刷新、覆写与运行时重载

“更新订阅”通常只负责重新下载远程 YAML。“重载配置”则让内核重新读取本地内容。部分客户端会把两个动作连续执行，部分客户端需要用户手动切换一次 Profile。更新后节点数量没有变化，并不一定代表失败，服务端也可能只调整了节点参数或规则内容。

用更新时间和日志判断刷新结果

执行更新前，先记下 Profile 显示的时间，例如 2026-08-27 09:30。刷新后确认时间改变，并查看日志中的 HTTP 状态。成功请求常见状态为 200；401 或 403 多与订阅权限、令牌失效有关；404 表示远程路径不存在；连接超时则需要检查当前网络和直连规则。

YAML 对缩进敏感。列表项前通常使用两个空格，不应混入制表符。编辑后可先观察客户端语法检查结果，再交给内核加载。若错误信息指向第 86 行，真正缺少冒号或缩进错位的位置也可能在第 85 行，因此要连同上一行一起检查。

编辑本地配置：先确认文件映射关系

多 Profile 环境最常见的误操作，是打开一个名为 config.yaml 的文件进行修改，却发现客户端界面没有变化。原因通常是客户端当前运行的是另一个缓存文件，或者运行配置还叠加了覆写内容。编辑前应从 Profile 的详情菜单进入文件，而不是在磁盘中凭文件名猜测。

安全的编辑顺序

1. 在配置列表确认当前启用条目。
2. 使用该条目的“打开文件”“编辑配置”或“打开目录”入口。
3. 复制原文件，并在副本名称中加入日期和用途。
4. 每次只修改一个区域，例如先改 mixed-port，验证后再改 DNS。
5. 保存后执行语法检查和配置重载。
6. 通过日志确认内核读取了预期文件。

对于 Mihomo，常见核心字段包括 mixed-port、allow-lan、mode、dns、tun、proxies、proxy-groups 和 rules。修改字段前要确认客户端是否提供独立开关。例如界面中的 TUN 开关可能通过运行时覆写控制；即使 YAML 写了 enable: false，客户端仍可能在启动内核前合并自己的设置。

需要判断最终配置时，可以查看客户端提供的“运行配置”“当前配置”或调试导出功能。这里展示的是远程订阅、本地覆写和客户端设置合并后的结果，比单独查看订阅缓存更接近 Mihomo 实际收到的内容。

清理旧 Profile：先停用，再删除

配置列表积累过多后，重复名称和失效订阅会增加误切换概率。清理时不要从当前启用项开始。先切换到确认可用的主 Profile，访问网页并检查日志，再处理旧条目。

删除前保留必要信息

• 记录 Profile 的显示名称、来源类型和最后更新时间。
• 本地自定义配置先导出 YAML，再删除列表条目。
• 确认旧 Profile 没有独有的规则、策略组或 DNS 参数。
• 远程订阅只保留仍在使用的入口，避免多个名称指向同一地址。
• 删除后检查缓存目录，区分客户端自动管理文件与手动备份文件。

建议把配置分成“当前使用”“测试中”“回退”三类。当前使用保留 1 至 2 份，测试配置在验证结束后合并或删除，回退配置保留最近一个稳定版本即可。以日期命名的副本如果超过数月，还要考虑规则和节点信息已经失效，不应长期当作首选配置。

多配置管理常见问题

一套可重复的 Profile 管理流程

稳定管理多个 Clash 配置，关键是让“来源、文件、运行状态”能够互相对应。导入时写清名称，切换后检查端口和策略组，更新前保存回退副本，本地修改则通过覆写或独立 Profile 保留。这样即使配置数量增加，也能快速判断当前内核究竟加载了哪一份内容。

• 名称包含场景、来源和更新方式。
• 远程订阅与本地测试配置分开保存。
• 切换后检查内核、端口、策略组和连接日志。
• 自动更新的订阅缓存不直接承担长期自定义修改。
• 大改前保留一个带日期的可用副本。
• 清理时先切换到主配置，再删除旧条目。