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

Profile 与 config.yaml 的关系

Profile 通常是 Clash 图形客户端对“一份可选择的配置档案”的称呼。它可能来自本地 YAML 文件，也可能关联一个远程订阅地址。除了配置正文，客户端还可能为它保存名称、来源、更新时间和覆写设置。这些管理信息属于客户端，不一定写在内核读取的 YAML 中。

config.yaml 则是常见的内核配置文件名。mihomo 是 Clash Meta 项目发展而来的内核，可以读取包含监听端口、节点、代理组、DNS 和分流规则的配置。文件名不必固定为 config.yaml：命令行可以通过 -f 指定其他文件，图形客户端也可能生成自己的运行时文件。

• Profile 列表：保存多份候选配置，便于按用途选择。
• 当前启用的 Profile：客户端用它生成或加载当前配置。
• 运行时配置：内核实际使用的内容，可能已经叠加全局设置、覆写和脚本处理。

因此，排查问题时要区分“原始订阅”“客户端编辑结果”和“内核当前配置”。只打开磁盘上的某个 config.yaml，未必能看到连接日志里正在执行的全部规则。

本地配置与远程订阅怎么选

本地配置也可以包含 proxy-providers 或 rule-providers，继续从远程获取节点与规则。“本地”只说明这份 Profile 的入口来源，不能据此认定所有资源都已离线保存。备份时若漏掉 provider 缓存和依赖文件，在断网环境下仍可能无法恢复。

订阅 URL 不是配置格式

同一个导入框接收的是网址，但网址返回的内容可能不同。完整 Clash YAML 可以包含 proxies、proxy-groups 和 rules；Base64 编码的节点列表通常只有节点信息，不能直接当作完整规则配置。另一些 YAML 是专供 provider 使用的 proxies 列表，也不等同于完整 Profile。

导入失败时，先查看客户端的错误详情，确认返回的是配置，而不是登录页、过期提示或 HTML 错误页。若服务端提供格式选择，应选择与当前内核兼容的 Clash 或 mihomo 配置。订阅地址通常带有访问令牌，不要贴到公共转换页面、截图或问题反馈里。

多套配置命名与分组方法

命名先表达用途，再表达来源，最后标记是否为实验副本。不要只用“配置 1”“新订阅”或反复追加“最终版”，否则很难判断当前哪份可以安全更新。下面是一组可直接采用的名称：

• 日常-主订阅：保留服务端更新，用于平时浏览。
• 备用-独立订阅：使用另一来源，故障时手动切换。
• 办公-本地规则：明确处理办公域名和内网地址。
• 实验-DNS-2026-08-18：只验证 DNS 改动，不覆盖日常配置。

日期适合写在快照和实验副本中，长期订阅名称则保持稳定。每份配置的备注建议记录三项：来源类型、适配内核、依赖的覆写名称。例如“远程 YAML；mihomo；叠加办公域名规则”，比只写一个服务商缩写更有助于迁移。

备用配置要提前验证

两份名称不同的 Profile 可能实际上指向同一订阅地址。这样的副本适合测试修改，却不能作为独立的线路备用。应提前确认备用配置能够更新、代理组有可选节点、目标网站能够访问，再切回日常配置。等主线路失效后才首次导入，容易同时遇到订阅下载和节点连接两个问题。

切换 Profile 的操作与验证顺序

不同客户端使用“配置”“订阅”或“Profiles”等入口，按钮名称也会随版本变化。先在配置列表中定位目标条目，区分“编辑”“更新”和“启用”：编辑只修改内容，更新只获取来源的新内容，启用才负责切换当前配置。有些客户端更新当前条目后会自动重载，有些则需要额外确认。

1. 记录当前状态。记下当前 Profile、规则模式、代理组选择和系统代理开关；必要时截取不含订阅地址的界面。
2. 更新目标条目。远程 Profile 先刷新一次，查看更新时间和失败提示。本地配置先检查依赖文件路径。
3. 启用目标配置。等待加载完成，检查日志是否出现 YAML 解析错误、策略不存在或资源下载失败。
4. 重新选择代理组。新配置的组名可能不同，不能假定上次选中的节点会自动继承。
5. 建立新连接。重新打开测试网页，在连接详情中核对规则、策略链和目标地址。

例如，旧配置使用 mixed-port: 7890，新配置改成 mixed-port: 7897，终端仍把代理指向 127.0.0.1:7890 时就可能连接失败。图形客户端也可能用全局端口设置覆盖 Profile 中的端口，所以要检查实际监听值，而不是只比较两个文件。

在 Linux 上可用下列命令查看示例端口是否存在监听。若设置了其他端口，应按实际值调整：

ss -lntp 'sport = :7890'
ss -lntp 'sport = :7897'

已有下载、视频播放或长连接可能沿用切换前的连接。验证时优先创建新连接；必要时在客户端连接页关闭相关连接再重试，避免把旧连接的出口误认为新配置未生效。

自定义规则放哪里才便于维护

远程订阅应尽量保留为可更新的原始来源，把长期修改放进客户端支持的覆写、合并或脚本入口。不同客户端对字段的合并方式并不一致：有的替换整个列表，有的允许前置或追加规则。保存前应查看生成后的配置，确认修改确实进入运行时结果。

规则顺序与代理组名称一起检查

下面是规则顺序示意，不是完整配置。它将内部示例域名与私网网段直连，再交给后续规则处理其他流量：

rules:
  - DOMAIN-SUFFIX,office.example,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

office.example 使用保留的示例域名；该规则不应被当作真实办公环境的域名。最后的 MATCH,DIRECT 只是让示例结构完整，照搬会让剩余流量全部直连。实际配置应保留所需的后续规则，并使用已经定义的兜底策略。

规则从上到下匹配。自定义域名规则若被追加在 MATCH 后面，就不会被执行。若规则指向名为 办公出口 的代理组，切换后的配置也必须存在同名组，否则可能加载失败。只引用 DIRECT 可以避免组名依赖，但“直连”是否符合需求仍需根据业务判断。

每次只调整一类设置

先验证规则，再调整 DNS，最后检查 TUN。不要一次同时替换订阅、修改 DNS、改端口和启用 TUN，否则出现故障时难以确定原因。全局覆写还可能影响所有 Profile；如果只希望实验配置使用新 DNS，应先确认覆写的作用范围。

备份、配置测试与回滚

完整备份至少包含原始配置、客户端管理数据和自定义覆写。单独复制一个运行时 config.yaml，可能丢失订阅 URL、自动更新时间、脚本和代理组选择记录；只导出客户端列表，也可能没有保存 provider 的实际内容。

1. 在客户端支持的导出或备份入口生成副本，并记录客户端版本和内核版本。
2. 把手工维护的规则、覆写脚本、provider 文件和必要的证书依赖一起归档。
3. 为变更前后的快照使用日期，例如 daily-2026-08-18.yaml，避免覆盖唯一可用副本。
4. 将包含节点密码、订阅令牌或控制接口密钥的备份存入受限目录；共享前先脱敏。

用 mihomo 测试候选配置

命令行用户可以先检查内核版本，再在独立目录中测试候选文件。下面假设当前目录已经有 candidate.yaml，且 mihomo 已加入命令搜索路径：

mihomo -v
mkdir -p ./profile-check
mihomo -t -d ./profile-check -f ./candidate.yaml

-t 用于测试配置，-d 指定工作目录，-f 指定配置文件。相对路径依赖与外部资源需要按实际目录准备；涉及规则集等资源时，也可能需要下载。测试通过说明内核接受这份配置，不代表节点可用、DNS 正确或系统代理已生效。

回滚时先恢复上一份可用 Profile，再恢复与它配套的覆写，重新加载后建立新连接测试。若使用命令行，更换磁盘文件后还需要通过既有管理方式重载配置或重启对应服务；覆盖文件本身不等于内核已经读取。

Profile 管理常见问题

日常维护可以固定为一个流程：保留原始来源，用覆写承载长期规则，切换后核对新连接，重要修改前保存可回滚快照。配置数量不必多，来源明确、作用范围清楚、恢复步骤可重复更重要。