Clash YAML
配置文件参考

CHAPTER / 01

YAML 结构总览与解析顺序

先看顶层，再检查引用关系

一份可以加载的 Clash 配置并不等于一份可以正确分流的配置。YAML 解析器首先处理缩进、列表和键值类型，内核随后读取顶层字段，再解析节点、策略组、规则提供器与规则之间的引用。校样时应按这个顺序检查：先确认文件是合法 YAML，再确认每个被引用的名称确实存在，最后观察运行时行为。直接从某条规则开始排查，往往会漏掉更上游的命名或缩进错误。

常见顶层区域包括监听端口、运行模式、日志等级、控制接口、DNS、代理节点、节点提供器、策略组、规则提供器和规则。字段顺序通常不改变语义，但按照用途稳定排版能显著降低维护成本。建议把基础监听字段放在顶部，把体积较大的节点和提供器放在中段，把策略组放在节点之后，最后放规则。这样阅读时会形成“原料—排版—付印”的自然顺序。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

proxies:
  - name: "示例节点"
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "示例节点"
      - DIRECT

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

上述配置展示的是完整引用链：规则把请求交给“节点选择”，策略组再引用“示例节点”，节点段提供实际连接参数。任何一处名称多出空格、全角符号或不同大小写，都会使引用断开。中文名称可以使用，但长期维护时要保持字面完全一致。若名称中含冒号、井号、逗号或前后空格，最好使用引号，避免解析器把字符理解成 YAML 语法。

缩进、列表与数据类型

YAML 使用空格表达层级，不能把制表符当作缩进。推荐统一使用两个空格，并让同一层级的字段严格对齐。以短横线开头的是列表项；短横线后的节点对象可以继续包含多个键。最常见的故障是把策略组的 proxies 列表缩进到错误层级，结果内核把它视作未知字段，或者认为策略组缺少可选项。

布尔值应写成 true 或 false，端口通常写成不带引号的整数，名称和地址则按字符串处理。虽然部分解析器会接受 yes、on 等旧式布尔写法，但跨客户端迁移时容易产生差异，稳定配置应采用明确的标准写法。数字型密码、以零开头的标识和包含特殊字符的文本应加引号，防止类型被自动推断。

最小化配置用于定位错误

面对数千行订阅文件时，最有效的排错方法不是反复修改原文件，而是另存一份最小配置，只保留一个端口、一个节点、一个选择组和两条规则。最小配置能够加载，说明基础字段和客户端环境正常；随后逐段加入 DNS、提供器与自定义规则，就能定位是哪一段引入了错误。每次只加入一个逻辑区域，重新载入后立即查看日志，避免多个改动同时进入而无法判断因果。

CHAPTER / 02

端口、模式与控制接口等通用字段

监听端口的职责边界

port 用于 HTTP 代理监听，socks-port 用于 SOCKS5 代理监听，mixed-port 则在同一个端口同时接收两类请求。图形客户端通常优先使用 mixed-port，因为系统代理与支持 SOCKS5 的应用可以共享一个入口。三者并非必须同时开启；如果同时设置，应确保端口不重复，也没有被浏览器调试工具、本地开发服务器或另一套代理程序占用。

系统代理设置只是把操作系统的 HTTP 或 SOCKS 请求指向监听端口，它不会自动修正配置中的数字。修改 mixed-port 后，还要检查客户端的系统代理开关是否读取了新端口。若浏览器显示连接被拒绝，而内核日志没有任何请求记录，通常应先核对系统代理地址与实际监听端口，而不是修改规则。

port: 7891
socks-port: 7892
mixed-port: 7890
redir-port: 7893
tproxy-port: 7894

allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false

redir-port 和 tproxy-port 主要面向 Linux 网关、路由器或透明代理场景。它们需要操作系统转发规则配合，单独写入 YAML 不会让流量自动进入内核。桌面用户通常不需要手工开启这两个端口；需要接管更多应用流量时，更适合在支持的客户端中配置 TUN 模式。Linux 客户端与内核入口可在下载页 Linux 分区核对。

局域网访问与绑定地址

allow-lan 决定是否接受来自本机以外设备的连接。设为 false 时，代理主要供当前设备使用；设为 true 后，还需要结合 bind-address、操作系统防火墙与局域网地址判断实际可达范围。开启局域网监听前，应确认家庭或办公网络的边界，并避免把控制接口暴露到不受信任的网络。

bind-address 指定监听地址。星号表示按内核规则监听可用接口，具体表现还受平台和客户端实现影响。只需要本机使用时，可保持客户端默认设置；需要让手机通过电脑代理时，应让手机与电脑位于同一局域网，在手机代理设置中填写电脑的局域网地址和 mixed-port，同时放行对应防火墙入站规则。

rule、global 与 direct 模式

mode: rule 表示按 rules 自上而下匹配，是日常使用中最常见的模式。global 会把流量交给全局策略组，适合临时验证某个节点能否连接，但它会绕开原有分流判断。direct 则让流量直接连接，适合确认故障是否由代理路径引起。排错时可以短暂切换模式作对照，得出结论后应恢复规则模式。

模式切换只改变流量决策入口，并不会修复节点参数或 DNS 响应。如果 global 模式也无法连接，应继续检查节点、网络与时间设置；如果 global 可用而 rule 不可用，问题更可能位于规则顺序、目标策略组或规则提供器。把模式当成诊断开关，比不断改写节点字段更容易得到清晰结论。

日志与外部控制器

log-level 常用值包括 silent、error、warning、info 和 debug。日常使用保留 info 较便于观察规则命中；定位复杂问题时可以临时使用 debug，完成后恢复，避免大量细节淹没关键错误。日志里的“匹配规则—选择策略—实际节点”是一条完整校样线索，应沿着三者逐级核对。

external-controller 用于图形界面与内核通信，例如监听在本机回环地址的某个端口。客户端通常会自动管理该字段，不建议在不了解界面连接方式时随意改动。若面板无法读取策略组，而代理本身仍能工作，应检查控制接口地址、端口及客户端配置，而不是先删除代理节点。

CHAPTER / 03

DNS 字段、增强模式与解析链

DNS 段处理的不是单一服务器地址

Clash 的 DNS 配置承担多个任务：决定域名向哪些解析器查询、是否接管应用发出的 DNS 请求、如何为规则匹配保留域名信息，以及在代理连接建立前如何解析节点服务器域名。只替换一行 nameserver 往往不能解决全部问题，因为代理节点自身的服务器地址、直连域名和代理域名可能走不同的解析阶段。

dns.enable 控制内置 DNS 模块是否启用。listen 指定监听地址与端口，图形客户端通常会结合 TUN 或系统设置自动管理。ipv6 决定 DNS 模块是否返回 IPv6 结果，它与顶层 ipv6 有关联但职责不同：前者影响解析结果，后者影响内核整体的 IPv6 使用。网络没有稳定 IPv6 路径时，返回可用性不明的 AAAA 记录可能造成连接等待。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"

default-nameserver 与 nameserver 的分工

nameserver 是主要解析器列表，可以填写普通 UDP 地址或内核支持的加密 DNS 地址。使用域名形式的加密 DNS 时，内核必须先知道该解析服务域名对应的 IP，这一启动阶段通常由 default-nameserver 协助完成。因此，default-nameserver 适合填写可直接访问的 IP 地址，而不是再填写一个需要先解析的域名，否则会形成循环依赖。

proxy-server-nameserver 用于解析代理节点的服务器域名。节点地址若写成域名，内核需要在建立代理连接之前得到它的 IP；这一步不能依赖尚未建立的代理隧道。不同网络环境对解析器的可达性不同，出现“节点全部超时，但节点服务器使用 IP 时恢复”的现象，应重点检查这一字段和本地网络的 DNS 可达情况。

部分 mihomo 配置还会使用 nameserver-policy，按域名把查询交给指定解析器。它适合处理内外网络对同一域名返回不同结果的场景，但策略本身也要保持清晰。若写入大批重复域名策略，会让 DNS 层与规则层同时承担分流，排错时很难判断结果来自哪一侧。通常先让 DNS 解析稳定，再用规则控制流量去向。

fake-ip 与 redir-host

fake-ip 会向应用返回保留地址池中的映射地址，内核据此保留域名关联，便于执行域名规则和嗅探后的流量决策。它并不代表目标网站真实使用该地址。应用连接假地址时，内核查回映射并建立实际连接。这个模式通常适合现代桌面与移动客户端，也能减少先解析后匹配造成的信息丢失。

redir-host 更接近传统解析流程，应用得到真实解析结果后发起连接。某些依赖本地网络设备、局域网发现或特殊 DNS 行为的程序在该模式下更容易兼容，但内核获得的域名上下文可能少于 fake-ip。两种模式没有脱离场景的绝对优先级；应根据客户端默认值、TUN 实现和应用兼容性选择，而不是在不同配置片段之间频繁混用。

fake-ip-filter 用于排除不适合返回假地址的域名。局域网设备、时间同步、部分登录与连通性检测域名可能需要真实结果。过滤规则不宜无边界扩张：如果把大量普通域名加入过滤表，会削弱 fake-ip 的域名映射优势。每增加一项都应记录对应故障现象，并在应用更新或网络变化后重新验证。

CHAPTER / 04

代理节点字段与连接参数

所有节点都从四项基础信息开始

proxies 是本地节点列表，每个列表项至少需要名称、类型、服务器地址和端口，随后再按协议补充认证、传输与 TLS 字段。节点名称是配置内部的引用标识，策略组通过名称找到节点；服务器地址决定实际连接目标；端口是远端服务监听端口，与本机 mixed-port 完全不同。把两类端口混淆，是手工抄录配置时最常见的错误之一。

节点参数必须与服务端设置成组对应。协议类型、加密方式、认证内容、传输层、主机名与路径中任意一项不一致，都可能表现为超时或握手失败。不能通过反复更换策略组来修复节点本身的参数错误。校样时应从协议基础字段开始，逐层加入 TLS、WebSocket 或其他传输选项，每次观察日志中的失败阶段。

proxies:
  - name: "SS 示例"
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "Trojan 示例"
    type: trojan
    server: edge.example.net
    port: 443
    password: "your-password"
    sni: service.example.net
    skip-cert-verify: false
    udp: true

示例中的地址与认证文本用于展示结构，实际使用时应由合法的服务配置提供。udp 表示节点是否允许承载 UDP 流量，它还受协议实现、服务端和网络路径共同影响。即使字段设为 true，服务端没有对应能力时也不会得到可用的 UDP 转发。游戏、语音与部分 DNS 流量出现异常时，应分别确认节点能力和策略组是否选择了该节点。

TLS、SNI 与证书检查

使用 TLS 的协议通常需要正确的服务器名称。sni 用于握手时发送目标主机名，它不一定与连接使用的 server 字段相同，但必须与服务端证书和部署方式相符。日志出现证书名称不匹配时，应核对服务提供方给出的 SNI，而不是首先关闭证书检查。

skip-cert-verify 控制是否跳过证书验证。稳定配置应优先保持 false，并修正设备时间、证书链、SNI 或网络拦截问题。设备时间偏差会让尚未生效或已经过期的判断出现错误；系统根证书环境异常也可能影响连接。把该字段改为 true只能作为短时对照测试，不能替代对根因的确认。

传输层字段必须作为一个对象阅读

WebSocket 等传输方式通常会带有路径与请求头。路径中的斜杠、大小写和编码需要与服务端一致，Host 请求头也可能参与反向代理路由。缩进错误会让 ws-opts 下的字段脱离节点对象，导致内核忽略设置。遇到“TCP 已连接但随后断开”的现象，应沿着 TLS 握手、HTTP 升级和应用协议三个阶段读日志。

  - name: "WS 示例"
    type: vmess
    server: edge.example.net
    port: 443
    uuid: "00000000-0000-4000-8000-000000000000"
    alterId: 0
    cipher: auto
    tls: true
    servername: service.example.net
    network: ws
    ws-opts:
      path: /gateway
      headers:
        Host: service.example.net

不同内核与协议会使用 sni、servername 等不同字段名，不能仅凭语义相近就互换。迁移到 mihomo 内核前，应对照当前客户端支持范围核查字段。有关内核关系与兼容边界，可继续阅读mihomo 内核与原版 Clash 的差异。

节点名称、重复项与健康检查

节点名称应当唯一。两个节点使用相同名称时，策略组的引用可能指向非预期对象，客户端界面也难以区分。订阅提供器中的重复名称还可能在更新后重新出现，适合在覆写阶段增加前缀、后缀或筛选规则。名称应表达地区、线路或用途，不建议把实时延迟写进名称，因为更新后容易失真。

节点能出现在列表中，只说明 YAML 已被读取，不代表连接可用。应使用客户端提供的连通性测试，随后以真实网页访问或目标应用验证。测试地址、DNS、节点协议和目标网站可能走不同路径，因此单一测试结果不能覆盖全部场景。若所有节点同时失败，优先排查本地网络、DNS 与系统时间；只有单个节点失败时，再集中核对该节点字段。

CHAPTER / 05

策略组类型、引用与选择逻辑

策略组是节点与规则之间的排字台

proxy-groups 不负责建立新的协议连接，而是把已有节点或其他策略组组织成可选择、可测试或可故障转移的逻辑单元。规则的最后一列通常指向策略组，策略组再决定使用哪个节点。把“用途”写进策略组名称，例如“节点选择”“流媒体”“直连服务”，比把协议名堆进组名更便于阅读。

策略组可以引用节点，也可以引用此前定义的其他策略组。多层引用适合把地区选择与业务分流分开，但层级过深会增加定位难度。建议保持两到三层：底层是实际节点或提供器，中层是地区或测试组，上层是业务策略。发生错误时沿着规则目标逐层展开，直到找到最终节点。

proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies:
      - "节点 A"
      - "节点 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "节点选择"
    type: select
    proxies:
      - "自动选择"
      - "节点 A"
      - "节点 B"
      - DIRECT

  - name: "故障转移"
    type: fallback
    proxies:
      - "节点 A"
      - "节点 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

select、url-test 与 fallback 的差别

select 由用户手工选择一个成员，结果稳定且容易解释，适合作为顶层入口。若客户端保存选择状态，重新加载配置后通常会恢复上次选择，但名称变化或组被重建时可能回到默认项。把最希望采用的默认成员放在列表前面，可以降低配置首次加载时的意外路径。

url-test 定期访问测试地址，根据测得结果自动选择成员。它反映的是节点到测试目标的连通性与响应情况，不等同于所有网站的实际速度。interval 控制测试间隔，设置过短会增加后台请求；tolerance 用于减少结果接近时的频繁切换。自动组适合日常选择，但关键业务仍应观察真实访问表现。

fallback 按顺序使用可用成员，当前成员失效时转向下一个，更强调稳定性而非最小响应时间。列表顺序因此具有实际意义，应把优先线路放在前面。若测试地址在当前网络无法访问，所有节点可能被误判为不可用，所以测试目标必须稳定、返回内容简短，并且与节点能够访问的网络范围相符。

load-balance 与流量连续性

load-balance 会在多个成员之间分配连接，具体策略取决于内核支持和组内参数。它不是把单个下载任务简单叠加到多个节点，也不能保证每个请求随机切换。登录态、来源地址敏感的服务可能不适合跨节点分配，因为同一会话出现不同出口会触发重新验证或连接中断。

选择负载均衡前，应先确认业务是否允许出口变化。网页浏览与多连接下载可能从中受益，但远程管理、支付登录和长连接更需要路径稳定。策略组设计应从业务约束出发，而不是仅按功能数量堆叠。没有明确需求时，select 配合一个 url-test 组通常已经足够清晰。

使用 use 引入提供器节点

当节点来自 proxy-providers 时，策略组可用 use 引用整个提供器，无须把每个节点名称写进 proxies。订阅更新后新增或删除的节点会随提供器进入组内，更适合长期维护。proxies 与 use 可以按内核能力组合使用，但应注意最终成员是否包含重复节点。

proxy-groups:
  - name: "订阅节点"
    type: select
    use:
      - provider-main
    proxies:
      - DIRECT

  - name: "自动测速"
    type: url-test
    use:
      - provider-main
    url: "https://www.gstatic.com/generate_204"
    interval: 600
    tolerance: 100

策略组为空时，引用它的规则无法得到有效节点。常见原因包括提供器下载失败、筛选表达式排除了全部节点、提供器名称拼写不同，或组引用了尚不存在的本地节点。客户端界面出现空组时，应先查看提供器状态和原始节点数量，再检查筛选条件，而不是立即修改规则。

CHAPTER / 06

规则语法、顺序与匹配边界

规则从上到下，只采用第一次命中

rules 是有顺序的列表。请求进入规则模式后，内核从第一条开始检查，命中后立即把流量交给指定策略，不再继续向下寻找更具体的规则。因此，精确范围应放在宽泛范围之前，例外项应放在会覆盖它的通用项之前，兜底规则必须位于末尾。规则内容相同但顺序不同，最终行为可能完全相反。

每条规则通常由规则类型、匹配内容与目标策略组成，以英文逗号分隔。目标可以是策略组，也可以是 DIRECT、REJECT 等内置动作。中文逗号看起来相似，但不会被当作字段分隔符。复制规则后应检查标点、前后空格和目标名称，尤其注意从排版文档中复制时可能混入全角字符。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - DOMAIN-KEYWORD,example,节点选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - PROCESS-NAME,example.exe,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

域名规则的精度差异

DOMAIN 只匹配完整域名，适合对单一主机作例外处理。DOMAIN-SUFFIX 匹配指定域名及其子域名，适合覆盖一个完整站点体系。DOMAIN-KEYWORD 只要域名包含指定文本就可能命中，范围更宽，也更容易误伤名称相似但无关的域名。配置应优先使用精确域名和后缀，只有目标域名变化频繁且规律明确时再使用关键词。

例如先写 DOMAIN,internal.example.com,DIRECT，再写 DOMAIN-SUFFIX,example.com,节点选择，才能让内部主机保留直连。若后缀规则位于前面，精确规则永远没有机会执行。定位域名误分流时，应在日志中找到实际请求域名，然后从规则顶部搜索第一条可能命中的规则，而不是只查看预期规则是否存在。

IP-CIDR 与 no-resolve

IP-CIDR 使用网段匹配目标 IPv4 地址，IPv6 则使用对应的 IPv6 规则类型。CIDR 后缀表示网络前缀长度，范围写得过宽会覆盖大量地址。局域网网段通常应在代理规则之前直连，以免访问路由器、打印机或存储设备时被送往远端节点。

no-resolve 表示匹配该 IP 规则时不要为只有域名的请求额外触发解析。它适合那些只需要检查现有目标 IP 的规则，可以减少不必要的 DNS 查询。是否加入该参数取决于规则目的：如果规则必须通过解析域名才能获得目标 IP，就不能机械地添加。理解解析时机比照抄参数更重要。

进程规则与平台差异

PROCESS-NAME、PROCESS-PATH 等进程规则依赖操作系统权限、内核能力和客户端接管方式。Windows、macOS、Linux 与 Android 对进程信息的获取条件不同；某个平台能命中，不代表另一平台具有同样结果。TUN 模式下是否能识别进程，也与客户端实现和权限配置有关。

进程规则失效时，应先在调试日志中确认内核看到的进程名或路径，再按实际值编写规则。可执行文件更新后路径可能变化，大小写和扩展名也要按平台核对。对跨平台共享的配置，域名规则通常比进程路径更容易保持一致；进程规则适合作为平台专属覆写，而不是直接塞进所有设备共用的订阅正文。

GEOIP、规则集与兜底

GEOIP 根据目标 IP 所属数据库区域进行匹配，其结果受数据库内容与更新时间影响。它适合作为较后位置的区域级判断，不适合替代明确的域名规则。域名解析得到的地址可能因网络与 CDN 调度而变化，同一服务也可能分布在多个区域，因此关键业务应使用更明确的规则集或域名规则。

MATCH 匹配此前没有命中的所有请求，只能放在末尾。若它位于中段，下面的规则都会失去作用。兜底选择直连还是代理，应根据配置目标决定：强调按清单代理时可以让未分类流量直连；强调默认代理时可以交给总选择组。无论采用哪种策略，都应让组名明确表达后果。

rules:
  # 本地与明确例外
  - DOMAIN,printer.lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # 业务规则
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,proxy-domain,节点选择
  - RULE-SET,private-ip,DIRECT

  # 区域判断与最终兜底
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

自定义规则的完整排查可以结合Clash 自定义规则语法详解阅读。修改后不要只看配置是否成功载入，还应选择几个能够代表精确域名、子域名、IP 与兜底情况的目标，逐项确认日志中的命中规则和最终策略。

CHAPTER / 07

节点提供器、规则提供器与订阅更新

proxy-providers 管理可更新的节点来源

proxy-providers 把远程或本地节点集合从主配置中分离出来。主配置负责策略结构，提供器负责节点内容，两者更新节奏可以不同。这样订阅更新时不必重写整份规则，也便于多个策略组共享同一批节点。客户端支持提供器时，优先采用这种分层结构比把大量节点直接展开到 proxies 更容易维护。

每个提供器需要唯一名称、类型、来源地址、缓存路径和更新间隔。远程类型通常通过 HTTP 获取 YAML，path 指定本地缓存位置。不同客户端对相对路径的根目录处理可能不同，迁移配置后若出现无法创建文件或缓存不更新，应检查客户端工作目录与文件权限。

proxy-providers:
  provider-main:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

提供器的健康检查会周期性测试其中的节点，但它与策略组的 url-test 不是同一个层次。前者维护节点可用状态，后者在组内执行选择。两者间隔都设置得很短会产生重复请求；应根据节点变化频率和实际使用需求安排。订阅地址失效时，客户端可能继续使用本地缓存，因此“当前还能连接”不能证明远程更新仍正常。

rule-providers 管理成组规则

rule-providers 将大量域名或网段规则放在独立文件中，主配置只通过 RULE-SET 引用。常见 behavior 包括 domain、ipcidr 和 classical。其中 domain 规则集用于域名类匹配，ipcidr 用于网段，classical 可以容纳带规则类型的传统条目。提供器内容格式必须与 behavior 相符，否则即使文件下载成功也可能无法解析。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: "https://example.com/rules/private-domain.yaml"
    interval: 86400

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-ip.yaml
    url: "https://example.com/rules/private-ip.yaml"
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,节点选择

domain 行为的文件通常只放域名负载，不应再写目标策略；策略在主配置的 RULE-SET 行中指定。classical 格式则可能包含 DOMAIN-SUFFIX 等完整规则前缀。混淆两种格式会产生“规则集已下载但没有命中”的假象。校样时应同时查看提供器状态、解析条目数量和主规则中的引用名称。

订阅更新与本地配置的边界

Profile 通常包含远程订阅与本地配置两类。远程订阅适合接收节点变化，本地配置适合保存设备专属端口、DNS 与规则。直接编辑订阅生成的文件，下一次更新时可能失去改动；将所有节点复制到本地文件，又会失去自动更新能力。更稳妥的方法是保留订阅作为原料，通过客户端覆写或独立主配置组织策略。

多配置管理时，应为每份 Profile 标明用途，例如“桌面日常”“移动网络”“规则实验”，避免只按导入日期命名。切换配置后要确认当前激活项、系统代理状态和策略选择，因为客户端可能为不同 Profile 分别保存状态。具体的导入、切换与整理方法见Clash Profile 配置文件基础。

更新失败的分层排查

提供器更新失败时，先区分网络错误、HTTP 状态错误、文件格式错误与缓存写入错误。网络错误说明地址无法建立连接；HTTP 错误说明远端返回了非预期状态；格式错误通常发生在下载完成后的解析阶段；缓存错误则与路径和权限有关。日志中的阶段信息比反复点击更新更有价值。

若远程地址需要通过代理访问，还要确认内核更新提供器时采用的网络路径。首次启动时策略尚未完整可用，过度依赖代理才能获取核心配置可能形成启动闭环。应保留能够直接初始化的基础配置，并确保提供器失败时仍有明确日志和可用的本地缓存。

CHAPTER / 08

覆写、合并与最终配置校样

真正生效的是合并后的结果

许多图形客户端允许在远程订阅之上应用覆写、脚本或合并配置。用户编辑的片段只是输入之一，内核最终读取的是客户端处理后的成品。排查时如果只看原订阅或覆写文件，而没有查看最终配置，就可能误判字段已经生效。客户端能够导出运行配置时，应优先检查导出结果，并与预期逐段对照。

合并通常涉及替换、追加和删除三类动作。标量字段如 mixed-port 常采用后值覆盖前值；映射对象如 dns 可能按键合并，也可能整体替换；列表如 rules 和 proxy-groups 的行为差异最大，有的客户端追加，有的按名称处理，有的直接覆盖。不能假设所有客户端使用同一算法，迁移配置时必须先做小样测试。

# base.yaml
mode: rule
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1

rules:
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

# override.yaml
dns:
  ipv6: false

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

如果客户端对 dns 做深度合并，最终结果可能同时保留 enable、enhanced-mode、nameserver 和新增的 ipv6。如果采用整段替换，最终 DNS 段可能只剩 ipv6，配置自然无法按预期运行。对于规则列表，追加到末尾的精确例外可能被原有 GEOIP 或 MATCH 提前截走，因此需要明确选择前置插入还是完整重排。

按名称合并策略组的风险

部分覆写工具会把同名策略组视作同一个对象，再合并其中的成员。这样可以向现有“节点选择”中加入本地组，也可能造成重复成员或保留不需要的旧字段。另一类工具会用新对象完全替换旧组，若覆写片段没有写全 type、proxies 或 use，最终组就会残缺。

处理策略组时，覆写片段最好明确说明目标：是完整替换组，还是只增加成员。无法确认客户端语义时，可使用新的组名，先验证规则能否正确引用，再决定是否接管原组。名称变化还会影响客户端保存的手工选择，更新后若选择突然恢复默认，应检查组名是否在合并过程中被改变。

规则覆写应保留顺序意图

本地规则通常用于添加设备专属直连、进程规则或业务例外。它们需要位于订阅宽泛规则之前，因此简单追加往往无效。稳定做法是把规则分成“本地例外、远程规则集、区域判断、最终兜底”四段，在最终配置中确保顺序固定。若客户端提供规则前置与后置两个入口，应把例外放前置，把额外兜底放后置，但全局只能保留一个真正的最终 MATCH。

规则去重不能只比较整行文本。两条规则可能匹配范围重叠但目标不同，例如精确域名直连与后缀代理必须同时保留，并通过顺序表达例外。自动去重脚本若只保留后出现的条目，可能改变原意。每次调整规则生成逻辑后，都应选取代表性域名读取日志，而不是仅比较文件行数。

从解析错误到运行错误的检查清单

第一层是 YAML 语法：检查缩进、冒号、短横线、引号与数据类型。第二层是结构引用：检查策略组、节点、代理提供器和规则提供器名称。第三层是资源加载：确认远程文件下载成功、缓存可写、格式与 behavior 一致。第四层是运行环境：确认端口未占用、权限满足、系统代理或 TUN 已指向当前内核。第五层才是请求决策：查看 DNS 结果、规则命中、策略组选择与最终节点。

这种分层能够避免用下游改动掩盖上游错误。例如端口冲突时，修改 DNS 不会产生帮助；策略组为空时，增加更多规则只会把更多流量送进空组；节点 TLS 参数错误时，切换为 global 模式仍会失败。每次日志只抓取与当前层有关的信息，确认通过后再进入下一层，故障范围会逐步缩小。

建立可回退的修改流程

每次修改前保留上一份能够工作的配置，并记录本次只解决什么问题。文件名可以包含用途与修订序号，但不要在多个目录里保存名称相同、内容不同的副本。修改后先做语法加载，再测试一个直连目标、一个代理目标、一个局域网目标和一个需要特殊规则的目标。四类样本覆盖了大多数配置链路。

如果客户端更新后出现行为差异，应先比较最终配置和内核日志，不要立即认定订阅内容发生变化。客户端可能调整默认 DNS、TUN 堆栈、合并语义或配置目录。将关键字段显式写入本地覆写，并记录其用途，可以减少默认值变化带来的不确定性；但也要定期删除已经失去场景依据的旧例外。

完成配置校样后，建议回到使用教程中的连接验证步骤，从系统代理、策略选择到网页访问走完一次完整流程。需要更换图形客户端时，下载页列出的 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等客户端对 YAML 支持范围并不完全相同，迁移前应先确认当前配置依赖的内核字段；桌面与移动平台的首选入口可在Clash 下载中心查阅。

一份可靠的 Clash YAML 不是字段越多越好，而是每个字段都有明确用途，每条引用都能追溯，每次更新都能得到可解释的最终结果。按照结构、通用字段、DNS、节点、策略组、规则、提供器与覆写的顺序检查，相当于从字粒到版面逐层校样：先保证字符正确，再保证组合正确，最后确认实际付印结果与预期一致。