入门指南 预计阅读 12 分钟

Clash Profile 是什么:订阅配置、本地 YAML 与多配置切换管理入门

从 Profile 的概念讲起,区分远程订阅与本地配置文件,说明更新间隔、配置覆写与多份配置之间的切换和备份方法。

Profile 是配置记录，不是单个节点

Clash 客户端中的 Profile 通常指一份可选择、可加载的配置记录。它可能来自订阅链接，也可能来自磁盘上的 YAML 文件。客户端往往还会为这条记录保存名称、来源地址、更新时间和更新策略；这些管理信息不一定写在内核读取的 YAML 里。

完整配置可以包含监听端口、DNS、代理节点、代理组和分流规则。节点只是其中的一部分。导入配置后，还要让客户端启用它，内核才会按最终配置处理新连接。订阅已添加、配置已启用、系统代理已打开，是三个不同的状态。

三个容易混淆的操作

  • 更新订阅：从原来的地址重新获取内容，不代表一定切换到这份配置。
  • 切换 Profile：更换当前使用的配置来源，代理组、规则和 DNS 都可能随之变化。
  • 切换节点：在当前配置的某个代理组中更改选择，通常不更换整份配置。

界面名称因客户端而异，常见入口包括「订阅」「配置」和「Profiles」。本文用 Profile 统称配置记录，不把某款客户端的按钮名称当作所有产品的统一菜单。

远程订阅、本地 YAML 与代理提供者的区别

类型包含内容更新方式适用情况
远程 Profile服务端返回的配置；是否完整取决于订阅格式客户端按 URL 重新拉取节点和规则由订阅来源维护
本地 Profile本地 YAML 文件中的配置手动编辑或重新导入固定配置、离线留档、测试规则
代理提供者可由代理组引用的节点集合按提供者的更新设置刷新保持主配置稳定，仅更新节点

远程订阅是一种获取方式，YAML 是一种数据格式，两者不是对立关系：远程订阅也可以返回 YAML。本地导入通常会在客户端内部保存副本，编辑原始下载文件后，客户端中的副本未必同步变化，需要确认它是复制导入还是直接引用文件。

订阅链接也不保证能被 Clash 内核直接读取。仅有节点 URI 列表、网页 HTML、登录页或错误消息，都不能当成完整 Clash 配置加载。导入前应选择订阅来源明确提供的 Clash 或 mihomo 兼容格式，并核对客户端使用的内核。

proxy-providers 不是另一份完整 Profile

在支持此功能的内核中，主配置的 proxy-providers 定义节点来源，proxy-groups 可以通过 use 引用提供者。提供者刷新节点时，不等于替换主配置的 DNS、规则或端口。规则提供者 rule-providers 则加载规则集合，也不能与节点提供者混为一谈。

首次导入：先确认格式，再确认启用状态

  1. 在 安装包页面选择适合操作系统的客户端。记录客户端版本和内核版本，后续排查配置兼容性时需要这两项信息。
  2. 打开配置管理入口，添加远程订阅地址，或导入本地 .yaml、.yml 文件。远程地址应粘贴完整，避免混入空格、换行和聊天软件附加的标点。
  3. 给记录设置明确名称，例如「日常-远程」「办公-本地」「测试-DNS」。名称用于管理，不会自动生成同名代理组。
  4. 执行更新并查看结果。若出现解析失败，先核对返回内容和格式，不要靠反复打开系统代理解决语法错误。
  5. 选择并启用这份配置，检查代理组与规则列表是否加载，再决定启用系统代理或 TUN。

系统代理用于让遵循系统代理设置的应用连接本地代理端口；TUN 通过虚拟网络接口接管符合路由条件的流量。二者都不是导入配置的必要步骤，也不会自动修复配置中的节点认证错误。TUN 能力还取决于内核、操作系统权限和路由设置。

端口以客户端实际显示值为准。下文示例使用 7890 作为混合代理端口，这只是示例配置值；不能据此认定所有客户端都监听 127.0.0.1:7890。

本地 YAML 示例：理解配置边界

下面是一份用于理解字段关系的本地配置示例，适合在 mihomo 环境中检查基础结构。它只包含直连出口，不提供远程代理能力。保存为 local-direct.yaml，导入后可以观察端口、代理组和规则之间的关系。

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

proxies: []

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手动选择
  - MATCH,DIRECT
  • mixed-port 为 HTTP 与 SOCKS 代理共用的监听端口；端口被其他进程占用时，需要改用空闲端口。
  • allow-lan: false 不向局域网设备开放代理访问；它与是否启用 TUN 是不同设置。
  • mode: rule 表示按规则分流。示例最后的 MATCH,DIRECT 接收前面未匹配的请求。
  • 手动选择 组里只有 DIRECT，所以命中该组仍然直连。组名被规则引用时必须一致。

YAML 缩进使用空格，不要混用 Tab。像 false 这样的布尔值应与字符串区分；列表项目需要保留 -。出现解析错误时，优先查看日志指出的行及其上一行，常见问题是缩进层级、漏写冒号或引号没有闭合。

能解析并不等于能联网。语法检查通过后，还要分别确认节点是否存在、代理组引用是否有效、规则是否命中预期出口。Clash 原版、Clash Premium 与 Clash Meta（现称 mihomo）的功能范围不同，不能只看扩展名就判断配置兼容。

更新间隔：区分订阅刷新与节点健康检查

远程 Profile 的自动更新一般由客户端管理。主配置里的 HTTP 代理提供者则可使用 interval 设置更新周期；在 mihomo 的相关字段中，该值以秒计。两者作用于不同层级，不应认为设置了一个就会自动管理另一个。

一个明确的周期换算

  • 3600 秒为 1 小时。
  • 21600 秒为 6 小时。
  • 86400 秒为 24 小时。

这些换算适用于以秒为单位的字段。客户端界面也可能要求输入分钟，或直接提供小时选项，应以输入框标注为准。日常配置可以先按订阅来源建议的周期更新；没有特别要求时，可从每天一次开始，再根据节点变动频率调整。

节点健康检查只是测试指定地址的连通性与延迟，不会下载新的节点列表。列表中出现失效节点时，应区分「健康检查失败」和「订阅拉取失败」：前者关注出口、测试地址和超时；后者关注订阅地址、网络路径、访问权限及响应格式。

配置覆写：把个人设置与远程内容分开

直接编辑远程订阅下载得到的 YAML，下一次刷新时可能被替换。需要长期保留的个人规则、DNS 或端口设置，应优先使用客户端提供的覆写、合并或脚本功能。具体能力取决于客户端，Clash 内核本身不会识别所有客户端专用的覆写文件格式。

先确认最终生效的配置

可以把加载过程理解为「订阅源配置 → 客户端合并与覆写 → 内核运行配置」。这是排查思路，不是所有客户端固定不变的执行顺序。部分客户端会用界面设置覆盖配置端口，部分会区分全局覆写与单个 Profile 的覆写，排查时要查看最终运行配置而不是只看订阅原文。

  1. 先做单项修改：例如只添加一条域名直连规则，避免同时调整 DNS、TUN 与全部代理组。
  2. 确认合并语义：列表可能是替换、前置或追加。规则按顺序匹配，把新增规则追加到兜底 MATCH 后面，通常不会得到预期效果。
  3. 核对引用名称：自定义规则指向的代理组，必须存在于合并后的配置中。
  4. 刷新后复查：手动更新一次订阅，再检查新增规则是否仍在、排序是否正确。

跨多个 Profile 共用覆写时尤其要小心：配置 A 有「手动选择」组，不代表配置 B 也有。若共享规则依赖这个名称，切换后可能产生无效引用。可以统一自己维护的组名，也可以为每份 Profile 设置独立覆写，避免把来源不同的配置强行套进一份修改脚本。

多配置切换：一份启用，多份留档

普通单实例客户端通常选择一份主 Profile，再叠加自身支持的覆写。添加三份订阅，不代表三份规则会自动合并，也不代表所有节点同时出现在同一个代理组里。需要聚合节点时，应明确设计主配置与代理提供者，而不是依赖配置列表的排列顺序。

建议保留三个用途清晰的记录

  • 日常配置：使用稳定来源，自动更新，作为默认入口。
  • 备用配置：来源和访问路径应经过单独确认，定期手动更新，避免临时需要时才发现已经失效。
  • 实验配置：验证 DNS、规则或 TUN 参数，关闭不必要的自动更新，便于比较修改前后。

切换前记下当前配置名、模式、代理组选择和端口。切换后检查新配置是否仍使用规则模式，以及 DNS、局域网访问和 TUN 是否发生变化。客户端可能保留某些全局开关，因此更换 Profile 并不总会恢复所有设置。

已有连接不一定跟随切换立即换出口，具体取决于客户端重载行为和连接是否被关闭。验证时应新建请求；必要时在客户端关闭旧连接，或重启目标应用。不要只凭一个仍在传输的下载任务判断切换是否成功。

备份与恢复：保存来源、覆写和运行条件

只备份 YAML 往往不足以完整恢复客户端。远程地址、更新周期、覆写文件以及界面上的全局设置，可能分别保存在客户端数据库或配置目录中。迁移前应优先使用客户端支持的导出功能，并确认导出内容是否包含敏感信息。

  1. 保存来源：记录订阅的管理位置、配置名称和更新周期；含令牌的链接放入受保护的存储位置。
  2. 保存本地文件：备份本地 YAML、覆写脚本和自行维护的规则文件。依赖相对路径的配置还要保留目录关系。
  3. 记录运行条件：记下客户端与内核版本、实际监听端口、系统代理状态及 TUN 设置。
  4. 做一次恢复验证：先导入配置，再加载覆写，确认日志没有解析或引用错误，最后测试新连接。

文件名可以采用 daily-2026-08-27.yaml 与 override-2026-08-27.yaml，让来源和日期一眼可辨。备份不是把缓存永久当作有效订阅：节点凭据可能过期，恢复后仍需重新拉取远程来源并验证连接。

常见问题：更新、切换与恢复异常

订阅更新成功，为什么自定义规则消失了？

通常是修改落在了远程配置副本上，刷新后被来源内容替换。先从备份找回规则，再迁入客户端支持的覆写位置，并确认列表合并方式与规则顺序。不要继续在每次更新后手工修补整份订阅。

切换配置后节点列表没有变化，应该检查哪里？

先确认执行的是「启用」而不只是「更新」，再查看当前活动配置标记和重载日志。如果最终配置使用代理提供者，两份 Profile 也可能引用同一份节点来源。还应检查界面是否仍展示上一次缓存的列表。

本地配置可以自动获取新节点吗？

纯静态节点列表不会自行变化。若本地主配置使用受支持的 HTTP 代理提供者，并设置了更新参数，就可以让主配置保留在本地、节点按远程来源刷新。此时需要分别备份主配置与提供者的来源设置。

导入另一款客户端后提示字段不支持，能直接删掉吗？

先核对新客户端实际使用的内核及版本。字段可能属于 mihomo 扩展，也可能是旧内核功能或客户端专用元数据。删除前应确认它承担的功能，否则即使解析通过，也可能丢失 DNS、规则或路由行为。可结合本站协议参考与内核文档逐项确认。

管理多份 Profile 的关键是分清四个位置：配置从哪里来、个人修改保存在哪里、当前启用哪一份，以及内核最终加载了什么。按照这四项检查，更新覆盖、切换异常和迁移丢失设置的问题通常都能缩小到具体环节。

下载客户端