Clash 配置文件 Profile 入门:订阅链接、本地配置与多配置切换

Profile 与订阅的关系

Clash 客户端里的 Profile，通常指一份可被选中并加载的配置档案。它可能来自远程订阅，也可能来自电脑上的 YAML 文件。档案除了保存配置内容，还可能记录来源地址、更新时间、更新周期等客户端信息。内核实际读取的是客户端处理后的配置，并不是界面里那张配置卡片本身。

理解这一点，就能分清三个常被混用的操作：导入是把配置加入列表；更新是重新取得配置内容；启用是把某份配置交给内核运行。导入成功不代表已经启用，下载成功也不代表内核接受了新内容。

尤其要区分整份订阅与 proxy-providers。前者可能同时定义端口、DNS、分组和规则；后者主要提供节点，再由主配置的策略组通过 use 引用。rule-providers 则提供规则集，不负责提供代理节点。

订阅链接如何导入

先确认返回的是哪种格式

同一个服务可能提供多种订阅格式。适用于其他代理软件的节点列表，不一定能直接当作 Clash 的完整 YAML 配置使用。优先选择服务方明确标注的 Clash 或 mihomo 格式；若内容包含 VLESS、Hysteria2 等协议，还要确认客户端实际使用的内核支持这些协议，不能只看应用名称中有没有 Clash。

1. 在客户端找到「配置」或「Profiles」页面，使用其中的链接导入入口。不同客户端的按钮名称可能是「新建」「导入」或「添加」，以当前界面为准。
2. 粘贴完整地址，不要带前后的空格、引号或聊天软件附加的标点。给档案取一个能识别用途的名称，例如「家庭网络」或「出差备用」。
3. 完成导入后检查更新时间，再主动选中这份配置。观察日志中是否出现解析失败、未知字段或策略组引用错误。
4. 打开代理组，确认节点列表存在，再测试一个明确经过该组的新连接。此时先不要同时改 DNS 和 TUN，以免混淆故障来源。

导入失败先看响应内容

如果错误提示涉及 YAML，却看到响应以 <html> 开头，下载到的可能是登录页或错误页面。HTTP 401、403 常与授权失效或访问限制有关；429 通常表示请求频率受限。这些情况应先核对订阅来源，不要反复点击更新，也不要为了绕过错误随意关闭 TLS 证书验证。

本地配置与最小示例

本地 Profile 适合需要固定规则、离线保留配置，或者先学习字段含义的情况。新建 UTF-8 编码的 profile-local.yaml，使用空格缩进，不要用 Tab。下面是一份用于理解结构的最小配置：监听本机 7890 端口，只有一个直连选项，不包含远程代理节点。

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

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手动选择

• mixed-port: 7890 提供 HTTP 与 SOCKS 代理入口；端口数值只是本例设置，不代表每个客户端都使用 7890。
• allow-lan: false 不开放给局域网其他设备使用。初次配置保持这个值，减少额外的网络暴露。
• mode: rule 使用规则模式；最后的 MATCH 接住前面未匹配的连接。
• 手动选择 是策略组名称，规则引用它时必须逐字一致。本例最终选择 DIRECT，所以流量仍然直连。

把文件作为本地配置导入后，客户端仍可能覆写监听端口、运行模式或 DNS。需要排查时，应同时查看原文件、客户端设置和运行配置，而不是只盯着 YAML。关于内核字段与兼容性，可继续查阅内核配置参考。

若系统已有可执行的 mihomo，可在文件所在目录执行以下语法测试。成功仅说明配置通过该内核的加载检查，不代表节点可达，也不代表桌面系统代理已经开启。

mihomo -t -f ./profile-local.yaml

自动更新间隔怎么设

对节点变动不频繁的日常配置，可以先把 Profile 自动更新设为每 24 小时一次；经常调整节点的服务，可按服务方建议改为每 6 小时一次。这是设置起点，不是实测性能结论。更新得更频繁，不会让已有节点延迟更低，反而可能触发服务端限流。

先看单位，再输入数值

• 客户端界面若以“分钟”为单位，24 小时应填 1440；以“小时”为单位则填 24。
• mihomo 的 HTTP 代理提供器中，interval: 86400 表示 86400 秒，即 24 小时；这个字段不是 GUI 的 Profile 更新周期。
• 提供器中的健康检查周期 health-check.interval 是检测节点状态的频率，不是重新下载订阅的频率。
• 不要默认 0 一定表示关闭。不同客户端的约定可能不同，优先使用明确标注的自动更新开关。

电脑休眠、客户端退出或网络不可用时，更新任务可能无法按时执行。恢复联网后先查看“最后成功更新”的时间；修改订阅地址后，再手动更新一次确认结果。不要仅凭自动更新开关处于开启状态，就认为文件已经是最新内容。

多配置切换的检查顺序

多数桌面客户端一次只启用一份主要 Profile。列表中保存三份配置，不等于同时把三家的节点全部加载进同一个策略组。切换档案时，新的规则、DNS 和策略组可能一起生效；而系统代理、TUN 授权等通常由客户端管理，未必随着档案同步切换。

1. 记录旧状态：记下当前配置名称、运行模式、选中的节点以及系统代理和 TUN 开关状态。
2. 选中新档案：确认界面显示其为活动配置，检查内核日志有没有加载失败；加载失败时客户端可能继续使用旧配置。
3. 检查策略组：同名组的选择可能被客户端记忆，但旧节点在新配置中可能不存在，不能假设仍选中了原来的节点。
4. 确认入口端口：若应用手动配置为 127.0.0.1:7890，而新运行配置实际监听 7897，就要统一两端设置。
5. 建立新连接：关闭并重开测试页面或相关应用连接，观察连接记录中的规则和出口。旧 TCP 长连接不一定会因切换立即重建。

出现“切换后浏览器能用，终端不能用”时，先检查终端环境变量，而不是立即换订阅。Linux 下执行以下命令可查看常见代理变量；输出可能包含内部地址，分享日志前应自行处理敏感内容。

printenv http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY

系统代理主要影响愿意遵循其设置的应用；TUN 通过虚拟网络接口接管更多连接，需要相应服务或权限。Profile 切换并不能代替 TUN 授权。两者的使用边界可对照TUN 模式说明逐项检查。

合并配置要处理哪些冲突

如果确实需要在一份配置里使用多个来源，优先考虑主配置搭配 proxy-providers，或客户端明确支持的合并功能。不要把两个完整 YAML 文件首尾拼接：重复的顶层键可能被解析器拒绝，也可能产生覆盖效果，结果并不等于节点与规则自动相加。

规则的顺序比条数更重要

规则通常按从上到下的顺序匹配。若把自定义规则追加在 MATCH,DIRECT 后面，连接已经被兜底规则接住，后续规则就不会按预期生效。客户端提供“前置规则”和“后置规则”两种入口时，应确认最终生成的位置，而不是只看编辑器里保存成功的提示。

此外，普通完整订阅不一定能直接作为 proxy-providers 的资源使用；提供器需要内核支持的节点资源格式。合并工具对数组也可能采用整段替换，而不是追加。每次只增加一个来源，加载测试通过后再检查运行配置中的节点数、策略组引用与规则末尾，比一次性粘贴多份内容更容易定位问题。

备份、恢复与常见问题

备份不能只留订阅地址

订阅地址能帮助重新下载远程内容，却不能完整恢复自定义规则、客户端覆写和策略选择。建议在首次可用、每次大改规则之前各留一份备份，并用日期区分。保留一份已知可用的本地配置，恢复时会更有把握。

• 配置文件：保存本地 YAML、远程配置的可用快照，以及来源名称和更新时间。
• 自定义层：保存覆写文件、合并脚本和自己维护的规则资源，不只复制运行时生成文件。
• 客户端设置：记录监听端口、系统代理、TUN 与更新周期；优先使用客户端正式提供的导出功能。
• 隐私保护：备份可能包含节点密码、订阅令牌或控制接口密钥，应保存在受限目录中；同步到其他设备时使用受保护的存储方式。

为什么更新后规则恢复原样？

最常见的原因是修改了远程文件本体。将改动移到客户端的独立覆写层，再检查生成配置是否保留规则。不要直接长期编辑临时运行文件，它可能在重启、切换或更新时重新生成。

为什么本地配置不会自动更新？

本地导入通常只有文件内容，没有远程来源。部分客户端会复制文件而不是持续读取原路径，因此修改磁盘上的原文件也未必立即生效。确认客户端是否支持文件关联；不支持时重新导入或使用其编辑入口，并重新加载。

恢复旧配置后仍不能连接怎么办？

先确认内核已成功加载旧档案，再检查订阅是否过期、系统时间是否正确、端口是否被占用。恢复配置不能恢复服务端已经删除的节点，也不能自动补齐系统权限。按“配置加载 → 入口端口 → 规则命中 → 节点连通”的顺序排查，通常比同时切换多个开关更有效。更多订阅问题见订阅常见问题。