Clash 配置大全

结构参考 / 01

YAML 结构与配置来源

先分清映射、列表与引用

配置文件不是一串按显示顺序执行的命令，而是交给内核读取的结构化数据。冒号左侧是字段名，右侧是字段值；没有立即写值时，下一层缩进通常表示子字段。顶层的 dns 是一个映射，rules 是一个列表，proxies 则是由多个节点映射组成的列表。先辨认数据类型，再修改内容，比根据界面位置猜测字段可靠。

缩进统一使用空格，不要混入制表符。两个空格是便于阅读的习惯，并非所有位置都强制只能两个；真正重要的是同层对齐、子层比父层更深。列表项前的短横线后面需要空格，普通字段的冒号后面也需要空格。中文冒号、全角空格和从聊天软件复制来的弯引号，看起来接近原字符，却可能使解析失败。

mixed-port: 7890
mode: rule

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

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手动选择

上例中，name、type 与 proxies 属于同一个策略组。组内的 proxies 保存的是名称列表，而不是节点连接参数。底部规则里的“手动选择”必须与组名完全一致，包含空格、大小写与标点。能通过 YAML 解析，只说明文件结构成立；名称引用不存在时，内核仍可能拒绝加载。

字符串与重复字段的边界

名称中包含特殊标点时，建议使用引号。密码如果含有井号、冒号或前后空格，更应明确写成字符串。双引号会处理反斜杠转义，单引号通常更适合按字面保留内容，但单引号自身需要成对转义。数字端口写成整数，布尔值写成 true 或 false，不要为了视觉统一把所有值都加引号。

同一映射内不要重复写字段。例如，文件开头已有一个 dns，又在底部追加另一个 dns，不同解析链可能拒绝读取，也可能只保留后者。把新增项目放进原有映射，比依赖重复键覆盖更稳妥。注释从井号开始，用来解释修改目的；注释不会成为运行参数，也不能用注释掉错误行的方式掩盖失效引用。

确认正在编辑哪一份文件

客户端通常同时保存订阅原文、本地编辑副本和最终运行配置。订阅原文是远程更新的输入；本地副本可能只用于编辑；最终运行配置则由客户端加入端口、控制接口和覆写内容后生成。先在客户端找到当前启用项，再查看运行配置或内核日志中的加载路径。不要因为资源管理器里有一个 config.yaml，就认定它是当前生效文件。

修改前复制一份原文件，并用清楚的文件名区分用途。编辑后先保存，再执行客户端的重新加载；仅关闭编辑器通常不会触发内核读取。若界面保存成功但行为没有变化，先检查启用项、生成路径与重载结果，不要立即怀疑规则本身。订阅更新可能重建原文件，需要长期保留的改动应放入客户端支持的覆写机制。

本页按字段语义组织内容，不保证每个客户端都暴露全部选项。先确认内核是 mihomo，再对照当前内核支持的字段；旧 Clash 客户端不能直接等同于现有 mihomo 实现。

遇到未知字段时，先缩小到单个配置段，查清它属于内核、客户端还是外部工具。客户端专属字段放进内核配置后，可能被忽略，也可能导致异常。需要补齐基本概念时，可先读概念速查，再返回对应章节，不必一次理解全部字段。

运行入口 / 02

端口、运行模式与控制接口

本地监听与系统代理是两件事

mixed-port 在同一个监听端口接收 HTTP 代理与 SOCKS5 代理请求，适合桌面软件统一填写。port 用于单独的 HTTP 代理入口，socks-port 用于单独的 SOCKS 入口。普通使用通常保留一个混合端口即可，不需要同时开启所有入口。端口数字只是本机监听位置，不代表服务器地址、节点质量或某种固定协议能力。

内核开始监听，不等于操作系统已经把请求交给它。系统代理开关一般由客户端管理，负责更新系统的代理设置；有些程序读取它，有些程序使用独立设置，还有些程序直接建立连接。排错时先确认监听成功，再确认应用是否采用该入口。不要把“系统代理已开启”和“所有程序都经过代理”当成同一个结论。

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 按规则顺序决定连接去向，是理解分流配置的起点。全局模式将普通连接交给全局策略处理，但全局策略仍需要选择合适出口；它不会自动修复失效节点。直连模式适合暂时绕过代理进行对照。模式变化后，已经建立的长连接可能沿用原路径，验证时应重新发起请求，而不是只刷新仍在复用连接的页面。

log-level: info 适合日常观察启动与连接状态；调试时可以临时提高详细程度，但日志会更密集，也可能包含访问目标等敏感信息。排错完成后恢复原设置，分享日志前移除订阅地址与认证内容。ipv6: false 不等于操作系统彻底禁用 IPv6，也不能单独保证应用不会通过其他路径使用 IPv6，需要结合 DNS 与流量接管范围判断。

局域网共享与管理接口分开配置

allow-lan 控制局域网访问能力，bind-address 决定监听地址。示例限定回环地址，只适合本机连接；即使把允许局域网改成开启，仍需确认监听地址是否允许其他设备访问。计划共享时，再明确调整到对应本地接口或所需监听范围，并按家庭网络、办公网络等场景限制防火墙来源。

允许局域网后，手机填写的是电脑的局域网地址与代理端口，不是 127.0.0.1。手机上的回环地址指向手机自身。电脑地址变化、访客网络隔离、睡眠和防火墙拦截都可能使共享中断。配置过程见混合端口与局域网共享说明。共享前还应确认网络使用约定，不要在不可信网络中开放访问。

external-controller 是供客户端或面板管理内核的接口，不是浏览器访问互联网的代理入口。保持回环监听通常就能满足桌面客户端需要。若确实需要远程控制，应另外设置强认证并限制网络可达范围，不要为了手机共享代理顺手把管理接口暴露出去。界面连接不上内核时，也要分别检查管理端口和代理端口，避免修改错位置。

出现端口占用时，优先退出另一个正在运行的代理实例，再重新加载。必须更换端口时，应同步修改系统代理、应用独立代理和局域网设备设置。只修改 YAML 而保留旧系统入口，会出现内核运行正常、浏览器却一直连接失败的情况。每次只调整一组相关字段，更容易确认故障来自哪里。

名称解析 / 03

DNS、fake-ip 与解析路径

先确定谁在发起解析

DNS 把域名转换成地址，但实际解析可能发生在应用、操作系统、浏览器、代理内核或远端代理服务器。开启内核 DNS 只说明内核具备解析能力，并不代表所有应用的查询都已进入内核。系统代理通常不会自动接管全部系统 DNS；TUN 的 DNS 劫持也有自己的匹配范围。先画清请求路径，再选择参数，避免一边修改内核 DNS，一边测试完全绕过它的浏览器内置解析。

dns.enable 控制内核 DNS 模块，listen 指定监听地址。示例使用回环地址与较高端口，便于理解而不占用常见系统端口。仅写监听字段不会让系统自动使用这个地址。桌面客户端可能通过 TUN 或其他集成方式把查询送入内核，应以其实际设置为准；不要直接把下例当成完整系统 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
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5

fake-ip 与真实地址模式

fake-ip 为请求域名建立一个虚拟地址映射。后续连接进入内核时，内核可以根据映射恢复域名，更方便进行域名分流。示例地址段是用于该机制的保留用途地址，不是可以填写到节点 server 的公网服务地址。看到解析结果属于该范围，先检查是否处于 fake-ip 模式，不要立即判断为解析污染。

redir-host 通常返回实际解析地址，适合需要真实地址结果的场景，但它并不等于所有解析问题的通用修复。切换模式会改变地址缓存与连接行为，旧缓存仍可能影响观察结果。修改后应重新加载配置，并根据操作系统与应用情况清理缓存、重启相关应用。先测试一个明确目标，再逐步扩大范围，不要同时改模式、上游和规则。

fake-ip-filter 用来让特定域名避开虚拟地址分配。局域网服务、设备发现或依赖真实地址的应用可逐项加入，但过滤范围过大，会减少域名映射带来的便利。不同过滤模式与匹配语法有具体语义，不能把所有条目都理解为普通正则表达式。优先从确实异常的域名开始，记录添加原因，避免长期积累无法解释的过滤列表。

上游解析与节点域名解析

nameserver 是普通查询使用的上游集合，default-nameserver 可承担解析上游 DNS 服务域名的引导工作。若所有上游都写成域名，却没有可达的初始解析路径，可能形成启动依赖问题。proxy-server-nameserver 用于代理服务器域名解析，让节点地址不必先依赖尚未建立的代理连接。上游应按所在网络的可达性选择，不是数量越多越稳。

nameserver-policy 可以针对指定域名或匹配范围选择上游；fallback 与相关过滤条件则用于按条件判断解析结果。它们不是简单的“第一个失败就问第二个”。如果没有明确需求，先使用容易解释的单一路径。需要结合路由规则控制 DNS 上游连接时，还应确认相关字段的支持情况及节点域名解析安排，避免解析与代理互相等待。

使用加密 DNS 只改变某段解析传输方式，不会自动接管应用，也不等于所有网络出口已经统一。检测结果要与系统 DNS、浏览器设置和当前连接日志一起判断。

排查时先测试域名能否解析，再测试返回地址能否建立连接，最后核对请求走的出口。只有域名失败而地址可通时，才更接近解析问题；证书错误和服务端拒绝不能直接归因于 DNS。进一步操作可读DNS 检测与 fake-ip 配置实操，保留原上游设置，便于逐项对照和回退。

出口定义 / 04

代理节点与远程节点集合

节点字段必须对应真实服务

proxies 保存节点连接参数。每个节点至少需要一个可引用名称，以及协议要求的地址、端口和认证字段。节点是实际出口，策略组是选择出口的方法，两者不能互换。订阅已经提供节点时，通常无需逐个手写；只有需要检查字段、接入自有服务或建立最小测试配置时，才应编辑节点段，并先保留原始内容。

下面使用 HTTP 代理展示字段结构，域名与认证内容均为假值，不能直接建立连接。server 只填写主机名或地址，不要附加 https:// 和网页路径；port 是远端服务的端口，不是本机混合端口。认证字段要以服务端提供的信息为准，不能通过修改名称或换一个端口猜出可用配置。

proxies:
  - name: "教学出口"
    type: http
    server: proxy.example.com
    port: 443
    username: "your-username"
    password: "your-password"
    tls: true
    sni: proxy.example.com
    skip-cert-verify: false

name 在配置内部承担标识作用。改名后，需要同步更新策略组和直接指向该节点的规则；名称相同而参数不同，也容易在合并时产生歧义。建议为本地补充节点使用可区分的前缀，但不要把密码、订阅识别码或个人联系方式写进名称。节点名可能出现在界面、日志和截图中，应当视为可被分享的信息。

协议参数与传输参数不要混填

不同协议的字段集合不同。Shadowsocks 常涉及加密方法与密码，Trojan 使用其认证与 TLS 配置，VMess、VLESS 等协议又有各自的身份与传输字段。看到别人的配置里有 uuid、network 或传输选项，不代表这些字段适用于当前节点。先确认协议，再核对服务端的传输方式，最后确认内核支持范围，不能把多种示例拼成一个节点。

TLS 的服务器名称与证书验证是另一层检查。使用地址连接时，服务端证书可能仍然签发给域名，因此需要按实际服务设置 sni；它不能任意编造。关闭证书验证会放弃重要的身份检查，不适合作为日常排错捷径。遇到证书报错，应检查系统时间、服务器名称与服务端证书链，相关分支见HTTPS 证书错误成因与处理。

节点字段里的 UDP 能力也要分层判断。内核支持某种传输，不代表远端服务、所在网络与目标应用都支持同一路径。HTTP 代理示例不能被当作任意 UDP 出口。网页正常而语音、游戏或其他应用异常时，应检查实际使用协议和远端能力，不要只看客户端是否显示连接成功。订阅中未知的协议扩展也应先确认，而不是直接删除。

provider 是节点集合，不是策略选择

proxy-providers 可以从文件或远程资源加载一组节点。策略组通过 use 引用集合名称，再把其中节点加入可选范围。远程资源需要返回内核能够识别的节点集合格式；一个完整订阅文件与一个 provider 文件未必能互换。资源能下载成功，只证明取得了内容，仍需确认格式、字段和节点列表是否有效。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: "订阅出口"
    type: select
    use:
      - local-nodes

上例依赖本地文件存在，文件内容应包含对应的 proxies 列表。相对路径通常按内核工作目录或客户端指定配置目录解析，不一定是当前编辑器打开的目录。下载、更新和健康检查是不同动作：更新负责取得节点参数，健康检查负责探测可用性，选择策略决定实际使用哪个节点。某一步成功不能替代另一步的结果。

真实订阅链接通常带有个人访问凭据。不要放进公开配置、问题截图或代码仓库；需要展示结构时替换为明显假值。更新失败应先检查网络、订阅有效状态和返回内容类型，再处理 YAML。服务端返回登录页或错误说明时，即使文件扩展名仍是 YAML，也不可能作为正常节点集合加载。

选择逻辑 / 05

策略组类型与引用关系

先让手动选择路径成立

proxy-groups 把节点或其他策略组织成可选择的出口。初次编写时，先建立一个 select 组，并在界面手动选择已确认可用的节点。这样可以把“节点连接失败”和“自动选择逻辑不符合预期”分开。规则最终可以指向组名；组再解析到实际节点，形成清楚的引用链，不必为每个域名重复填写节点名。

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - 教学出口
      - DIRECT

  - name: "网页访问"
    type: select
    proxies:
      - 手动选择
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,网页访问
  - MATCH,手动选择

这段示例依赖前一章定义的“教学出口”。访问示例域名时，规则先交给“网页访问”；若该组选择“手动选择”，则继续使用后者当前选中的成员。嵌套可以减少重复管理，但不要形成循环。甲组引用乙组、乙组又引用甲组，无法产生一个明确出口。检查配置时从规则目标向下追踪，直到节点或内置策略为止。

自动探测不等于业务体验

url-test 按探测结果选择成员，fallback 按候选顺序使用可用成员，load-balance 按相应策略分配连接。它们解决的问题不同，不能只因为都有自动行为就随意替换。测速地址反映的是到该探测目标的结果，不代表某个视频站、工作服务或账户登录都具有相同表现；遇到特定业务异常，应增加对应业务的实际验证。

proxy-groups:
  - name: "自动探测"
    type: url-test
    proxies:
      - 教学出口
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

示例为了展示结构只放一个候选，实际比较需要多个可用成员。interval 是探测间隔，tolerance 用于减少因微小差异引发的切换，lazy 会影响组未使用时的探测行为。探测越频繁，后台请求越多，并不总能带来更好体验。移动设备还需要考虑后台限制与耗电，先使用客户端合理默认值，再按明确现象调整。

自动组切换后，已有长连接往往仍沿用原出口，新请求才采用新的选择。测试时应新建连接，并核对连接面板中的实际链路。某些服务会把登录状态与出口环境关联，频繁切换可能增加重新验证的机会。需要保持会话稳定时，可以为该业务建立单独的手动组，而不是让所有连接共享同一套自动切换行为。

集合引用、过滤与保留选择

组内的 proxies 显式列出成员名称，use 引用 provider 名称。过滤表达式通常针对名称筛选，不会证明节点确实位于名称描述的位置，也不会验证其网络属性。订阅改名后，过滤条件可能筛出空集合。先查看最终成员列表，再检查表达式；不要因为组名仍存在，就判断其内部仍有可用节点。

内置 DIRECT 表示直连，REJECT 表示拒绝连接，两者都不是远端节点。把直连放进自动探测组，会让它参与候选比较；如果本意是仅在故障时人工切换，应放到外层手动组。自动后备与直连后备也不是同一概念：是否允许绕过代理属于路由决定，需要按实际使用场景明确安排。

某些客户端会保存策略组选择，重载配置后尽量恢复原选项；这通常依赖组名、成员名和持久化机制。改组名或订阅移除节点后，旧选择未必能恢复。内核的 profile.store-selected 可涉及选择保存，但客户端也可能自行管理状态。检查界面当前值比单看 YAML 更可靠，不要依赖文件中的排列顺序推断最终选中项。

新增策略组后，依次检查：成员是否存在、是否产生循环、规则是否引用正确、当前选项是否可用。只有四项都确认，策略组才算接入实际流量路径。

需要区分“规则”“策略组”“节点”时，可把它们理解为匹配条件、选择入口与连接参数三层。规则决定交给谁，组决定用哪个，节点决定如何建立远端连接。保持层次简单，后续替换节点时通常只需修改成员，不必重写整套业务规则。

流量匹配 / 06

规则顺序、规则集与兜底

从上到下，命中后采用目标策略

在规则模式下，常规路由规则按顺序匹配，命中后使用该条规则指定的目标。更具体的例外一般放在更宽泛的规则之前，最后使用 MATCH 接住未匹配连接。把兜底提前，会使其后的规则失去机会。一个域名在列表里出现，并不说明该条规则实际生效；前面可能已经有覆盖它的后缀规则、地址规则或规则集。

rules:
  - DOMAIN,login.example.com,手动选择
  - DOMAIN-SUFFIX,example.com,DIRECT
  - 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,手动选择

上例先把一个精确登录域名交给代理，再将其余示例域名交给直连。若互换前两条，登录域名会先命中后缀规则。示例中的目标“手动选择”必须已定义。规则语法里的逗号是字段分隔符，不要替换成中文逗号；目标名称也不要额外添加解释文字。编辑规则后，先挑一个明确目标，观察命中的类型和策略，再验证更多网站。

域名信息与地址信息并不总是同时存在

域名规则需要内核获得目标域名。通过显式 HTTP 代理或 SOCKS 域名请求时，信息通常较清楚；应用先自行解析再连接地址时，内核看到的信息可能不同。fake-ip 映射与嗅探可帮助恢复域名，但各有条件，不能保证识别所有加密流量。先确认连接面板实际显示了什么，再判断某条域名规则为什么没有命中。

no-resolve 用于适用的地址匹配规则，避免仅为尝试该规则而主动触发域名解析；若连接已经带有可匹配地址，它仍可能命中。这个选项不是禁止所有 DNS，也不会改变应用自己发出的查询。地址规则放得很靠前时，是否触发解析会影响路径与耗时，应结合域名规则的优先级考虑，而不是给每条规则机械追加同一个选项。

规则集声明与使用需要成对出现

rule-providers 定义可复用规则集合，RULE-SET 把集合接入规则列表。声明本身不会自动分流。behavior 决定内容按域名、地址段或经典规则解释，format 决定文件编码形式；两者必须与实际文件相符。远程更新地址与本地缓存路径也应区分，缓存存在不代表最近一次更新成功。

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

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,手动选择

与此配套的本地规则文件可写为下面的结构。这里的条目属于域名集合，不是完整的三段路由规则，因此不再附加策略名称。若把经典规则行塞进域名集合，可能发生解析错误或不符合预期的匹配。迁移第三方规则源时，先看文件实际内容，不要只根据文件名猜测格式。

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

对路由器、容器或 TUN 流量使用进程规则时，还需确认运行环境能否识别进程。桌面应用名规则不能原样推断为路由器可用，因为路由器看到的是远端设备连接。部署背景可看OpenWrt 旁路由部署概览。规则应按可观测信息编写，不要让配置依赖环境根本无法提供的字段。

最终验证至少记录目标域名、命中规则和实际出口三项。只看网页能打开，无法区分是代理成功还是直连可达。出现异常时先临时增加一条精确规则验证，再决定是否扩大匹配范围；过宽的关键词或整段地址放行，容易影响其他业务，也会让后续排错更难复现。

持久修改 / 07

订阅覆写、合并与更新保留

先识别配置生成链路

订阅更新会重新取得远端内容，直接编辑下载文件的改动可能随之丢失。客户端提供的覆写、合并、扩展配置或脚本，通常是在原始内容之上再加工，但它们的执行位置与合并算法并不统一。先确认原始订阅、客户端通用设置、订阅专属覆写和最终运行配置的先后关系，再决定把修改放在哪一层。

端口、系统代理与 TUN 等项目常由客户端界面管理，订阅中的同名字段可能被覆盖。规则和策略组则可能由订阅专属扩展追加。不要同时在多个入口修改同一字段，否则下次重载后很难解释谁最终获胜。先选择一个负责入口，修改后打开实际运行配置确认结果；界面显示的输入内容只代表意图，不一定等于内核最后读取的值。

映射合并与列表合并分开看

映射可以逐字段递归合并，也可以整体替换。例如覆写只写 dns.enable，某些机制会保留原有上游，另一些机制可能替换整个 DNS 段。列表更需要谨慎：规则、节点和策略组可能被追加、前插、按名称合并或整体替换。没有通用保证说“合并 YAML 就一定会保留原列表”，应以当前客户端说明和生成结果为准。

# 原配置中的一个片段
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

# 覆写意图：只更改这一项
# 在客户端的独立覆写入口填写，不要重复追加到原文件
# dns:
#   enhanced-mode: redir-host

上例把覆写意图写成注释，是为了避免复制后在一个映射里产生重复键。实际操作应在客户端独立覆写入口填写对应字段，再检查 nameserver 是否仍然保留。如果丢失，说明当前机制不能按预期递归合并，需要显式保留整个 DNS 段。测试过程中不要顺带改上游，这样才能把变化归因到合并行为。

规则前插、去重与命名冲突

本地例外规则通常需要放在订阅规则之前，才能在宽泛规则或 MATCH 之前命中。如果工具仅支持追加，把例外加在末尾可能完全不起作用。先检查生成后的顺序，确认兜底仍在最后，再测试实际命中。不要为追求“去重”随意排序规则，路由列表的先后本身就是语义，字母排序会改变行为。

添加策略组时，最好使用不容易与订阅冲突的名称。若订阅更新后出现同名组，按名称合并可能改变其成员，整体替换又可能删除原有选择。使用节点名称过滤时，还应考虑远端改名。把关键业务绑到稳定的本地策略入口，再让该入口选择订阅组，通常比让每条自定义规则直接依赖远端节点名称更容易维护。

脚本覆写能力更灵活，也更容易破坏结构。修改前应先确认脚本取得的是对象还是文本，返回值是否必须是完整配置，以及异常时客户端是保留旧配置还是停止加载。不要复制来源不明、会读取外部资源的脚本。配置可能包含订阅地址和认证字段，应当把扩展脚本视为能够接触这些内容的程序，而不是普通注释。

用一次更新测试保留能力

完成覆写后，先重载并验证功能，再手动执行一次订阅更新。比较更新前后的运行配置，检查自定义规则、组名、DNS 上游与端口是否符合预期。更新成功并不等于覆写成功，旧配置仍运行也不等于新配置已加载。注意日志中的生成与重载结果，确认测试针对的是当前文件，而不是更新失败后保留下来的旧实例。

建议保存三份材料：可用原配置、独立覆写内容、修改原因记录。恢复时先回到原配置，再单独启用覆写，避免把订阅变化和本地改动混在一起排查。

记录不用很长，但应写明修改字段、预期结果与验证目标。比如“为局域网设备保留真实解析结果”比“优化 DNS”更有帮助。今后问题复现时，可以根据目标判断这项改动是否仍必要。没有明确用途的历史覆写应逐项停用验证，而不是长期保留后再不断叠加补丁。

迁移客户端时，不要只复制生成后的运行文件。旧客户端注入的控制接口、文件路径和面板设置可能不适用于新环境。先从客户端下载页选择适合的平台，普通用户优先考虑 Clash Plus；重新导入原始订阅，再迁移确实需要的本地覆写，最后按本页验证流程逐项检查。

验证闭环 / 08

配置检查、连接验证与恢复

先检查语法，再检查接管范围

保存文件后，先使用客户端自带的检查或重载功能，查看是否存在解析错误、未知引用和文件路径异常。独立运行 mihomo 时，可以在正确的工作目录执行下面的测试命令。可执行文件名称与路径按本机实际位置调整；命令检查成功，不代表每个远端节点已经能够连接，也不会替代系统代理与 TUN 的接管验证。

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

报错带行号时，从该行向前检查同层缩进和上一行的引号、冒号。解析器指出的位置可能只是发现问题的位置，真正原因可能在更早的未闭合字符串。若提示策略不存在，按节点、组、规则三层核对名称；若提示资源文件不存在，检查工作目录、相对路径与访问权限。不要一看到红字就把整段配置替换掉。

用最小直连配置隔离本地问题

下面是一份独立的最小直连测试配置，只用于验证内核监听与规则基础路径。它不包含远端代理，也不会让目标流量自动变为代理出口。建议单独保存、单独加载，避免覆盖原订阅。若原客户端同时占用相同端口，先停止原实例，或明确更换测试端口并同步测试命令。

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

rules:
  - MATCH,DIRECT

如果最小配置也无法启动，优先处理端口占用、权限与可执行文件问题。能启动后，再用一个在当前网络本来就能访问的地址发起显式代理请求。不同系统对 curl 的命令映射可能不同，Windows 上可明确使用 curl.exe。下面的命令不修改系统代理，只测试指定的本地 HTTP 代理入口。

curl --proxy http://127.0.0.1:7890 --head https://example.com

收到 HTTP 响应说明这次请求完成了对应链路，但响应状态仍需结合目标站判断。连接本地端口被拒绝，重点检查监听与端口；成功连接代理后超时，再看 DNS、路由与出口；出现证书验证错误，则进入证书与时间检查分支。不能把所有失败都归为“节点不行”，也不要通过关闭证书验证掩盖原因。

逐层恢复到实际配置

最小测试成立后，恢复原配置，先只验证一个已知节点和一个手动组，再加入 DNS 设置、规则集及覆写。每加一层就重复同一个测试目标，记录日志差异。这样可以定位问题从哪层开始出现。显式代理能访问、普通浏览器不能访问时，更接近应用代理设置或接管范围问题，不应立即重写节点参数。

TUN 还涉及虚拟网卡、路由、权限与 DNS 接管。开启后应分别测试域名请求和地址连接，检查局域网资源是否仍可访问。其他 VPN、虚拟机和安全软件也可能修改路由，不宜同时切换多个网络工具。桌面系统代理与 TUN 可以有不同使用场景，先选择一个明确路径完成验证，再根据应用需求决定是否组合使用。

验证规则时，查看新建连接命中的规则和最终出口，不要只看总开关状态。浏览器缓存、连接复用和后台请求可能让一次页面刷新包含多种结果，必要时关闭目标应用后重试。共享截图时遮住目标账户、订阅地址和节点认证信息，只保留定位问题需要的字段、错误文字和相关配置段。

无法联网时先恢复，再继续定位

恢复顺序是先关闭新启用的接管功能，再还原系统代理，最后加载此前保存的可用配置。退出客户端后仍不能访问时，检查系统是否残留指向已关闭端口的代理设置；TUN 或其他工具留下的路由也需要按其正常关闭流程恢复。不要连续安装多个客户端试图覆盖故障，这会增加端口和系统设置冲突。

网络恢复后，再从最近一次改动开始逐项重做。订阅更新、内核切换、规则变更和系统网络调整，应尽量分开执行。持续出现“连接成功但网页打不开”时，可按八步断网排查清单核对订阅、出口、系统入口和 DNS；需要重新走通操作主线，则返回订阅导入与连接教程。

完成一次配置修改的标准：文件能够加载，目标请求按预期匹配，订阅更新后改动仍保留，并且已经知道如何恢复。把这四项做完，再继续下一项调整。