Clash YAML 配置字段参考

YAML 结构总览

配置文件描述的是一套连接处理关系，而不是可以随意拼接的参数清单。通用字段决定监听方式，DNS 决定域名解析，代理节点提供实际出口，策略组组织出口选择，规则把连接交给对应策略。阅读文件时，先辨认这些顶层区域，再追踪名称引用。即使文件能够被解析，只要规则引用的组名不存在，或策略组引用了错误的节点名，仍然可能在加载或连接阶段失败。

映射、列表与缩进

YAML 的映射采用键和值的形式，列表项以短横线开头，层级由空格缩进表示。建议统一使用两个空格，不混入制表符。冒号后留一个空格，兄弟字段保持对齐。下面的配置只使用内置直连策略，能够展示顶层关系，但不会建立远程代理出口；它适合观察配置是否加载成功，不应被当作已经包含节点的订阅文件。

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

proxies: []

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口选择

这里的 proxies: [] 表示空列表，并不等于字段缺失，也不等于空字符串。proxy-groups 是一个列表，每一项又是映射；组内的 proxies 则是名称列表。顶层节点定义与组内名称引用虽然使用相同字段名，含义并不相同。修改时应同时看字段所在的层级，不能只搜索某个单词后批量替换。

包含井号、冒号或特殊字符的文本适合加引号，尤其是密码、订阅地址和看起来像数字的标识。未加引号的井号在特定位置会开始注释，错误使用双引号还可能触发反斜杠转义。一般文本可使用单引号；如果文本自身带单引号，需要按 YAML 规则写成连续两个单引号。布尔值使用 true 或 false，端口写整数，不要把所有值都机械地改为字符串。

文件、配置档与运行配置

图形客户端中的配置档通常只是输入材料。客户端还可能添加监听端口、控制接口、TUN 参数及用户覆写，最后才生成交给内核的运行配置。因此，订阅原文与实际运行文件出现差异，并不必然表示导入错误。排查某个字段为什么没有生效时，应先查明当前激活的是哪个配置档，再查看客户端提供的运行配置预览或对应日志。

同一个映射层级不应重复定义相同键。例如先写一段 dns，在文件末尾再写另一段 dns，并不能可靠地表达追加设置。不同解析器可能拒绝重复键，也可能保留其中一段。将需要的子字段整理进同一个映射，才能明确表达意图。列表的追加与映射的递归合并属于客户端或脚本行为，并不是 YAML 文件格式本身提供的统一功能。

保存文件时使用 UTF-8 编码，并保留一份能够正常启动的副本。发生错误后，先恢复副本，再缩小修改范围，比反复重装客户端更容易定位原因。支持命令行测试的环境可以使用下列命令检查配置；可执行文件的实际位置与配置路径需要对应本机目录。测试通过表示配置可被内核接受，并不代表远端节点、DNS 或网络权限一定可用。

mihomo -t -f ./config.yaml

原版 Clash、mihomo 与不同图形客户端之间存在字段支持差异。复制示例前，应确认客户端实际使用的内核，而不是只根据应用名称推断。需要理解图形界面与内核的分工，可参阅Clash 开源生态与客户端关系；本手册继续以字段之间的依赖关系作为查阅主线。

通用字段与接管方式

通用字段决定流量如何进入内核，以及内核以什么方式处理这些连接。监听端口、系统代理与 TUN 是三个相关但不同的概念：端口是内核提供的本地入口，系统代理是操作系统向应用公布入口地址的设置，TUN 则通过虚拟网络接口接收符合路由条件的数据包。只配置监听端口，不代表系统已经把应用流量送到该端口。

监听端口与访问范围

端口号并不是固定承诺，示例中的数值只是常见写法。若本机已有其他进程占用同一端口，内核可能无法监听。处理时先查看日志中的地址与端口，再修改冲突项；如果客户端负责设置系统代理，还要确认系统代理同步到了新端口。仅修改订阅文件中的数字，却让客户端继续指向旧入口，会出现内核运行正常而浏览器无法连接的情况。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

监听地址控制服务绑定在哪个本地接口。只供本机使用时，可让入口保持回环访问范围；需要共享给局域网设备时，再评估监听地址、允许局域网访问与防火墙规则。控制接口用于管理内核，不是浏览器应填写的代理端口。把管理接口暴露给其他设备之前，需要设置访问凭据并限制网络范围，不能因为它与代理入口都表现为端口就混为一谈。

规则、全局与直连模式

rule 模式按照规则列表决定策略；global 模式把连接交给全局策略；direct 模式以直连方式处理流量。模式选择不替代节点连通性检查，全局模式也不表示所有应用都已经被接管。如果某个应用没有使用系统代理，切换全局模式通常不会改变它的流量入口，应先确认接管路径，再判断分流结果。

TUN 模式与平台权限

TUN 适合处理不读取系统代理设置的应用，但它涉及虚拟接口、系统路由与运行权限。不同客户端可能通过服务进程、管理员授权或平台提供的网络扩展建立接口，不能把某个平台的权限步骤直接套用到另一平台。下面列出常见 mihomo 字段关系；图形客户端若已管理这些字段，应优先通过对应设置页操作，避免生成配置时相互覆盖。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route 用于自动配置相关路由，auto-detect-interface 用于识别出站接口，dns-hijack 则参与接收匹配的 DNS 请求。这些选项不是对全部网络环境的保证：其他 VPN、虚拟机网卡、企业网络软件或手工路由都可能改变路径。启用后若局域网资源不可达，应检查路由与排除范围，不宜通过关闭全部 DNS 设置来掩盖问题。

系统代理与 TUN 可以同时存在，但排错时建议先保留一种清晰的接管方式。先确认浏览器通过本地入口能够建立连接，再启用 TUN 观察其他应用；如果启用后才出现故障，就重点检查权限、接口和路由变化。恢复前应记录当前开关，尤其是系统代理是否由客户端自动恢复，避免退出应用后系统仍指向已经停止监听的端口。

Windows 上的应用容器访问、Android 上的 VPN 授权以及桌面端后台服务，都属于平台接管层的问题，不等同于 YAML 语法错误。具体平台操作以快速上手为入口，异常现象可再查帮助中心。选择客户端时可先查看下载中心的 Clash Plus 平台选项，再确认所需的接管功能。

DNS 解析

DNS 配置应同时回答三个问题：谁向内核发起解析，内核向哪个上游查询，以及查询本身从哪条网络路径发出。只改一组 DNS 地址，无法自动约束浏览器自带的加密 DNS、系统缓存和其他网络服务。分析 DNS 泄漏时，需要先界定哪些请求原本应该由内核处理，再根据接管方式与日志验证，不能只凭单个检测页面的地区显示下结论。

监听、上游与引导解析

enable 控制内核 DNS 模块，listen 指定其监听地址，nameserver 指定一般查询使用的上游。若上游地址本身包含域名，内核需要先获得这个域名的地址，相关引导解析可由 default-nameserver 提供。引导解析器应能在当前网络上实际访问，否则会出现尚未连接到加密上游就已经卡住的循环依赖。

dns:
  enable: true
  listen: 127.0.0.1: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://cloudflare-dns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - localhost

示例展示字段结构，并不表示列出的公共解析服务适合所有网络。端口 1053 也不会自动成为系统 DNS；仍需要客户端的 DNS 接管设置或其他明确转发机制。桌面环境如果不允许系统解析器指定非标准端口，不能简单把该监听地址抄入系统设置。实际是否接收到查询，应通过内核日志与应用访问结果确认。

fake-ip 与真实地址响应

fake-ip 模式向应用返回映射地址，内核保留地址与域名之间的关系，后续连接进入内核后再据此匹配域名规则。它的作用是保留分流所需的域名信息，而不是把目标服务器真的改成映射网段。若应用拿到映射地址，却绕过内核直接连接，访问就可能失败，因此 DNS 响应路径与连接接管路径必须配套检查。

fake-ip-filter 用于让部分域名不采用映射地址。局域网服务、需要真实地址的设备发现流程或存在兼容问题的应用，可能需要有针对性地加入过滤。不要为了处理一个域名就把过滤范围扩大到全部域名；这样会改变其他规则获取域名信息的条件。加入过滤后还应清理相关缓存或重启受影响应用，避免旧映射与新响应同时存在。

在真实地址响应的解析方式下，应用收到实际 IP，域名规则能否使用仍取决于内核掌握的信息与连接入口。IP 规则可能触发额外解析，域名嗅探也不保证能够恢复所有协议中的名称。因此，比较两种模式时应观察实际规则命中、目标应用的行为与日志，不宜把一种模式概括为始终更快，另一种概括为始终更安全。

按域名选上游与查询路径

nameserver-policy 可以为特定域名指定上游，例如内部域名需要交给所在网络的解析器。它解决的是解析服务器选择，不等于为最终业务连接指定代理出口。业务流量仍由规则与策略组处理。若使用 respect-rules 让 DNS 连接遵循规则，需要同时考虑代理服务器域名的解析来源，避免解析代理所需的请求又依赖尚未可用的代理。

dns:
  enable: true
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - 192.168.1.1

此处的局域网地址只表示“交给当前网络中的解析器”这一用法，必须替换成实际可用地址。企业内部域名如果错误地发往公共解析服务，可能返回不存在的记录；相反，外部域名全部交给内部解析器，也可能受到该网络策略影响。使用域名后缀策略时应注意匹配范围，先用一个明确的测试域名确认行为，再逐步扩展。

排错可以从域名与 IP 的对照开始：同一目标若 IP 可达而域名访问失败，优先查看 DNS 日志；只有某个应用异常，则检查其独立解析设置；节点域名无法解析，则先修复引导与节点解析路径。修改后使用新连接重试，必要时清理系统及应用缓存。更完整的顺序见节点超时与连接失败排查。

代理节点字段

代理节点定义的是连接远程服务所需的协议参数。它与节点名称、地区标签和测速结果不是同一回事：名称只承担引用与识别，真正决定连接行为的是协议、地址、端口、认证以及传输设置。填写前应取得服务端提供的完整参数，不能根据一个服务器地址推断协议，也不能把其他客户端中的字段名原样移入 YAML 后假定含义相同。

公共字段与协议专属字段

常见公共字段包括 name、type、server 和 port。name 需要与策略组中的引用完全一致，建议保持唯一且易于辨认；type 决定后续哪些字段有效；server 可以是域名或 IP；port 是远端服务入口，不是本地监听端口。把两个端口概念写反，会让日志表现为连接失败而非 YAML 解析失败。

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

这个片段表达一个 Shadowsocks 节点的字段结构，示例域名与密码不能用于实际连接。cipher 与密码需要和服务端一致，不能为了“提高安全性”单方面更改算法名称。端口为 443 也不自动表示使用 HTTPS 或 TLS；协议是否包含加密与伪装，需要根据具体协议及其传输字段判断，而不是只看端口数字。

TLS、SNI 与传输参数

使用 TLS 的协议还需要核对服务器名与证书关系。连接地址、TLS 的 SNI、WebSocket 的 Host 以及路径可能分别承担不同作用，即使服务端部署时恰好使用相同域名，也不能认为这些字段可以互相替代。部分协议使用 servername，其他协议可能有不同字段；应以对应协议的配置结构为准，避免建立一份看似通用、实际不被识别的参数表。

proxies:
  - name: Trojan 示例
    type: trojan
    server: proxy.example.com
    port: 443
    password: 'your-password'
    sni: proxy.example.com
    skip-cert-verify: false
    udp: true

证书错误应先检查系统时间、域名、证书链与服务端设置，而不是直接跳过验证。关闭验证会改变连接的身份认证条件，并不能修复填写错误的 SNI。若服务提供方要求特殊证书或专用传输参数，应确认说明来源，并按对应协议设置。协议专属字段很多，本手册给出的是核对方法，不把不同协议的所有参数堆进同一个示例。

节点定义与实际连通性

udp: true 只表示配置允许使用相应能力，不会让原本不支持 UDP 的服务端具备该能力。应用还可能受到系统代理类型、TUN 接管、运营网络与防火墙限制。出现网页可用而语音或游戏异常时，应分别验证 TCP 与 UDP 路径；单次 HTTP 测试成功，不能代表所有传输类型均已具备条件。

节点加入文件后，还需要被策略组或规则实际引用。直接在 proxies 下新增一项，不表示当前出口会自动切换过去。检查连接页时，应同时看命中的规则、经过的策略组以及最终节点；如果规则仍选择直连，就不应先怀疑新节点的密码。反过来，策略已经指向节点却握手失败，才应继续核对地址、认证和协议参数。

订阅通常包含访问凭据，截图和日志也可能带有完整节点地址。排错分享时只保留必要字段，隐藏密码与订阅地址中的敏感部分。若比较原始链接、YAML 与其他配置格式，应逐项核对协议是否被完整表达，不能把“成功转换”理解为所有能力都被保留。相关差异可参阅订阅格式对照与转换。

策略组

策略组位于规则与节点之间。规则通常不必直接写死某个远程节点，而是指向一个含义稳定的组名，再由组决定使用哪个出口。这样更换订阅或切换节点时，规则本身可以保持不变。设计策略组时，应优先明确选择逻辑和引用关系，而不是先堆叠大量按地区命名的层级；每多一层嵌套，都应能说明它解决了什么选择问题。

手动选择、自动测试与故障转移

select 提供手动选择，适合作为面向用户的总入口；url-test 通过指定目标的探测结果选择出口；fallback 按候选顺序选择可用项；load-balance 则按配置的策略分配连接。它们的目标并不相同。低测试耗时不一定对应某项业务的最佳体验，故障转移也不等于把多个节点带宽合并使用。

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - 自动选择
      - DIRECT

  - name: 自动选择
    type: url-test
    use:
      - 主订阅
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

该片段依赖后文定义的 主订阅 provider。use 引用远程节点集合，proxies 引用具体节点、内置策略或其他策略组；二者不能仅因内容都显示为名称就互换。定义文件时可以按阅读习惯排列顶层区域，但所有引用必须在最终配置中存在，名称的空格、符号和大小写也应保持一致。

url 是探测目标，interval 是检查间隔，tolerance 可用于减少微小测试差异导致的频繁切换。示例中的数值只用于说明参数单位和关系。若目标在当前网络或某些节点上被限制，探测结果就可能主要反映该目标的可访问性，而不是节点整体质量。不要把一个探测站点的失败直接解释为服务端完全不可用。

候选范围与名称稳定性

订阅节点数量较大时，可以通过受支持的过滤字段限定候选范围。过滤通常按名称匹配，依赖订阅提供方的命名习惯；当地区文字、符号或标签变化时，原先的表达式可能筛不出任何节点。调整过滤后应查看组内实际成员，而不只是查看 YAML 是否通过测试。涉及正则表达式时，还需要同时考虑 YAML 引号与表达式自身的转义规则。

同一配置中不宜存在多个含义不同却名称相同的组或节点。为了让规则长期稳定，可以给业务组使用明确名称，例如“工作服务”或“媒体服务”，再把实际节点选择交给它们下层的出口组。这样修改节点来源时不必重写大量规则。但如果全部业务最终都走相同出口，保留一个入口组通常已经足够，不需要为视觉上的分类增加重复结构。

嵌套、缓存与切换验证

组可以引用其他组，但不能形成循环，例如甲组引用乙组、乙组又回到甲组。复杂引用应从规则目标开始，逐层画出实际出口路径，直到落到节点或内置策略。若某一层最终只能回到已经经过的组，就需要重新拆分。依赖内核报错才能发现循环并不利于维护，尤其在多个覆写文件分别添加组成员时更容易遗漏。

客户端可能记住手动选择，配置中也可通过 profile.store-selected 保存相关状态。保存状态不代表改名后仍能准确恢复：旧名称消失时，客户端或内核可能回到默认候选项。更新订阅后应检查当前选项是否仍指向预期出口，特别是对固定业务使用独立组的配置，避免把选择变化误判为规则顺序异常。

切换策略主要影响新建连接，已经建立的长连接可能继续使用原出口。验证时应刷新应用会话或重新建立连接，再查看连接页中的实际链路。若需要关闭旧连接，应评估对下载、会议或其他持续任务的影响。界面按钮的具体位置可参阅客户端代理页、配置页与连接页说明。

规则语法

规则的核心语义是从上到下匹配，先命中的规则决定处理策略。维护规则时，顺序通常比数量更重要：精确的例外放在宽泛规则之前，最终兜底放在末尾。规则目标可以是策略组、节点或内置策略，但需要在当前运行配置中有效。某条规则写得正确，却永远被前面的宽泛规则截住，仍然不会得到预期结果。

域名、地址与兜底规则

rules:
  - DOMAIN,login.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
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,出口选择

DOMAIN 匹配完整域名，适合单独处理一个主机；DOMAIN-SUFFIX 匹配指定域名及其子域；DOMAIN-KEYWORD 根据域名中的关键词匹配，范围更宽，应谨慎使用。示例先让登录域名直连，再处理整个域名后缀。若把后缀规则放在前面，登录域名就不会继续走到后面的精确例外。

IP-CIDR 按目标地址所在网段匹配，常用于局域网地址与固定服务地址。no-resolve 表示在这条规则上不为了匹配而主动触发域名解析，并不表示全局禁用 DNS，也不表示已有目标 IP 时跳过比较。它适合减少不必要的解析，但如果配置依赖域名解析后才能命中某个地址规则，就需要理解由此产生的匹配边界。

MATCH 是最终兜底，接收此前没有命中的连接。把它放到列表顶部，后面多数规则便失去机会。兜底选择应体现明确的默认路径，而不是把“未分类”当作错误。维护时可以先使用少量可验证的规则与一个兜底，确认命中关系后再引入大型规则集，避免同时处理入口、DNS、节点和规则四个变量。

进程规则与平台差异

进程类规则可用于按应用区分流量，但前提是当前平台、权限和接管路径允许内核取得进程信息。通过其他设备转发来的连接，不一定能关联到远端设备上的应用进程；某些平台的网络接口也不会提供相同信息。因此，在另一台电脑上有效的进程规则，不能直接视为手机或路由器环境中的通用规则。

域名规则同样有信息条件。应用直接连接 IP、使用自己的解析流程或通过某种转发方式进入内核时，连接记录可能没有预期的域名。此时反复增加域名后缀规则未必有效，应先检查 DNS 接管与连接元信息。嗅探能够在部分情况下补充名称，但受协议和加密方式限制，不宜用它替代清楚的解析与路由设计。

规则提供者与实际命中

RULE-SET 引用的是 rule-providers 中定义的规则集合，既可以用于域名集合，也可以用于地址或传统规则集合，但资源格式必须与提供者的行为类型一致。把完整配置文件作为域名列表加载，或把包含策略目标的规则逐行塞入只接受域名的资源，都会产生格式问题。资源定义与加载方法见下一章。

排查错误分流时，先选一个稳定且明确的目标，建立新连接后查看命中的规则名称与策略链。若目标命中了不该命中的前置规则，应缩小该规则范围或调整顺序；若已经命中正确规则而访问失败，则继续检查最终节点与解析结果。这样可以把“选错出口”和“出口不可用”分开，避免把节点问题归咎于规则语法。

大型规则集会随上游更新而变化，维护时应保留少量本地例外，并明确其插入位置。不要在远程规则资源中临时手改后期待更新继续保留修改。需要长期固定的规则，应进入独立覆写或本地资源，并在订阅更新后复查最终顺序。关于模式与规则的常见误解，可继续查阅帮助中心。

订阅与远程资源

订阅并不总是同一种文件。有的地址返回完整 Clash 配置，有的只返回节点集合，还有的返回节点分享链接编码后的文本。图形客户端可能提供订阅转换或预处理，但内核的 proxy-providers 并不会自动把所有格式识别成可用节点。配置之前应先确认响应结构，再决定由客户端导入完整配置，还是由内核作为远程节点资源加载。

节点提供者

proxy-providers:
  主订阅:
    type: http
    url: 'https://subscription.example.com/nodes.yaml'
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 出口选择
    type: select
    use:
      - 主订阅

rules:
  - MATCH,出口选择

type: http 表示从远程地址取得资源，url 是资源地址，path 是本地缓存位置，interval 是更新间隔。示例地址是教学地址，必须换成实际返回兼容节点集合的订阅。缓存路径通常与内核工作目录有关，不一定相对于订阅文件所在位置；桌面与手机客户端的可写目录也可能不同。

节点提供者的资源通常包含顶层 proxies 列表，而不是完整的端口、DNS 与规则配置。下面展示资源文件的形状，仍使用不能实际连接的教学参数。如果订阅返回的是网页、登录提示或错误信息，即使 HTTP 请求本身成功，也不会得到可用节点；应通过客户端日志确认响应内容类型与解析错误。

proxies:
  - name: 订阅示例节点
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: 'your-password'
    udp: true

更新间隔与健康检查间隔是两套机制。前者获取节点定义的变化，后者测试已有节点的可用性；缩短健康检查间隔不会让新节点更早出现在订阅中。节点很多时，频繁探测还会增加网络请求。设置时应结合资源变化频率、设备电量与实际选择需求，而不是把所有间隔都调到很小。

规则提供者

rule-providers:
  业务域名:
    type: http
    behavior: domain
    format: yaml
    url: 'https://rules.example.com/business.yaml'
    path: ./rules/business.yaml
    interval: 86400

rules:
  - RULE-SET,业务域名,出口选择
  - MATCH,DIRECT

behavior 决定规则资源如何解释，常见的 domain、ipcidr 与 classical 对应不同内容。format 决定文件编码形式，不能仅根据扩展名猜测。域名行为的 YAML 资源通常使用 payload 包裹条目；传统规则资源可表达更多规则类型，但同样需要遵守对应格式，不能混入完整配置的顶层字段。

payload:
  - '+.example.com'
  - api.example.net

资源名称与缓存路径应各自唯一。两个提供者共用同一个本地文件，可能让后一次更新覆盖前一次内容，从而出现资源看似加载成功、实际规则却不属于当前集合的情况。修改资源类型或格式后，还应关注旧缓存是否继续被使用。不要直接清空整个客户端数据目录；先根据日志定位具体缓存文件，并保留可恢复副本。

更新失败、引导依赖与隐私

远程资源更新失败时，内核可能继续使用已有缓存，也可能因首次运行没有可用文件而无法完成加载，具体应以日志为准。若获取订阅必须经过某个代理，而该代理又只能从这份订阅中获得，就会形成启动依赖。解决方向是提供可达的更新路径或独立引导出口，而不是反复点击更新并期望尚未存在的节点完成下载。

订阅地址常携带访问凭据，不应放到公开仓库或公开转换服务中。需要转换格式时，先了解转换服务能够接触哪些内容，再核对输出是否保留协议、传输与分组信息。多设备同步也应区分“同步同一订阅地址”和“同步完整运行配置”：后者可能带入不适合其他平台的监听、路由与路径设置。

跨设备使用时，较稳定的做法是共享节点来源与业务规则，把平台相关设置留给各自客户端。关于私有仓库、订阅地址与覆写文件的组合，可参阅电脑与手机共用配置的取舍；具体资源合并顺序仍需要按照下一章的方法检查最终运行结果。

覆写、合并与验证

覆写用于把长期保留的本地意图与定期更新的订阅内容分开。例如订阅负责节点与基础策略，本地覆写负责局域网例外、业务规则或平台接管参数。它不是一个由 YAML 统一规定的通用顶层字段，而是客户端在生成配置时实施的处理过程。名称相同的“合并”“覆写”或“脚本”功能，在不同客户端中可能有不同执行阶段与列表处理方式。

先确认合并规则

映射合并与列表合并需要分别理解。标量字段通常由后写入的值替换；嵌套映射可能递归合并，也可能整体替换；列表则可能追加、前置或直接替换。不能因为某个客户端保留了原有 DNS 子字段，就推断它也会保留原有规则列表。操作前应查看该客户端提供的说明与预览，以最终结果而不是功能名称判断行为。

# 基础配置片段
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://cloudflare-dns.com/dns-query

# 希望加入的字段片段
# 应通过客户端支持的合并方式处理，不要直接重复粘贴 dns 键。
# dns:
#   fake-ip-filter:
#     - '*.lan'

如果客户端对 dns 执行整体替换，只提交 fake-ip-filter 就可能让原来的上游设置消失；如果执行递归合并，列表是否保留仍取决于实现。稳妥方法是先对一个低风险字段进行试验，查看运行配置中的完整 DNS 区域，再应用真正需要的变化。测试期间保留基础配置与覆写文件的独立副本。

规则前置与名称迁移

本地规则通常需要插入远程规则之前，尤其是订阅已经包含兜底规则时。若客户端只是把本地列表追加到末尾，新增规则会落在 MATCH 后面，语法没有问题却不会命中。需要明确使用客户端支持的前置操作，或在脚本中控制插入位置。修改完成后应直接检查最终规则列表的首部和末尾，而不是只看覆写编辑器中的内容。

rules:
  - DOMAIN,internal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,出口选择
  - MATCH,出口选择

以上仅表示希望得到的最终顺序，不是一种跨客户端通用的覆写指令。若本地规则引用“出口选择”，订阅更新后该组被改名或删除，仍会导致引用失效。可以让本地维护一个稳定组名，再连接订阅提供的节点集合；也可以在更新后核对引用关系。不要依赖界面曾经显示过该名称，就认定当前运行配置中仍然存在。

最小变更与分层验证

建议每次只修改一个层面：先确认文件可解析，再检查名称引用，然后确认监听与接管，最后验证业务分流。若同时改变 DNS、TUN、节点协议与规则顺序，即使问题暂时消失，也无法确定是哪一项起作用。为每次变更记录目的、修改字段和测试目标，能够减少后续订阅更新时重复排查的成本。

1. 保存当前可用配置，记录激活的配置档与主要开关。
2. 检查 YAML 缩进、重复键、数据类型与名称引用。
3. 查看生成后的运行配置，确认本地字段没有被覆盖。
4. 建立新的测试连接，检查规则、策略组与最终节点。
5. 更新订阅并重新加载，确认本地设置仍按预期保留。

验证应覆盖至少一条直连路径与一条代理路径。如果仅测试某个网页能够打开，可能遗漏全部流量都被错误地直连或代理的情况。DNS 调整还需要观察域名解析与连接是否保持一致；TUN 调整需要检查局域网、其他 VPN 和休眠恢复后的行为。配置测试命令负责语法与部分语义检查，实际网络验证则需要独立完成。

不同平台之间迁移配置时，应剥离本地文件路径、网卡名称、控制端口以及平台专属的接管参数。共享的重点应是节点来源与分流意图，不是把一台设备的所有运行细节复制到另一台设备。对于 Clash Plus 等图形客户端，可先使用下载中心对应平台的选项建立基础环境，再按需迁移配置，避免同时引入安装与字段兼容问题。

最终维护对象应是一套能够解释的配置关系：每个远程资源有明确来源，每个组名有稳定用途，每条例外有对应测试目标，每次合并都能看到结果。首次使用可返回快速上手完成连接主线；已经确认配置可加载但仍有异常时，转到帮助中心或连接失败排查文章，按入口、解析、规则与出口逐层处理。