Profile 不是单独的节点列表

Clash 客户端里的 Profile，通常指一份可被内核加载的配置。它可能来自订阅地址，也可能是手动导入的本地 config.yaml。一份可用配置不只保存服务器地址，还会描述监听端口、DNS 行为、代理节点、策略组、分流规则以及 TUN 参数。切换 Profile，本质上是让客户端重新加载这一整套运行状态。

订阅服务返回的内容也不一定都是完整 Clash YAML。有些链接返回 Base64 节点集合，需要订阅转换服务生成 Clash 格式；有些链接直接返回包含 proxies、proxy-groups 和 rules 的 YAML。导入成功只说明文本被客户端接受，是否能正常联网还取决于字段兼容性、节点有效性和规则引用关系。

一份配置加载时发生什么

  1. 客户端读取 YAML，并检查缩进、字段类型和必要参数。
  2. Clash 或 mihomo 内核建立本地监听端口，例如 HTTP 与 SOCKS 混合端口 7890。
  3. 内核创建节点与代理组，解析各组引用的成员。
  4. 规则从上到下进入匹配器，规则集提供器按需下载远程内容。
  5. 启用 TUN 时，Android 客户端请求系统 VPN 授权并建立虚拟网络接口。

其中任何一步失败，都可能出现“配置已导入但无法启动”。例如 YAML 缩进错误会在解析阶段终止；策略组引用了不存在的节点名称，会在配置校验阶段报错；远程规则集不可达，则可能只影响依赖该规则集的分流结果。

config.yaml 核心字段逐层拆解

YAML 依赖缩进表达层级，通常使用两个空格，不使用制表符。下面是一份用于理解结构的精简示例。服务器地址、凭据和协议参数仅用于展示字段位置，不应直接作为可连接配置使用。

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

proxies:
  - name: HK-A
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: example-password

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

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

基础监听与运行模式

mixed-port: 7890 表示在同一端口接受 HTTP 和 SOCKS5 代理连接。桌面程序常把系统代理指向 127.0.0.1:7890。Android 客户端更多通过 VpnService 或 TUN 接管流量，但混合端口仍可用于局域网调试或单个应用手动配置。

  • mode: rule：按 rules 从上到下匹配，日常使用最常见。
  • mode: global：大部分流量交给全局策略组，不再依次判断普通分流规则。
  • mode: direct：流量直接连接，适合临时判断故障是否来自代理链路。
  • allow-lan: false：不向局域网设备开放本地代理端口。需要共享时还应同时检查监听地址与系统防火墙。
  • log-level: info：保留常规运行记录。短时排障可改为 debug，完成后再恢复。

proxies：具体出口节点

proxies 下的每一项代表一个节点。不同协议要求不同字段，例如 Shadowsocks 使用 cipher 与 password，Trojan 通常使用 password、TLS 服务器名称等参数。mihomo 还支持更多协议与扩展字段，但这不表示所有旧版 Clash 内核都能识别。

name 是配置内部的引用键。策略组写入的名称必须与节点名称完全一致，包括空格、大小写和符号。两个节点重名时，部分客户端会拒绝加载，另一些实现可能覆盖前项，因此订阅生成阶段应保持名称唯一。

proxy-groups：选择与自动测试

策略组把多个节点或其他策略组组合为一个可被规则引用的出口。常见类型包括手动选择的 select、按测试结果选择的 url-test、故障切换的 fallback 与负载分配的 load-balance。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - HK-A
      - SG-A
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

这段配置每 600 秒执行一次测试。tolerance: 80 表示延迟差距未超过 80 ms 时，不必频繁更换当前节点。缩短为 30 秒会增加网络请求与后台唤醒次数，移动设备通常没有必要持续高频测试。

rules：从上到下的首次匹配

Clash 规则不是给每条连接执行全部判断，而是按顺序寻找第一条命中项。更具体的域名规则应放在较宽泛规则之前，末尾通常使用 MATCH 处理剩余流量。若把 MATCH,DIRECT 放在第一行，后续代理规则将没有机会生效。

  • DOMAIN,api.example.com,节点选择：只匹配完整域名。
  • DOMAIN-SUFFIX,example.com,节点选择：匹配主域名及其子域名。
  • IP-CIDR,192.168.0.0/16,DIRECT：匹配指定 IPv4 网段。
  • GEOIP,CN,DIRECT：根据 IP 地理数据库匹配。
  • MATCH,节点选择：接收此前没有命中的连接。

DNS、Fake-IP 与 TUN 参数如何关联

DNS 字段决定域名如何解析，但并不单独决定流量出口。域名经 DNS 模块处理后，连接仍需进入规则系统。启用 fake-ip 时，本地 DNS 会返回映射地址，内核根据该映射还原域名并完成规则匹配。这样可以减少应用自行解析导致的域名规则失效问题。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

198.18.0.0/16 是常见的 Fake-IP 映射范围。看到应用连接这个网段，不等于它正在访问公网中的同名地址。mihomo 内核会维护域名与映射地址的对应关系，再将连接交给规则和目标节点。

何时需要 Fake-IP 过滤

局域网设备发现、某些游戏平台和依赖真实局域网地址的应用，可能不适合接收 Fake-IP。此时可在 fake-ip-filter 中加入精确域名或通配规则。过滤范围不宜直接扩大到所有常用域名，否则域名规则的完整性会下降，也可能重新暴露应用绕过代理 DNS 的问题。

TUN 配置不等于 Android 授权状态

配置中的 tun.enable 只是内核参数。Android 是否允许建立 VPN 接口，由系统 VpnService 授权决定。首次启动通常需要在系统连接请求中确认；同一时间已有其他 VPN 应用运行时，新接口可能无法建立。

不同 Android 客户端对菜单名称的安排并不完全相同。常见路径是「设置」→「参数设置」→「TUN 模式」，或在主页服务卡片中直接启用。修改 stack、路由排除项和 DNS 劫持后，应停止服务再启动，确保旧连接与路由表被重新建立。

订阅更新会覆盖哪些内容

远程 Profile 通常保存一个订阅 URL。客户端执行更新时，从该地址重新下载内容，再替换对应配置的远程快照。节点增删、策略组成员和规则顺序都可能随新内容变化。直接编辑下载后的 YAML，下一次更新时通常会被覆盖。

远程内容、本地覆写与运行配置

理解三层状态有助于避免“明明改了但没生效”。第一层是订阅服务器返回的原始配置；第二层是客户端保存的本地 Profile；第三层是经过覆写、脚本或兼容转换后交给内核的最终配置。界面中显示的内容可能属于第二层，而日志中的实际参数来自第三层。

  1. 先记录当前 Profile 名称和更新时间，例如 2026-07-30 09:40。
  2. 手动更新订阅，确认返回状态正常，并检查节点数量是否发生变化。
  3. 打开配置预览，核对 proxy-groups 与 rules 是否仍引用有效名称。
  4. 检查「设置」→「参数设置」中的 DNS、路由和覆写选项。
  5. 重载配置或重启服务，再通过连接日志确认实际命中的规则与策略组。

自动更新间隔应结合订阅变化频率设置。节点信息每天只调整一次时，没有必要每 15 分钟拉取。常见设置可从 1440 分钟开始；需要临时同步变更时，再执行手动更新。过短间隔只会增加后台请求和失败重试。

适合保留在本地的改动

固定的局域网直连规则、个人域名规则和设备专用 DNS 参数，更适合作为覆写层，而不是直接改远程文件。客户端若支持 Merge、Mixin 或覆写功能，可将新增字段与订阅结果合并。合并前需要确认数组处理方式：有的实现是追加 rules，有的实现会整体替换。

规则顺序尤其敏感。个人直连规则若追加在末尾 MATCH 之后，将永远无法命中。正确做法是插入到宽泛规则与最终规则之前，并在日志中检查类似 DOMAIN-SUFFIX 或 IP-CIDR 的命中记录。

多配置共存与切换管理

工作网络、家庭网络和测试环境可以分别保存为不同 Profile。多配置的价值在于隔离规则与参数，而不是把所有节点堆进同一个文件。每份 Profile 应使用可识别名称，例如 Daily-Meta、Office-Direct 和 Lab-TUN，同时记录来源与用途。

切换前检查四类差异

  • 内核兼容：配置是否使用 mihomo 专属字段。旧 Clash 内核遇到未知协议或规则集格式时可能加载失败。
  • 端口占用：两个本地服务若同时监听 7890 或 DNS 端口 1053，后启动者会出现绑定错误。
  • 模式状态：部分客户端把 rule、global、direct 作为全局界面状态，不一定随 Profile 一起切换。
  • 覆写范围：全局覆写可能作用于所有 Profile，配置专属覆写则只影响当前条目。

切换配置后，原有 TCP 连接可能继续使用旧出口，直到连接关闭。验证时应重新打开应用或清除测试连接，再观察新日志。只刷新网页不一定能触发新建连接，因为 HTTP/2 和 QUIC 都可能复用现有会话。

备份时保存什么

本地手写配置应保留独立副本，并记录修改日期。远程订阅则重点保存订阅入口、覆写规则和客户端设置，不必把每次下载的临时副本都当作主文件。订阅 URL 常包含访问凭据，备份时应放在受控位置，不要粘贴到公开日志、截图或问题反馈中。

从旧客户端迁移到 Clash Meta 或 mihomo 客户端时，先导入一份 Profile 做校验，再迁移其余配置。重点检查 proxy-providers、rule-providers、策略组筛选表达式和 TUN 字段。能被 YAML 解析不代表远程提供器一定可下载，也不代表所有节点协议均被当前内核支持。

配置加载失败的定位顺序

配置问题适合按层排查。先判断文件能否解析，再判断节点能否建立连接，最后判断规则是否把流量送到预期出口。跳过解析错误直接反复测试节点，通常无法得到有效结论。

第一层：YAML 与字段校验

  • 检查冒号后是否有空格，例如 mode: rule。
  • 检查列表项 - 与父级字段的缩进。
  • 包含冒号、井号或特殊符号的名称可使用引号包裹。
  • 检查策略组、规则和提供器引用的名称是否存在。
  • 查看客户端日志中的行号，优先修复第一处解析错误。

第二层：节点与网络连通性

选择单个节点执行延迟测试，只能说明测试 URL 的连接结果，不代表全部网站均可访问。可先将模式切到 global 做短时验证，再恢复 rule。若全局模式可用而规则模式不可用，应检查规则命中和策略组当前选择；两种模式都不可用，则继续检查节点参数、系统时间、DNS 与网络限制。

第三层：规则与最终出口

在日志中找到目标域名对应的匹配记录，确认它命中了哪条规则、进入哪个策略组、最终选择哪个节点。若日志只显示 IP 而没有域名，可检查 DNS 是否由 Clash 接管，以及应用是否使用了自带加密 DNS。排障期间可把日志级别调整为 debug，记录完成后恢复 info。

建立可维护的 Profile 使用习惯

配置管理的核心是区分来源与职责。订阅负责提供节点和基础策略，本地覆写负责个人规则，客户端设置负责系统接口与应用行为。把三者混在同一个远程文件里，更新后很难判断变化来自哪里。

  1. 为每份 Profile 设置用途明确的名称，并保留来源说明。
  2. 更新前记录当前可用节点与策略组选择，更新后对比关键字段。
  3. 个人规则放入可重复应用的覆写层，并确认插入位置。
  4. 减少高频自动测速与订阅刷新，移动设备优先控制后台唤醒。
  5. 切换 Profile 后重新建立测试连接，通过日志验证规则，而不是只看状态图标。
  6. 升级内核前检查配置兼容性，尤其是协议扩展、规则提供器和 TUN 参数。

当 Profile 被视为“节点、策略组、规则、DNS 与系统接管参数的完整快照”后，订阅更新和多配置切换就会更容易理解。出现故障时，也能沿着配置解析、节点连接、DNS 处理、规则命中和系统路由逐层定位，而不是反复删除和重新导入同一份文件。