配置字段 · mihomo

Clash 配置文件
YAML 与字段参考

按结构查字段，按连接路径排错。先区分配置来源，再调整节点、策略组与规则。

本页面向已经导入配置、需要理解 config.yaml 的用户。首次安装、导入订阅和启用系统代理，请先按使用文档完成快速上手，再返回这里查阅具体字段。示例以 mihomo 常用语法为基础；客户端界面名称、内核能力和最终生成配置可能不同，应结合运行日志确认实际结果。

一、YAML 结构与配置加载

顶层字段：先分清对象与列表

Clash 配置通常是一个 YAML 映射。mixed-port、mode 属于标量字段，dns 是嵌套映射，proxies、proxy-groups、rules 则是列表。先识别这几类结构，再看具体参数，能够避免把节点写进策略组、把规则放进 DNS 下面这类层级错误。

缩进表达从属关系，建议统一使用两个空格，不使用制表符。列表项以短横线和空格开头；同一项中的字段需要对齐。编辑器看起来排齐，不代表实际字符一致，粘贴配置后应打开空白字符显示。中文标点也会造成问题，字段后的冒号、规则中的逗号都必须使用半角字符。

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

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

这份骨架可以表达完整的引用关系，但只提供直连路径：最后一条规则指向 Proxy，该组内只有 DIRECT。它适合检查基本结构，不会凭空生成代理节点。实际接入时，再添加服务方提供的节点，或通过提供者加载节点列表，不要把结构示例当作可用订阅。

字符串、布尔值与重复键

端口一般写成整数，开关写成 true 或 false。名称、密码和含特殊符号的字符串可以加引号，尤其是含冒号加空格、井号或看似布尔值的内容。双引号字符串会解释部分转义字符，包含反斜线时要格外注意；无法确认时，先对照服务方提供的原始值，不要随意转换字符。

注释从字符串之外的井号开始，适合记录修改原因，却不参与内核配置。相同顶层键不要重复声明两次，例如先写一个 dns，文件末尾又写另一个 dns。不同解析器可能报错，也可能保留其中一份。正确做法是把需要的子字段归入同一个对象，而不是依靠后写覆盖前写。

YAML 能被解析，只说明语法成立，不代表字段受当前内核支持。一个拼错的字段可能没有产生预期效果，一个存在的策略组也可能引用了不存在的节点。检查需要分成三层：文本能否解析、内核是否接受、连接是否按预期走向。把这三层混在一起，容易把引用错误误判为网络故障。

配置来源与测试顺序

客户端中的订阅原文、本地编辑内容、覆写结果和内核运行配置，可能是四份不同的文本。排查前先确认当前启用的 Profile，再查看客户端是否应用了合并或脚本处理。界面里看到修改已经保存，并不等于运行中的内核已经重新加载；必要时执行客户端提供的重新加载操作，然后查看日志。

如果直接运行 mihomo，可用下面的命令检查指定文件；图形客户端则优先使用配置检查、运行日志或错误提示。命令中的配置路径应指向准备测试的文件，而不是另一个目录里的同名文件。测试通过后再启用，避免直接覆盖唯一可用配置，导致后续排查失去对照。

mihomo -t -f ./config.yaml

建议每次只修改一个层面：先确认骨架能加载，再增加节点，随后配置策略组，最后调整规则与 DNS。发生错误时退回上一份有效文件，比同时修改几十个字段更容易定位。多份配置的命名与切换，可继续阅读Profile 与本地配置管理。

二、端口、模式与通用字段

监听端口：明确入口协议

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

字段	用途	检查重点
`port`	HTTP 代理入口	应用是否使用 HTTP 代理协议
`socks-port`	SOCKS 代理入口	应用是否支持对应代理方式
`mixed-port`	合并 HTTP 与 SOCKS 入口	客户端与应用端口是否一致
`allow-lan`	控制局域网接入	监听范围、认证与防火墙

运行模式：入口接管与出站选择分开看

mode: rule 按规则列表选择策略；global 使用全局策略；direct 以直连为主。模式只决定已经进入内核的连接如何处理，不负责让所有应用自动进入内核。系统代理、应用内代理和 TUN 才属于流量入口这一层，不能用切换运行模式代替入口配置。

例如浏览器已经走代理，而某个命令行工具仍然直连，优先检查该工具是否读取系统代理或需要单独设置环境变量。相反，连接已经显示在客户端面板中，却走到了错误策略，才应检查模式、规则和策略组。先看连接有没有进入内核，再看出站选择，能够明显缩小排查范围。

局域网共享需要同时考虑 allow-lan、监听地址、操作系统防火墙和接入设备的代理设置。只把开关改成允许，并不能保证其他设备可连。若确需共享，限制可信网段并配置合适的认证；不要为了省去排错步骤，把代理入口和管理接口一并暴露到公共网络。

日志、持久化与管理接口

log-level 常用 info，临时排错可提高到 debug，定位后再恢复。详细日志可能包含域名、连接目标与路径信息，提交反馈时应先删除敏感内容。单条警告不必然意味着整个客户端失效，应结合出现时间、目标连接和是否能稳定复现来判断影响。

profile.store-selected 用于保存策略组选择，是否能按预期恢复还与客户端的配置切换方式有关。组名、节点名改变后，旧选择可能找不到对应项，表现为回到默认策略。这时应检查订阅更新是否改名，而不是立即重装客户端；保持关键策略组名称稳定，更有利于长期维护。

profile:
  store-selected: true

external-controller 是管理接口，不是给浏览器访问网站用的代理端口。普通用户无需为了连接网络主动开放它。确有面板接入需求时，应使用本机监听或受控网络，并按客户端要求配置认证。把管理端口误填到系统代理里，通常只会得到无法访问或协议不匹配的错误。

顶层 ipv6 与 DNS 下的同名字段作用不同，前者涉及内核的 IPv6 使用，后者涉及 DNS 对 AAAA 查询的处理；它们也都不是操作系统网卡开关。家庭网络、节点出口和目标服务的 IPv6 支持可能不一致，调整前保留原值，逐项测试，不要把所有异常都归因于 IPv6。

三、代理节点字段与协议边界

基础字段：名称是引用入口

proxies 中每一项描述一个具体出站节点。通常先看 name、type、server、port，再看认证与传输参数。名称主要供策略组引用，不是服务器域名；把节点名称改成某个地区，并不会改变出口位置。地区与线路情况仍应以服务方信息和实际连接结果为准。

节点名称应保持唯一，避免与策略组同名，也不要使用 DIRECT、REJECT 这样的内置策略名称。复制节点后只修改了地址，却忘记修改名称，可能导致引用歧义或配置加载错误。服务方频繁更名时，手工引用具体节点的组更容易失效，可考虑通过提供者接入并在组中筛选。

proxies:
  - name: Example-SS
    type: ss
    server: proxy.example.com
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

上面的 Shadowsocks 片段只说明字段关系，地址和密码需要替换为服务方给出的值。cipher 是协议加密方式，必须与服务端一致，不能凭名称相近自行更换。服务器端口也不一定代表常见网站服务，写成四百四十三端口，并不意味着该节点自动使用 HTTPS 或适合浏览器直接打开。

认证与传输：按协议成套核对

不同协议的认证字段不同。Shadowsocks 使用密码与加密方式，Trojan 使用密码并依赖相应的 TLS 设置，VMess、VLESS 常见用户标识字段。字段名不能跨协议照搬。排查认证失败时，应回到原始订阅或服务方文档，核对协议类型、账号标识与附加参数，而不是尝试随机补齐网上找到的字段。

部分协议还会指定传输方式、路径、主机头和 TLS 参数。这些字段需要与服务端部署成套匹配：WebSocket 路径不等同于网站首页路径，HTTP 主机头也不必与连接地址完全相同。不要因服务器能被浏览器打开，就认为代理认证一定正确；网页访问只验证了其中一部分网络条件。

servername 通常用于适用协议的 TLS 服务名。它与 server 可以不同，但这种差异应来自服务端配置，而不是随便填一个能访问的域名。证书相关错误要检查设备时间、服务名和证书链；不应把 skip-cert-verify 当作通用修复方式，否则会跳过重要的服务端身份验证。

UDP、域名解析与节点选择

udp: true 表达节点侧允许相关 UDP 转发能力，但不保证入口、服务端和目标链路都支持。应用是否发出 UDP、系统代理能否接管、节点协议是否支持、服务端是否放行，都需要分别检查。仅有网页访问正常，不能推出语音、游戏或其他实时应用也一定能够工作。

当 server 使用域名时，内核在建立代理连接前，需要先把节点域名解析成地址。这一步发生在访问目标网站之前。如果 DNS 配置又要求通过同一个尚未建立的节点查询，就可能形成依赖循环。遇到所有节点一起无法连接，应先查看节点域名解析是否成功，再判断是否是单条线路问题。

延迟测试成功，说明测试请求在当时完成，并不证明所有目标网站或所有传输方式都正常。选节点时应结合稳定性、目标服务地区、流量倍率和日常使用场景。更详细的比较顺序见节点挑选方法；测试指标的边界可参阅延迟测试与实际体验。

新建配置时，不必一次录入所有协议。先选一个参数齐全、能够确认有效的节点，用手动选择组完成连接，再扩展自动测试或备用线路。需要更换客户端时，可从下载页按系统选择，优先考虑 Clash Plus，并确认所需协议受到当前客户端内核支持。

四、策略组字段与选择逻辑

select：把手动选择集中到一处

proxy-groups 把节点、其他策略组和内置策略组合成可以被规则引用的出站入口。规则只写稳定的组名，节点调整留在组内完成，能够减少重复修改。最常用的 select 由用户选择成员，适合日常手动切换，也适合作为自动组与直连之间的统一入口。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    use:
      - Main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

这段示例依赖后文定义的 Main 节点提供者；单独粘贴而没有提供者，引用不会成立。Proxy 是总入口，用户可以在自动组与直连之间选择。为方便排错，组名应表达用途，例如通用出口、工作服务或媒体服务，而不是只写难以辨认的符号。

proxies 用来列出明确的节点或组名，use 用来引入节点提供者。两者描述的对象不同，不能把提供者名称直接当作普通节点名称填写。组内成员必须在配置中存在，且不能形成循环引用；甲组包含乙组、乙组再包含甲组，不会形成备用链路，只会造成无效结构。

自动组：先理解检测条件

url-test 根据测试结果选择成员，url 是测试请求地址，interval 是周期，单位通常为秒，tolerance 则用于减少因细微差异引起的频繁切换。测试地址应稳定、响应轻量，并能代表需要的基本可达性；不要使用包含账号信息或需要登录的页面。

自动测试不是持续下载测速。结果会受到测试服务器位置、解析方式、连接复用和当时链路状态影响。一个节点访问检测地址很顺畅，也可能对实际工作服务表现一般。若组选择反复变化，先检查线路波动和测试条件，再适度调整容差，不要仅靠缩短周期追求看起来更及时的数字。

fallback 更关注按成员顺序选择可用路径，适合有明确主备关系的场景。需要注意，主线路能打开检测地址但无法访问某个特定服务时，检测仍可能判定它可用。主备策略能减少部分故障影响，却不能替代针对目标服务的规则和可达性验证，组名也不应暗示绝对可用。

load-balance 按相应策略为连接分配成员，并不表示把一条下载连接拆到多个节点上叠加带宽。对登录状态、出口地址稳定性较敏感的服务，频繁变化出口可能带来额外验证。没有明确需求时，手动组或测试组通常更容易解释，也更适合先建立可复现的基础配置。

筛选与持久化：预防空组

从提供者引入节点时，可以使用筛选字段限制成员范围。筛选通常采用正则表达式，匹配的是节点名称而不是实际地理位置。供应方修改名称、标点或命名语言后，原筛选可能得到空列表。上线前要在客户端查看组内实际成员，不要只看正则文本似乎合理，就认定组已经可用。

策略组设计应控制嵌套深度。总入口接一个业务组，业务组再选具体节点，通常已经足够；层层包裹多个自动组，会增加理解成本。排查时沿着规则目标、当前组选择、下一级组、最终节点逐层查看，直到确定实际出站。只查看最外层组名，很容易遗漏里面仍选中了直连。

订阅刷新后选择变化，可能来自节点消失、名称变化、组结构重建或客户端持久化规则。先确认原成员还在，再检查 profile.store-selected 和客户端是否重置选择。需要长期稳定引用的业务组，可以放在本地覆写中维护；但必须同时考虑订阅更新后，该组引用的成员是否仍然存在。

当某一组异常而其他组正常时，先把同一个节点临时放入简单的手动组进行对照。如果节点本身可用，问题多半位于筛选、健康检查或组引用。这样能够把节点故障与调度逻辑分开，避免为了修复一处业务组，把整份订阅的所有策略都重写。

五、规则语法与匹配顺序

从上到下：具体规则放在前面

rules 是有顺序的列表，通常从上向下匹配，命中后采用指定策略。规则不是把所有条件综合计算再投票，因此更具体的例外要放在更宽泛的规则前面。排查某条自定义规则没有生效，首先查看它上方是否已有覆盖范围更大的规则，而不是立即更换规则类型。

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

示例中的 Proxy 必须是已定义的策略组或节点。规则最后一个策略字段不是自由备注，拼写、大小写和空格都应与实际名称一致。编辑器自动替换标点、复制时带入不可见空格，也可能造成引用失败。修改组名时，记得同步检查全部规则与其他组中的引用。

域名规则与地址规则的区别

DOMAIN 匹配完整域名，适合单个接口；DOMAIN-SUFFIX 匹配域名本身及其子域名，适合同一服务的域名族；DOMAIN-KEYWORD 按关键词匹配，范围更宽，容易覆盖无关目标。能用明确域名表达的需求，优先采用明确规则，减少后续难以解释的误匹配。

IP-CIDR 与 IP-CIDR6 面向地址网段。对带域名的连接，如果执行到需要目标地址的规则，内核可能触发解析。no-resolve 的含义是避免仅为这条地址规则主动解析域名，而不是禁止整条连接进行 DNS 查询；如果连接本来已有目标地址，仍可能匹配该规则。

GEOIP 依据地址数据库判断归属，结果受数据库内容与更新情况影响，不代表网站运营方所在地，也不能精确描述 CDN 每次调度的出口。启用相关规则前，要确认所需数据可被内核读取。域名解析到了不同地区地址时，相同网站走向变化，可能来自解析结果，而不是规则随机失效。

MATCH 是兜底项，通常放在列表末尾。若放在前面，后续普通规则就没有机会处理连接。DIRECT 表示直连，REJECT 表示拒绝，其他名称通常指向节点或策略组。不要为追求简短，把业务例外全部挪到兜底后面；配置看起来存在，运行时却永远匹配不到。

规则集与进程匹配的边界

较长的域名清单可以放入规则提供者，再用 RULE-SET 引用。主配置保留清晰的业务顺序，外部清单负责维护具体内容。需要注意，规则集仍然在它出现的位置参与匹配；即使清单内容很准确，如果前面已有兜底规则，整个规则集也不会获得处理机会。

进程类规则依赖运行平台、进程识别能力与接管方式。在桌面客户端上能识别的进程名，不一定能在路由器上识别，因为路由器接收到的是其他设备的连接。移动系统也可能限制相关信息。跨平台迁移配置时，应先确认能力边界，不要把进程规则当作普遍可用的域名规则替代品。

域名规则需要内核能够获得域名信息。应用直接连接地址、DNS 不经内核或某些加密解析路径，都可能影响识别；嗅探功能有适用条件，也不是所有协议都能还原域名。遇到连接只显示地址时，先看 DNS 与入口链路，再决定是否增加地址规则，不要盲目扩大关键词匹配范围。

验证规则时，在连接面板找到新建连接，查看命中类型、匹配内容、策略链和最终节点。修改前已经建立的长连接未必重新选择出站，必要时关闭该应用连接后重试。若仍有疑问，可到疑难解答按现象继续检查；保留一次成功与一次失败的连接记录，比只描述“规则不生效”更有帮助。

六、订阅、节点提供者与规则提供者

完整订阅与节点列表不是同一类内容

客户端的远程 Profile 通常是一整份配置，可以包含端口、DNS、节点、策略组和规则；proxy-providers 则用于在一份主配置中引入节点集合。两者都可能通过网址更新，但目标不同。把完整配置链接直接填进只接受节点提供者格式的位置，可能出现内容能下载、却无法解析的问题。

先确认服务方提供的内容格式，再选择导入入口。首次使用推荐通过客户端的订阅导入功能建立完整 Profile；只有明确需要自行维护主配置时，再把节点来源拆成提供者。关于客户端里的点击路径，见订阅导入步骤；格式转换的边界见订阅转换说明。

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

示例地址不提供真实节点。HTTP 节点提供者返回的常见 YAML 结构包含顶层 proxies 列表，不能用网页、登录页面或报错提示代替。path 用于本地缓存，通常相对于内核工作目录解析，具体还受客户端路径限制影响。不同提供者应使用不同缓存文件，避免相互覆盖。

更新周期与健康检查分别负责什么

提供者的 interval 控制重新获取节点列表的周期，健康检查中的同名字段控制检测周期，两者不是一回事。前者决定多久拿到新的节点信息，后者决定多久检查现有节点是否可达。把健康检查调得很频繁，并不会加快订阅内容更新；反而可能增加请求量与移动设备耗电。

更新失败要按获取链路逐步检查：网址是否过期、是否需要重新授权、当前网络能否访问、服务器返回什么内容、内容是否符合 YAML 结构。浏览器能打开网址，也要确认显示的不是账户页面。不要把完整订阅地址贴到公开反馈中，因为查询参数常常包含可直接使用的访问凭据。

如果本地缓存仍有效，远程更新失败不一定立即影响已有节点；但客户端的缓存策略和重启行为可能不同，不能把这一点视作保证。排查时先保留正在工作的配置，不要同时删除缓存与旧 Profile。更完整的错误分类可参阅订阅更新失败与自动更新间隔。

规则提供者：格式与行为要配套

rule-providers 维护的是匹配条件，不是代理节点。behavior 指定内容属于域名、地址还是经典规则形式；format 描述文件格式。两者需要与实际文件一致，不能只因扩展名是 YAML 就认定行为相同。主规则中的策略目标写在 RULE-SET 引用处，便于同一清单用于不同出站。

rule-providers:
  Work:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work.yaml

rules:
  - RULE-SET,Work,Proxy
  - MATCH,DIRECT

上面的 rules 是顺序示例，应整合到现有列表，而不是在文件末尾再声明一次。同一清单若采用域名行为，对应文件可以使用下面的结构。实际保存前，应确认客户端允许读取该相对路径；无法直接管理工作目录的移动客户端，更适合使用其提供的本地规则或覆写入口。

payload:
  - "+.github.com"
  - "example.com"

拆分提供者之后，维护责任也随之拆分：主配置负责组与顺序，节点来源负责线路信息，规则来源负责匹配范围。本地修改应该落在负责对应内容的层面。需要保留的自定义域名，不应只临时写进会被远程刷新替换的缓存文件，否则下一次更新就可能消失。

对多个来源并存的配置，建议记录每个提供者的用途、格式和被哪些组引用。新增来源后，先查看是否成功加载，再查看组内是否出现成员，最后测试连接。这样能把下载失败、格式错误、筛选为空和节点不可用分开，避免把所有问题都归到订阅链接本身。

七、DNS、Fake-IP 与 TUN 配合

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"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
    - 119.29.29.29

这个片段展示常见字段关系，不是适合所有网络的统一方案。listen 只是建立监听入口，系统不会因为它存在就自动把 DNS 请求送过去。监听在本机高位端口也不等于路由器已经为其他设备提供解析；需要结合客户端接管能力、系统设置和本机权限分别确认。

default-nameserver 常用于解析 DNS 上游自身的域名，nameserver 提供一般查询路径，proxy-server-nameserver 可为节点域名指定解析器。理解这些角色，比堆叠很多公共 DNS 更重要。节点建立前所需的查询，应有能够独立工作的解析路径，避免查询又依赖同一条未建立的代理连接。

Fake-IP：映射地址不是最终目标地址

fake-ip 为域名分配映射地址，内核再通过映射关系恢复目标域名并处理连接。看到返回地址属于配置的映射网段，不应立即判断为网站解析错误。它的前提是后续连接也进入能够识别映射的内核；如果查询经过内核、连接却绕开内核，应用可能尝试访问无法在普通网络直达的映射地址。

fake-ip-filter 可用于让特定域名不使用这种映射。局域网设备发现、某些依赖真实地址的应用，可能需要单独处理，但不宜一开始就添加过宽范围。例外越宽，域名映射可提供的识别信息越少；应先找到具体异常域名，再添加最小必要范围，并重新测试相关应用。

切换解析模式后，旧 DNS 缓存与已建立连接可能让结果看起来没有变化。可以先重开目标应用，再按系统或客户端提供的方法清理缓存。不要同时修改上游、映射模式、嗅探和规则，否则很难判断是哪项改动改善或破坏了连接。局域网名称还应检查路由器与本地解析环境。

TUN：接管流量仍需要路由与权限

TUN 通过虚拟网络设备接收流量，能覆盖部分不读取系统代理的应用。它并不代替规则与节点，也不保证所有系统环境下都能直接启用。桌面可能需要服务或提升权限，移动系统使用系统网络扩展接口，路由器则涉及网关和转发路径。具体启用步骤应以当前客户端界面为准。

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

这是常见桌面场景的字段片段，应用前应确认平台支持。auto-route 用于配置接管所需路由，auto-detect-interface 用于识别出站接口。多网卡、虚拟机、其他 VPN 和容器网络可能使自动判断不符合预期；出现断网时，先停用 TUN 恢复基线，再对照系统路由与接口选择。

dns-hijack 针对匹配的普通 DNS 流量，并不自动识别和改写所有 HTTPS 加密查询。若浏览器使用自己的加密解析路径，需要单独确认该行为与分流需求是否一致。与此同时，TUN 与系统代理同时启用时，应了解客户端如何防止自身流量回流，不要手工叠加多套不清楚来源的接管规则。

排查顺序建议是：先测试直连网络，再测试普通代理入口，再启用 TUN，最后核对 DNS 与域名规则。只有开启 TUN 才出错时，重点看权限、路由、接口与其他网络软件冲突；仅某个域名异常时，再看解析与规则。这样的分层测试，比一开始重写整段 DNS 更容易得到明确结论。

八、覆写、合并与可回退维护

区分订阅原文与最终运行配置

远程订阅更新通常会重新生成或替换配置内容。直接在订阅原文里增加规则，可能只在下次更新前有效。需要长期保留的端口、业务分流或 DNS 调整，应放入客户端支持的覆写、合并或脚本入口。先确认功能作用于哪些 Profile，再决定把修改写在哪里，避免全局修改意外影响另一份配置。

不同客户端对“合并”的定义并不完全相同。映射可能按字段递归合并，列表可能整体替换，也可能支持前置与追加；脚本还可能在合并后再次改动结果。不能看到同样叫覆写就假定行为一致。最可靠的方法是用小规模测试检查最终配置，而不是仅凭输入框内容判断已经生效。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

例如需要让工作域名优先走某个组，真正目标是把对应规则放到宽泛规则之前，而不只是把文字追加到文件末尾。若覆写接口只支持追加，且订阅已有 MATCH，新增规则可能永远无法命中。应改用前置入口或明确的规则插入功能，并在最终配置里核对它的位置。

跨字段引用：合并后重新检查关系

新增策略组时，要同时检查它引用的节点、提供者和其他组是否存在。保留本地组名并不能保证成员一直有效，远程订阅可能更换节点命名或提供者名称。建议让长期业务规则指向稳定的本地业务组，再由这个组引用一个结构清晰的来源，减少规则与远程节点名称的直接耦合。

覆盖 DNS 时也要确认是只替换某个子字段，还是整个对象被重建。如果只想换上游，却连监听地址、映射模式或过滤列表一起丢失，连接行为可能同时改变。修改前记录原有字段，修改后对照最终结果；不要把另一份配置里的完整 DNS 区块当成只修改一个参数的操作。

路径字段同样需要重新检查。原订阅使用的相对目录、客户端覆写文件所在目录和内核运行目录可能不同。迁移到另一台设备后，文件提供者与缓存路径可能失效。遇到找不到文件的错误，先核对工作目录与客户端允许访问的位置，不要通过随意放宽目录权限掩盖路径问题。

验证闭环：保存、加载、连接、回退

建议为每次修改留下简短记录：改了哪个字段、希望影响什么连接、使用哪个目标验证、失败时恢复哪份文件。记录不用复杂，但要让一周后仍能理解修改原因。临时排错开关也应标记清楚，完成后及时恢复，避免详细日志、特殊 DNS 例外或临时直连策略长期遗留。

操作顺序可以固定为四步。先备份当前有效配置；再执行语法与内核检查；随后应用并查看加载日志；最后使用一个新连接检查命中结果。配置加载成功只是中间环节，仍需验证实际业务。反过来，某个网站暂时能打开，也不能证明新规则生效，可能只是仍在使用原有长连接。

测试时尽量保持其他条件不变。使用同一目标、同一入口和同一节点，只比较修改前后的一个变量。若同时刷新订阅、更换节点、切换模式和启用 TUN，结果即使改善，也无法知道真正原因。稳定配置的价值，在于之后每一次变更都能够解释，而不是字段数量越来越多。

回退也应作为正常流程预先安排。保留最近一份有效 Profile、对应覆写内容和必要的客户端设置；恢复后重新加载，并确认系统代理或 TUN 状态与原先一致。备份文件包含节点与订阅信息，应保存在受控位置。向他人请求帮助时，提供经过删减的相关片段和错误信息即可。

最终维护原则是让每个字段有明确归属：订阅维护节点来源，本地覆写维护个人需求，策略组组织出站，规则决定选择，DNS 与入口保证连接信息能够进入正确链路。首次操作仍以快速上手文档为主；长期使用再按本页章节逐项扩展，不需要一次开启所有能力。