Clash Profile 是什么：订阅配置与本地配置的区别及多套切换管理

Profile 是客户端管理的配置档案

Profile 通常指客户端保存的一份配置档案，不等于一个节点，也不等于一种代理协议。它可能来自远程订阅，也可能来自本地 YAML 文件。客户端负责保存来源、名称、更新信息和选中状态，内核则读取最终生成的配置，建立监听端口、加载节点并执行分流规则。

一份完整配置可以同时包含 mixed-port、mode、dns、proxies、proxy-groups 和 rules。其中，节点是连接参数，策略组是节点选择入口，规则决定连接使用哪个策略。切换 Profile 可能同时改变这三部分，不能把它理解成只换了一个服务器。

不同客户端可能把入口标为“配置”“订阅”或“Profiles”，这些是界面名称，并非 Clash 或 mihomo 内核统一规定的菜单。判断操作是否生效，应看当前配置标记、内核加载结果和实际规则，而不是只看列表里是否多出了一张卡片。

远程订阅与本地 YAML 有什么区别

两者主要区别在来源与更新方式，不在 YAML 的能力。远程订阅通常由客户端通过 URL 获取；本地配置则由用户导入、创建或编辑。远程返回的内容如果是完整 Clash 配置，通常也以 YAML 表达，但“订阅链接”并不保证返回的一定是可直接加载的完整配置。

检查项	远程订阅 Profile	本地 YAML Profile
来源	客户端记录的订阅 URL	磁盘文件或客户端编辑器
内容变化	手动或定时重新获取	手动修改，或由外部工具更新
直接编辑风险	下一次更新可能覆盖修改	通常不受远程订阅刷新影响
节点时效	以服务方返回内容为准	复制来的节点不会自行刷新
迁移要点	保存来源与本地覆写配置	保存文件及其引用的外部资源

订阅地址不一定等于配置文件地址

有的服务返回完整 YAML，有的只返回节点列表，还有的返回编码后的协议链接集合。后两类内容需要客户端支持相应导入格式，或经过可信的转换流程，才能形成可用配置。浏览器能打开 URL，只能说明请求得到了响应，不能证明响应适合当前内核。

如果导入后提示缺少字段或解析失败，应先检查返回内容是不是登录页、错误提示或不兼容格式。订阅 URL 常含访问令牌，排障时不要公开完整地址，也不要把它交给来源不明的在线转换服务。

先用最小 YAML 理解配置的边界

下面是一份用于理解字段关系的本地配置，监听 127.0.0.1:7890，所有连接都选择内置的 DIRECT。它不含远程代理节点，因此不能用于验证代理出口，适合在隔离的测试配置中检查 YAML 加载与规则结构。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ROUTE
  - MATCH,DIRECT

mixed-port: 7890 表示同一个入口接受 HTTP 与 SOCKS 代理连接；如果该端口已被占用，需要改用空闲端口。
mode: rule 表示按规则列表处理连接；若运行时被切成全局模式，不能继续用这份规则判断分流结果。
ROUTE 是策略组名称，规则引用它时必须保持名称一致；内置策略 DIRECT 不需要另建节点。
MATCH 是兜底规则，应放在本例最后，否则后续规则没有匹配机会。

缩进使用空格，不使用制表符。导入现有订阅时，不要把这段示例整体覆盖到原文件中；它只展示结构，不包含服务方提供的节点和策略。完整字段含义可查阅配置字段说明。

多套配置如何命名、更新与切换

名称记录用途，备注记录来源

建议使用“用途－来源－管理方式”命名，例如“日常－订阅A－远程”“办公－本地规则－覆写”“排障－直连－本地”。不要只写“配置1”“配置2”，也不要在名称里放订阅令牌。客户端允许备注时，另外记录导入日期、内核类型和覆写位置，避免把这些信息全部挤进名称。

更新与切换分两步检查

更新前留退路：导出可用配置，并保存当前策略组选择和本地覆写。导出文件可能含节点凭据，应放在受控目录。
只更新目标项：确认操作对象的名称与来源，检查更新时间是否变化；更新时间变化不代表配置已被启用。
查看加载结果：激活目标 Profile 后检查内核日志，确认没有 YAML 解析错误、未知字段导致的加载失败或策略引用错误。
复查运行参数：检查代理模式、监听端口、DNS 和 TUN 开关。部分客户端会用全局设置覆盖文件里的同名字段。
验证新连接：打开一个新请求，在连接面板查看命中规则、策略链与出口，不只看节点延迟。

例如旧配置监听 7890，新配置改为 7891，终端里原有的 http_proxy 不会自动跟随变化。浏览器的系统代理入口与终端环境变量也不是同一套设置。多套配置尽量固定本地入口，能减少切换后的端口错配。

自定义规则怎样避免被订阅更新覆盖

优先把个人规则保存在客户端支持的持久覆写层，而不是直接修改订阅下载副本。常见实现包括合并配置、前置规则或配置处理脚本，但名称、作用范围和数组合并方式随客户端而异。没有通用的“所有客户端都适用”覆写文件格式，操作前需要确认当前客户端的说明。

先确认插入位置，再确认策略名称

假设需要让示例域名直连，可以把下列规则放在最终 rules 列表中较前的位置。这里展示的是最终配置应有的排列，不是可直接套用到任意客户端的覆写语法：

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,ROUTE

在规则模式下，规则按顺序匹配，首条命中后执行对应策略。如果个人规则被追加在 MATCH 后面，通常不会产生预期效果。如果改为引用 ROUTE，则最终配置里必须存在同名策略组。订阅更新把组名改成其他名称后，旧覆写也需要调整。

检查作用范围：覆写是只绑定一个 Profile，还是对所有配置生效？办公规则不应意外进入其他配置。
检查列表合并：客户端可能替换整个 rules 数组，也可能前置或追加条目，不能凭“合并”二字推断行为。
检查最终产物：若客户端提供运行配置预览，查看个人规则是否出现、顺序是否正确、目标策略是否存在。
做一次更新回归：保存覆写后手动刷新订阅，再查看规则和新连接，确认修改确实跨更新保留。

客户端不支持持久覆写时，可以复制为本地配置再编辑，但这份副本不再自动获得原订阅的节点变化。应明确选择“手动维护副本”还是“继续使用远程更新”，不要把本地修改与自动刷新混在同一个临时文件里。

proxy-providers 与多 Profile 不是同一层管理

proxy-providers 是配置内部引用节点提供器的机制；多个 Profile 则是客户端保存多套配置档案。以 mihomo 为例，可以在一份本地配置里引用多个提供器，让节点来源与本地规则分开维护，但仍需要正确设置策略组对提供器的引用。

提供器的更新通常只涉及它提供的节点，不等于重新下载整份主配置。提供器 URL 也必须返回当前实现接受的格式，不能认定任何“订阅链接”都能直接填入。若还使用 rule-providers，规则集合的下载与主配置更新同样需要分别排查。

普通使用场景可以先维护一份稳定订阅，再添加明确的本地覆写。只有确实需要拆分节点来源、规则集合与更新周期时，再考虑提供器结构，避免同时维护多份重复规则而难以定位最终来源。

配置切换后异常，按四层定位

来源层：确认更新的是目标 Profile，响应内容是配置而不是网页；检查订阅是否失效，避免连续重复导入同一个错误地址。
加载层：查看内核是否接受新配置。遇到缩进错误、策略不存在或字段不兼容时，先修正加载问题，不要直接归因于节点超时。
入口层：核对 7890 或自定义端口是否在监听，系统代理与终端是否指向同一入口；TUN 则另外检查权限、路由和 DNS 接管状态。
分流层：确认运行模式为 rule，检查新连接命中的规则和策略组选择，再判断是不是远端节点或服务端问题。

导入了三份订阅，节点会自动合并吗？

通常不会。多数客户端一次启用一份主配置，其他订阅只是留在列表中。确需合并时，需要客户端明确支持的合并功能，或在兼容内核中通过提供器组织节点，不能仅凭列表中存在三项判断。

切换 Profile 会自动切换 TUN 吗？

不一定。TUN 可能由客户端全局开关管理，也可能由配置与覆写共同决定，还涉及系统权限。应检查客户端运行状态和最终配置，不能只看导入文件里有没有 tun 字段。

备份一份 YAML 就能完整迁移吗？

不一定。主配置可能引用本地规则文件、提供器缓存、证书路径或客户端覆写；订阅 URL 和界面中的策略选择也可能单独保存。迁移前列出这些依赖，在新设备导入后验证端口、规则与新连接，并妥善处理含凭据的文件。

多配置管理的关键是把“来源更新”“本地修改”“运行选择”分开记录。保留一份确认可用的配置，只对目标项更新，并在每次切换后验证最终规则与新连接，通常比反复删除和重新导入更容易定位问题。