Clash Profile 配置文件基础：导入、切换与多配置管理

PROFILE / 01

Profile 到底保存什么

在 Clash 图形客户端中，Profile 通常指一份可被内核读取的配置。它可能来自远程订阅地址，也可能是手工导入的本地 YAML 文件。客户端负责下载、保存、切换和更新 Profile，Clash 或 mihomo 内核则根据当前激活的配置建立监听端口、载入节点、生成策略组并按规则处理连接。

不同客户端对 Profile 的中文名称并不完全一致，常见显示包括“配置”“配置文件”“订阅”或“Profiles”。这些界面名称虽然不同，核心关系基本一致：配置列表中可以保存多份文件，但同一时刻通常只有一份主配置交给内核运行。切换条目不是单纯更换节点，而是可能同时替换端口、DNS、策略组、规则和 TUN 参数。

一份简化配置可以呈现这些部分之间的关系。实际订阅通常包含更多节点和规则，字段支持范围还取决于所用内核版本。

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

proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - example-node
      - DIRECT

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

SOURCE / 02

订阅配置与本地配置的差别

远程订阅 Profile 由一个订阅地址提供。客户端保存地址后，可以按需或定时重新下载配置。更新得到的新内容通常会替换客户端缓存的旧版本，因此节点增减、策略组调整和规则变化会在下一次载入时生效。订阅地址往往包含访问凭据，应当按密码处理，不要贴入公开截图、日志或问题描述。

本地 Profile 则来自设备上的 YAML 文件。它适合保存手工规则、固定端口、实验性 DNS 设置，或作为故障排查用的最小配置。由于本地文件没有远程来源，客户端通常不会自动获取更新；后续变化需要重新编辑文件，或者再次导入修订后的副本。

还有一类容易混淆的情况：部分客户端允许复制远程配置并生成本地副本。副本在生成那一刻继承订阅内容，但此后通常不再随原订阅自动更新。判断一份配置究竟属于哪种来源，可以查看条目是否显示订阅地址、更新时间、更新间隔或刷新按钮。如果只显示文件路径和修改时间，它更可能是本地文件。

如果既需要订阅更新，又需要长期保留自定义规则，应优先使用客户端提供的覆写、合并或扩展功能；具体名称可能是 Override、Mixin、Merge 或覆写配置。此类功能在订阅下载完成后追加或修改指定字段，能够减少直接编辑缓存文件造成的覆盖问题。不同客户端采用的合并语法并不统一，迁移前要先阅读对应客户端的字段说明。

IMPORT / 03

导入配置与首次检查

导入远程订阅时，应在客户端的 Profile 页面使用“从 URL 导入”或同类入口，而不是把订阅地址粘贴到节点名称、规则编辑器或浏览器代理设置中。导入成功只代表客户端取得了响应，还需要确认返回内容能被当前内核解析。若服务端返回登录页面、提示文字或格式不完整的 YAML，客户端可能创建条目，但内核加载时仍会报错。

导入本地文件前，可以先检查扩展名和文本编码。YAML 通常使用 .yaml 或 .yml，建议保存为 UTF-8。YAML 依赖缩进表达层级，应使用空格，避免在同一层级混入制表符。策略组引用的节点名必须与节点定义一致，规则指向的策略名也必须实际存在。

1. 保留当前可用配置。首次导入新 Profile 前，不要立刻删除原配置，以便加载失败时快速切回。
2. 完成导入并查看更新时间。远程条目应显示最近拉取时间，本地条目应能识别文件名。
3. 激活配置并观察内核状态。确认客户端没有持续显示解析失败、启动失败或端口冲突。
4. 核对策略组。查看组内是否存在可选节点，自动测试组是否能够完成延迟检测。
5. 检查代理接管方式。系统代理模式要核对监听端口；TUN 模式要确认虚拟网卡状态和权限。
6. 分别测试直连与代理目标。单一网页能够打开，不足以证明规则、DNS 和全部策略都正确。

对于 mihomo 配置，还要留意仅由特定内核支持的字段。某份 Profile 在 mihomo 客户端中正常，不代表它能直接交给较早的原版 Clash 内核。迁移时如果出现“字段未知”或解析失败，应比较内核类型和版本，而不是反复修改订阅地址。

SWITCH / 04

正确切换多套 Profile

切换配置前，先记录当前运行模式和正在使用的策略组。部分客户端会按 Profile 保存策略选择，另一些客户端则会在新配置中尝试恢复同名策略。如果两份配置都包含“节点选择”，但组内节点完全不同，界面可能回到第一个可用选项。切换后应重新确认关键策略，而不是默认沿用旧结果。

端口是另一项需要校样的字段。配置甲使用 mixed-port: 7890，配置乙使用 mixed-port: 7893 时，系统代理若仍指向 7890，切换到配置乙后就会出现浏览器无法连接，而内核本身看似正常的情况。有些桌面客户端会自动同步系统代理端口，有些只负责加载配置；因此每次跨配置切换后，都应查看客户端显示的实际监听地址。

TUN 模式的切换影响更广。不同 Profile 可能包含不同的 DNS 模式、路由排除项、自动路由设置和接口探测参数。切换时虚拟网卡可能短暂重建，已有连接也可能继续沿用旧路径，直到连接关闭。验证新配置时，建议重新打开测试应用，必要时断开旧连接后再观察规则命中。

适合日常使用的切换顺序

1. 确认目标 Profile 最近一次更新成功，并查看是否存在加载错误。
2. 记下当前策略组选择，尤其是手动选择组和全局模式出口。
3. 切换目标 Profile，等待内核完成重载。
4. 检查运行模式是 Rule、Global 还是 Direct，避免模式被另一份配置改写。
5. 确认系统代理或 TUN 状态，并核对实际监听端口。
6. 打开连接日志，测试一条直连规则和一条代理规则。

如果切换后只想更换出口，不需要替换规则与 DNS，那么直接在现有 Profile 的策略组中选择节点更合适。减少不必要的配置切换，也能降低端口、规则和 TUN 参数同时变化带来的排查成本。

CATALOG / 05

多配置整理与命名方法

配置数量增加后，问题往往不在导入，而在辨认。多个条目都叫 config.yaml，很难判断来源、用途和更新方式。建议让名称至少包含“来源类型”和“使用场景”，例如“订阅-A-日常”“本地-规则测试”“备份-迁移前”。名称中不必写入订阅凭据、完整 URL 或节点服务器地址。

日期适合放在一次性快照中，例如“备份-2026-05-18”；持续更新的订阅则不宜每次改名，否则会产生大量难以区分的重复项。对长期使用的配置，可以在单独的记录中保存内核要求、端口、DNS 模式和自定义内容，而不是依赖记忆。

建议保留的信息

• 来源：远程订阅、本地文件，还是由订阅复制出的本地副本。
• 用途：日常使用、规则调试、TUN 测试或迁移备份。
• 内核要求：适用于原版 Clash，还是依赖 mihomo 扩展字段。
• 接管方式：系统代理、TUN，或仅为局域网设备提供代理端口。
• 修改点：是否调整过 DNS、端口、规则或策略组。
• 更新时间：订阅最后刷新时间或本地文件最后修订日期。

删除配置前要辨认它是否正在被使用。部分客户端会阻止删除当前 Profile，另一些会自动切换到列表中的另一项。稳妥做法是先激活一份确认可用的配置，再删除重复条目。对于含有重要手工规则的本地文件，应先导出到明确的备份目录。

REVISION / 06

更新、修改与覆盖关系

远程 Profile 的核心特征是“本地缓存受远程内容管理”。直接在客户端缓存中修改节点、规则或 DNS 字段，短期内可能生效，但下一次刷新订阅时通常会被新文件替换。若发现自定义规则总在更新后消失，应先检查修改位置，而不是把更新失败误判为内核问题。

长期修改可以采用三种思路。第一种是使用客户端的覆写或合并功能，只保存需要改变的字段；第二种是把订阅复制为本地配置，然后完全自行维护；第三种是使用 proxy-providers 和 rule-providers 将节点集合、规则集合与主配置分开。第三种方式更适合熟悉 YAML 和 mihomo 配置结构的用户，并且需要确认远程资源格式符合对应 provider 的要求。

proxy-providers:
  remote-set:
    type: http
    url: "https://example.invalid/provider.yaml"
    path: ./providers/remote-set.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.example.com/generate_204"

proxy-providers 不等同于客户端 Profile。Profile 是交给内核的主配置；provider 是主配置引用的外部资源。一个 Profile 可以引用多个 provider，也可以完全不使用 provider。将两者区分开，才能判断究竟应刷新客户端订阅、更新 provider，还是重新载入主配置。

编辑 YAML 时还要注意列表覆盖。某些合并工具会把新的 rules 整体替换旧列表，某些则支持前置或后置插入。规则自上而下匹配，如果自定义规则被追加到 MATCH 之后，即使文件能够正常载入，这些规则也永远没有机会命中。完成合并后，应查看最终生成的配置，而不只检查覆写片段。

PROOF / 07

多 Profile 常见故障定位

切换后所有应用都无法联网

先确认内核是否运行，再检查系统代理端口与当前 Profile 的监听端口是否一致。如果使用 TUN，查看虚拟网卡是否成功建立，并确认客户端具有所需权限。还可以暂时关闭接管功能，验证基础网络本身是否正常。不要一开始就删除配置，因为端口不同或 TUN 重建失败更常见。

配置更新成功，但节点没有变化

检查当前激活的是否确实是刚更新的条目。名称相近的重复 Profile 很容易造成误判。随后查看更新时间、策略组内容以及内核日志。如果主配置引用 provider，还要分别确认 Profile 与 provider 的刷新状态；只更新其中一层，不一定会立刻改变节点列表。

本地规则保存后又消失

这通常表示编辑的是订阅缓存，随后一次更新覆盖了修改。应把规则迁移到客户端支持的覆写机制，或者创建独立本地 Profile。迁移时同步复制被规则引用的策略组名称，避免规则存在但目标策略缺失。

一份配置在旧客户端正常，新客户端加载失败

比较两边实际使用的内核，而不只比较客户端名称。mihomo 支持的扩展字段会随版本演进，原版 Clash 与不同分支的字段集合也有差异。查看错误信息对应的字段，确认是语法缩进问题、字段类型问题，还是内核不支持。对于布尔值、数字和字符串，还要保持正确类型，不要为了绕过错误而统一加引号。

切换后策略组选择被重置

先看新旧配置是否存在完全相同的策略组名称，以及新组内是否包含原来选择的节点。若目标不存在，客户端只能回退到可用选项。自动测试组还可能根据延迟重新选择节点，这是组类型的正常行为，并不等于 Profile 切换失败。

只有部分域名无法访问

打开连接日志，查看请求命中的规则和策略。若域名解析失败，应进一步检查 DNS 配置、fake-ip 过滤项和上游可达性；若命中了错误策略，则检查规则顺序。多配置环境中，还要确认当前看到的规则编辑器属于正在运行的 Profile，避免在未激活条目中反复修改。

有效的排查记录应包含当前 Profile 名称、来源类型、内核名称与版本、运行模式、监听端口、接管方式以及一条具体错误。订阅地址和节点凭据应在分享前隐藏。通过这些信息，可以把问题快速归入“配置解析”“内核启动”“端口接管”“DNS 解析”或“规则匹配”，减少无方向的重复导入。

FINAL CHECK / 08

多配置管理检查表

• 配置名称能够辨认来源和用途，不依赖默认文件名。
• 远程订阅与本地文件分开管理，明确哪些内容会被更新覆盖。
• 切换后检查运行模式、策略组、监听端口以及系统代理或 TUN 状态。
• 重要自定义规则保存在覆写或本地文件中，并有可恢复的备份。
• 升级客户端或内核前，核对 Profile 是否使用特定分支的扩展字段。
• 排查时先确认当前激活条目，避免修改了未运行的配置。
• 删除重复配置前，先切换到已验证可用的 Profile。

Profile 管理的重点不是保存尽可能多的配置，而是让每份配置的来源、用途和更新边界都清楚。日常配置保持稳定，测试内容放入独立条目，远程订阅避免直接改缓存，切换后按端口、模式、策略和 DNS 顺序校样，能够显著降低多配置并存时的定位成本。