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

Profile 是一套可切换的运行配置

在 Clash 客户端中，Profile 通常指一份能够交给内核读取的配置文件。它一般采用 YAML 格式，内容可以包含监听端口、代理节点、策略组、分流规则、DNS 设置、代理提供器以及规则提供器。客户端选择某个 Profile 后，会解析这份文件并将有效配置交给 Clash 或 mihomo 内核。

Profile 不是单个节点的同义词。一个节点只是配置中的连接条目；策略组负责组织多个节点或其他策略；规则再按照域名、IP、进程等条件，把请求交给相应策略组。切换节点通常只改变某个策略组当前选中的成员，而切换 Profile 可能同时改变节点列表、规则顺序、DNS 模式、端口和 TUN 参数，影响范围更大。

不同客户端对 Profile 的称呼可能略有差异，例如“配置”“订阅”“配置文件”或“Profiles”。界面名称虽然不同，核心关系基本一致：客户端保存配置来源，内核读取当前配置，用户再通过策略组调整具体出口。

配置来源决定更新方式

常见 Profile 来源有三类：通过订阅地址导入、从本地 YAML 文件导入，以及在客户端中创建或复制后自行维护。来源不同，后续更新行为也不同。建立多配置体系前，应先确认每一份配置是远程维护还是本地维护。

通过订阅地址导入

订阅地址返回的是远程配置内容。客户端通常会保存该地址，并允许手动刷新或按设定间隔更新。刷新时，客户端重新请求远程内容，再用新内容替换对应的缓存版本。具体是否保留本地改动取决于客户端实现，因此不应直接在会被刷新覆盖的远程配置上长期修改规则。

订阅地址可能携带账户识别信息，应按敏感凭据管理。不要将地址写入公开截图、公开代码仓库、共享文档或问题日志。需要在另一台设备导入时，优先通过可信渠道传递，并在不再使用的设备中删除对应配置。

导入本地 YAML 文件

本地文件适合测试、自建规则和离线备份。部分客户端会复制文件内容到自身配置目录，后续修改原文件并不会自动同步；另一些客户端可能直接引用指定路径。导入后可修改一个容易识别的描述字段或规则，再重新载入，确认客户端实际读取的是副本还是原路径。

手动创建或复制配置

复制现有 Profile 后再调整，适合保留稳定版本并测试新规则。例如从“日常稳定”复制出“DNS 测试”，只修改 DNS 与相关规则。测试通过后，再决定是否将改动合并到长期配置。这样可以避免在唯一可用配置上反复编辑。

切换 Profile 后按层级确认生效

在界面中点选 Profile，只表示客户端准备使用该配置。是否真正生效，还要看配置解析、内核运行和系统流量入口三个层级。较稳妥的切换顺序是：保存当前工作，选择目标 Profile，等待解析完成，确认策略组状态，再检查系统代理或 TUN。

1. 选择目标配置：在 Profile 列表中点选需要使用的条目，确认当前标记已移动到目标配置。
2. 检查载入结果：查看客户端是否出现 YAML 语法、字段兼容、端口冲突或代理提供器下载失败提示。
3. 检查策略组：确认关键策略组存在，并查看当前节点是否仍然可用。不同配置中的同名策略组也可能包含完全不同的节点。
4. 确认运行模式：检查 Rule、Global 或 Direct 模式。一般日常分流使用 Rule；Global 会让大部分请求交给全局策略；Direct 则直接连接。
5. 确认流量入口：浏览器等遵循系统代理的程序需要系统代理处于正确状态；不读取系统代理的程序通常需要 TUN 或应用自身的代理设置。
6. 执行访问检查：分别测试直连目标、代理目标和 DNS 解析，避免只凭节点延迟判断配置是否完整生效。

切换到监听端口不同的 Profile 时，系统代理中保存的端口也要匹配。例如旧配置使用 mixed-port: 7890，新配置改为 mixed-port: 7897，但系统仍指向旧端口，应用就可能表现为无法连接。部分客户端会自动同步系统代理端口，仍建议在切换后核对一次。

mixed-port: 7890
mode: rule
allow-lan: false

dns:
  enable: true
  ipv6: false
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

这段示例只展示配置层级，不构成完整 Profile。实际配置还需要与所用内核版本、节点协议、规则结构和本地网络条件匹配。YAML 使用空格表达层级，Tab 字符、缩进错位或重复字段都可能导致载入失败。

多配置管理以用途、来源和状态命名

配置数量增加后，最常见的问题不是文件缺失，而是无法判断哪一份正在使用、哪一份可以更新。仅使用“配置 1”“新配置”“最终版”之类名称，很难在故障时快速回退。建议名称至少包含用途和来源，必要时再附加状态或日期。

日常使用通常不需要保存大量重复副本。保留一份主用远程配置、一份经过验证的本地稳定备份，以及少量按场景区分的测试配置，已经能够覆盖大多数切换和回退需求。过多副本会造成策略组选择、更新时间和订阅来源混淆。

区分系统代理配置与 TUN 配置

系统代理主要影响遵循操作系统代理设置的应用，结构相对直接。TUN 模式会建立虚拟网络接口并接管更广范围的流量，还涉及路由、DNS 劫持、接口自动检测和权限。若经常在两种模式之间切换，可以分别维护 Profile，避免每次手动改动多项参数。

使用 mihomo 内核时，TUN 配置可能包含 stack、auto-route、auto-detect-interface 和 DNS 劫持等字段。字段支持情况与内核版本、操作系统及客户端权限有关。将适用于某个平台的 TUN 段直接复制到另一平台，可能出现接口选择错误、局域网访问异常或 DNS 路径变化。

保留一个已验证的回退点

稳定备份应来自实际运行正常的配置，而不是刚下载但尚未使用的文件。备份时记录导出日期、内核类型以及适用场景。发生订阅内容异常、规则提供器不可达或新版本字段不兼容时，可以先切回稳定配置恢复连接，再单独检查更新内容。

订阅更新与本地修改需要分层处理

远程订阅的优势是节点、策略组和规则可以由来源方集中更新，但这也意味着刷新可能覆盖直接写入该 Profile 的改动。为了让更新与自定义同时可维护，需要把“远程生成内容”和“本机个性化内容”分开。

方案一：使用客户端覆写功能

部分客户端支持覆写、混入或脚本处理。它们会在远程配置下载后，再追加或修改指定字段。例如统一调整端口、启用局域网访问、补充规则或替换 DNS 设置。覆写语法并不属于所有 Clash 客户端通用标准，迁移客户端前应先导出并检查其格式。

方案二：使用 proxy-providers 与 rule-providers

mihomo 支持通过代理提供器和规则提供器把外部内容拆分管理。主配置负责端口、DNS、策略组和规则顺序，提供器负责按 URL 或文件路径加载节点与规则集。这样可以只更新外部数据，而不替换整个主配置。

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

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote-nodes

示例地址使用不可解析的保留域名，只用于展示结构。实际使用时，需要填入合法来源，并确认返回内容符合代理提供器格式。完整订阅配置与 provider 文件的结构并不一定相同，不能只把任意订阅地址放入 proxy-providers 后就假定能够解析。

方案三：维护完整本地配置

需要精确控制规则顺序、DNS 链路和 TUN 行为时，可以维护完整本地 YAML，并手动更新节点部分。这种方式控制范围更明确，但维护成本也更高。每次修改后都应先执行配置检查，再切换为当前 Profile，不要让未经验证的文件直接替代稳定版本。

导入失败与切换异常的检查路径

Profile 问题可以按“来源获取—文件解析—内核运行—系统接管—规则命中”的顺序检查。按层级定位比反复删除和重新导入更有效，也能保留错误现场。

订阅导入后列表为空

• 确认订阅地址仍然有效，并检查客户端是否显示 HTTP 状态或超时信息。
• 确认返回内容是 Clash 可读取的 YAML，而不是登录页面、错误提示或其他客户端专用格式。
• 检查系统时间。证书校验、订阅有效期和远程请求可能受明显错误的系统时间影响。
• 如果当前网络本身无法访问订阅来源，可先使用已有稳定 Profile 建立连接，再执行更新。

配置可以导入，但无法切换

• 查看日志中的具体字段与行号，重点检查 YAML 缩进、数组格式和重复键。
• 确认配置使用的字段受到当前内核支持。为 mihomo 编写的扩展字段不一定能被旧版 Clash 内核接受。
• 检查监听端口是否已被其他程序或另一个内核实例占用。
• 检查规则引用的策略组是否存在，名称大小写和字符必须一致。
• 检查外部 provider 文件是否成功下载，路径是否可写，内容格式是否符合对应类型。

切换成功，但访问路径没有变化

• 确认客户端界面的当前 Profile 标记已经变化，并检查内核是否完成重载。
• 确认系统代理地址与新 Profile 的监听端口一致。
• 确认当前运行模式不是 Direct，并检查目标请求最终命中了哪条规则。
• 使用 TUN 时检查虚拟接口、路由和权限状态；关闭 TUN 后残留的系统代理也需要单独核对。
• 浏览器或应用可能复用既有连接。切换后可关闭相关连接或重启应用，再进行测试。

建立可重复的日常配置流程

一套可维护的流程可以压缩为六步：导入、命名、检查、启用、测试、备份。首次导入时记录来源与用途；载入前检查语法和兼容性；启用后分别验证策略组、DNS、规则命中和流量入口；确认稳定后再创建本地回退版本。

远程配置更新时，不应只看节点数量是否变化。还要检查关键策略组名称、规则顺序、DNS 模式和监听端口，因为这些项目会直接影响客户端原有选择和系统设置。若更新后出现异常，先回退到已验证 Profile，再对比两份配置的结构差异。

对于经常移动办公或切换网络环境的设备，可以按场景保留配置，例如“家庭系统代理”“移动网络 TUN”“开发环境本地规则”。每份配置只承担清晰用途，并尽量共享稳定的命名规则。这样在网络变化时，操作目标是切换已验证场景，而不是临时修改大量字段。

Profile 管理的重点不是积累更多文件，而是让每一份配置的来源、更新方式、适用场景和回退关系都可判断。只要将远程订阅与本地修改分层、将节点选择与整套配置切换区分开，再按固定顺序核验生效状态，多配置使用就能保持清晰。