config.yaml 配置参考

一、YAML 结构与配置文件边界

映射、列表与标量

config.yaml 是描述内核运行方式的文本文件。顶层通常是映射，即字段名与字段值的集合；dns 下继续嵌套映射，rules 下则是有顺序的列表。字符串、数字和布尔值属于标量。先辨认这三种结构，再修改具体内容，可以避免把一个列表误写成字符串，或者把本应位于顶层的字段缩进到另一个对象内部。

YAML 用缩进表示父子关系，建议统一使用两个空格，不使用制表符。同层字段必须左对齐，列表项前的短横线后要留空格。字段名后的冒号通常也需要空格。下面的 mode 与 dns 同级，enable 属于 DNS 对象，nameserver 的两个值属于一个列表；空行只改善阅读，不改变层级。

mixed-port: 7890
mode: rule

dns:
  enable: true
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

rules:
  - MATCH,DIRECT

布尔开关使用 true 或 false，端口写成整数，具有标识意义的内容按字符串处理。密码、包含井号的地址、带冒号的复杂文本建议用引号包住，防止字符被解析成注释或映射边界。单引号中的反斜杠一般按字面保留，双引号支持转义；从网页复制 Windows 路径时尤其要注意反斜杠含义。注释从引号之外、符合语法位置的井号开始。

顶层结构不等于执行顺序

将 rules 放在文件末尾是一种阅读习惯，不代表内核先执行前面所有字段再执行规则。真正有顺序语义的是规则列表，以及某些策略组中的候选顺序。顶层键的先后通常不影响结果。同一个映射中不要重复定义同名键；不同解析器可能拒绝重复键，也可能保留后一项，不能利用这种差异实现可靠覆写。修改 DNS 时应进入已有的 DNS 对象，而不是在末尾再追加第二个对象。

还要区分原始订阅、客户端保存的配置与交给内核的运行时文件。订阅可能只有节点，也可能包含完整策略组与规则。客户端可能在导入后重新组织内容，再补入端口、控制接口或 TUN 设置。因此，编辑订阅缓存不一定改变运行结果，重启客户端又可能把修改覆盖。定位问题时，应先在客户端中找到当前配置、运行时配置或内核配置预览，记录它与原文件的差异。

语法通过之后仍要检查引用

YAML 能被解析，只说明缩进和数据格式基本成立，并不保证字段受到当前内核支持。规则引用不存在的策略组、策略组引用拼错的节点，都属于配置语义问题。名字通常区分大小写，中文空格、尾部空格和全角标点也可能改变名字。建议先把策略组和节点的名称列成清单，再核对规则最后一段，避免在错误位置反复调整缩进。

本页其余章节的代码属于局部示例。将片段加入现有配置时，需要保留现有的同级字段，并逐项合并列表。客户端并不一定使用名为 config.yaml 的文件，启动参数也可以指定其他名称；判断依据是当前内核实际读取的路径。关于原版 Clash 与 mihomo 的字段差异，可继续阅读内核演进与兼容性对照，不要把同一份配置在不同内核中的结果视为理所当然。

二、通用字段：端口、模式与访问范围

入站端口与系统代理是两层设置

入站端口是内核接收应用连接的入口。port 提供 HTTP 代理入口，socks-port 提供 SOCKS 入口，mixed-port 则在一个端口上兼容 HTTP 与 SOCKS。一般桌面使用场景可先保留一个混合端口，减少维护多个入口的负担。端口值只是本机约定，并不存在所有客户端必须使用的固定数字；应用里的代理地址必须与实际监听地址一致。

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

内核监听成功，不代表系统代理已经开启。系统代理是操作系统告知支持该机制的应用去连接某个代理地址；配置中的入站端口只负责接受连接。关闭系统代理后，手动填写代理地址的应用仍可能继续使用内核；反过来，内核退出但系统代理没有清除，浏览器可能继续访问一个无人监听的端口。检查故障时，应分别确认进程、监听端口和系统代理状态，而不是只看客户端上的总开关。

rule、global 与 direct

rule 表示按规则顺序为连接选择策略；global 表示把进入内核的连接交给全局策略；direct 表示直接连接目标。模式决定进入内核后的处理方式，并不负责让所有应用流量进入内核。因此，全局模式不是 TUN 的替代品，也不能强迫一个忽略系统代理的应用自动使用代理。需要先解决接管范围，再讨论连接进入之后应选哪条出口。

规则模式通常适合作为日常起点，因为可以分别定义直连与代理的匹配条件。全局模式适合暂时隔离规则因素，确认某个出口是否可用；直连模式可用于对照测试，但仍可能保留入站和 DNS 等组件的影响。测试结束后应恢复原模式，并查看实际连接记录。更完整的场景对照见三种代理模式的选择方法，不要只凭某个网页能打开就判断全部分流已经正确。

监听边界与管理接口

allow-lan 与 bind-address 共同影响其他设备能否连接入站。只在当前电脑使用时，将访问范围限制在回环地址更容易排查。需要共享给手机时，除了允许局域网，还要确认监听地址覆盖局域网网卡、两台设备网络互通，以及防火墙允许对应入站。不要把开放监听简单等同于可安全地暴露到公网；路由器端口映射会显著改变访问边界。

external-controller 是管理接口，不是浏览器代理端口。它用于控制面板与客户端管理内核，不能填入应用的 HTTP 代理设置。客户端可能自行生成管理地址和认证设置，手动覆盖容易导致界面失去连接。没有独立管理需求时应保留客户端安排；确需调整时，先绑定本机，再配置认证，并避免把包含管理凭据的运行时文件贴到公开讨论区。

出现端口冲突时，先退出其他代理程序，再检查旧内核进程是否仍在运行。修改端口后，既要重新加载配置，也要同步应用中手写的代理地址。log-level 可临时调整为 debug，但详细日志可能包含目标域名和连接信息；分享前应删去敏感内容。若需重新选择客户端，前往安装包页面按平台查看，常规图形界面使用可先考虑 Clash Plus。

三、DNS：解析入口、上游与域名关联

先区分谁向谁发起解析

DNS 配置至少涉及三个角色：应用或系统是查询发起者，内核 DNS 模块是接收与转发者，上游解析器负责返回结果。dns.enable 控制内核模块，listen 指定它监听的地址，而 nameserver 指定上游。仅开启模块并不能保证系统已经使用它；还需要系统 DNS 设置、客户端接管机制或 TUN 劫持规则，把相应查询送到这个入口。

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
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

这个示例把 DNS 服务限制在本机非标准端口，便于与已有系统服务共存。它展示的是 DNS 模块结构，不会自行修改系统解析器。default-nameserver 主要用于解析上游 DNS 服务器自身的域名，即建立访问加密 DNS 所需的引导链路；它不是所有业务域名的默认出口。若上游使用域名而引导解析不可用，表现可能是整个 DNS 模块无法稳定启动查询。

fake-ip 与 redir-host 的差别

fake-ip 为查询分配用于映射的虚拟地址，内核在后续连接中借此找回原始域名，再执行域名规则与出口选择。这个地址不是目标服务器的真实公网地址，应用查到它并不意味着解析故障。redir-host 通常返回实际解析结果，域名关联方式不同。选择哪一种应结合应用兼容性与接管路径，而不是把两者理解为速度档位或安全等级。

部分局域网服务、设备发现和依赖真实地址的应用可能不适合使用虚拟地址。fake-ip-filter 可以让指定域名绕过这种分配，但过滤仅调整 DNS 返回行为，不等于增加直连规则。对于需要访问内网真实地址的域名，还要确认上游能解析内部名称，以及后续路由允许抵达该网段。排错应先针对一个确定的域名增加过滤，不宜直接塞入范围过大的通配模式。

顶层 ipv6 与 DNS 对象中的同名字段作用位置不同。前者影响内核整体的 IPv6 使用能力，后者影响 DNS 模块的 IPv6 解析行为。关闭 DNS 的 IPv6 返回，不一定能消除应用已有缓存、内置解析器或预先保存地址的影响。网络确实支持 IPv6 时，可以在明确路由与出口能力后分别启用；不应仅通过隐藏 AAAA 结果来掩盖一条已经错误配置的 IPv6 路径。

分流解析与代理服务器解析

nameserver-policy 用于为特定域名选择解析器，适合企业内部域名或有明确解析需求的区域；它决定向哪个 DNS 上游提问，不直接决定业务连接的代理策略。proxy-server-nameserver 可专门处理代理服务器域名的解析，降低出口尚未建立却要依赖该出口解析服务器地址的循环风险。只有明确发现循环或解析差异时才增加这些层次，避免同时改动多个变量。

dns:
  nameserver-policy:
    "+.internal.example.com":
      - 192.168.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

上面的内部域名与路由器地址只是结构示例，应换成实际管理的内部域和确实提供解析服务的地址。排查时先查看内核是否收到查询，再测试上游可达性，最后检查返回结果与后续连接的域名关联。应用自带加密 DNS 时，查询可能绕过系统设置；浏览器已经建立的连接也不会因为改了 DNS 就立即重建。必要时关闭旧连接、清理相关缓存，再用同一目标重复测试，避免把旧结果当成新配置的行为。

四、代理节点：协议字段与提供者

通用字段与协议专属字段

proxies 是静态代理节点列表，每一项描述一个出口。常见通用字段包括名称 name、协议 type、服务器 server 和端口 port。其他参数由协议决定，不能把另一种协议的认证字段直接搬过来。节点名称供策略组和规则引用，不负责认证；服务器可以是域名或地址，但填写网站首页网址、带路径的订阅链接都不能替代服务器字段。

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

这段展示 Shadowsocks 节点的结构。服务器域名和密码为教学值，不能直接建立可用连接；加密方式、端口和认证内容必须与服务端逐项一致。udp: true 表示允许使用该节点的 UDP 能力，并不能让不支持 UDP 的服务端自动获得转发功能。应用实际能否使用 UDP，还取决于入站方式、策略组、服务端和中间网络是否共同支持。

对于 TLS 类连接，需要分清传输目标与证书校验名称。连接地址告诉客户端去哪里建立连接，服务器名称用于 TLS 握手和证书验证，两者在特定部署中可以不同，但这种不同必须来自服务端提供的准确参数。遇到证书错误时，应核对系统时间、服务器名称、证书链和地址，而不是直接关闭验证。跳过验证会改变安全边界，也可能暂时掩盖连接到了错误服务器的问题。

节点列表与完整订阅不能混为一谈

proxy-providers 把节点列表放到独立来源中，主配置通过提供者名称引用。这样可以让节点更新与本地规则分开维护。提供者通常接收具有 proxies 结构的内容，并不意味着任意订阅文本都可以直接读取。Base64 文本、单条 URI 与完整 Clash YAML 的结构不同，格式不匹配时要先转换或通过客户端导入，具体可参阅订阅链接格式与转换方法。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

这个提供者使用本地文件，不涉及订阅地址。相对路径通常基于内核工作目录或客户端指定的配置目录，而不一定是正在编辑的文件所在目录。出现找不到文件时，先查看启动参数和日志中的最终路径，再确认文件可读。文件内容仍需包含节点列表；不能把整个主配置原样复制进去，期望内核自动从任意层级抽取节点。由客户端管理的目录还可能受到应用沙箱权限限制。

远程提供者通常使用 type: http，并设置来源地址、缓存路径和更新间隔。来源地址可能携带访问凭据，应视为敏感配置，不放进截图或公开仓库。更新失败时先区分网络请求失败、认证失败、内容不是 YAML、协议字段不支持四种情况。缓存存在时，内核可能继续使用旧节点；因此界面仍显示节点，并不能证明最近一次更新已经成功。

健康检查不是业务可用性保证

健康检查通过指定 URL 测试节点的连通情况，其结果依赖测试目标、解析路径和服务端响应。测试通过只表明这条检查链路可用，不能代表所有网站、UDP 应用或地区服务都能访问。提供者检查与策略组检查也不是完全相同的层次；重复开启过密检查会增加请求。建议保留明确的测试目标和合理间隔，先验证单个节点，再扩展到自动选择。

节点定义看似完整却无法使用时，应查看握手阶段的具体错误。域名解析失败属于前置网络问题，连接超时可能涉及地址、端口或防火墙，认证错误通常需要核对凭据，协议解析错误则要检查类型和内核兼容性。不要一次替换全部字段。先保留原值，对照服务提供方的协议参数逐项修改，再用一个手动选择组固定出口测试，避免自动切换掩盖问题。

五、策略组：引用关系与选择机制

策略组是出口选择层

proxy-groups 把节点、其他策略组和内置策略组织为可供规则引用的目标。规则通常指向一个稳定组名，组内再决定具体出口。这样节点列表更新时，不必重写每条业务规则。组名属于配置接口的一部分，修改名称后需要同步所有引用；名称重复或形成循环引用，都会让配置难以理解，甚至无法加载。设计时可以把引用关系画成由规则指向组、再指向节点的单向图。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT
    use:
      - local-nodes

  - name: Auto
    type: url-test
    use:
      - local-nodes
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 50

示例依赖上一章定义的 local-nodes 提供者。proxies 用于显式列出候选名称，use 引入提供者中的节点，两者不能把名称类型互换。Proxy 是手动选择组，可以选择自动组，也可以选择直连或提供者节点。Auto 不应再引用 Proxy，否则会形成回路。拼接示例时必须保留提供者定义，单独复制策略组会产生未定义引用。

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

select 让用户显式指定候选，适合验证单个出口和固定业务策略。url-test 根据测试结果选择候选，适合希望自动维护可用出口的场景。fallback 更偏向按候选顺序使用可用项，适合主用与备用关系明确的配置。三者并不是逐级更高级的模式，选择依据是业务是否允许切换、是否要求稳定出口，以及能否接受测试带来的额外连接。

自动组中的 interval 是检查间隔，tolerance 用于减少因微小测试差异导致的频繁切换，它不表示网络延迟目标，也不是加速开关。某个节点在测试地址上更快，不代表文件下载或视频服务也更快。load-balance 分配的是连接，不会把一条普通下载连接自动合并成多个节点的带宽；不同连接使用不同出口还可能触发业务端的会话变化。

候选过滤与选择状态

大型提供者可以通过过滤条件缩小候选范围，但过滤后必须检查是否仍有结果。正则表达式中的特殊字符与 YAML 引号规则会叠加，复制节点名称作为正则时，括号、加号和方括号都可能需要额外处理。先在客户端预览候选列表，再连接业务，比等到流量进入空组后查错更直接。不要假定订阅永远保留同样的命名方式，重命名可能让既有筛选条件失效。

手动组的选择可能被客户端或 profile.store-selected 等机制保存。重新加载文件后仍保留旧选择，并不一定是配置没有生效；它可能只是恢复了先前的运行状态。若新增了候选但界面没有自动切过去，先检查当前组的实际选择。反过来，删除当前节点后，内核或客户端可能选择其他可用候选，不能只凭列表第一项推断最终出口。

排查策略组时，先确认规则命中了哪个组，再展开该组当前选择的下一层，直到看到最终节点或内置策略。若日志只看到组名而没有理解后续引用，容易把节点故障误判为规则问题。建议保留一条清晰的手动测试路径，避免多层自动组互相嵌套。需要按操作系统重新比较客户端时，可查看选型指南；不同界面的组展示方式不改变底层引用关系。

六、规则语法：匹配类型、顺序与规则集

从上到下，首次匹配生效

rules 是有序列表。内核按顺序检查连接，一旦命中适用规则，就把连接交给该规则指定的策略，不会继续寻找看起来更精确的后续规则。因此，具体业务例外通常放在宽泛规则之前，兜底规则放在最后。规则排序不是文档排版问题，而是实际运行逻辑；把广泛匹配项移动到顶部，可能让后面大量条目失去作用。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-KEYWORD,example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

通常一条规则由类型、匹配值和策略组成，以英文逗号分隔。MATCH 不需要匹配值，直接指定最终策略。策略可以是内置的 DIRECT、REJECT，也可以是已有策略组或节点名称。不要在英文逗号处换成中文逗号，也不要给策略名附加解释文字。示例中的 Proxy 必须与策略组名称完全一致，否则结构虽像规则，仍无法完成有效引用。

域名规则与地址规则的边界

DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名本身及其子域，DOMAIN-KEYWORD 根据域名中出现的关键词匹配。后缀匹配比随意使用关键词更容易控制范围。规则填写的是主机名，不是包含协议、路径和查询参数的完整 URL；如果希望只区分同一网站的某个网页路径，普通域名规则无法做到，因为代理路由并不一定看到加密连接内部的请求路径。

IP-CIDR 根据目标 IPv4 网段匹配，IPv6 网段可使用相应的 IP-CIDR6 规则。可选的 no-resolve 表示不要为了检查该条地址规则主动触发域名解析，并不是强制整条连接永远不解析域名。当连接已经有可用目标地址时，仍可按地址检查。这个参数适合避免无必要的解析，但可能让只有域名信息的连接跳过某条网段规则，需要结合实际流量理解。

GEOIP 依赖地址数据库，GEOSITE 依赖域名分类数据。它们体现的是数据库维护的归类，不是业务服务的永久属性。某个域名使用跨区域 CDN 时，地址位置与服务归属可能不一致。出现意外分流，先查看命中的是域名规则还是地址规则，再核对数据文件是否存在和更新是否成功；不宜一开始就更换所有节点或关闭 DNS。

规则提供者与 behavior

rule-providers 把规则内容拆到外部文件，RULE-SET 再把它接入主规则链。提供者的 behavior 决定内容格式：domain 存放域名匹配内容，ipcidr 存放地址网段，classical 存放带规则类型的条目。不同格式不能只改一个字段就互换，文件内部内容也要对应。来源是文本还是 YAML，同样应与格式设置匹配。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,Proxy

# ./rules/local-direct.yaml
payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

规则集内部通常不写最终策略，策略由主配置中的 RULE-SET 指定。上例将整组条目交给 DIRECT，便于在主规则链控制出口。远程规则更新失败时，缓存也可能继续生效，所以“仍能匹配”不等于“已经更新”。验证规则应选择一个明确目标，关闭旧连接后重新访问，查看命中条目、策略组和最终出口。已有长连接不会因为规则文本改变就自动按新顺序重新建立。

七、TUN：虚拟网卡、路由与 DNS 接管

TUN 解决流量入口，不替代规则

TUN 通过虚拟网络接口和路由安排，把原本不使用系统代理的流量送入内核。它与 mode 所处层次不同：TUN 负责流量怎样进入，规则负责进入后怎样处理。开启 TUN 后仍可使用规则模式，也仍可能因为路由排除、接口选择或权限问题而遗漏部分流量。判断接管成功不能只看开关状态，应观察目标程序是否产生对应的内核连接记录。

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

enable 开启虚拟接口，stack 指定网络栈处理方式，auto-route 请求自动配置相关路由，auto-detect-interface 用于自动识别出口接口。mixed 是 mihomo 支持的一种栈选项，不代表任何操作系统上都最合适；其他栈的可用性与具体行为应以当前内核和平台为准。排错时每次只更换一个栈选项，保留日志对照，避免把路由变化与栈变化混在一起。

DNS 劫持与加密 DNS 的边界

dns-hijack 中的 any:53 用于接管进入该路径、目标为常规 DNS 端口的查询，再交给内核 DNS 处理。它不是通用的加密 DNS 拦截器。应用通过 HTTPS 发起的 DNS 查询看起来像普通加密连接，不会因为目标不在该端口就被这项规则自动转换。若浏览器开启独立解析功能，排查时应先确认查询实际路径，而不是反复修改内核上游。

TUN 与 DNS 模块通常需要配合，但二者的开关并非同一个开关。DNS 模块没有启用、监听冲突或上游不可达时，可能出现流量已接管却无法解析的情况。反过来，DNS 返回成功也不能证明业务路由正常。可以分别测试一个已知地址的连通性与一个域名的访问，把“地址连接失败”和“名称解析失败”拆开，再进一步检查策略、出口和路由。

不同平台的权限与路由冲突

桌面系统通常需要管理员权限、特权服务或相应系统授权才能创建接口和调整路由。客户端可能代为管理这些能力，直接修改 YAML 无法取代系统授权流程。Android 客户端一般借助 VpnService 获取接管能力，系统显示的 VPN 授权与桌面虚拟网卡实现并不完全相同。iOS 客户端则通过自身支持的网络扩展机制工作，不应把桌面字段逐项照抄到移动端界面。

企业 VPN、虚拟机网络、容器网桥与其他代理工具都可能同时修改路由。自动检测选中了不合适的接口时，可能发生绕行或回环。先退出其他网络接管工具，保存当前路由信息，再单独开启一个客户端进行测试。确需并行使用时，应明确哪些网段交给企业 VPN，哪些流量交给代理内核；不要依靠反复重启碰运气，否则下一次网卡顺序变化后故障还会出现。

启用更严格的路由约束可能改变局域网访问、热点共享和其他 VPN 的行为，不能把相关开关当作通用修复按钮。应先建立最小可用 TUN 配置，再根据已确认的问题增加排除项或平台选项。休眠唤醒、网络切换后，还要检查系统代理和虚拟接口是否恢复到预期状态。具体开启步骤见TUN 原理与接管步骤；Android 后台被系统停止时，可查阅VpnService 与省电白名单说明，这类问题不一定来自 YAML。

八、覆写、合并与运行时验证

先确认配置来源，再定义合并规则

覆写是客户端在加载订阅或本地配置时，对部分字段进行替换、补充或重组的过程。它不是 YAML 语言自动提供的统一功能，也没有所有 Clash 客户端共同遵守的合并顺序。同一个界面名称，在不同客户端中可能分别表示浅层替换、递归合并或脚本处理。修改前先查看该客户端的覆写说明，确认入口针对当前配置还是全部配置，以及订阅更新后是否继续执行。

映射和列表尤其需要分开看。递归合并 DNS 对象，可能保留未修改的上游字段；整对象替换则会删除原对象中的其他设置。规则列表若采用替换，会丢失订阅原有分流；采用追加，又可能因为原有 MATCH 已经提前兜底而永远无法命中。节点与策略组列表还涉及名称引用，不能简单把两份文件拼接后认定结果有效。

# 原配置中的 DNS 对象
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

# 希望通过客户端覆写的字段片段
# 这是另一份输入，不应原样追加成第二个 dns 键。
# dns:
#   ipv6: false

上例想得到的结果，是在原 DNS 对象中增加 ipv6: false，而不是删除原有的启用状态、解析模式和上游。具体能否这样合并，取决于客户端实现。保存后必须打开运行时预览，看四个字段是否同时存在。若客户端只支持整段替换，就应在覆写对象中明确写出需要保留的字段，避免靠隐含行为维持网络可用性。

订阅更新与本地修改的保存位置

直接编辑订阅下载的缓存文件，往往会在下一次更新时被远端内容覆盖。更稳定的做法是把个人规则、DNS 偏好和端口安排放进客户端支持的持久覆写入口，或者维护独立本地配置，再通过提供者引用远程节点。两种方法各有成本：前者依赖客户端的合并机制，后者需要自行管理策略组和规则。选择之前应明确哪些字段由订阅维护，哪些字段由本地维护。

对节点或策略组进行重命名时，要把名称当成跨段引用的接口处理。先生成最终节点和组，再核对规则目标；删除对象前，搜索它是否仍被其他组引用。订阅转换服务还可能重建名称、规则和分组，因此转换前后的文本不是同一份结构。涉及敏感订阅地址时，优先使用可信的本地处理方式，并在分享配置前删除地址中的认证信息。

语法测试、加载确认与连接复测

具备命令行内核时，可使用测试参数检查配置是否能被当前二进制读取。测试必须使用与客户端实际相同的内核和相关数据目录；另一份可执行文件测试通过，不能证明图形客户端的内核也支持这些字段。包含提供者文件和地理数据时，还要确认测试环境能访问这些依赖。测试结果用于发现配置问题，不会替代真实网络连接验证。

mihomo -t -f ./config.yaml

验证过程可分成四步：先保存备份并完成语法测试，再通过客户端重新加载配置，接着检查日志是否明确接受新配置，最后关闭旧连接并测试一个目标。查看运行时文件能确认字段是否保留，查看连接记录能确认规则和出口是否符合预期。若只按保存按钮却没有触发加载，或当前配置并不是正在编辑的文件，网络表现自然不会变化。

保留一个修改记录很有帮助：写下本次改变的字段、期望结果、实际结果和恢复方法。每轮只处理一个层次，验证通过后再继续。详细日志仅在排查期间开启，分享前移除订阅凭据、服务器认证内容和不必要的访问记录。若客户端状态本身异常，可回到使用指南重新核对导入、模式和连接步骤；需要替换客户端时，再到安装包页面选择对应平台，而不是把全部问题都归结为配置文件损坏。