Clash 配置字段参考
YAML 与运行配置

一、YAML 结构与配置边界

mihomo 读取的是结构化配置，不是按行执行的命令。一个文件通常以映射作为根节点，下面分别放置通用字段、DNS 设置、代理节点列表、策略组列表和规则列表。字段在文件中的书写先后通常不决定生效优先级，但列表顺序可能直接改变行为。最明显的是规则列表：内核从上向下匹配，因此不能把它当作可任意排序的说明清单。

映射、列表与缩进

映射使用冒号表达字段与值，列表使用短横线表达多个元素。缩进必须用空格，建议每一级固定两个空格；不要混入制表符。同一级的字段保持对齐，子字段缩进到父字段内部。冒号后需要分隔空格；英文标点不能替换成全角冒号或中文逗号。编辑器显示的行号并非一定是根因所在，上一行缺失的引号也可能让解析器到下一行才报错。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

proxies: []

proxy-groups:
  - name: 默认出口
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,默认出口

这份示例可作为理解结构的起点，所有流量最终选择直连，不会凭空提供代理连接。proxies: [] 表示一个空列表，和把字段留成空值不同。根节点下的 dns 是映射，nameserver 是它内部的列表。策略组列表中的每一项又是映射，因此同一个文件会交替使用这几种结构。复制示例时应保留完整层级，而不是只复制看起来相关的一行。

字符串类型与引用关系

密码、名称、路径和带特殊字符的值建议使用引号，尤其要留意数字外观的密码、井号、冒号和反斜杠。井号在普通标量中可能开始注释，Windows 路径放在双引号内还可能触发转义处理；使用正斜杠路径或正确的单引号字符串通常更容易检查。布尔字段写为 true 或 false，不要为了统一外观而给所有值加引号，否则可能把布尔值变成字符串。

节点名、策略组名和规则中的目标名形成引用关系。规则引用一个组时，必须与组的 name 完整一致，包括空格和大小写。名称中尽量避免逗号，因为传统规则格式依靠逗号分隔参数。删除某个节点或重命名策略组之前，先搜索它在其他组和规则中的引用；解析成功不等于所有引用都能建立，后者通常会在配置验证或加载时暴露。

源文件与最终运行配置

订阅原文、客户端本地设置和内核实际加载的文件是三个不同对象。客户端可能在启动时重新写入端口、DNS 或 TUN 字段，也可能对订阅追加规则。直接编辑临时运行文件，下一次刷新或重启就可能被覆盖。应先找到客户端的配置管理、覆写或合并入口，确定修改保存在哪一层，再查看最终生成结果。若界面没有导出运行配置的入口，可结合日志与受保护的控制接口核对关键字段。

局部示例只解释对应字段。除本章的结构起点外，不要把后续片段直接当作完整配置启动；先确认引用的节点、策略组和提供器已在同一份最终配置中定义。

YAML 锚点可以减少重复，但合并键主要用于映射，不应期待它自动拼接两个规则列表。对初次维护的配置，显式书写比复杂复用更利于排错。也不要在同一层重复定义 dns 或 rules 来表达追加：不同解析器对重复键的处理可能不同，可靠做法是整理成唯一字段，再交由明确的合并流程处理。

二、端口、模式与网络接管

通用字段决定内核如何接收连接、如何选择出站，以及是否开放局域网访问。修改之前先区分三条路径：应用主动连接代理监听端口，系统代理把遵循系统设置的应用引向该端口，TUN 则通过虚拟网络接口接管路由范围内的流量。这些路径可以共存，但出现异常时应分别验证，避免同时启用多个接管机制后无法判断问题位于哪一层。

监听端口与访问范围

没有兼容性需求时可以仅配置混合端口。多个监听器必须使用不同端口，不能让 port 和 mixed-port 同时占用相同的地址与端口。端口变更后，手动填写代理的浏览器、终端和其他设备不会自动跟随修改。若日志提示地址已被使用，先确认是否还有另一个 Clash 客户端、旧内核进程或本机服务占用监听端点，而不是连续更换端口掩盖进程冲突。

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

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

上例把 TUN 明确关闭，用来先验证应用显式代理路径。需要启用时再将 tun.enable 改为 true，并确认客户端具备创建虚拟网卡和修改路由的权限。stack 的可用取值与平台、内核能力有关，不能单凭某个取值名称推断兼容性。客户端也可能自行管理这些字段，手工填写后仍需检查最终运行配置。

规则、全局与直连模式

mode: rule 使用规则列表决策；全局模式把流量交由全局策略处理；直连模式主要用于排查是否为代理链路故障。切换全局模式不代表所有流量必然经过远端节点，因为全局策略仍可能选中 DIRECT。修改模式后应同时确认实际选中的组成员。已有长连接也可能保留原来的出口，验证时要建立新请求，必要时关闭相关连接后重试。

局域网共享需要监听配置、主机防火墙和网络拓扑共同允许。只修改 allow-lan 不保证其他设备可以连接；对端还要使用主机的局域网地址，而非自己的回环地址。开放监听前应评估所在网络是否可信，并按需配置代理认证。代理认证保护的是代理入口，不等同于控制接口的访问凭据，二者不能互相替代，更不应把控制接口直接开放到公共网络。

TUN 与 IPv6 的边界

auto-route 用于自动配置相关路由，auto-detect-interface 用于辅助确定出口接口。它们不能消除所有多网卡、虚拟机或其他 VPN 的冲突。发生连接循环时，应检查代理服务器自身的出站是否被再次接管，以及其他软件是否持续重写默认路由。桌面系统的服务权限与移动系统的 VPN 授权不是同一机制，不能把一个平台的权限处理步骤原样套用到另一个平台。

顶层 ipv6 与 dns.ipv6 处在不同控制层级，前者影响内核的 IPv6 使用，后者影响 DNS 的 AAAA 解析行为。排错时应同时记录系统是否具有可用 IPv6 路由、节点是否支持相应出口，以及 DNS 是否返回 IPv6 地址。只关闭其中一个开关，不能据此断定整个连接路径都已经改为 IPv4。字段调整应以连接记录和实际解析结果为依据。

三、DNS 与 Fake-IP 字段

DNS 配置既影响目标域名解析，也可能影响代理服务器地址解析。需要先分清系统向谁提问、内核使用哪个上游、上游域名如何获得初始地址，以及查询通过哪条出口发送。页面能否打开并不足以证明 DNS 路径符合预期，因为应用可能使用缓存，也可能内置加密 DNS。排查应从一条新查询开始，并分别观察应用、系统与内核的解析行为。

监听、上游与初始解析

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:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.com":
      - https://dns.alidns.com/dns-query

enable 启用内核 DNS 模块，listen 设置服务监听端点。示例的回环地址和非标准端口仅用于本机调用，系统不会因为这个字段存在就自动把所有 DNS 请求送到这里。实际接管可以由客户端、系统 DNS 设置或 TUN 的 DNS 劫持完成。TUN 中的 any:53 也不代表能够接管应用自行发往任意加密 DNS 服务的请求，后者通常是普通加密连接。

nameserver 指定常规查询上游，default-nameserver 用于需要初始解析的场景，例如先解析加密 DNS 服务的域名。proxy-server-nameserver 则用于代理服务器域名解析，能够减少节点域名依赖代理连接、代理连接又依赖节点域名的循环。示例使用公共解析服务，实际选择应依据网络可达性和隐私要求；切换上游时，先验证它本身在当前网络能够访问。

Fake-IP 与真实地址解析

Fake-IP 模式向应用返回地址池中的合成地址，内核保留该地址与域名的映射，在接管后续连接时恢复域名信息并执行规则。这有助于保留基于域名的决策上下文，但前提是应用获得的合成地址与连接流量都经过同一套内核处理。若请求绕过内核直接访问合成地址，或内核重启后应用继续使用旧缓存，就可能出现连接失败，而不是某个节点本身不可用。

fake-ip-filter 用于让特定域名不使用合成地址。示例列出局域网常见名称后缀，但过滤条目并不会自动让公共上游知道内网记录；必要时还要通过解析策略指定内网 DNS。不要为了修复一个局域网设备就把所有域名都放进过滤列表，否则会改变原本的域名恢复路径。应先确认失败域名，再增加最小范围条目，最后清理应用和系统缓存进行复测。

redir-host 向应用返回真实解析地址，连接阶段再结合已有信息处理分流。它与 Fake-IP 的主要区别在于地址返回与域名关联方式，不能简单理解为一种更快、一种更安全。依赖真实地址展示、特殊局域网发现或应用内部地址检查的场景，需要结合接管方式实测。进一步的原理说明见Fake-IP 与 redir-host 的区别。

解析策略与流量策略分开检查

nameserver-policy 根据域名选择解析上游，规则列表则根据连接信息选择出站。域名交给某个 DNS 服务器解析，并不意味着访问该域名时就会使用同一条代理策略。若需要让 DNS 上游连接也遵循规则，可研究 respect-rules，但启用前应保证代理服务器域名有独立可用的解析路径，并检查上游自身的域名不会形成依赖环。不要一次叠加多个机制后再猜测实际查询方向。

DNS 结果变化后，已有连接、应用缓存和系统缓存可能继续保留旧状态。测试时使用新请求，并记录查询域名、返回地址、命中的解析策略及最终出站，避免把缓存差异误判为配置未生效。

配置 fallback 时还应阅读对应的过滤条件；它不是一个简单按列表顺序逐个尝试的备用服务器清单。涉及地域判断时，地理数据库的可用性也会影响结果。对于刚接触配置的用户，优先保持一个明确可达的常规上游和独立的节点解析路径，确认工作后再引入复杂策略。若解析超时，先区分上游不可达、初始解析失败与流量接管缺失，不要直接更换全部 DNS 字段。

四、代理节点与协议参数

proxies 是内联代理节点列表，每个元素描述一个可供策略组引用的出站。节点至少需要唯一名称、协议类型，以及该协议要求的服务器和认证信息。协议字段不能随意互换：同样写着密码，Shadowsocks 的加密方法、Trojan 的 TLS 参数和其他协议的用户标识也不是等价结构。应以服务端给出的参数为基准，而不是从不同教程里拼接看起来相似的行。

基础字段与完整协议上下文

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

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

示例中的保留域名与教学密码不能用于实际连接，必须替换为服务提供者给出的完整参数。server 可以是域名或地址，port 是远端服务监听端口，与本地 mixed-port 没有对应关系。name 是本地引用标识，不参与远端认证。名称修改可以改善组内可读性，但必须同步调整使用该名称的策略组，否则节点存在也无法被正确选中。

Shadowsocks 的 cipher 必须与服务端一致，认证失败通常不能通过修改 DNS 解决。Trojan 一般基于 TLS，sni 用于 TLS 握手中的服务器名称，不能仅因为连接超时就改成任意可访问网站的域名。若服务器通过地址连接而证书签发给域名，应根据实际服务参数填写名称。这里的地址、端口、认证和 TLS 身份属于不同层次，应分别检查。

TLS、传输层与 UDP

skip-cert-verify: false 保持证书验证。证书错误需要检查系统时间、证书链、名称是否匹配，以及连接是否确实到达预期服务器。直接关闭验证可能让错误表面消失，却无法证明连接身份正确。某些协议通过 tls 开启 TLS，另一些协议本身就包含 TLS 语义，不能假设所有类型都接受同一套开关；未知或错层字段也可能被忽略，而不是立即报出明显错误。

使用 WebSocket、HTTP/2 或其他传输方式时，传输选项必须与服务端部署一致。WebSocket 路径通常放在 ws-opts.path，需要额外请求头时放在相应的 headers 映射中。连接地址、TLS 的服务器名称、HTTP 的 Host 头和请求路径可能不同，但这种差异应来自真实部署，而不是随意混用。仅把节点类型改正确，仍不足以补齐传输层要求。

udp: true 表示允许节点处理相应 UDP 流量，不会让一个本身不支持 UDP 的服务端获得此能力。若网页正常而语音、游戏或 QUIC 连接失败，应分别检查应用接管路径、内核协议支持、远端服务和网络中间设备。关闭某个应用的 QUIC 只能作为定位手段，不能证明 UDP 已经恢复。测试结果还应区分 UDP 转发与 DNS 请求，两者可能采用完全不同的出口。

节点导入与敏感参数处理

订阅中的节点不一定直接出现在 proxies 中，也可能通过代理提供器动态加载。原始分享链接、编码节点集合和完整 Clash 配置是不同格式，不能只改文件扩展名就当作 YAML 使用。若导入报错，先检查返回正文是否为登录页、错误页或不兼容的格式，再检查具体协议字段。相关定位顺序见订阅导入失败与解析错误自查。

分享配置片段前，应移除服务器身份信息、密码、用户标识、订阅地址及可能附带的访问参数。即使节点名称没有敏感性，完整订阅链接也可能具有账户访问能力。排错时保留字段名、层级、协议类型和错误文本通常已经足够，不必公开认证值。对自动更新的订阅，不建议直接长期维护内联节点副本；应保留订阅作为源，在客户端支持的覆写层表达本地规则和组选择需求。

节点名称重复会让引用含义变得不明确，尤其在多个订阅合并后更常见。导入第二个来源前，先检查是否存在同名节点、同名策略组及相同提供器路径。若客户端提供名称前缀或筛选功能，可在来源边界统一处理，而不是逐个手工改名。配置维护的目标是让来源、认证参数和策略引用彼此分离，更新其中一项时不必重新编辑其他所有部分。

五、策略组与代理提供器

策略组把节点或其他策略组组织成可被规则引用的出站目标。它解决的是如何选择出口，而不是如何判断一条连接属于哪个业务。一个常见结构是：规则指向业务组，业务组再选择手动组或自动组，自动组从提供器中取得节点。这样的层级可以减少节点变化对规则的影响，但层级不能形成循环，否则无法得到确定的最终出口。

手动选择与自动测试

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

proxy-groups:
  - name: 自动出口
    type: url-test
    use:
      - 本地节点
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 50

  - name: 默认出口
    type: select
    proxies:
      - 自动出口
      - DIRECT
    use:
      - 本地节点

这里的 providers/local.yaml 需要实际存在，其根节点应包含 proxies 列表，内部写真实节点；前章的教学节点只能用于检查结构。路径通常相对于内核工作目录解析，客户端也可能进一步限制文件访问范围。找不到文件时，应先确定实际工作目录，而不是默认认为相对于当前编辑文件。文件提供器适合解释引用关系，远程订阅则通常使用 HTTP 类型并提供更新地址。

select 由用户手动选择成员；url-test 根据测试结果选择可用出口；fallback 侧重按成员顺序寻找可用出口；load-balance 则按所选策略分配连接。自动测试只能反映到测试目标的表现，不代表所有网站、流媒体或业务服务的可用性。测试目标应稳定可达，且尽量避免把需要特定登录状态的页面作为健康检测依据。

间隔、容差与组内成员

interval 的示例单位是秒，tolerance 表示自动选择时的延迟容差，示例值以毫秒计。容差有助于避免结果轻微波动时频繁切换，但不能修复节点不稳定或测试目标选择不当。健康检测也会产生真实网络请求，大型订阅不宜盲目使用很短的间隔。客户端可能在后台或休眠时调整任务执行，不能把界面更新时间直接当作每个检测请求都准时发生的证据。

proxies 列出显式成员名称，use 引用代理提供器名称。两者可以出现在同一个组中，但含义不同：前者引用已知节点或组，后者引入提供器中的节点集合。提供器健康检查与策略组测试也处在不同层次，虽然可以使用同一测试地址，仍不应把两者的结果和时机完全等同。出现组为空时，先检查提供器加载结果，再检查筛选条件，不要直接归因于全部节点失效。

嵌套组必须保持有向、无循环的关系。例如业务组可以引用默认出口，默认出口可以引用自动出口，但自动出口不应再引用业务组。过多嵌套还会让界面中的当前选择难以解释，维护时可先画出规则目标到最终节点的引用链。若规则命中正确却仍然走直连，要检查链条中的每一级是否允许并选中了 DIRECT，而不是只看最外层组名。

远程提供器与更新持久化

HTTP 类型的提供器通常需要 url、path 和更新间隔。订阅地址属于访问凭据的一部分，不应放入公开仓库或公开日志。缓存路径要保持唯一，不同来源共用一个路径可能互相覆盖。自动更新失败时，还应区分远程请求失败与本地缓存是否仍可使用；界面里仍有节点并不表示最新订阅已经拉取成功，也不代表缓存中的节点仍然有效。

如果使用名称筛选，应检查正则表达式的匹配范围、大小写以及提供器更新后的名称变化。筛选规则命中零项会造成自动组没有候选节点，继续缩短测试间隔没有帮助。建议先取消筛选确认节点能够加载，再逐步缩小范围。保存组选择需要客户端或内核的相应持久化机制，例如 profile.store-selected；它保存的是选择状态，不会替代订阅更新或把已删除节点重新创建出来。

策略组名称稳定、节点来源可更新，是比复制整份订阅更容易维护的结构。将本地规则指向稳定组名，再通过提供器更新节点，可以减少订阅变动对规则的连带影响。

六、规则语法与匹配顺序

在规则模式下，rules 是按顺序执行的匹配列表。每条规则通常由类型、匹配内容和目标构成，部分类型还支持附加参数。第一条匹配成功的规则决定出站，后面的规则不再继续竞争。因此规则维护首先是顺序设计，其次才是规则数量。把大量规则集合接入配置，并不会自动让分流更准确；重叠条件和过早出现的宽泛匹配反而容易掩盖原本的细分策略。

域名、地址与兜底

rules:
  - DOMAIN,printer.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,默认出口
  - 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 匹配目标 IPv4 地址范围，IPv6 范围使用相应的 IP-CIDR6。no-resolve 用来避免仅为评估这类规则而主动触发域名解析；它并不表示整条连接永远不需要 DNS，也不意味着已有真实目标地址时不能匹配。私网直连规则同样依赖连接上下文，尤其在 Fake-IP 模式下，不应把合成地址直接当作应用最终访问的真实服务器地址。

规则集合与行为类型

rule-providers:
  本地域名:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,本地域名,DIRECT
  - MATCH,默认出口

这个片段需要一个实际存在的规则文件，其内容可以是下例。域名行为的规则集合只写域名条目，不在条目后追加策略组；策略目标由主配置中的 RULE-SET 规则指定。classical 行为则使用带规则类型的条目，ipcidr 行为用于地址段。行为类型、文件格式和实际正文需要一致，不能把一种集合下载后仅改文件名就交给另一种行为读取。

payload:
  - "+.example.com"
  - "printer.example.org"

RULE-SET 中的提供器名称必须与 rule-providers 的键一致，不是本地路径，也不是远程 URL。多个集合重叠时，仍按主规则列表中的位置决定优先级。HTTP 类型规则提供器还涉及缓存与更新，排查时应同时记录当前加载的规则条目和更新时间。远程更新成功只证明资源获取完成，并不能证明业务域名确实包含在集合里。

进程规则与平台差异

进程名称、进程路径及应用标识相关规则依赖平台和权限，也依赖内核能否获取连接所属进程。不能因为桌面系统上进程规则命中，就假设移动系统一定提供相同的进程信息。若日志里没有预期进程字段，先检查运行权限与客户端支持情况。对跨平台配置，域名和地址规则通常更容易保持一致；进程规则适合作为经过实测的补充条件，而不是唯一分流依据。

GEOIP 或地理域名集合依赖相关数据库和加载方式，数据库缺失、来源变化或更新失败都可能影响匹配。规则未命中时，应先确认目标信息和资源状态，再讨论规则写法。不要把某个域名解析到的单个地址永久当成业务唯一地址，CDN、区域解析和服务迁移都可能让地址变化。需要精准控制的业务优先维护域名边界，并通过连接记录验证实际请求涉及的其他域名。

MATCH 是兜底规则，通常放在最后；放在前面会让后续条目无法获得匹配机会。自定义例外应放在会覆盖它的集合之前，但不必机械地永远置于第一行。每次变更后建立一条新连接，查看规则类型、命中内容、策略组和最终节点。若命中结果正确而访问失败，应转向节点或 DNS 排查，而不是继续添加重复规则。规则决策与链路可用性是两个需要分别验证的问题。

七、订阅覆写与配置合并

订阅通常由外部来源维护，本地需求则包括监听端口、局域网设置、DNS、额外规则和策略组选择。覆写机制的作用是把这些本地需求保存在独立层，在订阅更新后重新应用。它不是直接修改订阅服务器上的内容，也不是 YAML 自带的一套统一标准。不同客户端对映射、列表和空值的处理可能不同，因此先确认合并规则，再决定覆写片段应写成完整对象还是局部字段。

先识别字段的所有者

端口和 TUN 常由客户端设置页面管理，节点和提供器通常来自订阅，业务规则可能来自订阅与本地追加的共同结果。如果同一字段被两层管理，最终生效的值取决于配置生成顺序。不能仅凭界面中的某个开关就断言源文件已被修改，也不能凭源文件里写着一个值就断言运行时没有被覆盖。应把源订阅、本地覆写和最终运行文件并排核对，记录每个关键字段的来源。

映射合并与列表替换

以下是一个局部覆写片段，目的只是调整 DNS 与日志。它是否保留原订阅中的其他 DNS 字段，取决于客户端采用递归合并还是整体替换。若采用整体替换，遗漏 nameserver 可能让 DNS 配置不完整。部署前应先导出或查看合并结果，而不是用是否保存成功判断结果正确。某些客户端提供单独的 DNS 覆写开关，开启后还可能使通用覆写中的同名字段不再成为最终来源。

# 局部覆写示例；合并语义由客户端决定。
log-level: info
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

列表比映射更需要谨慎。把一个只含两条规则的 rules 列表写进通用覆写，可能替换整个订阅规则，而不是追加两条。把策略组列表写进去也可能删掉订阅原有组，进而使大量规则引用失效。优先使用客户端明确区分的前置规则、后置规则或专用合并入口；如果只有整体替换机制，就需要维护完整列表，并承担订阅结构变化后的同步责任。

规则追加还存在位置问题。原订阅末尾通常已有 MATCH，直接在它后面加入域名例外不会被执行。要实现例外，通常需要把条目插入相关宽泛规则之前。与此同时，若例外目标是一个本地新组，必须先保证该组和成员来源都能生成。规则、组、提供器是完整引用链，只保存其中一段，无法构成可执行的本地定制。

客户端差异与更新后的复核

Clash Plus、Clash Verge Rev、FlClash 等客户端对订阅配置的管理入口不同，同一个片段不能未经检查就跨客户端复用。应寻找与配置管理、覆写、规则追加或运行配置相关的入口，先读取其说明，再用一个不影响连通性的字段测试合并方式。例如只调整日志等级，确认运行时变化后，再加入一条可观察的域名规则，最后才涉及 DNS 与接管路径，便于明确是哪一层产生差异。

更新订阅前保存本地覆写和可用配置副本，但不要把包含凭据的副本上传到公开位置。更新后重点复核稳定组名是否仍存在、提供器是否改名、节点筛选是否为空以及规则目标是否有效。订阅内容变化不只是节点新增或删除，也可能调整组层级和规则资源。若更新后失效，比较前后结构通常比反复重新导入更有效；初次启动相关检查见首次安装与初始设置清单。

不要直接维护客户端生成的临时运行文件。将持久需求保存在客户端认可的覆写层，保留可回退副本，并在一次订阅刷新后再次确认修改仍然存在。

YAML 中的 & 锚点、别名和映射合并不能代替客户端的跨文件合并流程。它们只在解析当前 YAML 文档时复用结构，无法自动知道外部订阅应该如何更新。也不要依赖重复顶层键实现覆盖，或假定空对象总能清除旧配置。可维护的覆写应尽量小，明确声明要改变的字段，并为每次改变保留一个可观察的验证步骤。

八、配置验证与故障定位

配置排错应按文件解析、引用建立、监听启动、DNS、出站连接和规则决策分层进行。每层都有不同的失败信号，不能把所有问题归为订阅失效。加载失败时先处理语法与字段；加载成功但没有流量时检查接管；有流量但解析失败时检查 DNS；解析成功但远端连接失败时检查节点；连接可用但出口不符合预期时检查规则与组选择。按这个顺序能够减少无关修改。

静态检查与内核验证

在客户端外维护文件时，先使用编辑器的 YAML 检查功能定位缩进、引号和重复键。通用 YAML 解析成功只说明语法成立，不代表协议字段和引用合法。还需要用实际运行的 mihomo 内核验证配置，尽量保持与客户端使用的内核一致。若改用另一个内核验证，字段支持差异可能产生误导。客户端没有提供内核命令入口时，不要为了验证而随意替换程序文件。

# 在独立测试目录中检查；路径按实际文件位置填写。
mihomo -t -d ./mihomo-check -f ./config.yaml

# 使用显式 HTTP 代理检查监听与基础请求路径。
curl -I --proxy http://127.0.0.1:7890 https://example.com

# 由代理端解析目标域名，检查 SOCKS 请求路径。
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

# 检查本文示例中的本地 DNS 监听。
nslookup example.com 127.0.0.1

最后一条 DNS 命令使用系统工具的默认 DNS 端口，并不直接查询前文的 1053。如果没有在本机标准端口部署 DNS 服务，应改用支持指定端口的工具，例如下例。这个区别很重要：向错误端口发起查询后超时，不能说明内核配置的上游不可达。命令是否可用取决于操作系统和已安装工具；终端中还应确认调用的是实际的 curl 程序。

dig @127.0.0.1 -p 1053 example.com A

-t 用于测试配置，-d 指定工作目录，-f 指定配置文件。配置引用的相对路径资源需要在对应工作目录下可用，测试阶段缺少提供器文件并不等同于 YAML 有语法错误。正式运行客户端时也要检查其工作目录是否不同。不要同时启动第二个占用相同代理端口的内核进行测试，否则会制造新的端口冲突，掩盖原始问题。

通过新连接检查决策链

先用显式代理请求验证监听和基础出站，再启用系统代理，最后验证 TUN。这样可以将应用是否遵循系统代理与内核本身是否可用分开。HTTP 请求成功也不能证明 UDP、IPv6 或所有应用正常，需要按实际业务分别测试。SOCKS 的域名由本地解析还是代理端解析会影响诊断含义，示例中的 socks5h 用于让代理端处理目标域名，便于与本地解析路径作对照。

观察连接记录时，依次核对目标域名或地址、命中的规则、外层策略组、嵌套组选择和最终节点。修改规则或组选择后建立新连接，不要只刷新一个可能复用连接的页面。若客户端提供连接关闭功能，可针对测试连接重建，但不要在未保存工作时批量中断所有业务。DNS 相关变更还要考虑缓存；Fake-IP 地址变化后，应用使用旧缓存可能产生与新配置不一致的现象。

日志分级与最小回退

日常使用保持适度日志等级，定位问题时临时提高详细程度。先看首个导致失败的错误，再看后续连带信息，例如远端域名解析失败可能导致后面所有拨号都超时。端口占用通常发生在启动阶段，TLS 身份错误发生在远端握手阶段，二者没有相同修复方法。具体字段阅读可参考mihomo 常见日志报错与定位顺序，分享日志前先移除认证和订阅信息。

每次只改一类变量，并记录修改前取值、修改理由和测试结果。出现问题时先回退最近变更，而不是同时重装客户端、更换订阅和改 DNS。若最小直连配置能运行，而完整配置不能，按模块逐步恢复提供器、策略组、规则和接管功能，首次失败的模块通常就是进一步调查的边界。最小配置可运行只证明基础环境可用，不代表被移除的远端节点一定正常。

最终验收至少包含一次重载、一次客户端重启和一次订阅刷新，分别确认配置能够解析、持久设置能够恢复、覆写不会被更新抹除。再检查局域网监听范围、控制接口访问范围和日志等级是否回到预期状态。需要重新梳理操作顺序时返回入门指南；需要更换客户端时到安装包页面按系统选择。将可用状态保存为本地基线，后续维护才有明确的回退起点。