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

Profile 是什么：一份可选中的配置档案

Profile 是客户端管理配置时使用的档案条目，不是某一个节点。它通常记录配置内容、显示名称、来源地址和更新时间。客户端中的入口可能叫「配置」「配置文件」或「Profiles」。选中其中一项，客户端会把相应内容交给内核加载。

内核是实际处理连接的程序。Clash 与 Clash Meta（现称 mihomo）属于这一层；桌面窗口、订阅列表和更新按钮则属于客户端界面。不同客户端的 Profile 管理方式并不完全相同，本文按操作目的说明，不把某一个界面的按钮位置当成通用标准。

YAML 是用缩进表达层级的文本格式。完整配置通常含有端口、节点、策略组和规则；订阅地址返回的内容却不一定完整。有些地址只提供节点列表，有些提供 Base64 编码的数据，还有些返回完整的 Clash YAML。扩展名看起来像配置文件，并不能证明内容可以直接使用。

先判断来源：订阅配置还是本地配置

订阅配置：更新时重新获取远程内容

订阅配置适合由服务提供方维护节点和基础规则的场景。客户端保存来源地址，点击更新时再次请求服务器。远程内容变化后，本地缓存通常会被替换；客户端是否保留旧副本、如何合并设置，要看具体实现。

• 优点：节点增删、连接参数变更可以通过刷新获取，不必逐项修改。
• 注意：直接编辑下载下来的原始配置，修改可能在下次更新时消失。
• 检查点：条目是否显示来源地址、上次更新时间，以及本次更新是否成功。

本地配置：由自己维护文件内容

本地配置适合学习规则、保留固定配置或做故障对照。导入后，有的客户端复制文件，有的读取指定路径。不要默认修改原文件就会立即生效：编辑后应重新加载，并确认客户端实际使用的是哪一份。

本地配置也可以包含 proxy-providers，即从远程拉取节点的提供器。因此，「本地 Profile」不等于「完全没有远程更新」。完整配置的更新、节点提供器的更新，以及 rule-providers 规则提供器的更新，是三个不同层次。

导入第一份配置：先确认格式，再确认启用状态

导入成功和正在使用是两件事。列表中多出一个条目，只能说明客户端建立了档案；是否通过语法检查、是否已激活、流量是否进入内核，还要分别确认。

1. 打开客户端的「配置 / Profiles」页面，选择远程导入或从 URL 导入。粘贴服务提供方明确标注为 Clash 或 mihomo 格式的订阅地址。
2. 把新条目命名为 日常-订阅A，先不要删除原来可以使用的配置。名字写用途，比只写「新配置」更容易辨认。
3. 执行一次更新，查看结果。如果提示格式错误，检查返回内容是否其实是登录页面、到期提示或其他格式的订阅数据。
4. 选中该条目，执行启用或切换。查看日志是否出现加载失败、策略组引用不存在等错误。
5. 到「代理 / Proxies」页面检查策略组是否出现，再确认模式为 Rule，即规则模式。最后打开一个明确知道预期走向的网站，观察连接记录。

本地导入则选择文件导入入口，选取 .yaml 或 .yml 文件，再重复启用与验证步骤。客户端可能使用「导入」「新建」「添加」等不同名称；找不到时，可先看使用文档中的基础流程。

建立本地对照配置：把语法问题和网络问题分开

准备一份结构简单的本地配置，有助于判断客户端能否正常加载 YAML。下面的示例面向 mihomo，只用于演示配置层级和策略组引用，不包含远程代理节点，也不会提供代理出口。

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

proxies: []

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

rules:
  - DOMAIN-SUFFIX,example.com,手动选择
  - MATCH,DIRECT

• mixed-port: 7890 定义一个同时接受 HTTP 与 SOCKS 请求的本地代理端口。它是示例值，不代表所有客户端都使用 7890。
• allow-lan: false 不开放局域网设备访问该代理入口，适合先在本机检查。
• 手动选择 是策略组名称，规则最后一段必须与它完全一致。
• DIRECT 表示直连，REJECT 表示拒绝；两者都是内置出站选项，不是远程节点。
• MATCH,DIRECT 是兜底规则：前面的规则没有匹配时，连接走直连。

把文件保存为 local-baseline.yaml，导入后命名为 排查-本地直连。这份配置即使加载成功，也只能证明基本结构可被接受，不能证明订阅节点可用。如果客户端启用了全局覆写，实际端口和模式还可能与文件不同。

编辑 YAML 时使用空格缩进，不要用 Tab。需要深入了解字段时，可对照YAML 手册。不要把面向 mihomo 的新字段直接套到所有旧版 Clash 内核上；未知字段可能报错，也可能被忽略。

多配置命名与切换：用途固定，验证顺序固定

多数客户端同一时刻只激活一份主配置。列表里有三份 Profile，不表示三个订阅自动合并，也不表示流量会同时分配给它们。要把多个来源放在同一份配置中，通常需要提供器或客户端支持的合并机制。

每次切换后检查四项

1. 激活条目：确认选中标记确实到了目标配置，而不是只打开了编辑窗口。
2. 运行模式：Rule 按规则分流；Global 使用全局策略；Direct 走直连。界面保留的模式可能覆盖文件中的 mode。
3. 策略组选择：打开实际被规则引用的组，查看当前选项。新配置的组名变化后，旧的选择记录未必能够沿用。
4. 新连接记录：重新发起请求，观察匹配规则、策略组和最终出站。浏览器已有的长连接可能暂时保留切换前的路径。

如果切换后效果没有立即改变，先关闭测试页面再打开，必要时仅关闭相关旧连接。不要一开始就同时重装客户端、清空全部配置和修改 DNS；一次改动太多，会失去判断原因的线索。

定时更新与自定义规则：分清谁负责保存修改

更新周期属于管理策略，不是越短越好。例如，可先把普通订阅的刷新间隔设为 24 小时；提供方有明确要求时按其说明调整。若输入框以分钟计，24 小时是 1440 分钟；以秒计则是 86400 秒，保存前先看单位。

定时更新通常由客户端负责，电脑休眠或程序退出后未必执行。proxy-providers 中的 interval 则是内核提供器字段，通常以秒为单位，不能用它代替客户端的整个 Profile 更新计划。

需要长期保留的规则，放在独立修改层

• 客户端有「覆写」「合并」或脚本处理功能时，先阅读对应说明，再把自定义内容放在独立层。不同客户端的合并顺序并不统一。
• 只有原始文件编辑功能时，先导出副本再修改，并接受后续需要手工维护的成本。
• 添加规则时注意顺序。常见规则按从上到下的顺序匹配，把新规则追加在 MATCH 后面通常不会得到预期结果。
• 更新后检查最终生效配置，而不只是检查订阅原文件；客户端可能又应用了一层端口、DNS 或 TUN 覆写。

切换后规则错乱：按症状检查，不盲目换节点

策略组消失，或者规则指向不存在的名称

先查看加载日志。例如，规则引用 日常代理，而新配置只定义了 手动选择，引用就不匹配。检查拼写、大小写和空格，再检查覆写规则是否仍在引用上一份配置的组名。组名更换后，自定义规则也要同步修改。

切换成功，但只有部分应用走代理

先确认流量有没有进入内核。系统代理是操作系统提供的代理设置，不保证所有应用都会遵循；TUN 模式通过虚拟网络接口接管流量，也需要正确的权限、路由和 DNS 设置。切换 Profile 不等于自动修复这些入口问题。

如果应用仍指向 127.0.0.1:7890，而运行端口已经变成 7897，它可能连接到旧端口或直接报错。这里的两个数字只是排查示例，请以客户端显示的实际监听端口为准。系统代理是否随切换同步刷新，也要单独确认。

页面能打开，但出站与预期不同

先看连接记录是否收到域名，再看命中了哪条规则。应用自带 DNS、加密 DNS、IP 直连以及旧连接复用，都可能影响观察结果。不要只凭一个网站显示的出口信息判断整份配置是否生效；用一个明确域名、新建连接和对应日志一起核对。

刷新后无法使用，旧配置却正常

保留错误信息，恢复最近可用的副本，再比较节点、组名和规则变化。若是订阅返回异常，应先联系提供方确认格式与有效期。连续快速点击更新只会重复请求，不能修复远程内容错误；更多入口问题可参照常见问题逐项检查。

备份与回滚：至少留一份已验证的配置

备份要包含内容，也要包含使用状态。只保存订阅链接，无法恢复当时的规则；只保存 YAML，也未必包含客户端中的模式、TUN 开关和覆写设置。

1. 大改之前导出当前可用配置，文件名可用 daily-before-edit-2026-08-03.yaml，方便按日期辨认。
2. 记录内核类型、实际监听端口、模式、策略组选择以及正在启用的覆写项。截图时遮住订阅地址和节点凭据。
3. 把修改放在新条目中测试。确认加载正常、规则命中符合预期后，再决定是否替换日常条目。
4. 需要回滚时选中备份条目，恢复对应的客户端设置，再用新连接验证。不要把「文件导入成功」当作恢复完成。

日常管理可以保持简单：一份日常订阅、一份备用配置、一份本地排查配置。先分清来源，再固定命名，切换后按相同顺序检查。这样遇到异常时，能判断问题来自配置内容、更新过程，还是系统代理与 TUN 等流量入口。