Clash Profile 是什么

Profile：客户端保存的一份配置档案

Clash Profile 通常指客户端管理的一份配置档案。它可以来自订阅链接，也可以来自本地 YAML 文件。FlClash 负责保存、更新和选择这些档案，再把处理后的有效配置交给 Clash Meta 内核（mihomo）执行。Profile 不是单个节点，也不等于某个策略组。

一份完整配置可能同时定义监听端口、DNS、代理节点、策略组和分流规则。例如，mixed-port: 7890 指定 HTTP 与 SOCKS 混合代理端口；proxy-groups 决定怎样选择出口；rules 决定连接应交给哪个出口。切换 Profile，可能同时改变这些内容，而不只是更换节点。

• Profile 切换：选择另一份配置，规则、节点来源与组结构都可能变化。
• 策略组切换：仍使用当前配置，只改变某个组选择的节点或子策略组。
• 出站模式切换：在规则、全局、直连之间切换处理方式，不会自动换成另一份订阅。

订阅配置与本地配置有什么区别

两者最终都要生成内核能识别的配置，差别主要在来源和维护方式。订阅配置从远程地址获取内容，后续可以重新拉取；本地配置由用户导入并维护，原始文件发生变化后，是否同步到客户端取决于导入方式，不能默认它一直与磁盘上的文件联动。

订阅地址不一定返回完整 YAML

“订阅”只描述获取方式，不保证内容格式一致。有的地址返回完整 Clash 配置，有的仅返回节点列表或其他客户端格式。下载成功后仍可能无法启用。应选择服务方明确标注适用于 Clash 或 Clash Meta 的入口，并核对当前客户端与内核支持的字段和协议。

订阅链接中的查询参数或路径可能包含访问凭据。排查问题时只展示报错、字段名称和已脱敏的片段；不要把完整链接放进公开截图、工单附件或配置示例。

需要自定义规则时，先确认修改保存在哪里

FlClash 的界面选项、配置覆写与远程 YAML 可能共同影响最终配置。不同版本提供的编辑入口和合并能力不同，不能假定修改订阅正文后会永久保留。优先使用当前版本明确提供的覆写功能；若没有合适入口，可另存本地副本，再记录改动。另存副本后，远程节点变化也需要自行处理。

订阅导入与自动更新间隔

导入时，先区分“添加了一条记录”和“已启用这份记录”。建议按“添加订阅 → 首次拉取 → 检查配置 → 选择启用 → 新建连接验证”的顺序操作。界面名称可能随 FlClash 版本变化，下面以功能为准，不把某一版菜单文字当成通用路径。

1. 添加来源：在配置管理页选择通过链接添加，粘贴完整订阅地址，并填写能识别用途的名称。
2. 确认内容：首次下载完成后，检查节点或策略组是否出现；仅有更新时间并不能证明配置已经应用。
3. 启用配置：将新记录设为当前配置，查看是否出现解析失败、未知策略组或端口占用提示。
4. 验证出口：选择规则模式，打开一个新的测试请求，在连接页检查命中的规则和出站链路。

普通使用可从每 24 小时更新一次开始

24 小时是一个便于管理的起点，不是内核要求。若服务方经常调整节点，可按其说明缩短到 6 小时；若有明确的请求频率限制，应以服务方限制为准。频繁拉取订阅不会改善节点带宽，也不能修复本机 DNS 或 TUN 路由问题。

• 先核对单位：24 小时等于 1440 分钟或 86400 秒。输入框写“分钟”时不要填 24 来表示一天。
• 区分两类更新：Profile 的远程更新与 proxy-providers 中的 interval 不是同一个设置；后者在 mihomo 配置中以秒为单位。
• 确认后台条件：电脑休眠、客户端退出或移动系统限制后台时，不能保证按墙上时钟准点刷新。需要时前台手动更新。
• 分开看时间：最近尝试更新的时间、最近成功更新的时间与订阅到期时间含义不同。更新成功不等于账号有效期延长。

多配置命名与备份：来源、用途、日期

配置数量达到 3 份以后，只用“订阅 1”“新配置”很容易选错。建议按“来源－用途－维护方式”命名，例如“线路A－日常－远程”“线路B－备用－远程”“日常规则－实验－本地”。日期更适合放在备份名中，例如“日常规则－备份－2026-11-03”。

配置名称只用于客户端管理，不会自动变成规则目标。规则引用的是 YAML 中的策略组名称。如果将 proxy-groups 内的组名从“日常出口”改成“主出口”，就需要同步修改引用它的规则和其他组；仅重命名列表中的 Profile 则通常不涉及这些引用。

至少保留一个可回退状态

• 修改前：记录当前配置名、出站模式、选中节点、系统代理和 TUN 开关状态。
• 备份内容：保存 YAML 与必要的覆写设置；只导出基础 YAML，可能漏掉客户端单独保存的参数。
• 保存位置：将含节点密码的备份放在受控目录，避免与公开代码仓库或共享网盘混放。
• 清理旧项：确认替代配置可正常启动，再删除重复记录。不要让已失效地址持续自动刷新。

切换后，连接与规则怎样生效

配置选中、内核加载成功、应用的新连接使用新配置，是三个需要分别确认的环节。客户端可能先保存选择，再加载内核配置；遇到 YAML 错误或不存在的策略组时，界面选中状态并不足以证明切换完成，应结合日志和连接页判断。

新连接与既有连接分别检查

成功加载新配置后，新建连接通常按当前模式和规则处理。已经建立的 TCP 长连接、视频会话或应用连接池，不应假定会自动迁移到新节点。有的客户端会主动关闭连接，有的会继续保留，具体取决于实现与操作方式。验证时优先重新建立请求，必要时使用客户端的关闭连接功能，或重启目标应用。

不要只刷新一个保持长连接的页面就断言切换失败。可在连接页查看新请求对应的域名、命中规则与出口。浏览器缓存、连接复用和 HTTP/3 都可能让一次刷新无法清楚体现变化；“新开标签页”也不保证底层一定新建网络连接。

模式、DNS 与 TUN 不一定随 Profile 一起切换

系统代理、TUN 模式和部分 DNS 参数可能由客户端全局设置管理，也可能通过覆写影响基础 YAML。切换 Profile 后，不能仅凭文件中的 tun 或 dns 内容推断最终状态。检查界面实际开关和有效配置，尤其留意客户端是否仍在使用全局模式。

例如，配置 A 使用 mixed-port: 7890，配置 B 改为 mixed-port: 7891。如果客户端没有覆盖端口，而某个应用手动填了 127.0.0.1:7890，切换后该应用会连接旧端口。由客户端管理的系统代理与应用单独填写的代理地址，也需要分别核对。

本地配置示例：先验证引用关系

下面是一份用于理解本地 Profile 的最小直连示例，可保存为 profile-local-demo.yaml 后导入。它不包含远程代理节点，所有匹配到“日常出口”的连接最终都走 DIRECT，因此不能用来验证远程代理是否可用。

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

proxy-groups:
  - name: 日常出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,日常出口
  - MATCH,日常出口

这份示例展示了两层引用：规则中的“日常出口”必须与策略组名称一致；组内的 DIRECT 是内核内置出站。最后一条 MATCH 接住前面未命中的连接。实际订阅可能使用嵌套策略组、规则集合和代理提供者，不能只复制其中一段就认为依赖已经完整。

YAML 缩进使用空格，不使用 Tab。若导入时提示端口被占用，应先检查是否有其他程序正在监听 7890，而不是反复刷新订阅。若提示找不到某个代理或策略组，则检查名称拼写和引用关系。

常见问题：更新成功但配置没有变化

刷新了备用配置，当前连接为什么没变？

更新某条记录不等于启用它。确认更新对象与当前启用项是不是同一份 Profile；若更新的是备用项，当前运行配置不变是正常结果。即便更新了当前项，也要检查客户端是否已重新加载，以及内容是否真的有差异。

切换后节点名字还在，是否没有切换成功？

不同订阅可能采用相同节点名；客户端也可能恢复同名策略组先前的选择。应同时核对配置名、规则内容和新连接出口，不能只看节点名称。节点改名或被删除后，旧的选择也未必能继续恢复。

本地副本为什么没有收到远程新增节点？

本地副本通常是导入时的内容快照。除非它自己引用了可更新的代理提供者，否则不会因为原订阅变化而自动增加节点。需要持续获取远程节点又保留自定义规则时，应采用当前客户端支持的覆写方式，或正确配置代理提供者及其引用。

推荐的排查顺序是什么？

1. 确认启用的 Profile 名称，检查最近一次成功加载记录。
2. 确认规则、全局或直连模式，核对策略组当前选择。
3. 检查代理端口、系统代理与 TUN 实际状态。
4. 重新建立连接，在连接页核对规则和出口。
5. 若仍异常，回到已验证的备份，一次只恢复一项改动。

Profile 管理的重点是分清来源、更新和运行状态。先用一份配置完成导入与连接验证，再增加备用或实验配置；每次切换都检查新连接，能减少把旧会话、全局设置和订阅内容混在一起排查的时间。