Profile：一套可载入的配置
在 Clash 客户端中，Profile 通常指一份可以选择、更新或编辑的配置记录。它包含配置内容，也可能附带名称、来源地址、更新周期等管理信息。配置内容通常采用 YAML 格式，决定监听端口、节点、策略组、分流规则和 DNS 等行为；名称与更新周期则可能保存在客户端自己的数据库中，而不是写进 YAML。
因此，Profile 不等于一个节点，也不等于订阅账户。一个 Profile 可以包含几十个节点和多个策略组；一条订阅链接则可能在每次获取时返回不同内容。客户端保存的是这条来源对应的配置记录，内核运行时读取的是经过加载、合并或覆写后的配置。
先区分三个层次
- 配置来源：远程订阅地址、本地文件，或者客户端提供的编辑入口。
- 配置内容：YAML 中的
proxies、proxy-groups、rules等字段。 - 运行状态：当前选中的策略、代理模式、已建立连接与系统代理开关。
切换 Profile 主要改变当前加载的配置，不代表所有运行状态都会恢复默认。部分 Clash 客户端会记住策略组选择，部分会通过覆写保留端口或 TUN 设置。判断实际效果时，应同时检查当前配置名称和运行配置，而不是只看配置列表中的高亮项。
订阅配置与本地配置的区别
订阅配置从远程地址获取，适合接收节点、策略组或规则的后续变化。本地配置从设备文件导入，内容由使用者管理。两者都可能是完整 YAML，区别主要在来源与维护方式，不在文件扩展名。
| 项目 | 订阅配置 | 本地配置 |
|---|---|---|
| 导入入口 | 粘贴远程配置 URL | 导入或拖入 YAML 文件 |
| 更新方式 | 手动获取或定时获取远程内容 | 编辑后重新加载，或重新导入文件 |
| 适合内容 | 需要随来源变化的节点与规则 | 固定规则、实验配置和自主管理方案 |
| 主要风险 | 来源过期、返回错误、更新覆盖修改 | 语法错误、字段不兼容、节点信息失效 |
订阅链接不一定返回完整配置
有的链接返回完整 Clash YAML，有的只返回节点列表，还有的返回其他格式的订阅。仅有节点列表时，不能保证直接作为完整 Profile 使用。导入前应确认来源提供的格式；不要仅凭链接中出现“clash”字样判断兼容性。
此外，proxy-providers 是配置内部定义的节点提供器，不等同于客户端列表中的订阅 Profile。一个本地 Profile 可以引用远程 provider；一个远程 Profile 也可以同时包含内置节点和 provider。此时会存在“更新整份配置”和“更新提供器资源”两个独立动作。
YAML 字段与最小验证配置
先理解配置结构，再调整具体参数。不同内核版本支持的字段可能不同；Clash Meta 现称 mihomo，不能把某个 mihomo 扩展字段默认视为所有历史 Clash 内核都支持。以下示例仅用于验证 YAML 加载与本地监听，所有流量均直连，不提供代理节点。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: Route
type: select
proxies:
- DIRECT
rules:
- MATCH,Routemixed-port: 7890：在同一端口提供 HTTP 与 SOCKS 代理入口。7890 是本例指定值，不是所有客户端的固定端口。allow-lan: false：不开放局域网设备访问。需要共享代理时，再单独检查监听地址和防火墙。mode: rule：按规则处理连接。客户端界面中的模式选择可能覆写这个值。proxy-groups：定义名为 Route 的选择组，本例只有 DIRECT 一个选项。MATCH,Route：作为最后一条兜底规则，把此前未匹配的连接交给 Route。
使用内核检查语法
将示例保存为 profile-test.yaml。如果已经安装 mihomo 命令行内核，可在文件所在目录执行：
mihomo -v
mihomo -t -f ./profile-test.yaml第一条命令记录实际内核版本，第二条测试配置。Windows 上可使用 .\mihomo.exe -t -f .\profile-test.yaml，可执行文件名称以安装内容为准。检查成功只说明内核接受配置，并不证明远程节点可连接，也不证明系统流量已经经过代理。
YAML 缩进使用空格，不使用 Tab。策略组引用的名称必须与节点或其他策略组名称一致；将规则写成 DOMAIN-SUFFIX,example.com,Route 时，Route 必须存在。若测试报告行号，先检查该行附近的缩进、冒号和列表符号，再排查字段兼容性。
导入、命名与更新间隔
订阅配置的导入顺序
- 进入 Clash 客户端的配置管理页面，选择远程导入或新增订阅。入口可能显示为“配置”“Profiles”或“订阅”，以实际客户端为准。
- 粘贴来源提供的完整 URL。保留查询参数，不手动删掉令牌；确认返回的是当前内核支持的配置格式。
- 等待获取完成，检查节点、策略组和规则是否存在，再选择启用这份配置。
- 查看日志中的加载结果。若界面仅显示“下载成功”，还需确认后续的配置加载没有报错。
名称包含来源与用途
建议使用 A源-日常-远程、B源-备用-远程、本地-规则实验-20260729 这类名称。来源用于区分维护方，用途用于判断切换目标，日期用于识别实验快照。不要把订阅令牌或密码写进名称，也不要只用“配置1”“配置2”。
订阅 Profile 可以保持稳定名称，把最近更新时间交给客户端记录；本地实验配置则适合增加日期。完成实验后，将稳定版本另存为 本地-日常-稳定，避免长期从多个日期副本中猜测当前应该启用哪一个。
更新周期必须核对单位
日常订阅可先尝试每 24 小时更新一次，这是管理建议，不是协议要求。如果客户端字段单位是分钟，24 小时对应 1440；如果单位是秒，则对应 86400。不要把同一个数字直接复制到不同客户端，也不要为了排查连接失败而把更新周期压到每分钟一次。
配置中的 proxy-providers 或 rule-providers 若使用 interval，其单位通常为秒，需要按当前内核文档确认。客户端的 Profile 更新周期与 provider 的 interval 分别管理不同资源，不能用其中一个替代另一个。
多配置切换与连接验证
常见 Clash 客户端通常一次启用一份主 Profile。配置列表中保存十份记录，不代表十份规则同时生效。部分客户端支持合并、覆写或脚本处理，但这些属于显式配置功能，不能通过“多选几份订阅”推断其运行方式。
切换前记录四项状态
- 主配置：当前 Profile 名称，以及是否存在本地覆写。
- 代理模式：规则、全局或直连，避免把模式变化误认为配置问题。
- 入口端口：例如当前混合端口是否仍为 7890，外部应用是否使用同一端口。
- 接管方式：系统代理与 TUN 开关状态，以及系统所需的权限。
- 点击目标 Profile，等待客户端完成加载。不要在加载期间连续选择多个配置。
- 打开策略组，确认选择项存在且符合用途。若原节点名称已消失，重新选择有效节点。
- 发起一个新的请求，在连接列表中查看匹配规则和最终策略，不只依赖延迟测试。
- 若结果异常，切回上一份已知可用配置，再逐项比较差异。
切换后，已有的长连接可能继续使用旧连接路径；浏览器、下载工具和消息应用也可能复用连接。验证时应创建新请求，必要时关闭目标应用的旧连接。某些客户端提供关闭连接功能，但执行后会中断正在进行的传输，应先确认没有重要下载或会话。
用指定端口验证入口
若当前混合端口确实是 7890，可使用下面的命令强制 curl 走本地 HTTP 代理入口，而不依赖系统代理设置：
curl --proxy http://127.0.0.1:7890 --head https://example.com此命令用于检查请求能否通过该入口完成，并不单独证明使用了远程代理节点。还要在连接记录中检查最终策略；若规则命中 DIRECT，请求会直连。若端口实际是 7897，就必须将命令中的端口同步改为 7897。
TUN 模式负责在系统层接管流量，不是 Profile 的同义词。切换到新配置后，即使 TUN 仍开启，DNS、路由和分流结果也可能改变。先在不开启 TUN 的条件下验证指定代理端口，再检查 TUN 接管，通常更容易区分配置问题与系统权限问题。
更新覆盖与本地修改管理
直接修改远程订阅下载后的 YAML，下一次更新可能覆盖改动。长期维护端口、规则或 DNS 时，应优先使用 Clash 客户端明确提供的覆写、合并或扩展功能；如果没有这类功能，可以复制为本地配置管理，但需要承担后续同步节点的工作。
按内容划分维护责任
| 内容 | 建议维护位置 | 更新后检查 |
|---|---|---|
| 节点地址与认证 | 可信订阅来源或节点提供器 | 节点是否仍存在、认证是否有效 |
| 本地监听端口 | 客户端设置或明确的覆写层 | 运行端口与应用代理地址是否一致 |
| 个人域名规则 | 本地规则扩展或自管配置 | 规则顺序与策略名称是否正确 |
| DNS 与 TUN | 选定一个明确的管理位置 | 运行值、系统权限与路由是否匹配 |
规则顺序尤其重要：普通规则通常从上到下匹配。如果新增域名规则放在 MATCH 后面，就不会按预期处理这些连接。覆写列表时还要确认客户端是替换整个列表，还是插入到列表头部或尾部；不同实现不能互相套用。
修改前保存一份已知可用配置，同时记录客户端名称、内核版本和覆写内容。每次只调整一类设置，例如先改规则，再改 DNS。这样在更新后出现问题时，可以回退具体改动，而不必重置整个客户端。
常见问题与整理清单
订阅更新成功，为什么节点没有变化？
可能是来源本身没有变化，也可能是节点来自独立 provider，需要更新该提供器。还应确认更新的是当前启用的 Profile，而非列表中的备用记录。不要把客户端显示的更新时间当作节点必然更新的证明。
配置导入成功，为什么不能连接？
导入、解析、加载和实际连接是不同阶段。依次检查日志是否加载成功、策略组是否选择了有效节点、7890 等实际端口是否监听，以及应用是否通过系统代理或 TUN 接管。节点延迟测试成功，也不代表所有网站都会匹配同一策略。
两份订阅可以合成一份吗？
可以通过支持的配置合并机制或自管 provider 组织节点，但不能简单拼接两个 YAML 文件。同名顶层字段、重复节点名称、策略组引用和规则顺序都需要处理。入门阶段保留两份独立 Profile，按用途切换，更容易验证与回退。
迁移到另一台设备需要复制什么？
除配置文件外，还要记录订阅来源、更新周期和本地覆写。迁移后重新确认端口、系统代理与 TUN 权限；桌面平台的路径、网络接口名称和路由设置不应原样套用到手机。复制文件之前，先确认保存位置与传输方式适合承载账户凭据。
- 保留一份日常配置、一份备用配置和一份实验配置，及时清理确认不用的副本。
- 为远程配置记录来源与更新周期，为本地配置记录修改日期与用途。
- 更新后检查加载结果；切换后检查新连接的规则与最终策略。
- 修改前备份，遇到问题先切回已知可用配置，再定位具体差异。
Profile 管理的重点是区分来源、内容和运行状态。把远程更新与本地改动分开，把配置切换与连接验证配对，才能在节点变化、客户端升级或设备迁移时保持配置可追踪、可回退。