Clash 配置文件(Profile)是什么:结构拆解与多配置切换管理方法

Profile 不是订阅地址，而是内核实际读取的运行配置

在 Clash、Clash Meta 或 mihomo 客户端里，Profile 通常译作“配置”或“配置文件”。它最终是一份 YAML 文档，里面不只放节点，还会定义监听端口、DNS、代理组、分流规则、TUN 参数以及控制接口。内核启动时读取的是这份配置，不是浏览器里那条订阅 URL。

订阅地址更像配置来源。客户端向订阅 URL 发起请求，下载服务端返回的内容，再把结果保存为本地 Profile。之后即使暂时断网，只要本地文件仍在且节点凭据有效，客户端通常仍能加载该配置。点击“更新订阅”时，客户端会重新下载并覆盖或重建对应的本地内容。

一份完整配置通常包含什么

最小可运行结构会因内核版本和客户端封装而异，但常见字段可以分成六层：

• port、socks-port、mixed-port：本机代理监听端口。
• proxies 或 proxy-providers：具体节点或远程节点集合。
• proxy-groups：手动选择、自动测速、故障转移等策略组。
• rules 或 rule-providers：域名、IP、进程和规则集的匹配顺序。
• dns：DNS 监听、上游服务器、Fake-IP 或 Redir-Host 行为。
• tun、sniffer、external-controller：系统流量接管、域名嗅探和控制接口。

下面是一份用于理解层级的精简示例。端口 7890 用作 HTTP 与 SOCKS 混合入口，9090 用作外部控制接口。示例省略了真实凭据，不应直接作为可连接配置使用。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxies:
  - name: Tokyo-A
    type: ss
    server: 203.0.113.10
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Tokyo-A
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Tokyo-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

三大核心段：proxies、proxy-groups、rules

理解 Profile，先不要从几百行 DNS 和规则集开始。抓住三个核心段就够了：proxies 提供出口，proxy-groups 组织出口，rules 决定每条连接交给哪个组。三者是一条从底层到上层的引用链。

proxies：节点本体与连接参数

proxies 是静态节点数组。每一项至少包含名称、协议、服务器地址、端口和认证信息。不同协议还会追加不同字段，例如 Shadowsocks 的加密方式、Trojan 的密码与 TLS 参数、VMess 的 UUID、VLESS 的流控与传输设置。

节点名称必须在当前配置内可识别。代理组通过名称引用节点，因此重命名节点时，要同步检查 proxy-groups。如果组里仍写着旧名称，配置校验可能直接失败，也可能在界面里出现空组或不可用成员。

proxies:
  - name: HK-01
    type: trojan
    server: hk01.example.net
    port: 443
    password: change-me
    sni: hk01.example.net
    udp: true

大型订阅通常不会把所有节点手工写进主文件，而是使用 proxy-providers。Provider 可以从远端拉取节点集合，并按指定时间更新。它只负责“节点来源”，不会自动决定这些节点用于哪些网站。

proxy-groups：把节点变成可执行策略

proxy-groups 是用户在客户端“代理”页面里真正操作的对象。常见类型有四种：

组可以引用节点，也可以引用另一个组。常见做法是建立一个总组 PROXY，再放入 HK-AUTO、JP-AUTO、Fallback 和 DIRECT。规则只引用总组或业务组，底层节点更新时就不必逐条修改规则。

proxy-groups:
  - name: Streaming
    type: select
    proxies:
      - HK-AUTO
      - JP-AUTO
      - PROXY

  - name: HK-AUTO
    type: url-test
    use:
      - provider-main
    filter: "(?i)港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

rules：从上到下，命中即停止

rules 是有顺序的匹配列表。请求从第一条开始检查，命中后就把连接交给指定策略，不再继续向下。精确规则应放在宽泛规则前面，最终用 MATCH 兜底。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - PROCESS-NAME,git.exe,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

这段里，api.example.com 会直连。其他 example.com 子域走代理。Windows 上由 git.exe 建立且能被内核识别的连接交给 PROXY。局域网地址直接连接，剩余中国大陆 IP 直连，最后未命中的流量交给 Fallback。

Profile 与订阅更新：哪些内容会被覆盖

直接编辑订阅生成的 YAML，短期能生效，下一次更新却可能全部消失。原因很直接：客户端把远端响应当作该 Profile 的权威版本，更新时重新写入节点、策略组和规则。手工增加的 PROCESS-NAME、DNS 上游或自定义组，如果没有单独的覆写机制，就会被远端内容替换。

三种来源的行为差异

1. 本地文件导入：从磁盘加载 YAML，通常不会自动访问远端。适合完全自行维护的配置。
2. 订阅 URL 导入：按客户端设定的周期请求远端。常见更新间隔是 24 小时，也可以手动触发。
3. Provider 拆分：主配置保留 DNS、组和规则，只让 proxy-providers 更新节点。适合需要长期维护规则结构的人。

以常见图形客户端为例，导入路径通常是「配置」→「新建」→「从 URL 导入」，更新动作位于对应配置卡片的“更新”按钮。端口则常在「设置」→「参数设置」→「混合端口」中调整。不同客户端会把 Profile 称作“配置”“订阅”或“配置管理”，按钮位置可能变化，但底层关系不变。

mihomo 的 Provider 结构可以把远端节点缓存到本地文件。下面的 interval: 86400 表示每 86400 秒，也就是 24 小时检查一次。健康检查每 600 秒执行一次：

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.net/clash
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

如果客户端支持覆写、扩展脚本或 Merge 配置，优先把本地 DNS、规则和策略组放进覆写层。远端只负责节点，个人逻辑留在本地。这样更新 80 个节点时，不会顺手冲掉为开发环境写的直连规则。

多机场、多用途配置怎么命名和并存

配置一多，最先失控的通常不是 YAML，而是命名。列表里出现“新配置”“订阅 2”“测试副本最终版”，几周后很难判断哪个正在使用、哪个可以删除。命名应直接表达来源、用途和更新时间。

推荐命名格式

[来源]-[用途]-[更新方式]-[日期]

A站-日常-自动-20260625
B站-流媒体-自动-20260625
本地-开发分流-手动-20260625
应急-基础直连-手动-20260625

日期不必每次节点更新都改。它更适合记录配置结构最后一次人工调整的时间。自动订阅自己的更新时间交给客户端记录，否则每天重命名只会制造噪声。

按来源拆，还是按用途拆

刚开始使用时，每个来源保留一份 Profile 最省事。规则需求稳定后，再迁移到“一个主配置加多个 Provider”。不建议一上来就把所有来源、几十个业务组和上万条规则塞进一个文件，任何缩进错误都会扩大排障范围。

保留一份应急配置

应急配置不需要复杂。保留一个可用节点、一个 select 组、几条基础规则，并关闭非必要的 TUN 与复杂 DNS。主配置更新失败、规则集地址不可达或 TUN 驱动异常时，可以切回应急配置，先恢复基本连接再排查。

应急配置应使用本地 YAML，不依赖每次启动都下载远程规则集。每月手动加载一次，确认配置可以通过校验、节点仍可连接、7890 端口没有被其他程序占用。

切换 Profile 时，客户端内部发生了什么

切换 Profile 不是单纯换一个节点列表。客户端通常会停止或重载当前内核，把新 YAML 交给内核校验，然后重新建立监听端口、DNS、TUN 网卡和策略状态。配置越复杂，重载涉及的系统组件越多。

旧连接不一定自动迁移

切换前已经建立的 TCP 连接可能断开，也可能继续维持到超时，具体取决于客户端的重载方式。新连接会按新规则处理。正在下载大文件、执行 Git 推送或保持 SSH 会话时，不要随意切换 Profile。

一次可复现的切换检查可以这样做：先在连接面板确认活动连接数，例如 23 条；停止下载任务；切换配置；等待内核状态恢复为“运行中”；再打开测试域名检查新连接的规则命中。常见桌面环境中，简单配置可在 1 至 3 秒完成重载，启用 TUN、远程规则集和大量 Provider 时可能需要更久。

策略选择可能被记忆，也可能被重置

某些客户端会按策略组名称保存上次选择。例如两个 Profile 都有名为 PROXY 的组，切换后客户端可能尝试恢复上次选中的节点。但如果新配置里没有同名节点，就会回落到该组的第一个可用成员。

因此，多配置共用相同策略语义时，可以统一使用 PROXY、Streaming、Fallback 等组名。不同语义不要硬套同名，否则界面看似保留了选择，实际出口逻辑已经变化。

TUN 配置切换要额外检查

TUN 模式会接管更多系统流量。两个 Profile 如果分别设置不同的 stack、DNS 劫持或路由排除项，切换时可能需要重建虚拟网卡和路由表。切换后应检查：

• TUN 状态是否重新启用，而不是只保留系统代理。
• 局域网地址如 192.168.1.1 是否仍可直连。
• DNS 请求是否交给新配置的监听端口，例如 0.0.0.0:1053。
• 需要排除的进程或网段是否仍在 route-exclude-address 中。
• 浏览器、命令行和不读取系统代理的软件是否都按预期分流。

一套可执行的配置管理流程

管理 Profile 不需要复杂工具。关键是把导入、验证、切换和回退分开做，不要在当前唯一可用的配置上直接试错。

第一步：复制后再改

修改 DNS、TUN 或规则前，先复制当前配置并加上日期。原配置保持不动。若客户端没有复制功能，就导出 YAML 保存到独立目录。修改版先命名为“测试”，验证完成后再替换主配置。

第二步：先做语法校验

YAML 使用空格表达层级，Tab、错位缩进和缺少引号都可能导致加载失败。尤其要检查带冒号的名称、正则表达式和 URL。内核报错中若出现具体行号，先看该行上方的列表缩进，因为错误位置经常是解析器最终无法继续的位置，不一定是问题起点。

# 容易出错：组名含冒号但没有引号
- name: Work: Git

# 更稳妥
- name: "Work: Git"

第三步：按固定样本验证分流

准备四类固定样本：一个国内域名、一个需要代理的域名、一个局域网地址、一个指定进程。打开客户端连接日志，逐项确认规则类型、命中策略和最终节点。不要只用浏览器查 IP，因为浏览器缓存、HTTP/3 和已有连接都可能干扰判断。

1. 国内域名应命中 DIRECT 或预期的国内策略。
2. 代理域名应命中业务组，而不是直接落到末尾 MATCH。
3. 192.168.0.0/16 等私有网段应保持直连。
4. 指定进程规则应在对应程序新建连接后出现。
5. DNS 日志不应持续出现超时或循环查询。

第四步：记录回退点

确认当前稳定配置的文件名、混合端口、TUN 开关和主策略选择。测试配置异常时，按「配置」→“稳定配置”切回，再到「设置」→「参数设置」确认 7890 等端口已经恢复。若内核没有自动重启，手动执行一次“停止”再“启动”。

常见问题：导入成功但配置不能用

配置列表存在，代理组却是空的

先看 proxies 是否有节点，或 proxy-providers 是否下载成功。再检查组里的 proxies 名称和 Provider 的 use 名称是否完全一致。名称区分字符，额外空格也会造成引用失败。

更新后自定义规则消失

这是直接修改订阅成品的典型结果。把自定义内容迁移到客户端覆写层，或者建立本地主配置，通过 Provider 引入远端节点。若客户端不支持覆写，就保留本地副本并手动合并，不要继续把订阅缓存文件当长期编辑入口。

切换配置后浏览器仍走旧节点

先新建无痕窗口或彻底关闭浏览器，排除连接复用。再查看连接面板是否产生新连接。如果新连接仍走旧节点，检查同名策略组是否恢复了历史选择，以及规则是否实际引用了另一个组。启用 TUN 时，还要确认虚拟网卡已按新配置重载。

规则已加入，但始终命中 MATCH

检查规则顺序、域名类型和 DNS 行为。DOMAIN 只匹配完整域名，DOMAIN-SUFFIX 才覆盖子域。IP 规则需要连接目标能得到对应 IP；带 no-resolve 时不会为匹配主动触发 DNS。进程规则还依赖平台和内核是否能获取进程信息。

结论：把 Profile 当作可版本化的运行配置

Profile 的核心不是“装了多少节点”，而是把入口、出口、策略和匹配顺序组织成一份内核能执行的配置。proxies 提供出口，proxy-groups 组合策略，rules 分配连接；DNS 与 TUN 则决定域名和系统流量怎样进入这条链路。

多配置并存时，使用可读命名，分清自动订阅与本地配置，保留一份应急 Profile。更新后检查节点、策略组和规则命中；切换前停掉关键连接，切换后验证端口、DNS 与 TUN。这样即使订阅变化或规则改坏，也能快速回到可工作的状态。