Clash YAML 配置文件参考

1. YAML 结构与配置加载路径

先区分源文件与运行文件

Clash 配置不是一张只记录节点的清单。顶层通常同时包含监听端口、代理模式、DNS、节点、策略组和规则。客户端导入订阅后，可能先保存远程内容，再叠加本地设置，最后生成交给内核的运行文件。因此，编辑器里看到的订阅文本与内核正在读取的文本不一定相同。排查时要记录当前选中的配置名称，找到客户端提供的运行配置查看入口，避免修改了未启用的文件却反复重启。

原始订阅适合保留服务端维护的节点与分组，本地扩展适合保存个人规则。把两类内容分开，可以减少更新时相互覆盖。客户端若没有清楚标明扩展作用范围，先用一条容易观察的规则测试，再确认它是否仅作用于当前订阅。不要仅根据配置文件名推断加载状态；界面选中项、日志中的加载结果和实际请求的规则记录应能相互对应。

缩进、类型与引用名称

YAML 用缩进表达层级，建议统一使用两个空格，不混入制表符。冒号后面的空格区分键与值，短横线表示列表元素。同一列表中每个对象的属性要保持对齐。端口通常写整数，开关使用小写布尔值；把布尔值包进引号会成为字符串，部分字段会因此报类型错误。节点名和策略组名是引用标识，大小写、空格和标点都参与匹配，不会自动纠正近似名称。

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

proxies: []

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

rules:
  - MATCH,出口选择

上例是一份仅直连的基础文件，用来检查解析和引用关系，不提供代理出口。空节点列表是合法的，策略组引用的是内置的 DIRECT。后续加入节点时，应先在 proxies 定义节点，再把其名称放进策略组。规则最后引用策略组，形成从请求到规则、从规则到策略、从策略到出口的链条。理解这条链比一次复制大量复杂字段更重要。

引号与重复键

密码、包含特殊符号的名称和可能被解释为其他类型的字符串，适合使用引号。字符串中若包含冒号加空格、注释符号或换行，要格外注意解析结果。单引号里的单引号需要连续写两次；双引号允许转义，反斜杠也需要按规则处理。不要把网页排版产生的弯引号当作 YAML 引号。注释只能解释内容，不会改变字段含义，也不能代替缺失的必填参数。

同一层级不要重复定义 dns、rules 或 proxy-groups。部分解析器会拒绝重复键，部分流程可能保留后面的值，结果难以预测。把两段各带一个 dns 的示例拼在一起，不等于合并 DNS 设置。应保留一个父键，再把需要的子字段移入其中。列表也是如此：新增规则应添加到现有 rules 列表，而不是另起一个同名顶层键。

能够访问内核命令行时，可以使用下面的测试命令。可执行文件名和配置路径按设备实际情况调整；图形客户端如果提供配置检查功能，优先使用其入口。语法检查通过只说明文件能够被接受，不代表远程节点可达，也不代表策略符合预期。启动后仍需检查监听端口、规则命中和出口选择；详细日志阅读可参考运行日志定位方法。

mihomo -t -f config.yaml

2. 端口、代理模式与通用字段

监听端口只负责接收请求

port 是 HTTP 代理监听端口，socks-port 是 SOCKS 监听端口，mixed-port 则在同一端口接受 HTTP 和 SOCKS 请求。它们描述的是应用连接本地内核的入口，不是远程节点端口。一个应用填入本机地址和 mixed-port 后，请求才进入内核；远程节点如何连接，仍由节点字段决定。初次配置通常保留一个混合端口即可，只有明确需要独立入口时才增加其他端口。

端口冲突通常发生在两个客户端同时运行、旧内核未退出，或其他程序已经监听相同地址时。遇到地址占用报错，应先退出重复进程，再决定是否换端口。修改端口后，浏览器手动代理、终端环境变量和局域网设备上的设置也要同步更新。客户端显示启动成功并不保证所有应用已经改用新端口；应从应用自己的代理入口反向核对，而不是只观察客户端开关。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

规则、全局与直连模式

mode: rule 按 rules 顺序决定出口；mode: global 将流量交给全局策略；mode: direct 则使用直连。这里的全局只针对已经进入内核的流量，不会自动接管所有应用。某个程序未遵循系统代理时，即使切换全局模式，它也可能继续直连。判断模式是否有效，要先确认请求出现在连接记录中，再检查对应出口。模式切换的界面操作见代理模式说明。

全局模式适合临时判断分流规则是否导致问题，不宜被当作修复所有网络故障的按钮。若规则模式失败而全局模式成功，优先检查命中规则与所选策略组；若两种模式都失败，则更应检查节点参数、网络可达性和解析链路。直连模式也不会自动清除操作系统代理设置，应用仍可能先连接本地监听端口，再由内核直连，所以关闭内核前要确认系统代理能正常恢复。

监听范围与管理接口

allow-lan 与 bind-address 需要一起理解。前者表示是否允许局域网使用，后者限定监听地址。仅在本机使用时，可限制在回环地址；确实需要共享时，再按实际网卡、防火墙和认证要求开放。把监听地址设成所有接口，并不意味着外部设备一定能够连通，还取决于路由和系统安全规则。也不要为了排查手机连接问题，直接把服务暴露到公网。

代理入口与 external-controller 管理接口是两回事。管理接口用于控制配置、策略和连接状态，不应作为浏览器代理端口填写。客户端往往自行生成接口地址和访问凭据，手工改动可能导致界面失联。普通桌面使用不必为了套用示例额外开放管理接口；需要远程管理时，应单独规划访问限制，而不是沿用代理监听端口的信任范围。

log-level 日常使用 info 通常足够，定位问题时可临时切到 debug，复现一次后恢复。日志可能含访问域名、节点名称和本地路径，分享前应删除个人信息。若通用字段每次启动都会恢复，先检查客户端设置页是否维护同名选项；如果是，就在设置页修改，不要持续编辑自动生成的文件。浏览器和终端行为不同的情况，另见系统代理分线排查。

3. 代理节点字段与外部节点集合

节点对象的共同部分

proxies 是节点对象列表，每个节点通常有 name、type、server 和 port。name 供策略组引用，type 决定协议及其余字段的解释方式，server 是远端地址，port 是远端服务端口。协议不同，认证字段、加密方式和传输设置也不同。不能只把 type 从一种协议改成另一种，再保留原来的参数期待自动兼容；客户端能解析对象，也不代表远端提供了对应服务。

订阅给出的节点参数应整体保留，尤其是 TLS、传输层和协议专有字段。某些分享链接可以被客户端转换为节点对象，但转换结果仍要受内核支持范围约束。客户端名称相同或界面相似，并不能证明它们内置同一内核。选择客户端时可先查看下载中心，优先考虑 Clash Plus；已有配置迁移前，再用客户端对比核对平台与配置适配方向。

proxies:
  - name: 示例出口
    type: ss
    server: proxy.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

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

上例展示 Shadowsocks 节点与策略组的引用关系，域名和密码用于说明，必须替换成服务实际参数。cipher 需要与服务端一致，不是越复杂越好；udp 表示允许该节点处理相应 UDP 流量，但不能凭此给原本不支持 UDP 的服务增加能力。节点名称若修改，所有直接引用它的策略组也要同步修改，否则配置可能在检查引用时失败。

TLS 与传输层不是可随意开关的优化项

对使用 TLS 的协议，server、servername 和证书校验各有职责。server 决定连接目标，servername 通常参与 TLS 握手时的服务器名称指示及证书名称判断。两者可能相同，也可能因部署方式而不同，应该按服务提供的参数填写。连接失败时，不要先开启跳过证书验证；先检查设备时间、服务器名称、证书有效性与网络路径，避免把部署错误长期掩盖。

WebSocket 路径、请求头和其他传输参数也必须匹配远端。把服务器地址复制正确，却漏掉路径或请求头，仍可能出现握手失败。排查顺序应从底层往上：域名能否解析，目标端口能否到达，TLS 是否成功，协议认证是否通过，最后才看规则与目标网站。日志若明确指向认证失败，就不必反复修改 DNS 或策略组顺序，应回到节点参数和账户状态检查。

用 proxy-providers 管理外部节点

proxy-providers 把节点集合从主文件中分离出来，适合需要定期更新节点、但希望规则和策略组保持稳定的配置。提供器内容应是内核支持的节点集合格式，不是任意网页，也不一定等同于一份完整客户端订阅。主配置中的策略组通过 use 引用提供器名称，而不是把提供器名当作普通节点放进 proxies。两种列表承担不同引用关系，不应混写。

proxy-providers:
  本地节点:
    type: file
    path: ./providers/local.yaml
    health-check:
      enable: false

proxy-groups:
  - name: 出口选择
    type: select
    use:
      - 本地节点
    proxies:
      - DIRECT

本地文件可以使用如下结构。相对路径以实际配置目录和客户端运行方式为准，不能默认它总是相对于桌面快捷方式所在目录。先确认文件确实被读取，再排查节点是否出现。远程提供器还涉及更新间隔、缓存和请求出口；若更新失败，应分别检查下载请求与旧缓存是否可用，而不是立即删除全部配置。

proxies:
  - name: 示例出口
    type: ss
    server: proxy.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

订阅链接本身可能包含账户授权信息，应当按凭据保管。分享配置时，除了密码，也要检查远程提供器地址及请求头。若服务端更新后节点名变化，手写的单节点引用可能失效；通过提供器接入的策略组通常更容易跟随集合变化。节点挑选不只看测试结果，还要考虑用途、地区和流量规则，具体判断见节点选择方法。

4. 策略组类型与引用关系

策略组是出口决策层

策略组把规则引用与具体节点分开。规则指向一个稳定的组名，组内再选择节点或其他组，这样替换节点时通常不必重写全部规则。组名与节点名应保持唯一、易辨认，避免同名导致理解混乱。设计时先画出请求的单向路径：规则进入业务组，业务组进入选择组，选择组最终到达节点或 DIRECT。任何一条路径都应能够结束，不能重新绕回自身。

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

rules:
  - MATCH,出口选择

该片段依赖上一章的本地节点提供器。url 是实际探测目标，interval 是探测间隔秒数，tolerance 是自动切换时使用的延迟容差毫秒数。探测目标需要能代表当前用途，并且允许持续访问；示例中的地址不是外部页面资源，不会由本页浏览器自动加载。探测请求成功只能说明这条测试路径可用，不能证明所有网站、视频服务或 UDP 应用都能正常工作。

自动选择与故障回退的边界

url-test 通常偏向测试条件下表现较好的候选项，fallback 则更强调顺序和可用性。若希望优先使用固定出口、失败后再使用备用出口，fallback 比单纯追逐较低测试耗时更贴近需求。测试失败也可能来自探测地址受限、临时解析异常或网络抖动，不应立即认定节点完全失效。先用实际业务验证，再决定是否更换探测目标或延长观察时间。

load-balance 不会把多条线路拼成一条下载连接，也不能保证所有连接使用同一公网地址。不同分配策略对目标和连接的处理不同，使用前要确认是否允许出口变化。涉及账户风控、支付或长会话的应用，通常更适合固定选择。即使启用了负载分配，单条连接的速度仍受它实际经过的节点、远端服务和本地网络限制，不能把组内节点数量当作带宽总和。

名称、循环与持久选择

组中可以引用另一组，但不能形成循环。例如业务组引用出口组，出口组又引用业务组，就没有真正的出口终点。增加分组层级之前，先确认这一层是否有独立用途；过多嵌套会让界面显示正常，却很难看出最终使用哪个节点。排查时沿着当前选中项逐层展开，直到看到实际节点、DIRECT 或 REJECT，再结合连接记录确认。

客户端可能记住手动选择，配置重新加载后仍恢复上次的组内项目。因此，改变 YAML 中候选项的排列顺序，不一定会让当前出口改变。若出现新配置已加载但出口未变化，应检查策略组当前选择和选择持久化行为，而不是继续重排节点。需要重置时，优先使用客户端提供的选择操作，避免直接删除整个配置目录造成订阅和本地规则一并丢失。

5. DNS 设置与 Fake-IP 工作方式

先确认应用把解析交给了谁

DNS 配置决定内核如何解析域名，但应用未必使用内核 DNS。系统解析器、浏览器安全 DNS、应用内置解析和 TUN 劫持可能同时存在。遇到 Clash DNS 泄漏疑问，应先识别哪一类请求绕过了预期入口，再调整设置。仅把 nameserver 换成加密地址，不能证明设备上所有解析都经过代理；加密解决传输可读性问题，代理出口与请求接管则是另一个维度。

dns.enable 开启内核 DNS 功能，listen 定义监听地址，nameserver 指定常规上游。default-nameserver 通常用于解析上游 DNS 地址里的域名，帮助完成启动阶段的基础解析；proxy-server-nameserver 可为代理节点服务器域名单独指定解析路径。需要区分解析目标网站与解析代理服务器：若后者依赖尚未连通的代理，就可能形成启动循环，表现为节点域名一直解析失败。

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5

该片段说明字段层级，不代表适合所有网络。上游地址需要在当前网络中可达；更换网络后，应重新测试解析延迟与返回结果。监听在回环地址的端口不会自动成为系统 DNS，仍需客户端、TUN 或系统设置把查询送到这里。若电脑仅开启系统 HTTP 代理，使用 SOCKS 的应用又在本地自行解析，两者可能产生不同的 DNS 路径。

Fake-IP 与真实地址映射

Fake-IP 给应用返回映射用的合成地址，内核记录该地址对应的原始域名。后续连接再次进入内核时，可以根据映射恢复域名并参与规则匹配，而不是直接把合成地址当作公网目标。它不是公共 DNS 的另一组真实解析结果，也不应该被路由器直接转发到互联网。配置正确时，解析与连接需要落到同一套能识别映射的处理链中。

某些局域网发现、设备管理或依赖真实地址的程序可能不适合合成地址，可通过 fake-ip-filter 按实际需求排除。排除后通常返回正常解析结果，不等于给该域名增加直连规则；最终出口仍由 rules 决定。不要为了一个应用的兼容问题直接排除所有域名，否则会失去该模式提供的域名映射能力。先限定具体后缀，清理旧缓存，再检查影响范围。

分域名上游与解析出口

nameserver-policy 可以针对域名选择解析上游，适合企业内网域名、局域网后缀与公共域名需要不同解析服务的场景。下面使用内网 DNS 的示意地址；只有该地址确实是所在网络的解析器时才应使用。策略匹配后还要保证到上游的路由可达，否则规则写对了也只会得到超时。不要把仅在办公网络可达的上游永久套用到所有网络环境。

dns:
  nameserver-policy:
    "+.corp.example.com":
      - 192.168.1.1

respect-rules 等设置会影响 DNS 上游连接是否遵循路由规则，启用前应理解相关依赖，并配置好节点服务器域名的独立解析。若所有 DNS 请求都要先走代理，而代理服务器名称又必须依靠同一路 DNS 才能解析，就会卡在初始化。分域名解析和代理分流是两套规则，应分别核对，不能只看到某个域名使用了指定上游，就认定其后续连接必定经过同一出口。

修改 DNS 后，应关闭旧连接、清理客户端和系统缓存，必要时重启使用内置缓存的应用，再做一次完整请求。测试时记录应用使用的解析方式、返回地址类型及连接命中规则。IPv6 也要单独验证：关闭内核相关选项，不代表系统其他入口不再发送 IPv6 请求。若仍有异常，按常见问题中的网络排查顺序缩小范围，不要同时关闭多个安全与解析设置。

6. 规则语法、规则集与匹配顺序

规则从上到下，命中后停止

rules 是有顺序的列表，不是根据精确程度自动排序的集合。较早命中的规则决定出口，后面的规则不再处理该请求。因此，具体域名通常放在宽泛的地域规则前，MATCH 放在最后兜底。若前面已经有覆盖所有请求的规则，再往下面添加例外不会生效。排查某个网站走错出口时，应从连接详情读取实际命中项，再从该位置向前检查，而不是只搜索期望命中的那一行。

常见规则形态是类型、匹配内容、策略，MATCH 则只需要策略。策略可以是节点名、组名或内置动作，但必须存在且可用。建议业务规则引用稳定的组名，不直接依赖经常变动的节点名称。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀及其子域，DOMAIN-KEYWORD 匹配关键字；关键字覆盖范围较宽，不能用来替代需要边界清晰的后缀匹配。

rules:
  - DOMAIN,login.example.com,出口选择
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,出口选择

上例依赖名为出口选择的策略组。第一行只处理指定登录域名，第二行处理示例后缀，第三行处理目标地址属于指定网段的连接。GEOIP 使用本地地理数据判断目标地址所属区域，不能把它理解为访问者所在地区。最后一行接收此前未匹配的请求。实际配置中还需覆盖所在网络使用的其他私有地址段，不能把示例里的单个网段视作全部局域网范围。

解析时机与 no-resolve

域名规则需要内核能够取得域名信息；若应用只提交地址，且没有可用映射或其他域名识别来源，单靠域名规则就可能无法匹配。IP 类规则在处理域名目标时可能触发解析。no-resolve 的含义是不要仅为了这条规则主动解析域名，并不是禁止整条请求发生任何 DNS 查询。请求已经具有目标地址时，仍可进行地址匹配；没有可用地址时，则继续检查后续规则。

规则中的 REJECT 是拒绝动作，DIRECT 是直连动作，都不是节点类型。临时拒绝一条精确域名规则，可以帮助验证规则是否真的加载，但测试后应恢复预期配置。不要用过宽的关键字拒绝规则做诊断，容易误伤登录、更新或资源域名。一个网页也不只建立一个连接，主站、静态资源和认证服务可能命中不同策略，应逐项查看，不能以页面标题作为全部请求的代表。

规则集把维护对象拆开

rule-providers 用于外部规则集合，与 proxy-providers 的节点集合不同。规则集需要选择正确的 behavior，常见有 domain、ipcidr 和 classical；文件内容必须与行为类型匹配。domain 集合以域名模式为主，ipcidr 集合以网段为主，classical 承载规则类型和匹配内容。引用规则集时由主配置指定策略，便于同一集合在不同配置中复用不同出口。

rule-providers:
  业务域名:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/business.yaml

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

对应的本地规则集如下。这里不在 payload 的每一行追加出口策略，因为策略已在主配置的 RULE-SET 引用处指定。文件路径、编码、列表缩进和 behavior 任一不匹配，都可能导致加载失败。远程规则集还要检查下载是否成功、缓存是否更新，以及提供的内容是不是所声明的格式；一个返回错误页面的地址不会因为扩展名是 YAML 就自动变成规则集。

payload:
  - DOMAIN,login.example.com
  - DOMAIN-SUFFIX,example.org

维护规则时，先解决可观察的问题，再扩大覆盖范围。记录目标域名、当前命中项、期望策略和修改理由，可以避免长期累积互相覆盖的例外。地理数据、规则集缓存和主配置有各自的更新周期，修改其中一项不等于其他项同步刷新。若规则文件正确但行为始终不变，回到运行配置检查覆写位置，再确认旧连接是否仍沿用原有出口；规则更新通常不意味着既有连接自动迁移。

7. TUN、系统代理与 DNS 接管边界

先选择入口，再讨论分流

系统代理是告诉遵循系统设置的应用，把请求发送给本地代理入口；TUN 则通过虚拟网络接口和路由处理更多网络流量。两者处于入口层，不改变节点认证参数，也不自动修复错误规则。命令行工具、游戏或自带网络栈的程序可能不读取系统代理，因此客户端里没有连接记录时，应先判断入口是否覆盖该应用，再考虑是否需要 TUN，而不是反复更换远端节点。

TUN 的实际能力取决于操作系统、权限、客户端集成和内核实现。桌面客户端可能通过服务组件申请权限，移动端通常通过系统 VPN 授权建立网络入口。权限未授予、虚拟网卡创建失败和路由写入失败，都可能发生在节点连接之前。Clash Plus、Clash Verge Rev、FlClash 等客户端的操作入口不完全相同，不能把一个客户端的服务安装步骤直接照搬到另一个客户端。

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

该片段展示常见字段关系，不承诺在所有平台无需调整即可运行。enable 开启功能，stack 选择协议栈实现，auto-route 尝试配置路由，auto-detect-interface 尝试识别出口网卡。若系统有多个网卡、虚拟网络、企业 VPN 或容器桥接，自动识别未必符合预期。调整协议栈前，先看日志是否明确报错；不要把切换 stack 当成无法解释的固定优化步骤。

DNS 劫持不等于接管所有解析

dns-hijack 将匹配的 DNS 流量送入内核解析流程，示例主要针对传统 DNS 的对应端口流量。应用通过加密协议自行连接解析服务时，流量形式不同，不会仅因为存在这条配置就自动变成普通 DNS 查询。浏览器安全 DNS、应用私有解析与系统解析应分别检查。若目标是让某应用遵循统一解析策略，优先调整该应用的解析设置，并验证请求最终进入哪条链路。

Fake-IP 与 TUN 结合时，要确保合成地址的连接也进入同一内核。若应用缓存了合成地址，随后关闭 TUN 或切换到另一套配置，旧地址可能失去对应映射，表现为部分站点突然无法访问。此时先清理相关缓存并重新建立连接，而不是立刻更改上游 DNS。重启客户端、恢复配置和重启应用的顺序也应记录，否则难以分辨恢复来自哪个动作。

路由冲突与局域网访问

企业 VPN、其他代理客户端、虚拟机网络和安全软件都可能改变路由。多个程序同时尝试接管默认路由时，可能出现来回转发、错误出口或本地服务无法访问。排查应先保留一套网络接管方案，关闭其他接管入口，再复现问题；不是要求永久卸载其他工具。确认单独运行正常后，再研究是否支持共存，并针对需要直达的网段设计排除或分流。

局域网打印机、网络存储和开发服务访问失败时，先确认名称解析，再确认目标地址和路由。给域名设置直连规则，并不必然解决系统路由层把流量送错接口的问题；反过来，路由可达也不保证域名能被正确解析。应分别使用名称和已知地址测试，判断故障位于解析还是连接，再做最小范围调整，避免为了一个内网服务把全部流量都排除在接管之外。

远程维护服务器时，不要直接套用桌面 TUN 配置接管全部路由。应先准备控制台或可恢复通道，确认管理连接不受影响，再逐项启用。普通用户应从图形客户端下载入口选择适合的平台；独立内核更适合能自行维护服务、权限与网络规则的场景。首次安装权限问题可结合跨平台初始设置检查。

8. 订阅覆写、合并与变更验证

先确认每层配置的所有者

配置来源通常可以拆成远程订阅、本地扩展、客户端全局设置和最终运行文件。远程订阅负责服务端发布的内容，本地扩展负责个人规则，客户端设置负责监听、权限或网络入口，运行文件则是这些来源处理后的结果。不同客户端的处理顺序和粒度并不统一，因此不能把某种覆写语法当作 YAML 本身的标准。迁移客户端时，应迁移意图与实际字段，不只迁移某个扩展文件。

直接修改订阅源文件，可能在下次更新时被替换；直接修改运行文件，则可能在重载或切换配置时被重新生成。较稳妥的做法是把长期自定义内容放到客户端明确支持的扩展入口，并保留独立备份。若客户端只支持整份本地配置，就应自行维护更新流程。不要因为一次修改立即生效，就认定这个位置能够长期保存，至少要验证一次重载和一次订阅更新。

对象合并与列表合并不是同一件事

对象字段可能按键递归合并，也可能整段替换；列表则可能前插、后插、替换或经过专用处理。以 rules 为例，后插的例外如果位于 MATCH 之后，文本已经存在却不会命中；整段替换又可能删除订阅原有分流。以 nameserver 为例，追加上游可能增加并行查询范围，而不是把旧上游替换掉。使用扩展前，应先阅读客户端对对象和列表分别采用的行为。

# 目标是把例外放在现有规则之前，
# 不是把此片段原样当作所有客户端的覆写语法。
rules:
  - DOMAIN,dev.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口选择
  - MATCH,出口选择

上例表达期望的最终顺序。实际操作时，要用所在客户端支持的前置规则、扩展配置或脚本机制实现，不能把它盲目粘贴到订阅末尾。最终检查点是运行文件中只有一个 rules 顶层键，例外确实位于兜底之前，引用的策略组仍然存在。还要确认扩展绑定的配置范围，避免个人开发规则无意应用到其他订阅或其他设备。

订阅更新与手动选择分别验证

订阅更新成功，只能说明某个更新步骤完成，不一定意味着当前运行配置已经重新生成并启用。部分客户端将下载、解析、保存和重载分开执行，任一步失败都可能保留旧内容。应检查更新时间对应的日志、节点集合变化及当前选中配置，再确认内核重载结果。遇到更新失败时，先按订阅常见问题区分网络失败、内容格式错误与授权问题。

恢复备份也要注意客户端保存的选择状态。即使文件恢复原样，策略组仍可能沿用上一次手动选择，DNS 缓存和既有连接也可能未清理。复现测试时应固定模式、策略组出口、请求目标和应用入口，必要时关闭旧连接后再发起请求。每次只改变一个变量，记录结果，才能判断配置恢复是否真正解决了问题，而不是恰好碰到远端服务恢复。

按四层完成一次变更闭环

第一层检查语法与类型，确认缩进、引号、布尔值和重复键。第二层检查引用，确认规则指向的组、组内节点和提供器都存在，且没有循环。第三层检查运行状态，确认内核读到新配置、端口成功监听、DNS 和 TUN 没有初始化错误。第四层才是业务验证，使用目标应用访问明确的地址，读取命中规则与出口。前一层未通过时，不应跳到下一层盲改。

备份至少应覆盖本地规则、策略组结构和客户端相关扩展，不能只导出节点列表。敏感节点参数应存放在受控位置，分享给他人时改成说明用途的示例值。清理旧文件前，先确认哪些是源文件、哪些是缓存、哪些由客户端生成；随意删除缓存目录可能导致离线时无法启动，而删除源文件又可能丢失尚未同步的个人配置。

最终应能回答三个问题：应用请求从哪个入口进入，哪条规则决定出口，哪一层配置负责这条规则。回答不清时，回到最小基础配置逐层增加功能，比继续堆叠覆写更容易定位。快速完成连接仍按快速上手执行；需要解释名词时查名词解释，需要分析具体报错时查运行日志说明，避免把查阅手册当成必须一次启用的功能清单。