Clash 配置文件与订阅

Profile、配置文件与订阅链接

Clash 客户端中的 Profile，通常指一份可供内核加载的配置及其管理记录。配置正文多采用 YAML 格式，常见扩展名是 .yaml 或 .yml。管理记录则可能保存显示名称、订阅地址、自动更新时间等信息；这些记录不一定写在配置正文里。

订阅链接是获取内容的入口，不是代理节点本身。客户端访问链接后，服务端可能返回完整 Clash 配置，也可能只返回节点列表。导入成功只说明客户端拿到了可识别的内容，不能单凭这一状态判断节点可用、规则正确或流量已经被接管。

三大段落如何连接

读配置可以从出站引用关系入手：proxies 定义节点，proxy-groups 把节点或其他策略组织成组，rules 决定连接交给哪个出站。某些配置还通过 proxy-providers 引入节点，因此本地 proxies 为空不一定是故障。

proxies：节点的连接参数

每个节点通常包含 name、type、server、port，以及协议所需的认证和传输字段。节点名称是后续引用的标识。修改名称后，需要同步修改策略组中的引用；只改一处，可能出现找不到代理的加载错误。

节点的出口地区、认证信息与服务端端口由提供方决定。不要把客户端本地监听端口写成节点的服务端端口，也不要仅凭名称判断协议。名称中的“香港”或“备用”只是标签，不参与连接协议选择。

proxy-groups：手动选择与自动选择

• select：手动选择成员。适合需要明确固定出口的场景。
• url-test：根据指定探测地址的测试结果自动选择。测试结果不等同于文件下载速度。
• fallback：按成员顺序检查可用性，优先使用排在前面的可用成员。
• load-balance：按支持的策略分配连接，不代表把一条下载连接的带宽直接相加。

规则引用的是策略组名称，而不是“当前鼠标选中的节点”。例如规则指向“网页出口”组，就应检查这个组及其下层组的实际选择。只在另一个无关策略组中切换节点，不会改变该规则的出站。

rules：从上到下匹配

常见规则包括精确域名匹配 DOMAIN、域名后缀匹配 DOMAIN-SUFFIX、IP 网段匹配 IP-CIDR，以及末尾兜底的 MATCH。在规则模式下，通常由第一条匹配的规则决定去向；具体规则应放在宽泛规则之前，MATCH 放在最后。

DIRECT 与 REJECT 是内置出站，分别表示直连与拒绝。规则最后一段也可以填写已定义的策略组名。名称要完全一致，包含空格、大小写与标点；外观看起来相近的全角逗号不能代替规则中的英文逗号。

用最小配置核对 YAML 结构

下面是一份用于理解结构的直连示例。它没有远程代理节点，不能作为远程代理服务使用。示例将 HTTP 与 SOCKS 混合监听端口设为 7890，关闭局域网访问，并用一个手动组连接规则与内置直连出站。

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

proxies: []

proxy-groups:
  - name: 手动出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手动出口

1. proxies: [] 表示本段没有定义节点。策略组仍可引用内置的 DIRECT。
2. DOMAIN-SUFFIX,example.com,DIRECT 匹配示例域名及其子域名，用于说明语法，不代表某项服务的实际分流需求。
3. 192.168.0.0/16 是私有地址范围；no-resolve 表示不为这条 IP 规则主动触发域名解析。
4. 未命中前面规则的连接交给“手动出口”，该组在本例中只有直连成员。

YAML 缩进使用空格，不使用 Tab。这里每层缩进为两个空格。键名后面的冒号与值之间保留空格；名称中包含 # 等特殊字符时，应使用引号包裹。排查时先看日志报告的行号，再检查前一行的缩进与引号是否闭合。

导入订阅与首次验证

以 Clash Verge Rev 的常见界面为例，先进入「订阅」，把提供方给出的完整订阅地址粘贴到订阅链接输入框，再执行导入。不同发行版本的按钮文字可能不同，但应区分“新增订阅”“更新内容”和“启用配置”这三个动作：新增不等于已经切换当前运行配置。

1. 确认响应格式。使用提供方标注为 Clash 或 mihomo 的订阅入口。如果下载结果是登录页面、错误提示或一串编码后的节点地址，不要直接当作完整 YAML 使用。
2. 给 Profile 命名。导入后立即设置容易识别的本地名称，确认列表中能区分不同来源。
3. 启用目标配置。选择该 Profile，等待内核加载完成。出现报错时先读日志，不要连续导入同一个地址制造重复记录。
4. 检查策略组。进入「代理」，确认预期组存在，组内有可选成员，再选择需要的出口。
5. 验证接管链路。先使用一种接管方式，例如系统代理；打开目标应用建立新连接，在连接记录中检查规则与出站。

如果实际混合端口是 7890，可在终端用以下命令明确指定 HTTP 代理，帮助区分“应用没有遵循系统代理”与“代理本身不可用”。该命令只测试这次请求经过本地代理的情况，不证明 TUN 或其他应用已经正常接管。

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/

端口不同就使用实际值。若收到连接被拒绝，先检查客户端是否运行和端口是否监听；若已连接本地代理但远端请求失败，再检查节点认证、目标站点与 DNS 日志。不要把所有错误都归结为订阅失效。

多份订阅的命名与切换

多数桌面客户端可以保存多份 Profile，但内核通常只加载一份最终运行配置。保存三份订阅，不代表三份规则会自动叠加。切换 Profile 一般会替换节点、策略组与规则；客户端全局设置和覆写功能则可能继续生效。

名称区分来源，备注记录用途

• 工作主用：保存日常办公配置，并在备注记录依赖的策略组与分流需求。
• 家庭备用：保存另一来源，主用不可用时手动切换，不与主用混成同一条更新记录。
• 本地规则实验：复制配置后用于修改规则，避免直接覆盖可用的远程订阅。

不要在 Profile 名称中写完整订阅地址或令牌。名称可能出现在截图、日志与屏幕共享里。备份时还要确认备份包含哪些客户端记录：仅导出 YAML，不一定包含远程地址、定时任务以及策略组的历史选择。

切换后的四项检查

1. 确认当前激活标记落在目标 Profile 上，日志中没有加载失败信息。
2. 重新检查规则引用的策略组，不能假设上一份配置的选择会在新配置中保留。
3. 保持系统代理或 TUN 的预期状态，避免同时修改接管方式和订阅，导致问题难以定位。
4. 关闭并重新建立目标应用连接，再查看新连接的出站；已有长连接不一定立即迁移到新节点。

需要同时使用多个来源的节点时，应考虑 proxy-providers 或客户端明确支持的聚合机制，而不是把两份 YAML 文本直接拼接。重复的顶层键、重名节点和策略组都可能造成解析错误或引用歧义。完整配置订阅也不能保证可直接作为 provider 的节点数据使用，需要确认返回格式。

更新间隔与本地修改的保存方式

“更新订阅”和“测试节点”是不同任务。前者获取远程内容，后者探测已有节点。更新频率设得更高，不会自动降低延迟，也不会把不可用账号变成可用账号。对于变动不频繁的来源，可以先按每天一次安排，再根据提供方要求调整。

远程更新通常会替换下载得到的配置正文。若直接在远程文件中插入自定义规则，下次更新可能丢失。需要长期保留的修改，应放入客户端支持的覆写或合并机制；如果只想做一次离线实验，可以另存为本地 Profile，并明确它不再自动跟随远程更新。

覆写也要验证合并方式。规则列表是追加、前置还是整体替换，取决于客户端实现。若自定义规则被追加到 MATCH 后面，就不会按预期命中。保存后检查最终规则顺序，而不是只确认编辑器中存在那一行。

导入失败与配置失效的排查顺序

下载失败：检查地址与获取路径

保留订阅地址原有的查询参数，不要漏掉令牌，也不要把聊天软件附带的句号一起复制。HTTP 状态 401 或 403 常与认证或访问限制有关；429 表示请求受到频率限制，应停止反复刷新。若需借助代理才能更新订阅，先保留一份可用配置，避免形成“没有节点就无法下载节点”的循环。

解析失败：检查格式与内核兼容性

看到 YAML 错误时，先确认响应正文不是 HTML，再检查缩进与冒号。看到不支持的代理类型或字段时，核对当前内核及提供方要求，不要随意删除认证字段来消除报错。能够加载但找不到组成员时，检查节点名称、provider 引用与组名称是否一致。

能加载但不能访问：检查实际出站

先确认出站模式是否为 rule。处于全局模式或直连模式时，观察到的路径可能不是配置中的规则路径。再检查连接记录里的命中规则、策略组和目标地址；必要时用前面的显式代理请求进行对照。DNS、系统代理与 TUN 的进一步设置可参考配置进阶，基础接管步骤见系统代理说明。

稳定的管理顺序是：先保留可用 Profile，再导入新来源；先验证规则与出站，再安排更新；长期修改放入可维护的覆写层。每次只改变一个环节，才能判断失败发生在下载、解析、选择还是流量接管阶段。