Profile 与 config.yaml：配置条目和运行配置的区别

Profile 通常指客户端保存的一份配置条目。它可以来自订阅 URL，也可以来自导入的本地 YAML 文件。除了配置正文，客户端还可能保存条目名称、来源地址、更新时间、更新间隔和本地处理规则。Profile 是客户端的管理概念，不是必须写进 YAML 的顶层字段。

config.yaml 则是常见的配置文件名。内核真正读取的是配置内容以及启动时指定的文件路径，不要求每份配置都叫这个名字。一个客户端可以保存多份 Profile，但某一内核运行实例通常只加载一份最终配置；选择另一份 Profile 后，客户端会生成或载入新的运行配置。

对象保存的内容修改后的影响
远程 Profile订阅地址、下载的 YAML、更新设置下次更新可能替换下载内容
本地 Profile本地导入或创建的配置正文通常需要手动维护节点和规则
运行配置原始配置与客户端覆盖设置合成的结果直接编辑可能在重新加载后失效
客户端偏好系统代理、界面设置、部分 TUN 开关等可能跨 Profile 保留

因此，“编辑了文件但端口没有变化”并不一定是保存失败。客户端可能用自己的设置覆盖了 mixed-port，也可能正在使用另一条 Profile。排查时先确认当前选中的条目，再查看客户端提供的最终配置或启动日志。

本地文件与订阅配置：按维护来源分类

远程 Profile：保留订阅更新能力

订阅地址返回的内容需要符合所用内核支持的格式。支持 Clash YAML 的订阅通常包含节点、策略组与规则；只有节点列表的订阅则不能直接替代完整配置。URL 是取得配置的入口，不代表其响应一定是可直接加载的 YAML。

远程 Profile 适合持续接收节点变更。直接在其下载副本中增加规则，只影响当前本地内容；下一次订阅刷新可能重新写入整个文件。部分客户端会另存编辑结果，但具体行为需要通过一次更新测试确认，不能只凭文件名判断。

本地 Profile：固定副本与独立实验

把远程配置导出为本地文件，再作为新条目导入，可以建立一个独立副本。它适合排查规则、测试 DNS 或保留故障前状态。代价是主订阅发生节点改名、地址调整或认证信息变更时，本地副本通常不会自动获得这些变更。

实际管理时，建议同时保留“远程日常条目”和“本地排查副本”。前者负责接收更新，后者只在确认问题或测试改动时启用，避免同一份配置承担两种维护方式。

多配置命名与切换：一次只改变一个变量

命名包含来源、用途与日期

文件名用来识别来源，不宜把订阅密钥放进去。以下命名便于区分远程条目与冻结副本；日期表示创建备份的日期，不表示订阅到期时间。

  • remote-main：主要订阅，日常使用并允许定期刷新。
  • remote-backup：备用订阅，使用前手动确认有效性。
  • local-main-2026-09-30.yaml：主配置在该日期的本地副本。
  • local-dns-test-2026-09-30.yaml：只用于 DNS 参数对比的实验配置。

切换前后的六步检查

不同客户端的入口可能叫“配置”“Profiles”或“订阅”。以下按操作对象说明，不把某一客户端的菜单名称套用于所有版本。

  1. 记录当前状态。记下启用的 Profile、规则模式、选中节点、系统代理与 TUN 开关。需要复现问题时，这些信息比文件名更重要。
  2. 备份当前可用配置。通过条目的导出或复制功能保存一份 YAML，并记录所用内核名称与版本。
  3. 先导入，后启用。把新文件加入配置列表，先执行客户端提供的配置检查；若报告未知字段，核对内核兼容性。
  4. 选择目标 Profile。等待加载完成，查看日志中的解析错误、策略组引用错误或端口绑定失败信息。
  5. 检查实际策略。确认仍处于预期的规则模式，策略组没有回到意外的默认节点，系统代理端口与运行配置一致。
  6. 建立新连接测试。重新打开目标页面，并结合连接列表查看规则和出口；仅观察已有下载任务不足以判断切换结果。

配置切换与已有连接的处理方式取决于客户端及内核。旧连接可能继续使用之前的出口，也可能被重载操作中断。需要确认新规则时，应建立新的请求；存在重要传输任务时，先等待任务结束，再切换配置。

订阅自动更新：客户端计时与资源计时分开看

完整 Profile 的订阅刷新通常由客户端管理。更新入口一般在对应条目的编辑面板或全局订阅设置中。先手动更新一次，确认能下载并解析，再启用自动更新，能把网络问题与计时问题分开。

设置间隔时确认单位

如果界面单位是分钟，360 表示 6 小时，1440 表示 24 小时；如果单位是小时，则应分别填写 6 或 24。这些是间隔换算示例，不是所有客户端共用的默认值。不要把其他客户端截图中的数值直接照填。

  • 先查看订阅提供方是否规定刷新频率，避免短时间重复请求。
  • 电脑休眠、应用退出或移动系统限制后台活动时，定时任务可能延后；“每 6 小时”不保证每次都准点执行。
  • 更新成功后，确认当前 Profile 是否自动重新加载。部分客户端只更新缓存，需要再次选择或执行重载。
  • 若更新失败，记录时间和错误类型，再检查网络、订阅有效期、服务端响应与返回内容。

不要混淆 provider 的 interval

在支持相应字段的 Clash 或 Clash Meta（mihomo）内核中，HTTP 类型的 proxy-providers、rule-providers 可以设置 interval，单位通常为秒。例如 interval: 86400 表示对应资源每 24 小时更新一次。它只控制该资源，不会自动刷新整个 Profile 的订阅 URL。

同样，profile.store-selected 用于保存策略组选择状态，不是订阅调度器；支持该选项的内核中，profile.store-fake-ip 涉及 Fake-IP 映射保存，也不是多份配置的清单。客户端里的 Profile 列表与 YAML 中的 profile 字段属于不同层次。

本地规则保留：覆盖层、资源拆分与完整副本

想在订阅自动更新的同时长期保留自定义规则，优先使用客户端明确提供的覆写、合并或脚本处理功能。其目的都是在订阅内容更新后，再应用本地改动；功能名称、执行顺序和语法由客户端决定，不能随意把某个覆写文件当成通用 Clash 配置导入。

规则插入位置决定是否命中

rules 按顺序匹配。自定义规则放在 MATCH 后面通常不会得到处理；而替换整个规则列表，又可能丢失订阅原有的分流逻辑。操作前应确认工具执行的是“前置插入”“追加”还是“整体替换”，再查看最终运行配置核对结果。

下面是一份独立的最小本地演示配置，用于观察 Profile 切换、端口与规则顺序。它只提供直连和拒绝策略，不含远程代理节点，也不能代替订阅配置。

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

proxy-groups:
  - name: LocalChoice
    type: select
    proxies:
      - DIRECT
      - REJECT

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

启用后，新连接到 example.com 及其子域名会先匹配直连规则；其他连接进入 LocalChoice。如果同机另一个进程已监听 7890，配置可能无法绑定端口。若客户端启用了全局端口覆盖，实际端口还应以界面和日志为准。

需要自己维护规则而只更新节点时，也可以采用固定主配置配合节点提供器的方式，但前提是所用内核支持该能力，远程响应符合 provider 格式，策略组也正确引用对应资源。这比完整订阅导入更复杂，适合已经理解配置引用关系的用户。

备份与回滚：保存原文，也保存运行条件

备份应包含哪些内容

  • 配置正文：保存可用 YAML，区分订阅原文与合成后的运行配置。
  • 本地覆盖：单独保存覆写、合并或脚本文件，以及它们绑定到哪些 Profile 的说明。
  • 运行环境：记录客户端版本、内核版本、端口、模式与 TUN 状态。
  • 引用资源：离线恢复时还需要考虑外部规则集、节点提供器和地理数据库的可用性。

每次大幅修改前保存一个带日期的快照，并保留至少一份已确认可用的配置。不要只备份客户端临时生成的运行文件：它可能含有机器相关路径，或者下次启动就被重新生成。导出客户端管理数据时，也应确认导出范围是否包含本地覆盖与订阅地址。

回滚按“配置、覆盖、状态”依次恢复

  1. 暂时关闭出问题条目的自动刷新，保留报错配置以便后续对比。
  2. 导入已知可用的本地快照，先检查语法，再启用。
  3. 暂停新增加的覆盖层，避免旧快照仍被同一份错误规则再次修改。
  4. 恢复原来的规则模式、策略组选择和代理接管方式，再建立新连接测试。
  5. 确认恢复后，逐项加入改动；确定远程内容正常后，再恢复自动更新。

常见问题：切换无效、节点变化与更新覆盖

切换 Profile 后，系统代理为什么没有跟着改变？

Profile 切换通常改变内核配置，不保证重写操作系统代理设置。假设系统代理仍指向 127.0.0.1:7890，而新配置实际监听 7891，应用就可能无法连接。应让系统代理端口与客户端实际监听端口一致，并确认相关应用是否采用系统代理。

节点选择为什么在切换后恢复默认？

选择状态可能由内核或客户端缓存。新配置中策略组改名、节点改名、原节点被移除，都会使旧选择无法对应。即使开启了保存选择的选项，也应在订阅刷新后检查主要策略组，不能把名称变化当成节点连接故障。

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

先确认改动是否写在远程下载副本内。如果是，刷新覆盖符合远程条目的常见工作方式。把需要长期保留的改动迁移到受支持的本地覆盖层，再手动更新一次，检查最终规则顺序。若客户端没有覆盖功能，就使用独立本地副本并承担手动维护工作。

两份配置能否同时生效？

在同一内核运行实例中，普通 Profile 切换是选择当前配置，不是把两份文件自动叠加。确需组合节点或规则时，应通过明确的合并逻辑或 provider 引用完成。配置片段的叠加顺序、同名策略组处理和端口设置都需要检查，不能仅同时勾选两个文件便假定合并完成。

日常管理可以归纳为三个动作：远程条目负责更新，本地覆盖负责长期改动，日期快照负责回滚。每次只调整一个层次，再用新连接验证结果，配置变化就更容易定位。字段与引用关系可继续查看进阶配置，首次导入流程见使用指南。