配置管理 预计阅读 10 分钟

Clash Profile 配置文件是什么：订阅链接、本地配置与多配置切换管理

解释 Profile 与订阅的关系、远程配置与本地 YAML 的区别、更新间隔设置，以及在客户端里并存多份配置并按场景切换的做法。

Profile、订阅链接与运行配置

在 Clash 类客户端中，Profile 通常指一份可保存、更新和启用的配置档案。界面可能将其称为「配置」「订阅」或「Profiles」。它不是单个节点，也不是一个独立代理协议。对 mihomo 内核而言，真正参与运行的是客户端最终交付的配置内容，包括节点、策略组、规则、DNS 与监听端口等设置。

订阅链接是获取远程内容的地址。客户端访问该地址，将响应保存为本地配置，再进行检查和加载。因此，链接、已下载的文件、内核当前运行的配置，是三个不同层次。界面里新增了一个订阅条目，不代表它已经启用；文件下载成功，也不代表里面的所有字段都能被当前内核接受。

对象保存内容主要用途
订阅链接远程地址，常包含访问凭据重新获取服务端发布的配置
远程 Profile下载后的配置及更新相关信息保留来源，按需或定时更新
本地 Profile手工创建或导入的 YAML 文件自行维护节点、规则与配置结构
运行配置客户端处理后交付内核的结果决定当前连接如何解析和出站

完整配置与节点订阅的区别

不是所有标为「订阅」的响应都能直接作为完整 Profile。完整 mihomo 配置可以包含 proxies、proxy-groups、rules 等字段；仅包含节点的资源则可能用于 proxy-providers。其他格式的节点列表，还需要客户端明确支持的导入或转换能力。不能只看文件扩展名判断兼容性。

远程配置与本地 YAML 的维护边界

远程配置：由来源方维护主体内容

远程 Profile 适合持续接收节点变更和服务端规则调整。常见操作路径为「配置」→「新建」或「导入」→「URL」，粘贴来源方提供的兼容链接，完成下载后再选中启用。不同客户端的菜单名称不统一，应以当前版本界面为准，重点确认条目的来源类型与启用状态。

直接编辑远程配置的下载副本有覆盖风险。下次更新可能重新生成节点、策略组和规则，使手工增加的域名规则消失。需要长期保留修改时，优先使用客户端提供的覆写、合并或脚本功能；这些能力属于客户端层，不是所有 mihomo 客户端都具有相同实现。

本地配置：维护责任在文件本身

本地 YAML 适合规则实验、离线留档或固定场景。它不会因为最初来自某个订阅就自动保持更新。若文件内部使用了远程 provider，则对应资源仍可按自身配置刷新；这与整个本地 Profile 被远程替换是两回事。

下面是一份用于观察结构的直连配置。它没有远程节点，不能作为代理服务使用。示例监听 7890 混合端口，允许 HTTP 与 SOCKS 客户端接入，并通过规则将流量交给可选择的策略组。

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

proxies: []

proxy-groups:
  - name: 日常出站
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,日常出站
  • proxies 保存内联节点；示例为空列表，因此没有可用代理节点。
  • proxy-groups 将出站项组织成策略组。规则引用的组名必须真实存在，名称应完全一致。
  • rules 自上而下匹配。上面的域名规则先匹配，最后一条 MATCH 处理剩余流量。
  • mode: rule 表示使用规则模式，但不会自动替操作系统打开系统代理或 TUN。

区分源文件与有效配置

部分客户端会用界面设置接管端口、DNS 或 TUN，再把这些值合并进 Profile。此时源文件写着 mixed-port: 7890，运行结果却可能采用界面里的另一个端口。遇到不一致，应查看客户端的「运行配置」「有效配置」或对应日志，而不是反复修改源文件。

订阅更新间隔与资源刷新

整个远程 Profile 的定时下载，一般由客户端负责。proxy-providers 和 rule-providers 的资源刷新，则可以由 mihomo 按各自的 interval 执行。二者不是同一个计时器，也不会因为更新其中一个就保证另一个同时变化。

更新层级设置位置间隔含义
远程 Profile客户端的订阅条目设置界面可能用分钟或小时，应查看单位
HTTP 代理 providerproxy-providers 对应条目interval 通常以秒计，3600 为 1 小时
HTTP 规则 providerrule-providers 对应条目interval 以秒计，86400 为 24 小时

按来源频率设置更新

  1. 先在「配置」→ 对应订阅条目 →「编辑」或「设置」中确认更新开关和时间单位。
  2. 来源方没有特别要求时，可先用 24 小时作为远程 Profile 的维护起点，再根据节点变动频率调整。这是管理建议，不是内核默认值。
  3. 手动执行一次更新，检查完成时间与错误提示，再确认配置是否重新加载。
  4. 设备休眠后不要假定定时任务一直执行。恢复网络后查看最后更新时间，必要时手动刷新。

不要通过每分钟拉取来处理连接故障。高频请求可能触发来源站限流，也不能修复错误密码、DNS 故障或规则误匹配。更新操作应解决「配置内容是否过期」，连接日志才用于回答「这次请求走了哪里」。

更新成功但节点没有变化

先确认更新的是当前启用条目，而非列表里名称相近的另一份配置。随后检查节点来自内联列表还是 provider：如果节点位于 provider 中，重新下载 Profile 可能只拿到相同的 provider 定义。还应区分文件下载成功和内核重载成功；客户端保留旧配置继续运行时，网络可能正常，但新内容并未生效。

覆写规则与订阅更新共存

把远程节点交给来源方维护，把本地分流意图留在覆写层，是较容易长期维护的方式。例如，工作服务域名需要直连，而其他流量继续沿用订阅策略，就只维护相关规则，不必复制整份远程节点列表。

  1. 确认客户端是否支持绑定到单个 Profile 的合并配置，还是所有 Profile 共用全局覆写。
  2. 核对规则的插入位置。追加到已有 MATCH 后面的规则无法获得匹配机会。
  3. 检查合并策略：列表是整体替换、前置还是后置，由客户端实现决定，不能假定 YAML 合并会自动拼接规则。
  4. 重载后检查有效配置，确认规则顺序以及引用的策略组名称。

例如 DOMAIN-SUFFIX,example.com,DIRECT 表示该域名及其子域名直连。若希望把某类请求送入订阅中的策略组，必须使用订阅实际存在的组名。来源方重命名策略组后，覆写中的旧名称也要随之调整，否则可能出现配置检查失败。

多配置并存与场景切换

保存多份 Profile 不等于同时启用多份配置。多数桌面客户端在同一内核实例中只加载一份最终配置。切换 Profile 通常会重载规则、节点和策略组，但不保证立刻迁移已经建立的连接；具体处理方式取决于客户端与内核行为。

按用途命名，避免按节点数量命名

  • 日常－远程：用于稳定使用，按来源方的更新策略维护。
  • 工作－本地规则：保留明确的内部服务访问要求，并记录需要的 DNS 与路由条件。
  • 测试－本地副本：用来修改规则和验证新字段，不直接覆盖日常配置。

备份文件可以命名为 daily-2026-09-09.yaml。日期有助于回滚，但不要把订阅令牌写进文件名。每份配置还应记录来源、更新方式和覆写范围；这些备注比记忆「列表第三项」更可靠。

切换后的五项检查

  1. 确认启用标记：选中目标 Profile，等待客户端完成加载，并检查是否出现配置错误。
  2. 确认策略组选择：同名策略组可能恢复之前的选择；有 profile.store-selected 等持久化设置时尤其需要核对。
  3. 确认监听端口：若应用手工使用 127.0.0.1:7890，新配置必须提供对应入口，或同步修改应用设置。
  4. 确认接管方式：检查系统代理、TUN 和 DNS 状态。Profile 的切换不等于操作系统网络设置必然同步切换。
  5. 验证新连接：重新发起目标请求，在连接记录中查看命中规则与出站链。必要时先断开相关旧连接，再进行验证。

工作网络存在专用 VPN 时，还要检查 TUN 路由与内部 DNS 是否冲突。不要直接把「能访问公网」当作切换成功的全部标准；内部域名能否正确解析、文件服务能否直达，也属于对应场景的验收项目。

常见故障与恢复顺序

导入后出现 YAML 解析错误

检查缩进是否使用空格，是否混入 Tab，以及冒号后是否缺少必要空格。还要打开下载内容的开头：若是 <html>、登录提示或到期说明，说明链接返回的不是预期配置。不要把网页错误内容继续作为 YAML 修改。

提示找不到策略组或节点

对照 proxy-groups、proxies 和 provider 的引用关系。规则里的目标名称必须能够解析为现有出站项。优先撤回最近添加的覆写，再加载原始配置，确认问题来自订阅本身还是本地修改。

更新后无法加载，但旧配置仍可用

保留旧配置，不要先删除全部 Profile。查看日志中第一条与加载失败有关的错误，记录当前客户端与 mihomo 内核版本；GUI 版本和内核版本并非一回事。新字段不被支持时，可依据维护说明升级兼容内核，或恢复之前可用的配置。

更新连接超时或返回访问错误

HTTP 401、403 通常需要检查凭据、权限或服务端限制，429 则提示请求频率受到限制。超时应检查网络、DNS，以及客户端拉取订阅时采用直连还是代理。不要假定更新请求必然经过当前选中的节点。

如果现有节点已失效，而订阅下载又依赖该节点，更新可能陷入循环依赖。可以在客户端允许的范围内临时改用可访问来源站的更新方式，获取新配置后再恢复原设置。处理过程中不必反复清空订阅列表。

备份与日常管理清单

  • 至少保留一份最近确认可用的配置，以及与其配套的覆写内容。
  • 将远程 Profile 与本地实验文件分开命名，避免更新时覆盖手工规则。
  • 导出文件可能包含节点密码、订阅地址和控制接口凭据，应按敏感文件保存。
  • 跨设备迁移时重新检查端口占用、文件路径、TUN 权限与系统代理设置，不只复制 YAML。
  • 每次重大调整后，记录启用 Profile、策略组选择和验证目标，便于复现与回滚。

Profile 管理的核心，是把来源、修改与运行状态分开：订阅负责提供远程内容，本地文件或覆写负责保留场景需求，有效配置和连接记录负责证明实际行为。建立这三层边界后，更新与多配置切换就能按固定步骤检查，而不必靠反复重装定位问题。

下载Clash