Clash 配置文件是什么:Profile 结构入门与多配置管理

Clash Profile 到底保存了什么

Clash 客户端里的 Profile 通常翻译为“配置”或“配置文件”。它不是单纯的节点列表，而是一份描述代理核心如何监听端口、解析 DNS、组织节点、建立策略组并匹配流量规则的结构化文档。经典 Clash、Clash Meta 以及后续的 mihomo 核心主要使用 YAML 格式，但不同图形客户端还会在 YAML 之外保存选中策略、订阅更新时间和界面偏好。

一份可以启动的基础配置通常包含监听端口、运行模式、代理节点、策略组和规则。使用 mihomo 时，还可能包含 TUN、sniffer、rule-providers、proxy-providers 等扩展字段。客户端读取 Profile 后会解析 YAML，再把有效内容交给核心进程；缩进错误、字段类型不符或引用了不存在的策略组，都可能让加载过程停止。

常见字段	作用	典型内容
`mixed-port`	提供 HTTP 与 SOCKS 混合代理入口	`7890`
`mode`	决定流量按规则、全局代理或直连处理	`rule`
`proxies`	保存静态代理节点定义	节点名称、服务器、端口与协议参数
`proxy-groups`	组织手动选择、自动测速和故障转移策略	`select`、`url-test`、`fallback`
`rules`	从上到下匹配域名、IP、进程或规则集	`DOMAIN-SUFFIX`、`IP-CIDR`、`MATCH`
`dns`	控制 DNS 监听、上游服务器与解析模式	`fake-ip` 或 `redir-host`

下面这段精简示例展示了字段之间的引用关系。规则最后一列必须指向已有策略组，例如规则中的“节点选择”要与 proxy-groups 里的名称完全一致，包括空格和大小写。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "节点 A"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "节点 A"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,节点选择
  - MATCH,DIRECT

订阅配置与本地配置的区别

订阅配置由一个远程 URL 获取。客户端向该地址发起 HTTP 请求，服务端返回 Clash YAML，客户端再保存为本地副本并加载。订阅链接本身相当于访问凭据，复制到日志、截图或公开仓库都可能造成账户信息暴露。日常管理时应把它当作密码处理。

本地配置则是用户直接导入或编辑的 YAML 文件。它不会因为点击“更新订阅”自动改变，适合保存自建节点、固定规则、调试配置和离线环境。两者最终都要变成核心能够读取的 YAML，但来源、更新方式和覆盖行为不同。

比较项	订阅配置	本地配置
内容来源	远程订阅服务返回	本机文件或手工编辑
更新方式	按周期或手动重新请求 URL	直接修改文件后重新加载
远端覆盖	更新时通常替换下载副本	不受订阅更新影响
适合场景	节点经常变化、由服务端统一维护	固定规则、实验配置、自建服务

为什么直接修改订阅 YAML 容易丢失

很多客户端允许打开当前订阅的缓存文件并编辑，但下一次更新会重新下载整份文档，手工添加的规则、DNS 参数或策略组因此被覆盖。即使客户端保留了旧文件，新的 Profile 也可能获得另一个内部标识，造成修改内容没有被继续使用。

需要长期保留自定义内容时，优先使用客户端提供的覆写、脚本或合并功能。不同客户端的菜单名称并不统一，常见入口包括「配置」→「覆写」、「Profiles」→「Merge」或配置卡片右侧的编辑菜单。使用 mihomo 的客户端还可能支持覆写 DNS、规则和 TUN 字段。启用前应确认合并顺序：后写入的同名标量一般覆盖前值，而数组是替换还是追加由客户端实现决定。

更新与切换实际发生了什么

手动更新与自动更新

点击配置卡片上的更新按钮后，客户端通常按“请求订阅地址、检查响应、写入临时文件、解析 YAML、替换旧缓存、通知核心重载”的顺序工作。HTTP 请求成功并不代表配置一定可用：返回登录页、错误提示或格式不完整的 YAML 时，状态码可能仍是 200，但解析阶段会失败。

自动更新只是定时执行同一流程。常见间隔为 6、12 或 24 小时，部分客户端读取订阅响应中的更新间隔，部分则使用「设置」→「配置」或「Profiles」页面设定的固定周期。笔记本休眠期间通常不会执行任务，唤醒后是否立即补更取决于客户端调度逻辑。

更新前记录当前 Profile 名称和选中的策略组，避免更新后难以确认变化来源。
确认系统时间正确。系统时间偏差过大可能导致 HTTPS 证书验证失败。
更新后检查节点数量、策略组名称和最后更新时间，不要只看“请求成功”。
打开核心日志，确认没有 yaml、parse、proxy group 等错误。
用一个普通 HTTPS 页面验证规则命中，再测试需要代理的目标，不要只依赖延迟数字。

切换 Profile 不等于只换节点

在配置列表选择另一份 Profile，客户端会让核心重新载入整份配置。监听端口可能从 7890 变成 7897，DNS 模式可能从 fake-ip 变成 redir-host，TUN 开关、路由规则和策略组也可能同时变化。因此，切换后出现“浏览器可以访问，终端不通”或“系统代理仍指向旧端口”时，应先核对端口和接管模式。

系统代理只是操作系统中的代理地址设置。例如 Profile 使用 mixed-port: 7890，客户端通常会把系统 HTTP 与 HTTPS 代理指向 127.0.0.1:7890。如果新配置改为 7891，但图形客户端没有同步刷新系统代理，应用仍会连接旧端口。可先关闭再开启系统代理，让客户端重新写入地址。

TUN 模式的切换范围更大。mihomo 会创建虚拟网络接口并接管符合路由条件的流量，DNS 劫持、严格路由和自动路由参数都来自当前配置或客户端覆写。切换 Profile 后应在「设置」→「网络」或「设置」→「TUN 模式」检查状态；macOS 还可能要求重新确认网络扩展或管理员权限。

多配置并存的命名与分组方法

同时使用多个订阅时，最常见的问题不是配置数量，而是名称失去辨识度。仅使用“机场 A”“备用”或自动生成的随机文件名，几个月后很难判断配置用途、来源和更新策略。名称应描述用途，而不是描述当时的临时状态。

建议采用四段式名称

用途-来源-平台-更新方式

工作-服务A-macOS-自动12h
个人-服务B-全平台-手动
测试-本地规则-mihomo-固定
应急-服务C-iOS-自动24h

“用途”用于区分工作、个人、测试或应急；“来源”只写便于识别的简称，不要把完整订阅地址放进名称；“平台”标记是否包含特定系统规则；“更新方式”提示这份配置会不会自行变化。客户端名称长度有限时，可以缩短为 Work-A-Mac-12h，但应保持所有配置使用同一顺序。

不要把所有节点塞进一份文件

将多个来源合并到一份大型 YAML 看似方便，实际会带来重名、规则覆盖和更新困难。两个订阅都可能包含“自动选择”“香港节点”等同名项目；合并工具若没有稳定的重命名规则，策略组会引用到错误节点。配置达到数百个节点后，测速请求也会在短时间内产生大量连接。

更清晰的方式是保留独立 Profile，需要跨来源选择时再使用 proxy-providers。mihomo 的 provider 可以从多个远程文件载入节点，并在主配置中通过 use 引用。这样主配置负责规则和策略，节点来源独立更新。

proxy-providers:
  provider-a:
    type: http
    url: "https://subscription.example/provider-a.yaml"
    path: ./providers/provider-a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "自动选择"
    type: url-test
    use:
      - provider-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

示例中的 interval: 43200 表示每 12 小时更新一次 provider，健康检查每 600 秒执行，策略组每 300 秒重新评估延迟。实际间隔不宜设置得过短；节点较多时，60 秒一次的全量测试会增加连接数和电量消耗。移动设备可将策略评估调整为 600 至 1800 秒。

备份与恢复应该保留哪些内容

配置备份的目标不是复制整个应用目录，而是保存能够重建运行环境的必要资料。不同客户端的目录结构与数据库格式会随版本变化，直接覆盖应用数据目录可能把旧版状态带入新版。更可靠的做法是同时保留可读的 YAML、订阅来源说明和关键设置记录。

建议备份的五类资料

本地 YAML：包括手写主配置、覆写文件、自定义规则和 provider 定义。
订阅清单：记录服务名称、用途和更新周期；订阅 URL 应保存在受保护的密码管理工具中。
客户端设置：记录系统代理、TUN、开机启动、允许局域网连接和端口设置。
版本信息：记录图形客户端版本与核心版本，例如客户端 2.0.0、mihomo v1.19.x，便于复现字段兼容性。
恢复说明：写明导入顺序、默认 Profile、常用策略组和必要的系统授权步骤。

备份文件可以按日期归档，例如 clash-profile-backup-2026-07-09。每次大改 DNS、TUN 或规则前保存一个版本，并在文件名中增加用途，例如 work-mac-before-tun-change.yaml。YAML 本身适合使用 Git 记录差异，但包含订阅地址、认证参数或私有服务器信息的文件只应进入访问受控的私有仓库。

恢复时不要一次开启所有功能

安装与原环境兼容的客户端版本，先保持系统代理和 TUN 关闭。
导入 YAML，检查核心能否启动，并确认日志没有字段解析错误。
手动选择一个可用节点，使用 127.0.0.1:7890 测试本地代理端口。
开启系统代理，验证遵循系统代理的浏览器和应用。
最后开启 TUN，检查 DNS、局域网访问和休眠唤醒后的网络状态。

分阶段恢复可以明确问题属于 Profile、节点、系统代理还是 TUN。如果导入后立即开启所有功能，一旦网络中断，日志里会同时出现 DNS、路由和连接错误，很难判断最初的失败点。

常见 Profile 问题与定位方法

配置更新了，但节点列表没有变化

先确认更新的是当前启用的 Profile，而不是名称相近的另一份配置。随后查看更新时间和订阅响应内容。如果远端确实返回新节点，但界面仍显示旧列表，可切换到其他 Profile 再切回，或重启核心触发重新加载。仍未变化时，检查客户端是否启用了固定覆写或 provider 缓存。

导入 YAML 后提示解析失败

YAML 使用空格表达层级，不能依赖 Tab 缩进。重点检查列表项前的短横线、冒号后的空格、包含特殊字符的节点名称和重复字段。错误日志若给出行号，应从该行向上检查一个完整区块，因为真正的缩进问题经常发生在前几行。

# 正确：proxies 是数组
proxies:
  - name: "节点 A"
    type: socks5

# 错误：列表项与字段层级不一致
proxies:
 - name: "节点 A"
    type: socks5

切换配置后所有网站都直连

检查 mode 是否为 direct，规则末尾是否写成 MATCH,DIRECT，以及目标域名是否命中了直连规则。mihomo 日志会显示连接目标、命中规则和最终策略。若日志完全没有新连接，问题通常在系统代理、应用代理设置或 TUN 接管，而不是规则本身。

策略组选择每次重启都会恢复

经典配置字段 profile.store-selected: true 可让支持该字段的核心保存策略组选择；mihomo 也支持 Profile 持久化相关设置。不过图形客户端可能接管这部分状态，或者在每次更新时生成新的配置标识。除了开启持久化，还应保持策略组名称稳定，避免在订阅转换中自动添加日期或节点数量。

profile:
  store-selected: true
  store-fake-ip: true

新手管理流程：从一份配置开始

刚开始使用时，不必立刻合并多个订阅或编写复杂规则。先保留一份主用订阅，确认更新、切换节点、系统代理和日志查看都能正常工作。第二份配置只作为应急来源，并使用明确名称区分。等到确实需要跨来源选择节点时，再引入 provider 或覆写机制。

日常操作可以固定为一套短流程：每周检查一次订阅更新时间；配置更新后确认节点数量和策略组；修改规则前复制本地 YAML；切换 Profile 后检查端口与接管模式；客户端升级后记录核心版本。这样可以把“突然无法连接”拆成几个可验证的环节，而不是反复删除和重新导入。

Profile 管理的关键是区分三层内容：远端维护的订阅、本机长期保留的规则、客户端记录的运行状态。订阅负责提供变化中的节点，本地配置负责表达稳定的路由意图，客户端状态负责记住当前选择。三者分开管理后，多配置并存、自动更新和设备迁移都会更容易控制。