Clash Profile 是什么：配置文件基础概念与多配置切换管理

Profile、config.yaml 与运行配置

Profile 是客户端管理的一份配置档案。它可以来自本地 YAML 文件，也可以来自远程订阅地址。档案除配置内容外，通常还带有名称、来源、更新时间等管理信息。切换 Profile，主要是在切换配置来源与配置内容，而不是重新安装客户端或更换操作系统的网络设置。

config.yaml 是常见的配置文件名，不是所有 Profile 共用的固定身份。直接运行 Clash 或 mihomo 内核时，可以指定某个配置文件；使用 Clash Nyanpasu 时，客户端可能将订阅内容、客户端设置和覆写处理组合成供内核加载的运行配置。配置列表里的原文与内核最终读取的内容，因此不一定完全相同。

排查时先确定改的是哪一层。修改源 YAML 后没有生效，可能是尚未重新加载，也可能是同名字段被客户端设置或覆写替换。修改临时生成的运行文件，即使当次有效，也可能在下一次切换、更新或重启时被重新生成。

本地配置、远程订阅与覆写的分工

本地配置：固定输入，便于复现

本地配置适合规则实验、故障复现和离线留档。导入后应确认客户端是复制了文件内容，还是保留了对原文件的引用；不能假定修改桌面上的原文件就会同步到客户端。可以用修改名称、重新导入并对比内容的方式确认管理行为。

远程订阅：定期拉取的配置来源

远程 Profile 通常保存订阅 URL，并在手动更新或定时更新时重新获取内容。订阅若返回完整 Clash YAML，就可能同时提供 proxies、proxy-groups 和 rules。只含节点 URI 的文本，不等同于完整的 Clash 配置文件，不能仅通过改成 .yaml 扩展名完成转换。

直接编辑远程档案中的节点或规则，需要考虑下一次更新。若更新操作替换了源内容，手工修改也会被替换。长期保留的个人规则应放入独立维护的覆写层，或者将订阅另存为本地档案后维护；后者不再自动获得原订阅的变化。

覆写脚本：保留个人差异

覆写用于在输入配置之上增加或调整字段，例如插入局域网直连规则、统一日志级别。具体可用的合并方式、脚本接口、处理顺序和作用范围取决于客户端版本。不要将其他客户端的脚本直接当作 Clash Nyanpasu 的通用接口，也不要假定列表字段一定采用追加合并。

建立一个可验证的本地 Profile

下面的 YAML 用于验证导入、切换和规则加载，不含代理服务器。保存为 UTF-8 编码的 local-check.yaml，在「配置」页面通过本地文件导入入口添加，再选中该档案并确认加载状态。入口名称可能随版本变化，应以当前界面的文件导入操作为准。

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

proxy-groups:
  - name: Local-Choice
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN,example.com,DIRECT
  - MATCH,Local-Choice

• mixed-port: 7890 是本例指定的 HTTP 与 SOCKS 共用端口，不代表所有客户端版本的默认端口。
• allow-lan: false 用于限制局域网接入，不应把本例当作局域网共享代理配置。
• mode: rule 表示规则模式；若客户端另行管理模式，应检查界面当前值及最终运行值。
• Local-Choice 只含直连与拒绝两个内置目标，导入成功不代表已经具备远程代理能力。

加载后在策略组页面确认 Local-Choice 存在，并选择 DIRECT。若需要验证本机 HTTP 代理端口，可执行下面的命令；此测试不依赖系统代理开关，也不代表浏览器的所有流量都已接管。

curl --proxy http://127.0.0.1:7890 --head https://example.com

检查命令结果的同时查看连接记录。example.com 应命中域名直连规则；若端口连接被拒绝，先查内核启动状态及实际监听端口，不要立即将问题归因于订阅。

多配置命名与切换步骤

用来源、用途和状态区分档案

名称应能说明内容边界。建议采用“来源－用途－状态”的格式，例如 订阅A－日常－稳定、本地－规则验证－测试、订阅B－备用－待检查。名称不写完整订阅 URL，也不写账号令牌。日期放在备份文件名中，避免配置列表每天出现新的近似名称。

1. 记录当前状态。记下当前档案、策略组所选节点、规则模式、实际端口，以及系统代理和 TUN 开关。以 7890 为例，切换后若监听变成其他端口，手动设置代理的应用也需要调整。
2. 检查目标档案。远程档案先执行一次更新，确认内容获取成功；本地档案检查 YAML 缩进及规则目标，确保被引用的策略组存在。
3. 执行切换。在「配置」页面选择目标档案，等待客户端完成加载。观察内核日志是否出现解析失败、字段不支持或端口占用。
4. 重新确认策略组。两个 Profile 即使都有名为“代理”的策略组，成员也可能不同。查看当前选中的具体节点，不要只凭组名判断。
5. 新建连接验证。发起新的网页请求，并检查连接记录中的规则、策略链和目标。仅看到档案卡片被选中，不足以确认流量路径正确。

Profile 切换通常针对后续连接生效，已经建立的连接未必立即迁移。需要严格验证时，可关闭测试应用后重新打开，或使用客户端提供的关闭连接功能。关闭连接会中断下载、会议和长连接，应先保存工作。

多 Profile 与多节点、TUN 的区别

同一份 Profile 内可以包含多个节点，并通过 select、url-test 等策略组组织。只是从节点 A 换到节点 B，通常不需要新建 Profile；需要替换整套规则、DNS 设置或订阅来源时，再考虑切换档案。

一个常规桌面客户端实例通常只向其当前内核提供一份最终运行配置。列表里同时存在三份 Profile，不表示三份规则会自动并行叠加。需要组合多个来源时，应使用明确支持的配置组合机制，检查节点名、策略组名和规则目标是否冲突。

接管流量与选择配置是两件事

• 系统代理：影响遵循操作系统代理设置的应用。部分程序使用自身代理设置，或完全不读取系统代理。
• TUN 模式：通过虚拟网络接口及相关路由接管流量，需要操作系统权限与正确的 DNS、路由配置。
• Profile：提供内核处理连接时使用的节点、规则和相关参数，不等同于上述接管开关。

切换 Profile 后某个应用仍然直连，应先确认该应用是否进入内核连接记录。没有记录时优先检查接管方式；有记录但走错目标时，再检查模式、规则顺序和策略组选择。不要仅为解决规则匹配问题反复开启或关闭 TUN。

覆写的最小变更与兼容性检查

长期使用的覆写应保持范围小、目标明确。例如只添加一条内网直连规则，而不是复制整份订阅后逐项替换。规则目标尽量引用已确认存在的组名；若多个 Profile 的组名不同，就应分别配置，或在处理逻辑中明确检查目标是否存在。

# 插入到 rules 列表前部，而不是 MATCH 后面
- IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

这是一条规则片段，不是可单独导入的完整 Profile。它仅覆盖示例网段 192.168.50.0/24；实际局域网若为 192.168.1.0/24，需要按路由表调整。no-resolve 表示不为匹配这条 IP 规则而主动触发域名解析，不是关闭所有 DNS 查询。

1. 先在稳定档案副本上测试，保留原档案作为回退入口。
2. 每次只改一类字段，例如先改规则，再改 DNS，不同时调整端口和 TUN。
3. 检查最终运行配置，确认字段值、列表顺序与规则目标符合预期。
4. 执行一次订阅更新后再次检查，确认个人变更仍由覆写稳定生成。

Clash、Clash Meta（mihomo）及其不同版本的字段支持并不完全一致。出现“未知字段”或规则类型不支持时，先记录当前内核名称和版本，再对照 YAML 手册检查兼容性。单纯修改 Profile 文件名不能解决内核能力差异。

配置备份与恢复顺序

备份内容不止一份 YAML

一份可恢复的备份应覆盖配置正文、覆写内容和必要的客户端设置记录。远程 URL 也要保存，但应单独加密存放。只备份订阅链接，无法保留订阅服务后来删除的节点；只备份源 YAML，也可能遗漏实际生效的个人覆写。

• 源配置：导出稳定档案，例如 local-check-2026-09-27.yaml。
• 覆写与关联：保存脚本、规则片段，以及它们作用于哪些 Profile 的说明。
• 环境记录：记下客户端版本、内核版本、监听端口、系统代理与 TUN 状态。
• 敏感信息：检查订阅令牌、节点密码、控制接口密钥和证书材料，避免上传到公开仓库。

恢复时先导入源配置，确认能够解析；再恢复覆写并检查最终字段；最后按需启用系统代理或 TUN。跨机器恢复不要原样套用旧机器的网卡名、绝对路径和局域网地址。规则集与代理提供者若依赖远程下载，也要确认新机器能够获取相关内容。

常见异常的排查顺序

稳定的管理方式是保留一份可回退档案，将订阅来源与个人修改分开，并在切换后核对运行状态。配置文件负责描述处理方式，客户端负责组织和加载，系统代理或 TUN 负责把流量送入内核。按这三个层次排查，比反复重新导入订阅更容易定位问题。