Clash 从零到进阶安装、订阅与规则分流

阶段 01 / 先认识连接链路

核心概念：客户端、内核与配置

从首页开关看起

打开 Clash 类客户端，通常会看到配置、代理、日志和启动开关。先不要同时改动这些页面。客户端是提供按钮、通知和系统授权的应用；内核是实际读取规则、建立连接和转发请求的程序。mihomo 是 Clash 生态中常见的内核，不等于某一个界面应用。同一份配置在不同客户端里，可能由不同内核或不同的启动参数执行，因此界面相似并不代表所有功能完全相同。

配置文件是一份网络处理说明，通常使用 YAML 格式。YAML 通过缩进表达层级，空格位置也属于内容。配置里可以保存代理节点、策略组、域名解析方式和分流规则。订阅则是获取这些内容的入口，常见形式是一个链接。链接下载得到的可能是完整配置，也可能只是节点集合；能否直接导入，取决于客户端识别的格式，而不是链接名称里是否含有 Clash。

区分节点、策略组和规则

节点是一个可连接的代理端点，包含服务器地址、端口、协议及必要的认证信息。策略组负责从若干出口中选择一个，例如手动选择、按测试结果选择或故障切换。规则负责回答另一件事：这次访问应交给哪个出口。规则把请求送到策略组，策略组再选节点；如果规则指定直连，请求就不通过远端代理节点。只切换节点，不一定会改变一条已经被规则判定为直连的请求。

可以把一次访问按顺序拆开：应用发起请求，系统把流量交给客户端，内核获取目标信息，按规则选择出口，再连接目标或代理服务器。域名解析穿插在其中，用来把名称转换成地址。任一环节出错，表面都可能只是网页打不开。排查时先确认请求有没有进入客户端，再看命中规则，最后看出口连接结果，比直接反复更换订阅更容易找到原因。

本机 VPN 接口不等于远端服务

Android 上出现 VPN 图标，表示系统允许某个应用接管相应流量。VpnService 是系统提供的本机 VPN 接口，客户端借它读取并处理流量。这个图标只能证明本机接口处于工作状态，不能证明订阅有效、节点可用或目标网站能够访问。代理服务启动成功与远端连接成功是两个独立检查点，后面的验证步骤会分别观察它们。

另一个容易混淆的概念是系统代理。桌面系统代理通常向应用提供一个代理地址，由应用决定是否遵循；虚拟网卡方式则从更低的网络层接收流量。Android 客户端也可能提供分应用设置，明确哪些应用进入 VPN。浏览器能访问而另一款应用失败，首先应检查接管范围和应用自己的网络设置，不能仅凭浏览器结果推断整台设备的流量路径。

本手册以具备相应功能的 mihomo 系客户端为主要说明对象。示例中的字段是否受支持，仍要看实际内核和客户端的配置处理方式。图形界面可能在启动时生成额外字段，甚至覆盖文件中的同名项；因此后续所说的检查配置，既包括保存的源文件，也包括应用真正加载的运行配置。先建立这一区分，才能解释文件已经修改、运行行为却没有变化的情况。

阶段 02 / 确定设备与功能需求

选择客户端：平台、架构与内核能力

先按平台选择，再比较功能

进入客户端下载页，先选设备系统，再读安装说明。Android 首推 Clash Plus，也可按配置兼容性选择 Clash Meta for Android、FlClash 或 Surfboard。首推不代表其他客户端的配置能直接通用，特别是 Surfboard 使用的配置体系与 Clash YAML 不同，不能把文件改个后缀就当作已经完成转换。已有服务提供方配置时，应先确认其明确支持的客户端和订阅格式。

选择时优先回答三个问题：设备能否安装、订阅能否识别、所需功能是否存在。只需要导入订阅和切换节点，不必为了一个暂时用不到的参数迁移全部配置。需要规则覆写、分应用代理或特定 DNS 行为时，再检查客户端是否提供对应界面。界面提供某个开关，也应阅读其说明，因为相同名称可能对应不同的底层实现，不能仅凭截图判断兼容性。

安装包架构要与设备对应

Android 安装包名称中的 arm64、arm 和 universal，分别表示面向不同处理器及运行环境的构建。大多数较新的手机使用六十四位 ARM 环境，但不能只凭购买年份推断；部分设备的系统用户空间仍有额外限制。优先查看系统信息或下载页说明。通用包往往体积更大，也不意味着可以绕过系统最低要求、签名冲突或设备策略限制。

电脑端同样需要区分处理器。Apple Silicon 与 Intel 的 macOS 构建应按芯片选择；Linux 的软件包格式还要匹配发行版。不要把内核压缩包当作普通图形应用安装。下载页的 mihomo 内核区面向服务器、路由器或明确需要命令行部署的用户，它通常没有供手机用户点击导入订阅的完整界面，也不会自动替你完成所有系统接管设置。

迁移前保留可以回退的状态

Clash for Windows 与 ClashX Meta 已停止维护，下载页保留归档入口用于既有环境。新部署应优先考虑仍在维护的替代方案。迁移时不要只导出节点列表：还应记下当前策略组选择、分应用范围、本地规则及启动设置。新客户端可能能读取订阅，却不会继承原应用的系统授权和电池设置，这些部分需要重新确认。

在同一台设备上安装多个客户端可以用于比较，但实际测试时只启动一个接管网络的服务。两个应用争用系统代理或 VPN 接口，会让结果难以解释。先停止原客户端，导入同一来源的配置，再用相同网络和相同目标进行测试。比较结果应记录行为差异，例如某规则是否命中，而不是只凭一次页面加载快慢作结论。

移动端与电脑端共用订阅时，保留共同节点和规则，再把设备特有设置留在本地。Android 的应用包名分流不能直接替代桌面的进程规则；桌面监听端口也不一定需要复制到手机。关于停更客户端的迁移背景，可继续阅读mihomo 系客户端替代路线。完成本章后，应能说明选择当前应用的理由，并确认它支持接下来要使用的配置格式。

阶段 03 / 完成本机安装与授权

Android 安装、VPN 授权与后台设置

从安装结果开始确认

在Android 下载区选择适合设备的安装包。下载完成后，从浏览器下载列表或系统文件管理器打开文件。系统如果提示不允许此来源安装应用，进入对应来源的授权页面，允许本次使用的浏览器或文件管理器安装，然后返回继续。授权对象是打开安装包的应用，不是整个网络；安装结束后，可以按自己的设备管理习惯收回这项权限。

如果提示应用未安装，先看系统给出的具体原因。空间不足时清理可用存储；架构或系统不受支持时换成符合要求的构建；同名应用签名不一致时，不要立即卸载旧应用。先导出配置与本地设置，确认可以恢复，再决定是否更换安装来源。卸载通常会清除应用私有数据，订阅链接、规则覆写和策略组选择不一定能够从系统备份完整找回。

首次启动只处理必要权限

打开客户端后，先确认应用名称和配置入口。导入一份有效配置，再点启动服务。首次连接通常出现 Android 的 VPN 连接请求，核对请求来自正在操作的客户端后确认。这个授权允许应用创建本机网络接口，不会替你购买远端代理服务。若没有出现提示而启动失败，查看系统是否已有其他 VPN、工作资料策略或设备管理限制阻止创建连接。

系统通常只允许同一用户或资料空间内有一个活动的普通 VPN 服务。另一款代理、企业接入或防火墙应用正在运行时，新的连接可能替换原连接，也可能被策略拦截。先明确当前任务需要哪一个服务，停止冲突应用后重试。不要把启动失败归因于节点超时，因为此时请求可能还没有走到远端节点；应先处理本机授权，再观察日志中的连接记录。

锁屏后断连，检查电池与后台限制

长按应用图标进入应用信息，找到电池或后台耗电管理。需要持续运行时，将限制调整为允许后台活动或不受限，具体名称随系统而变。部分厂商还单独提供自启动、后台运行保护和最近任务锁定；这些选项的作用不同，不能只开一个就认为全部完成。修改后先保持屏幕亮起验证，再锁屏一段时间，确认通知与服务状态是否仍然存在。

通知权限与 VPN 授权也不是同一件事。允许通知有助于观察服务、快速停止连接，但通知被隐藏不必然表示服务已经停止。反过来，通知仍在也不能证明远端正常。排查后台问题时，记录锁屏前后服务开关、系统 VPN 状态和日志时间是否连续。若应用被系统结束，重新打开时常会出现服务重建；若服务一直存在而访问失败，应转向网络切换和节点连接检查。

安装后的第一次测试建议使用普通家庭网络，不同时启用路由器代理或复杂的工作网络策略。先打开一个原本就能直连的网站，再访问需要代理的目标，分别记录结果。移动网络和无线网络都要测试时，一次只切换网络，不同时更换节点和配置。这样失败发生在哪一步会更清楚，也能区分设备安装问题与当前网络的限制。

完成授权后可参考VpnService 授权与省电白名单设置要点补查厂商相关设置。本章的完成标准不是只有一个 VPN 图标，而是配置已加载、服务能启动、基础访问正常，并且锁屏后不会立即被系统终止。达到这些条件再开启自动启动，能够减少设备重启后难以判断的连锁问题。

阶段 04 / 建立可更新的配置来源

订阅导入、配置检查与更新边界

先判断拿到的是什么内容

打开配置页，选择新增配置或从链接导入，粘贴服务提供方给出的订阅地址。保存时使用能辨认来源的本地名称，不要把完整链接当名称显示。订阅地址可能带有个人授权信息，能够访问它的人可能取得你的节点配置；截图、日志求助和同步笔记时都应隐藏链接中的识别参数。不要把私人订阅粘贴到不熟悉的在线转换网站来测试格式。

导入后先看下载结果，再选择该配置作为当前配置。列表里多了一项，只说明内容已经保存，不代表它已经被加载。客户端可能要求点选、启用或重新载入。随后打开代理页面，确认是否出现预期的策略组和节点。如果只有节点而没有规则，可能得到的是节点集合；如果显示网页文本、登录页面或解析错误，应回到订阅来源确认链接用途，而不是先修改本地 DNS。

检查 YAML 时先看结构

配置解析失败时，记录错误行号及其附近内容。常见原因包括用制表符代替空格、同级项目缩进不齐、列表项缺少连接符，以及字符串中的特殊字符没有正确处理。错误报告的位置也可能在真正问题之后，例如上一行引号没有闭合。先恢复最近一次可用副本，再逐段核对修改，不要用批量替换把整份配置的缩进全部改掉。

下面是用于理解结构的最小直连配置，没有远端代理节点。它可以帮助区分配置能否被内核读取与代理服务能否连接两个问题，但不能代替你的订阅。图形客户端可能自行管理监听端口和 DNS，导入前应确认其是否允许完整配置，不能把这段示例直接拼接到订阅末尾形成第二套同名字段。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

其中混合端口用于接收本机支持的代理请求，禁止局域网访问则限制其他设备使用该监听入口；规则模式按规则处理访问，日志级别用于日常观察。末尾规则把尚未匹配的请求交给直连。端口如果被其他进程占用，内核仍可能启动失败，因此语法有效并不等于运行环境满足。遇到端口冲突应关闭占用者或在客户端允许的入口修改端口。

把远端更新与本地修改分开

订阅更新通常会替换远端配置内容。直接编辑下载得到的文件，下次更新后可能丢失。优先使用客户端提供的覆写、合并或本地规则功能，把个人修改独立保存；但先确认该功能的执行时机和合并规则。有的工具会追加列表，有的会替换整个字段，不能假设所有名为合并的功能都会保留原来的策略组和规则顺序。

设置更新间隔时，考虑来源限制与实际变化频率。更新过密可能触发请求限制，也会在网络不稳时反复制造失败提示。先手动更新一次，确认配置能被重新加载，再开启定时更新。如果更新失败但旧配置仍可用，先保留当前工作状态，检查订阅有效期、链接权限和下载网络；不要为了刷新列表，先删除唯一能工作的配置。

多设备同步建议同步配置来源和必要的个人规则，而不是覆盖每台设备的全部应用数据。手机和电脑可以使用相同订阅，但系统接管、监听端口、应用范围及文件路径应分别保留。具体取舍见手机与电脑共用订阅的同步方案。本章结束时，应明确当前加载哪份配置、它从哪里更新，以及哪些本地改动需要单独备份。

阶段 05 / 先确定请求交给谁

Rule、Global 与 Direct 的使用顺序

日常先用规则模式

打开客户端的模式设置，日常优先选择 Rule，也就是规则模式。内核按配置中的规则依次判断目标，决定直连、拒绝或进入某个策略组。规则模式不是所有请求都代理，也不是只对浏览器生效；它处理的是已经进入内核的请求。若某个应用被排除在 VPN 之外，或桌面程序根本不使用系统代理，切换规则模式不会把这些请求自动拉进来。

进入代理页面后，找到规则实际指向的策略组，再选择可用出口。配置里可能同时有总选择组、自动选择组和按服务划分的组。只更改其中一个，不一定影响目标访问。先从日志或连接页面查看该请求命中了哪个组，再调整那个组。名称类似的两个策略组可能互不关联，不能凭一个看起来最醒目的按钮判断它就是所有流量的最终出口。

全局模式用于对照，不代替接管检查

当某个目标在规则模式失败，可以短暂切换 Global，并确认全局策略组选择了预期节点，再重复相同访问。如果此时正常而规则模式失败，优先查规则命中、策略组选择和解析差异。这个结果只能缩小范围，不能单独证明原规则一定错误，因为两种模式可能连带使用不同出口。对照时保持网络、目标和节点不变，才能减少额外变量。

全局模式也不意味着每个设备数据包都必然经过远端代理。分应用排除、本地路由、系统限制，以及客户端实现都会影响接管范围。若切到全局后日志里仍完全没有目标应用请求，继续换节点的意义不大。此时应检查应用是否被纳入、系统 VPN 是否有效，以及程序有没有独立的代理或直连设置。把模式选择与接管范围分开观察，是本章最重要的原则。

直连模式与停止服务不是一回事

Direct 模式让已进入内核的请求走直连出口，客户端的本机接口和 DNS 处理可能仍然存在。真正停止服务后，系统网络路径又可能不同。因此直连模式能用、停止服务不能用，或两者相反，都需要检查接口、解析及系统的阻止绕过设置。不能把直连模式当作所有网络设置都已经恢复原状，也不要在不知道原因时同时删除系统 VPN 配置。

修改模式后，优先新建一次连接再验证。浏览器会复用连接，应用也可能保存长连接；旧连接通常不会因为切换策略就自动重建。可以关闭相关页面重新打开，或只在客户端允许时结束对应连接。清空全部连接会中断正在进行的任务，应先保存工作。验证应观察新连接的出口和命中规则，而不是只刷新一个仍在复用旧会话的页面。

节点测试结果也只代表某次测试目标和测试方式，不能等同于所有网站的可达性。实际请求可能使用不同协议、端口或地址族。选择节点后，用目标应用发起真实请求，并查看连接错误。如果某应用正常、另一个失败，先比较它们是否被接管、是否使用同一策略组，以及是否需要不同的网络能力，再决定要不要更换节点。

完成对照后回到规则模式，把临时更改记录下来。若一直停留全局模式，很容易掩盖原本需要修正的分流问题，也可能让本来应直连的本地服务走错出口。关于桌面浏览器和终端接管差异，可阅读系统代理不生效的分开排查方法。下一章会把这里看到的命中结果对应到具体规则。

阶段 06 / 从一条规则开始修改

规则分流：匹配顺序与本地覆写

先定位现有规则，再新增规则

打开日志或连接详情，发起一次目标访问，找到目标域名、匹配规则和最终策略。规则一般自上而下处理，首次命中后就决定出口，因此更具体的例外通常要放在更宽泛的规则之前。追加在兜底规则之后的内容可能永远没有机会生效。修改前先确认当前配置有没有规则集合、本地合并层或客户端自动插入的规则，运行时顺序不一定等于源文件顺序。

域名精确匹配只针对指定名称；域名后缀匹配可涵盖该域名及其子域名；地址段规则按目标地址判断。三者解决的问题不同，不能把一个应用界面上显示的品牌名直接当作域名规则。应用可能访问多个域名，也可能连接固定地址。先根据日志收集实际目标，再用足够小的规则范围试验，避免为了解决一个页面，把整个大范围域名都交给同一出口。

用完整最小示例理解顺序

下面示例不包含远端节点，演示本地域名、私有地址与兜底规则的排列。它可以作为独立的直连实验配置；若将其中规则移入订阅，应在客户端的本地规则或覆写入口操作，并保留原配置的其他字段。示例只覆盖部分常见本地地址，不是完整的内网分类清单，也不保证适合企业使用的特殊地址规划。

mode: rule
rules:
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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
  - MATCH,DIRECT

最后的 MATCH 接住前面没有匹配的请求。实际订阅里，它可能指向一个代理策略组；修改时必须使用该配置中真实存在的策略组名称，名称不同会导致引用失败。地址规则后的 no-resolve 表示不为匹配该条规则而主动发起域名解析，并不禁止整个请求流程中的其他解析。理解这个边界，才能避免把它误当成全局 DNS 开关。

规则集合与策略组分别管理

规则集合用于维护一批匹配条件，策略组用于管理出口选择，两者不要混为一谈。规则集合更新失败时，节点仍可能可用；节点订阅更新成功时，远端规则也不一定已经刷新。检查规则提供器时，核对来源格式、行为类型、下载结果和本地缓存。首次下载没有成功，运行结果可能与已经保存过旧缓存的设备不同，迁移测试时要特别留意这一点。

需要按应用分流时，先查客户端提供的是分应用 VPN 范围，还是内核进程规则。把某应用排除出 VPN，意味着该应用可能完全不进入内核；给某应用匹配直连，则可能仍由内核处理。两种方式在日志可见性和 DNS 行为上可能不同。Android 的应用标识与桌面进程名称也不同，不能把电脑规则直接复制到手机后就认为已完成适配。

每次只添加一条规则，保存并重新加载，再创建新连接验证。如果界面提示成功但结果没变，按顺序检查是否加载了目标配置、覆写是否启用、规则是否在兜底之前，以及连接是否仍被复用。确认这些环节后，再考虑域名识别和 DNS 映射问题。直接不断增加重复规则，通常只会让配置更难读，也增加下一次更新时的合并冲突。

当多个目标出现同样错误，先找共同策略组或共同解析路径，不要立刻为每个域名单独加例外。过度细分会把真正的出口问题藏在规则里。更多概念可查Rule 术语说明，常见配置问题可跳到FAQ。本章完成标准是能解释一条请求为什么走当前出口，并能通过单条可回退的修改改变结果。

阶段 07 / 扩展接管前先理解解析

TUN、VpnService 与 DNS 的配合

虚拟网卡解决什么问题

TUN 是一种虚拟网络接口方式，用于接收网络层流量。桌面端常在系统代理覆盖不足时使用，例如程序不遵循代理设置，或需要处理特定的非浏览器流量。它与 Rule、Global 不是同一维度：前者决定流量怎样进入内核，后者决定进入后走哪个出口。开启 TUN 后仍然可以使用规则模式，不需要为了虚拟网卡而把全部请求都改为全局代理。

Android 客户端通常通过 VpnService 获取系统流量，但不应把每个桌面 TUN 参数原样复制到手机。移动端可能由客户端建立接口、路由和文件描述符，再交给内核工作；桌面的自动路由配置则可能依赖额外权限和系统命令。先使用客户端提供的开关和默认值，确认它支持自定义相关字段后再调整，避免界面生成的设置与手写配置互相覆盖。

开启前检查路由和权限

桌面端启用虚拟网卡时，系统可能要求管理员或服务权限。授权后先看接口是否建立，再检查普通网站、局域网设备和代理目标是否都可访问。如果代理节点连接自身又被送回虚拟网卡，可能形成循环；如果与其他 VPN 同时修改默认路由，可能出现部分流量走错路径。遇到此类问题先关闭新增的接管方式恢复网络，再检查路由排除与客户端文档。

局域网访问尤其需要单独验证。打印机、路由器管理页和网络存储可能依赖本地地址、组播发现或设备名称解析，不能只用能否打开一个公网网站来判断。优先保留客户端推荐的本地路由处理方式，再检查是否确有必要增加排除。不要为了临时访问一台设备，关闭所有防火墙或允许整个局域网使用本机代理，这些改动涉及另一组访问权限。

DNS 决定名称如何变成地址

DNS 是域名解析系统。浏览器输入名称后，需要得到地址或由代理端参与解析才能继续连接。解析成功并不保证该地址能连通，连接失败也不一定是解析失败。先区分日志中的名称解析错误、连接超时和认证错误，再决定是否修改解析配置。订阅下载用的解析路径也可能与代理运行后的解析路径不同，所以订阅无法更新和网页打不开未必属于同一故障。

部分客户端提供 fake-ip 模式，即先向应用返回用于映射的虚拟地址，再由内核保持域名与连接的对应关系。它有助于保留域名信息，但对某些依赖真实地址行为的应用可能需要例外。看到一个非公网的返回地址，不应立即认定遭遇错误解析。先确认是否启用了该模式、请求是否仍由同一内核处理，以及应用有没有绕过正常的解析链路。

加密 DNS 用于保护解析传输，不会自动保证出口正确。解析服务器本身也需要可达，启动阶段若依赖一个尚未建立的代理路径，可能陷入先有解析还是先有连接的循环。修改时先保留一条能够完成基础解析的路径，再逐步调整上游和分流。浏览器自带的安全 DNS、系统私人 DNS、客户端 DNS 都可能参与，应记录实际启用项，而不是同时换掉全部设置。

验证顺序可以固定为：接口存在、目标请求进入日志、域名得到合理处理、规则命中、出口建立连接。每一步都正常而个别应用失败，再检查地址族、UDP 支持或应用自身限制。节点对某种传输的支持不能从一次网页测试推断。完成本章后，应知道何时需要 TUN，也知道仅为了修复一个配置引用错误，没有必要扩大到整机虚拟网卡设置。

阶段 08 / 建立可重复的维护流程

更新、备份与分层排错

把三种更新分开处理

客户端更新、内核更新和订阅更新是三个不同动作。客户端更新可能改变界面、系统权限和配置处理；内核更新可能影响字段支持与网络行为；订阅更新主要改变节点、策略组或规则内容。一次全部更新后出现故障，很难确定来源。日常维护应先备份当前可用状态，再逐项变更，每做完一项都进行基本访问测试，确认正常后再继续下一项。

备份至少应覆盖配置来源、本地规则、策略组选择和系统相关设置。含订阅地址或认证字段的文件应存放在自己控制的安全位置，公开求助只提供脱敏片段。应用导出的备份可能包含个人信息，也可能不包含系统 VPN 授权；恢复前应阅读导出说明。不要把能恢复一份 YAML 理解为整个设备已经完整备份，电池限制和分应用列表可能仍需重新设置。

从最近变化与影响范围开始

发现无法上网时，先记录故障从什么时候开始，之前改了什么，以及影响一个应用还是全部应用。再区分无线网络与移动网络、直连目标与代理目标。如果停用服务后本机也无法正常访问基础网络，先修复网络连接或登录认证页面。网络入口尚未可用时，客户端里反复测试节点只能得到一串失败结果，不能帮助判断节点本身的真实状态。

节点超时表示某次连接没有在规定时间内完成，不直接说明是服务器停用。订阅失效、地址解析错误、当前网络限制、系统时间异常和协议不受支持都可能参与。先确认节点信息来自最近一次成功更新，检查设备时间是否自动同步，再比较另一种网络。详细顺序见节点超时、全部无法连接排查清单，不要同时修改服务器地址、端口和协议来碰运气。

日志只为回答具体问题而增加

日常使用保持适当日志级别。需要定位时，先准备可重复的操作，例如只打开一个目标页面，再短时间提高日志详细程度。捕获到问题后恢复原级别，避免长期产生大量记录。分享前检查域名、地址、订阅参数和认证信息是否需要隐藏；仅贴最后一句错误可能不足以判断，但整份未经检查的运行日志也不适合直接公开。

阅读日志时区分阶段：解析错误发生在获得地址之前，连接拒绝通常表示对端或中间设备明确拒绝连接，超时表示在等待期限内没有完成；这些现象不能相互替代。证书相关错误应先核对系统时间、服务器名称和网络环境，不应通过关闭安全验证来掩盖。配置解析错误则应回到文件结构，通常还没有进入真正的网络连接阶段。

每次修复后记录最小结论，例如恢复某条规则后目标正常，而不是笼统写网络好了。随后测试订阅更新、锁屏恢复和网络切换，确认修复没有破坏其他场景。保留一个最近可用的配置副本和简短变更记录，下一次故障就能优先回退到明确状态。遇到常见界面问题，可直接查常见问题分类，减少在整份手册中反复寻找。

阶段 09 / 从可用配置走向可维护配置

进阶路线：验证、分层与最小变更

先建立自己的验证清单

进阶不等于把所有功能都打开，而是能解释当前行为，并在修改后证明结果符合预期。先挑选几个稳定的测试场景：一个直连网站、一个需要代理的目标、一个局域网入口，以及一个日常使用的应用。每次变更后重复这些场景，观察接管、规则和出口是否一致。测试目标应来自自己的实际需求，不需要为了配置完整而加入从未使用的协议或规则集合。

为配置分层时，可以把来源分成远端订阅、本地策略和设备设置。远端订阅负责节点及通用规则，本地策略保存少量个人例外，设备设置处理 VPN 范围、监听端口和启动行为。各层只承担明确职责，更新时才能判断哪部分应该变化。若同一个 DNS 字段在订阅、覆写和客户端界面都被修改，应先找出最终生效来源，再决定保留哪一个入口。

用内核检查辅助编辑

有命令行使用经验时，可以用 mihomo 的配置测试功能检查本地文件。下面命令应在已安装内核、当前目录确有配置文件的环境中执行；它用于测试配置，不负责替操作系统建立代理接管。Android 图形客户端用户可以继续使用应用内的检查和日志功能，不必为了执行命令把内核安装到手机的额外环境中。

mihomo -t -f ./config.yaml

检查成功主要说明内核能够读取配置，并通过它执行的相关检查，不代表所有远端节点都已连通，也不代表路由和授权已经正确。涉及外部规则、提供器和资源文件时，还要看工作目录、相对路径及下载条件是否满足。终端启动与图形客户端启动可能使用不同目录，某个本地文件能在一处读取，不保证换个启动入口仍然有效。

编辑配置前保存副本，修改后先做语法检查，再在客户端重新加载，最后观察新建请求。遇到异常先恢复刚才的单项变更，而不是继续叠加补丁。需要比较文件时，只比较必要字段，并避免把认证内容粘贴到公开的差异工具。对订阅自动生成的复杂配置，优先使用已经理解合并规则的本地覆写，不要为了看起来简洁而手工删除暂时不懂的引用项。

远程控制与局域网共享需要额外边界

部分内核支持控制接口，供面板或客户端读取状态、切换策略。它与代理监听端口用途不同。普通单机使用没有必要把控制接口监听到所有网卡；确实需要远程管理时，应同时考虑认证、网络隔离和防火墙范围。不要把控制入口、订阅地址或带权限的面板链接公开分享，也不要把一个可以从浏览器打开的管理页面误当作适合公开部署的网站。

局域网共享代理同样应单独规划。允许其他设备访问后，本机成为这些设备的网络出口，需要确认监听地址、端口和允许来源。移动热点、公共无线网络与家庭网络的信任程度不同，不能用同一套开放设置长期运行。共享前先在受控网络验证一台设备，共享结束后恢复范围；是否需要认证以及如何限制访问，应以当前客户端实际支持的能力为准。

继续学习时按问题选择方向

若重点是多设备维护，继续研究订阅与本地覆写如何分离；若重点是应用兼容，学习 DNS、地址族与传输方式的关系；若重点是路由器部署，再研究接口、路由和服务管理。服务器或路由器上的配置还涉及开机服务、文件权限及网络防火墙，不应直接把手机上的成功配置视为完整部署方案。先在可以恢复的环境验证，再迁移到承担日常联网的设备。

最后保留一份简短的运行说明：使用哪个客户端、配置从哪里来、本地改了哪些项、如何确认正常以及怎样回退。这份说明比一长串无法解释的参数更有价值。需要重新走一遍基础操作时返回快速上手文档；需要更换设备时从下载页重新确认平台要求。能够复现、能够定位、能够恢复，就是这条学习路线的完成标准。