Clash 配置参考

YAML 结构与配置依赖

从顶层映射识别配置边界

Clash 配置不是按顺序执行的脚本，而是描述运行状态的一份映射。顶层的 mixed-port、mode 和 log-level 是标量；dns 是嵌套映射；proxies、proxy-groups 和 rules 是列表。缩进决定父子关系，字段所在的位置与字段内容同样重要。例如，把 rules 缩进到 dns 下面，不会得到一套特殊的 DNS 分流规则，而是改变了原有结构，可能报错，也可能被忽略。

阅读完整文件时，先标出四条依赖链：监听入口把连接送入内核；规则把连接交给某个目标；策略组把目标名称映射到节点或其他组；DNS 为域名访问提供解析结果。提供者负责补充节点或规则数据，但不会天然成为出口。只有策略组引用了节点提供者，或者规则引用了规则提供者，对应资源才进入实际处理路径。理解这些关系后，排错就不必逐行猜测。

# 最小直连配置，可用于验证文件结构和监听入口
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

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

rules:
  - MATCH,出口选择

这份最小配置只使用内置目标 DIRECT，不会提供远端代理服务。它适合先确认内核可以读取文件、端口能够启动、客户端能切到规则模式。需要代理出口时，再添加真实节点，并将节点名称加入策略组。不要把结构示例与可用订阅混为一谈：配置文件能通过语法检查，只能证明结构和部分引用成立，不能证明远端服务器存在或账户具有访问权限。

缩进、引号与列表的常见边界

建议始终用两个空格缩进，不混用制表符。短列表可以写成 [DIRECT, 出口选择]，较长对象列表则使用每项一行的形式，便于观察层级。字符串包含冒号后接空格、井号或看起来像布尔值的内容时，用引号明确类型。密码、订阅地址以及纯数字形式的名称也适合加引号，避免解析器把它们解释为其他类型。注释只在字符串之外起作用，不要用注释保存账户信息。

同一映射内不要重复定义键。例如，在文件开头和末尾各写一个 dns，不能当成可靠的增量合并方式；不同解析器可能拒绝重复键，也可能只保留其中一段。需要补充 DNS 字段时，应回到同一个映射内修改。列表项目也不是按名称自动合并：两个同名策略组通常意味着冲突，而不是把候选节点拼接起来。配置越长，越需要明确一处定义、其他位置引用的约束。

区分源配置、资源文件与运行配置

客户端通常同时管理订阅原文、提供者缓存、覆写片段和交给内核的运行配置。界面里看到的文件不一定就是最终文件，编辑缓存也可能在下一次更新时被替换。开始修改前，应记录当前选中的配置名称，导出一份不含个人凭据的结构备份，并确认编辑入口究竟是订阅原文还是持久覆写。安装客户端可先选择 Clash Plus，再按实际平台核对配置编辑与运行日志入口。

拆分文件主要用于维护，不代表 YAML 自带任意文件导入能力。不要自行添加 include 字段并期待内核读取目录。节点与规则的拆分应使用受支持的提供者机制；通用设置的复用则依赖客户端明确提供的合并功能。相对路径通常以工作目录为基准，不一定相对于正在编辑的文件。迁移设备时，除了主配置，还要检查资源路径、写入权限和客户端生成目录。

监听端口、模式与控制接口

入口协议与监听地址

port 提供 HTTP 代理入口，socks-port 提供 SOCKS 入口，mixed-port 在同一个端口接受 HTTP 与 SOCKS 请求。通常选择一个混合端口即可，不必为每种入口都开启监听。应用需要主动使用代理地址，连接才会进入这些端口；仅启动监听不会自动接管系统流量。客户端的系统代理开关属于操作系统集成，TUN 则是另一种接入方式，二者不能仅凭端口是否存在来判断。

allow-lan: false 适合只供本机使用。开启局域网访问后，还要确认 bind-address、操作系统防火墙和网络隔离策略是否允许其他设备连接。监听在回环地址上的服务不能从另一台设备访问；监听在所有地址上也不代表防火墙已经放行。不要为了排查单个应用而直接扩大整个设备的暴露范围，应先用本机连接确认入口工作，再按需要逐步开放。

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

# 管理接口只监听本机；凭据请在本地单独设置
external-controller: "127.0.0.1:9090"

运行模式与日志粒度

mode: rule 按规则列表选择目标；global 把连接交给全局策略；direct 使用直连路径。规则文件写得正确，但界面处于全局模式时，规则不会按预期参与选择。某些客户端会通过 API 恢复上次使用的模式，因此磁盘上的初始值与界面当前状态可能不同。遇到分流异常，先核对运行模式，再检查规则顺序，不要立刻把所有规则改成代理。

log-level 用于控制日志详细程度。日常使用可保留 info，需要追踪解析、连接或资源加载时再临时切到 debug。详细日志可能包含域名、目标地址和请求上下文，分享前应删除订阅地址、账户字段及其他个人信息。排错结束后恢复原级别，避免长时间记录不必要的访问细节。日志里有连接记录，也只说明流量到达某个处理阶段，不能直接证明完整请求成功。

管理 API 与运行环境的约束

管理接口可以切换策略、读取连接并修改运行状态，其权限与普通代理入口不同。建议保持回环监听，由本机客户端调用；确需跨设备管理时，应配置独立访问凭据、限制来源地址，并在可信网络边界内使用。不要将接口凭据写进公开仓库，也不要把完整管理 URL 截图发布。界面打不开时，先确认控制地址是否与客户端设置一致，再检查端口冲突和内核是否已经退出。

端口号本身没有固定魔法含义，示例中的数值可以调整，但应用、系统代理与客户端必须同步。多个代理程序同时启动时，最常见的问题是端口占用、系统代理相互覆盖和虚拟路由竞争。排查时一次只保留一套接管机制，确认连接路径后再恢复其他工具。Linux 服务还要检查运行用户、工作目录和文件权限；桌面客户端正常，不代表相同文件交给系统服务后也能读取到同一份资源。

ipv6 也不是单纯的网络加速开关。是否启用应结合本地网络、节点出口和 DNS 返回结果决定。关闭内核的 IPv6 支持不会替代操作系统防火墙策略，也不能自动解释所有 IPv6 直连现象。若应用绕过代理入口建立连接，应先解决接管范围，再讨论地址族选择。常见的系统代理失效、端口冲突和局域网连接问题，可继续对照 FAQ 故障排查检查。

代理节点字段与协议边界

节点对象的最小组成

proxies 中每个对象描述一个出口。所有节点都需要可引用的 name，协议由 type 决定；server 与 port 指向服务端监听地址。认证方式、加密方法、传输层与 TLS 设置则取决于协议，不能在不同协议之间机械复制。名称不是连接参数，却是策略组引用的标识。修改节点名称后，需要同步修改所有直接引用，尤其是手工维护的组和规则目标。

下面以 Shadowsocks 展示结构。服务器使用保留的示例域名，密码为教学假值，必须替换成服务提供者给出的对应参数后才能连接。不要仅凭端口或协议名称推断密码、加密方法和传输方式。订阅中已经包含完整节点时，优先保留上游字段；只有确认具体含义后再做局部调整。错误地删除传输设置，可能让一份可用订阅变成语法正确但握手失败的配置。

proxies:
  - name: 示例出口
    type: ss
    server: proxy.example.com
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

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

传输层与 TLS 字段不是通用拼装件

同样使用 TLS 的协议，也可能采用不同字段名称。某些节点使用 servername 指定握手名称，另一些协议使用 sni；是否需要 tls 开关、是否支持特定传输选项，都应按该协议的内核文档确认。服务端地址可以是域名或 IP，但证书通常对应域名。将域名替换为 IP 后若不保留正确的握手名称，就可能出现证书名称不匹配，而不是服务器离线。

WebSocket、HTTP/2 或 gRPC 等传输还涉及路径、主机头或服务名称。它们属于服务端约定的一部分，不是可以随意精简的备注。排错时应依次核对协议、地址、端口、认证和传输，再检查证书及网络可达性。不要把关闭证书验证当成常规解决方法；它会降低对服务端身份的确认能力，也无法修复错误密码、错误路径或服务端并未开启对应协议的问题。

UDP、解析与节点更新

udp: true 表示在相应协议支持时允许 UDP 转发，并不能让不支持 UDP 的服务端获得此能力。应用还必须通过支持 UDP 的入口进入内核，出口链路也要允许对应流量。网页可访问而游戏或语音不可用时，应分别检查入口、策略组所选节点和远端能力，不要仅观察 HTTP 测试结果。相反，节点测试正常但特定网站失败，也可能是规则选错了出口，而非节点本身不可达。

当 server 使用域名时，连接节点之前就需要完成解析。这与通过代理访问网站时的目标域名解析不是同一个阶段。若用于解析节点的 DNS 请求又依赖尚未建立的代理，会形成启动依赖环。配置代理域名专用解析器，可以使初始连接路径更清晰；具体字段见后文 DNS 章节。应先证明节点服务器地址能够正确解析，再分析目标网站的解析策略。

订阅更新可能改变节点名称和数量。若手动策略组逐个枚举节点，上游删除或重命名后就可能出现失效引用；用提供者的 use 引入节点集合更适合动态订阅。对订阅内容有疑问时，只导出已脱敏的单个节点结构进行比较，不要公开整条订阅 URL。节点列表、完整 YAML 和 URI 链接并不是同一种输入，格式识别可参阅订阅格式区别与转换，避免把编码文本直接放进 proxies。

策略组与出口选择

稳定的组名与可变化的节点集合

策略组把规则与具体节点解耦。规则可以长期指向 出口选择，节点更换则在组内完成，不必修改每条规则。组名、节点名和内置目标处于可引用的目标体系中，应避免重名，也不要把组命名成容易与 DIRECT、REJECT 混淆的字符串。列表中的 proxies 是显式目标，use 则引用节点提供者，两者含义不同，不能把提供者名称直接当成节点名称填写。

select 由用户选择出口；url-test 按探测结果选择候选；fallback 按列表顺序寻找可用出口；load-balance 按相应策略分配连接。自动选择并不等于所有业务都经过比较后选出最佳路径，探测 URL 只反映某个目标在某个时刻的可达性。访问目的地、协议类型或服务端限制不同，都可能让实际业务表现与探测结果不同。

# 与前章的“示例出口”节点配套使用
proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - 自动选择
      - 示例出口
      - DIRECT

  - name: 自动选择
    type: url-test
    proxies:
      - 示例出口
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - MATCH,出口选择

探测间隔、容差与故障切换

interval 使用秒作为探测周期；tolerance 在适用的自动选择组中使用毫秒描述切换容差。设置容差可以减少轻微波动导致的频繁切换，但并不能修复远端拥塞。周期过短会增加请求数量和设备唤醒，移动设备尤其需要考虑电量与网络切换。探测地址应能稳定返回可预期响应，且没有登录前置条件；若探测目标本身不可达，整个候选集合都可能被误判为不可用。

故障切换组的顺序具有业务含义。排在前面的目标不是永远更快，而是在满足可用条件时优先使用。负载均衡也通常是连接级分配，不会把单次下载拆成多个节点叠加带宽。需要保持登录会话或来源地址稳定的业务，应慎重使用跨出口分配，先明确目标服务是否允许地址变化。规则目标切换后，既有 TCP 连接通常不会自动迁移到新出口，验证时应建立新连接。

嵌套引用与选择状态

策略组可以引用其他组，但必须形成有出口的有向关系。若甲组引用乙组、乙组又引用甲组，就构成循环依赖；即使界面允许保存，运行时也可能拒绝配置或无法选出有效出口。维护时从最终规则目标向下追踪，直到具体节点或内置目标，确认每条分支都能终止。组层级不宜过深，因为界面显示的第一层选择往往不足以解释最终连接走向。

客户端可能保存手动选择，并在重启或更新后恢复，因此列表第一项不一定是当前出口。profile.store-selected 等持久化能力还会影响恢复行为；不同客户端也可能通过自己的状态文件保存选择。判断组是否工作，应同时查看组当前选项和连接记录中的完整链路，不要仅依据 YAML 顺序。修改组名后，旧选择可能不再对应，必须重新确认一次。

节点集合为空时，自动组不能凭空产生可用出口。使用筛选表达式后应检查是否仍有候选，特别是上游改变命名习惯时。手动组保留直连选项是否合适，取决于业务要求：对于必须固定代理出口的服务，直连不应被当作未经确认的备用路径。测试规则、检查策略和验证业务应分开进行，才能区分是候选为空、探测失败、选择恢复异常，还是远端服务限制了访问。

规则语法与匹配顺序

首条命中决定处理目标

rules 是有序列表。内核从上到下检查，命中后使用该条规则指定的目标，不再继续寻找更具体的匹配。因此，具体域名和例外规则应放在宽泛条件之前，MATCH 放在末尾兜底。规则没有自动计算“最长前缀优先”或“域名规则天然优先于地址规则”的全局排序，实际优先级就是文件顺序。把一条宽泛规则提前，可能使后面的整段规则永远无法触达。

多数规则采用“类型、匹配内容、目标”的形式。DOMAIN 精确匹配域名，DOMAIN-SUFFIX 匹配域名本身及其子域，DOMAIN-KEYWORD 检查域名中的关键词。IP-CIDR 和 IP-CIDR6 匹配目标地址网段，GEOIP、GEOSITE 依赖对应地理或站点数据。PROCESS-NAME 依赖进程识别能力，不能假定在所有平台和所有入口上均可获得。

rules:
  - DOMAIN,login.example.com,出口选择
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,example,出口选择
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - MATCH,出口选择

这里的登录域名先命中代理，其他该域名后缀直连；关键词规则只能处理前两条未覆盖的情况。示例域名用于说明顺序，不代表实际服务分流建议。网段规则带有 no-resolve，表示不为了该地址规则主动触发域名解析；若连接已有目标 IP，仍可据此匹配。它不是禁止所有 DNS 请求的开关，也不会让后续依赖解析的规则失去作用。

域名、地址与进程并非同时可见

不同入口携带的信息不同。HTTP 代理请求通常能提供目标主机名；某些应用只把解析后的 IP 交给代理，内核就不一定知道原域名。TUN、fake-ip 映射和嗅探可以补充上下文，但各有适用边界。域名规则未命中时，先在连接信息中确认内核实际拿到了什么，再决定是否调整解析或嗅探。盲目补更多域名规则，无法解决域名信息根本没有进入匹配流程的问题。

数据规则与拒绝目标

地理数据规则需要检查实际加载的数据格式和文件路径。GEOSITE 的分类名来自数据库，不是任意标签；GEOIP 的判断也受到数据更新与地址归属变化影响。不要把地址所在地等同于服务所有者所在地，更不要据此推断内容一定从某个区域提供。数据库加载失败、分类不存在和规则顺序错误是不同问题，排查方法见GeoIP 与 GeoSite 数据库更新方法。

REJECT 用于拒绝连接，适合明确需要阻断的匹配范围。把过宽的关键词规则指向拒绝目标，可能连带影响登录、验证码或静态资源；测试时应先缩小范围并观察命中记录。规则目标还可以是节点或策略组，但必须真实存在。拼写差异、尾部空格和组名重命名都可能造成引用错误，不能只检查规则前半段的匹配表达式。

验证修改时，选择一个明确目标，记录模式、请求域名、命中规则和最终出口，然后只改一处重新建立连接。浏览器连接池、HTTP/2 复用和应用长连接可能继续使用旧连接，刷新页面不一定产生新的规则判断。必要时关闭对应连接再测，但不要把“关闭所有连接”当成日常自动操作。规则只处理已进入内核的流量；若连接列表完全没有对应请求，应先回到入口与接管范围排查。

DNS、fake-ip 与 TUN 接管

解析器职责与启动依赖

dns.enable 开启内核 DNS 模块，listen 定义监听地址。nameserver 是常规解析器列表，default-nameserver 用于引导解析 DNS 服务器自身的域名，proxy-server-nameserver 则用于解析代理服务器域名。三者解决的阶段不同，不应仅因为某个地址响应更快就全部替换。尤其在加密 DNS 使用域名地址时，需要先有可工作的引导解析路径，否则启动时可能出现依赖环。

enhanced-mode: fake-ip 为域名分配映射地址，后续连接到达内核时可据此恢复域名上下文。它不是远端服务器的真实地址，也不表示网站部署在该网段。应用绕过内核连接映射地址时，访问通常不会成功，因此 DNS 应答与流量接管必须配套。遇到局域网发现、特定设备协议或检查真实地址的应用，可以按需配置 fake-ip-filter，但不应把所有域名都排除后仍期待保留相同的映射效果。

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

解析策略不是出口规则的替代品

nameserver-policy 可以为指定域名选择解析器，其职责是决定从哪里获取解析结果，不直接决定业务连接走哪个出口。fallback 与 fallback-filter 用于备用解析和结果筛选，也不能简单理解成“第一个失败才串行请求第二个”。实际行为与筛选条件有关，配置前应明确期望的返回结果。解析路径、DNS 连接出口与目标业务出口是三个相关但不同的问题，不能只看一条解析结果就下结论。

加密 DNS 保护的是客户端到解析器之间的传输，不能单凭使用 HTTPS 地址就判定不存在泄漏。操作系统、浏览器与应用可能使用各自的解析器；浏览器自带的加密 DNS 请求也可能作为普通 HTTPS 连接通过网络，而不经过内核监听端口。应检查请求由谁发起、是否进入内核、最终走哪个策略。字段分工可继续阅读nameserver、fallback 与 fake-ip 说明。

TUN 的路由、权限与劫持范围

TUN 通过虚拟网络接口接收流量，适合不读取系统代理的应用。它通常需要管理员权限或相应系统能力，还依赖路由配置、设备接口和内核网络栈支持。开启后并不意味着任意网络活动都已接管；虚拟机、容器、其他 VPN、特定绑定接口的应用，都可能有独立路径。不要同时启动多套自动路由工具来碰运气，应先保留一套配置，检查接口与路由是否建立成功。

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

dns-hijack 将接管范围内匹配的传统 DNS 请求交给内核 DNS 模块，并不会识别并解开所有加密 DNS 流量。上述片段需要与已开启的 dns 配套，且实际支持受平台、路由和防火墙影响。auto-detect-interface 尝试选择出站接口，在多网卡、网络切换或其他隧道存在时仍需检查结果。若默认出口错误，节点连接也可能被再次送回虚拟接口形成异常路径。

修改 fake-ip 模式、映射范围或 DNS 接管方式后，应用与系统缓存可能保留旧结果。应重新建立测试连接，必要时清理对应缓存，并确认内核映射没有因重启而丢失。若出现仅部分应用失败、局域网域名异常或休眠恢复后断网，应分别比较解析路径与路由变化，而不是永久关闭 DNS 模块。可按DNS 泄漏检测与修复中的思路复测，同时保留修改前后配置用于回退。

节点订阅与规则提供者

远程资源的声明与实际引用

proxy-providers 把节点集合从主配置中分离，适合上游定期更新的订阅。提供者声明资源来自 HTTP 还是本地文件、保存路径以及更新周期；策略组再通过 use 引入该集合。仅声明提供者而没有组引用，不能让规则自动选中其中的节点。与完整配置订阅相比，节点提供者更适合保留本地策略和规则，只让上游更新节点内容，从而缩小每次更新影响的范围。

下面的 URL 使用示例域名，正式使用时应在本机替换为自己的资源地址。远程节点文件通常需要以 proxies 为顶层键，内容为节点列表，不能直接填入任意网页、Base64 文本或未经转换的 URI 集合。部分客户端会提供格式转换，但这是客户端能力，不是所有内核都接受任意格式。先识别返回内容，再决定使用提供者还是导入完整配置。

proxy-providers:
  上游节点:
    type: http
    url: "https://example.com/proxies.yaml"
    path: ./providers/upstream.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

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

规则提供者的行为与格式

rule-providers 管理规则集合，通过 RULE-SET 在主规则列表中引用。behavior 描述集合如何解释：domain 面向域名集合，ipcidr 面向地址网段，classical 可以包含不同类型的经典规则条件。format 则描述资源编码，例如 YAML 或文本。行为与格式是两个维度，不能因为文件扩展名是 YAML 就推断它一定包含完整经典规则。

rule-providers:
  本地直连域名:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/direct.yaml

rules:
  - RULE-SET,本地直连域名,DIRECT
  - MATCH,出口选择

对应的 rules/direct.yaml 可使用下方结构。域名集合中的 +.example.com 表达该域及其子域的集合匹配，不应直接照搬成主规则列表中的一整条规则。经典规则集合则通常写匹配条件而不附目标，由引用它的 RULE-SET 决定出口。把两种语法混在一起，可能导致加载失败或实际覆盖范围与预期不一致。

# rules/direct.yaml
payload:
  - "+.example.com"
  - "localhost"

更新周期、缓存与访问路径

资源更新周期与健康检查周期相互独立。前者下载新的节点或规则内容，后者检测已有候选的可用状态。修改周期不会立即证明更新发生，仍需查看资源时间、日志和当前集合。下载请求还依赖初始网络路径，若资源只能通过代理获取，而代理节点又只存在于尚未下载的同一份资源中，就会形成启动困境。应保留可用缓存或明确的初始获取方式，而不是不断重启。

path 应在允许写入的工作目录中，并为不同提供者分配不同文件。多个提供者共用缓存路径会覆盖内容；从桌面环境迁移到服务环境时，工作目录变化也可能造成文件找不到。资源失效后是否继续使用旧缓存，应以当前客户端和内核日志为准，不能假设失败时总会安全保留上一份。重要规则需要有可回退副本，避免远程资源临时不可用影响整体加载。

订阅 URL 常带账户标识，完整地址应视为个人访问凭据处理。分享配置时，把 URL、认证头和节点认证字段一起脱敏；不要把含参数的地址放入公开截图或工单。若更新返回 HTML 页面，先检查登录跳转、地址过期和响应状态，不要将页面内容当作 YAML 错误逐字修补。只有确认上游格式正确之后，再检查本地提供者字段、引用名称与缓存路径，才能避免在错误层面反复修改。

覆写合并与生效验证

明确由谁生成最终文件

覆写是客户端在源配置与运行配置之间执行的处理，不是一套所有客户端都相同的内核语法。常见流程是读取订阅、应用通用设置、执行覆写或脚本，再生成运行文件；具体先后顺序需要在当前客户端确认。一个 override.yaml 文件不会因为放在目录里就自动生效，必须由客户端明确加载。更新后改动丢失时，优先检查编辑入口与处理顺序，不要反复修改自动生成文件。

标量覆盖、映射递归合并和列表拼接是三种不同操作。将 mode 从全局改为规则，通常属于标量替换；只修改 dns.nameserver 是否保留其他 DNS 字段，取决于是否做深层合并；修改 rules 则可能替换整张列表，也可能在前后追加。客户端把功能称为“合并”，并不保证这三类数据都采用同一算法，应使用小片段测试结果后再扩大修改范围。

# 仅作为客户端覆写输入；合并行为需在客户端确认
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

profile:
  store-selected: true

列表操作需要保留完整语义

规则前置与规则追加的效果不同。例外规则若追加在 MATCH 后面就不会命中；把新兜底规则前置又会遮住原有列表。策略组也不能简单按名称推定合并：新增同名对象可能产生冲突，替换对象则可能丢失原来的提供者引用。设计覆写时，应先写清期望变化，例如“只在末尾兜底前插入局域网例外”，再查客户端是否支持对应操作，而不是先拼一份看起来相似的 YAML。

如果客户端提供脚本覆写，应在本地保留脚本和修改说明，避免从未知来源直接运行处理逻辑。脚本可能读取或更改完整配置，影响范围大于普通字段覆盖。较稳妥的做法是只操作必要键，对缺失对象和空列表做边界处理，并在修改后保留其余字段。跨客户端迁移时，优先迁移期望结果与数据文件，不要假设原客户端的脚本接口、变量名和合并顺序可以原样使用。

从静态检查到运行链路验证

独立内核可以使用配置测试命令检查结构与引用。下面命令以当前目录为工作目录，读取 config.yaml；可执行文件名和目录应按实际安装位置调整。桌面客户端通常有内置检查或日志入口，不必另外启动第二个内核抢占监听端口。测试成功只代表检查阶段通过，不能验证账户有效性、远端服务状态、系统代理、TUN 权限和所有应用的实际流量路径。

mihomo -t -d . -f ./config.yaml

修改前先保存可用配置，应用后检查运行文件中的关键字段，而不是只看源文件已保存。随后建立一条新的测试连接，依次确认入口、模式、命中规则、策略组链路和出口。DNS 相关修改还应核对解析结果与是否使用缓存。将这些检查点分开记录，可以明确错误属于加载阶段、资源阶段还是业务访问阶段；即使最终症状都是“无法上网”，修复方向也完全不同。

回退应同时考虑配置与运行状态。恢复旧文件后，还要确认当前模式、手动组选择、DNS 缓存及 TUN 路由没有保留新状态。一次只调整一类行为，并保留简短变更记录，比同时替换节点、DNS 和规则更容易定位原因。初次部署仍可回到快速上手教程按主线验证；具体故障再查常见问题。本手册的作用是解释字段之间的关系，而不是提供适用于所有网络的固定参数组合。