Clash Profile 是什么:多份订阅与本地配置的切换和管理

Profile 是配置条目，不是单个节点

Clash 客户端中的 Profile，通常指配置列表里的一份配置条目。它可以来自订阅链接，也可以来自本地导入的 YAML 文件。列表里同时保存三份 Profile，不代表内核正在同时运行三套配置；常见桌面客户端一次启用一份主配置，再叠加客户端支持的覆写、合并或运行参数。

先把“配置”“订阅”“节点”分开：订阅是取得内容的来源，YAML 是内容的常见文件形式，Profile 是客户端管理这些内容的入口，节点则是配置中的一个代理出站。切换节点通常只改变某个策略组的选择；切换 Profile 可能连规则、DNS、监听端口和策略组一起更换。

多份配置命名：来源、用途、日期分开记录

建议先保留两类条目：跟随服务方更新的远程配置，以及用于试验和回退的本地配置。不要只命名为“订阅 1”“订阅 2”，也不要把完整订阅链接写进显示名称。链接中的令牌可能关联账户权限，截图时容易泄露。

三份配置的命名示例

• 日常-A-远程：日常使用，保留原订阅来源，按客户端设置自动更新。
• 备用-B-远程：备用线路，单独保存来源与到期信息，不与日常配置混写。
• 实验-规则-本地-20261016：从可用配置复制出的本地副本，只用于测试规则改动。

显示名称不是 YAML 的通用顶层字段。不要为了改 Profile 名称，在配置中随意添加 profile-name。应通过客户端配置条目的重命名或编辑入口修改；如果编辑界面没有名称字段，就在导入前使用清楚的文件名。

导入与启用分两步

1. 打开配置管理页。不同客户端可能称为“配置”“订阅”或“Profiles”，应以实际界面为准。
2. 导入订阅地址或本地文件，先检查新条目的名称、来源类型和更新时间。
3. 主动选择新条目，等待客户端提示加载成功，再查看当前生效的配置标记。
4. 进入代理组页面，确认组名和节点列表已经变化；仅仅出现在配置列表中，不等于已经启用。

本地导入通常会复制文件到客户端的数据目录，但不同产品也可能采用其他管理方式。修改桌面上的原文件后，不能假定客户端里的副本同步改变。需要重新导入，或者使用客户端提供的“编辑文件”“打开配置文件”入口修改其实际管理的文件。

切换 Profile：检查模式、端口和策略组

一次可靠的切换，应同时核对“加载是否成功”和“流量是否走了预期路径”。配置里写了 mode: rule，也不代表界面一定处于规则模式：部分客户端会用运行参数覆盖文件值。最终以客户端当前状态、内核日志和连接详情共同判断。

切换前后的四项检查

1. 备份当前可用项：记录当前 Profile 名称和关键策略组选择，必要时导出配置副本。
2. 确认加载结果：查看日志中是否出现 YAML 解析错误、未知字段或策略组引用不存在等信息。
3. 核对入口设置：检查系统代理、TUN 和监听端口，不要只看节点列表。
4. 建立新连接验证：重新打开测试页面，在连接详情中查看命中规则、策略组和实际出站。

例如旧配置的混合端口是 7890，新配置改为 7891，但终端仍使用旧的代理环境变量，就可能无法连接。以下是两个不同配置中的端口示意，不是要求把它们同时写进同一个文件：

# 日常配置中的入口
mixed-port: 7890
mode: rule

# 切换到另一份配置后，入口可能变为 7891
# mixed-port: 7891

若客户端固定接管端口，上述文件值也可能被覆盖。排查时先看客户端显示的实际端口，再核对浏览器、终端或开发工具里手动设置的代理地址。TUN 是否启用、虚拟网卡是否建立、路由是否安装成功，也需要分别检查，不能从 Profile 名称推断。

订阅更新覆盖修改：把来源与个人设置分层

直接编辑远程 Profile 的下载内容，通常只能保留到下一次更新。更新会重新获取服务方的配置，并可能替换本地缓存。最常见的现象是：刚添加的直连规则消失、手动改过的 DNS 恢复、策略组名称又变回原样。

按修改目标选择保存位置

例如要让 intranet.example.com 直连，规则片段可以写成下面的形式。域名仅用于说明，应替换成实际需要的内部域名；这个片段不是可单独导入的完整配置。

rules:
  - DOMAIN-SUFFIX,intranet.example.com,DIRECT
  - MATCH,Proxy

这里的 Proxy 必须是最终配置里已经定义的节点名或策略组名。切换到另一份只包含 Auto 组的 Profile 后，原来的引用可能失效。多份配置共用覆写时，要么统一策略组命名，要么为不同配置分别绑定覆写，不能只复制规则文本。

“合并”也不一定意味着自动追加。某些工具会替换整个 rules 列表，另一些支持前置、后置或脚本处理。规则应放在 MATCH 等兜底项之前；放在其后通常无法命中。设置完成后，查看客户端生成的运行配置，确认原有规则仍在且顺序符合预期。

两份订阅如何并用：切换与聚合不是同一件事

在配置列表中导入 A、B 两份订阅，通常得到两个可以切换的 Profile，不会自动把两边节点拼进同一个策略组。若只是需要一份备用，分别保留条目更容易排查；若确实需要同时选择两边节点，才考虑节点提供者或客户端明确支持的聚合机制。

主配置与节点提供者的职责

• 主配置负责 proxy-groups、rules、DNS 等整体行为。
• proxy-providers 负责取得兼容格式的节点集合，策略组通过 use 引用提供者名称。
• 完整配置订阅不能不经确认就当作节点提供者使用；是否支持其返回格式，要看内核与来源内容。

以 mihomo 为例，HTTP 类型节点提供者中的 interval: 3600 表示按 3600 秒的间隔更新该提供者，不等于客户端每小时更新整个 Profile。提供者内 health-check.interval 则是健康检查间隔，也不是订阅更新周期。客户端远程 Profile 的自动更新往往另有界面设置，单位还可能显示为分钟或小时。

管理时把这三个动作分别记录：整份配置何时更新、节点集合何时更新、节点何时测试可用性。这样遇到“节点已变化，规则没有变化”时，就能先判断是不是只更新了提供者，而不是反复删除和重新导入所有配置。

配置备份与迁移：源文件、覆写、状态分别保存

只导出一份运行 YAML，不一定能完整恢复日常环境。运行文件可能已经合并了覆写，却没有保留远程订阅地址；也可能包含节点密码、订阅令牌和本地监听设置。它适合帮助还原当时的配置内容，但不能替代客户端的数据备份。

建议保留的备份清单

1. 配置来源：保存订阅来源说明、Profile 名称，以及必要的订阅链接；敏感链接放入受保护的存储位置。
2. 本地 YAML：保存手写配置和试验前的可用副本，例如 daily-local-20261016.yaml。
3. 个人覆写：单独保存规则、脚本及其绑定对象，记录处理顺序。
4. 运行设置：记录端口、系统代理、TUN、DNS 相关设置，以及客户端和内核的实际版本。
5. 选择状态：记录常用策略组的选择；不同客户端保存这类状态的位置和方式可能不同。

迁移时优先使用客户端提供的导出与恢复功能。若必须复制数据目录，先退出客户端，再复制到本地受保护位置，避免复制到仍在写入的数据库或状态文件。不要猜测固定目录路径：安装方式、便携模式和操作系统都会影响实际位置。

恢复后按顺序验证

先导入配置，再恢复覆写，最后逐项开启系统代理或 TUN。第一次验证时只启用一个需要的流量入口，更容易判断问题所在。确认能加载、能解析域名、能建立连接之后，再恢复自动更新与后台启动。

跨客户端迁移时，YAML 中的基础字段可能可复用，但客户端的配置索引、覆写脚本和界面状态不一定兼容。跨内核迁移还要检查专有字段。遇到加载失败，先根据日志定位具体字段，不要把旧客户端整个数据目录直接覆盖到新客户端。

常见问题：配置存在，为什么没有按预期运行

切换后节点变了，规则为什么没变？

先检查两份配置是否本来就使用同一套规则，再检查客户端有没有全局覆写。若共用的覆写替换了 rules，切换源 Profile 后规则仍可能相同。判断依据应是最终运行配置和新连接的命中结果，而不是源文件的预览内容。

删除 Profile，会同时删除订阅账户吗？

删除本地条目通常只影响客户端保存的配置，不会注销服务方账户。但客户端是否同时移除缓存、关联覆写和本地副本，需要看删除提示。操作前导出必要内容；如果订阅链接已经泄露，应到服务方重置链接，而不是仅删除本地 Profile。

本地配置是否永远不会自动变化？

本地文件本身通常不按远程 Profile 的方式更新，但它仍可能引用会自动更新的 proxy-providers 或 rule-providers，也可能叠加客户端的运行设置。需要复现问题时，应记录这些外部来源和更新时刻，不能只保存顶层 YAML。

日常管理最少要做哪些事？

保留一份可用配置作为回退；远程订阅与本地试验分开命名；长期改动放在可持久保存的覆写层；每次切换后用新连接检查规则和出站。首次导入的操作说明可继续查看订阅导入教程，字段关系可查看YAML 结构参考。