Mihomo
从零到进阶手册

核心概念：内核、客户端与连接路径

Mihomo 是网络代理内核，负责读取配置、接收连接、匹配规则并选择出站。Clash Meta 是理解其发展背景时常见的名称。桌面或手机上的图形客户端则负责配置导入、节点选择、权限申请与运行状态展示。界面能打开不代表内核已经启动，内核启动也不代表应用流量已经进入代理。理解这两层差异，是后续排查的起点。

先区分四个对象

客户端是操作入口，内核是实际处理网络请求的程序，配置文件是内核运行的依据，代理服务器是远端出站。订阅通常用于分发节点或完整配置，但不是代理软件本身。安装客户端不会自动产生可用服务器；节点能建立连接，也不代表其带宽、出口地区或协议能力符合当前用途。

一份配置可能同时包含监听端口、DNS、代理节点、策略组、规则和远程规则集。策略组把若干出站组织成一个可选择的目标，规则再引用这个目标。界面里的节点选择只是其中一层：如果请求最终命中了直连规则，切换代理组中的节点不会改变该请求的路径。

沿着请求方向理解分流

浏览器访问一个域名时，需要先得到地址，再建立连接。请求可通过系统代理设置进入本地监听端口，也可由 TUN 虚拟网卡接管。进入内核后，规则根据域名、目标地址或其他条件决定使用哪个出站。远端服务器是否可达、目标网站是否响应，是这条路径后半段的问题，不能只靠界面中的连接状态判断。

系统代理通常只是向支持它的应用声明一个代理入口。部分游戏、命令行程序和自行管理网络的应用不会读取该设置。TUN 的接管范围更广，但会涉及路由、DNS 和权限。两种方式各有适用范围，不能简单理解为打开 TUN 就一定更快，或系统代理不能使用就必须重装客户端。

认识协议、传输与配置格式

Shadowsocks、Trojan、VLESS、Hysteria2、TUIC 和 WireGuard 等名称描述不同的协议能力。支持列表不等于任意节点都能使用这些协议，还要看服务器提供的参数、客户端所用内核及其构建能力。UDP 转发同样需要入口、出站协议和远端服务共同支持，网页能打开只能证明相关网页连接可用。

YAML 是结构化文本。相同缩进代表同一层级，冒号后通常需要空格，列表项使用短横线。缩进应使用空格而不是制表符。中文说明可以写在注释里，但不能把中文冒号或弯引号混进字段语法。编辑后先执行客户端提供的配置检查，再应用到正在运行的内核。

学习时准备一个稳定的测试页面、一份已知可用配置和一条清晰的回退路径。记录使用的是系统代理还是 TUN、当前模式以及所选策略组。遇到问题时每次只改变一个变量。需要补充名词含义，可先查术语表，再回到本章的连接路径判断问题落在哪一层。

选择与安装：平台、架构及权限

先在下载中心选择操作系统，再核对处理器架构。本站首推 Clash Plus；桌面端也可按使用习惯选择 Clash Verge Rev 或 FlClash。Windows 另有 Clash Nyanpasu。客户端之间的界面和配置合并方式存在差异，先选一个完成基础验证，比同时安装多个并开启网络接管更容易管理。

按系统与维护状态选择

macOS 可选择 Clash Plus、Clash Verge Rev 或 FlClash。Android 可选择 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard，但 Surfboard 的配置体系不同，不能默认直接导入 Mihomo YAML。iOS 的 Clash Plus 从 App Store 安装，官网为 clashplus.io。跨客户端迁移时，应先确认订阅输出格式，而不是仅比较文件扩展名。

Linux 下载区提供 Clash Verge Rev 与 FlClash，安装前核对发行版使用的包格式。Clash for Windows 与 ClashX Meta 属于已停止维护的归档选项，不适合作为新用户的默认起点。Mihomo 内核包面向能自行管理配置和进程的用户；普通桌面使用优先选择图形客户端。

完成一次最小安装

安装前退出其他代理或 VPN 程序，并关闭它们的自动接管选项。桌面安装包按系统流程安装，便携包则放到有写入权限的固定目录，不要一直从压缩包内部运行。首次打开后，先找到配置、代理、日志和设置这几个入口，暂时不要开启开机启动、局域网共享或复杂的自动更新任务。

Windows 中，普通系统代理使用与 TUN 服务安装可能需要不同权限。仅在安装程序或已确认的客户端明确请求时授权。macOS 中，应先确认下载来源，再按系统提示处理应用与辅助服务权限，不要通过关闭整体安全机制解决单个应用的启动问题。授权后仍需回到客户端确认内核是否真正运行。

Android 启用网络接管时通常会出现系统 VPN 授权框。允许后，系统状态栏可出现 VPN 标识，但这仍不能证明远端节点可用。同一系统环境中其他 VPN 服务可能与其竞争接管位置。先保持单一服务运行，成功后再处理省电白名单和后台保活，避免把权限问题与节点问题混在一起。

安装后的验收与退出

先导入一份可信配置并查看内核日志。若出现端口占用，确认是否有旧客户端或残留进程监听相同端口，不要随意结束不认识的系统进程。更换端口后，引用该端口的应用代理设置也必须同步修改。日志若是语法错误，则回到配置文件处理，反复安装程序通常不能修复错误字段。

最后测试正常退出：先关闭系统代理或 TUN，再退出客户端，确认浏览器仍能按原网络访问。若退出后整个网络异常，检查系统是否保留了指向本地端口的代理设置。完成这一步，才算建立了可控的安装环境。系统权限的进一步处理可查常见问题，而不是立即引入第二个客户端替换现有环境。

订阅与配置：导入、更新及本地覆盖

订阅地址是配置分发入口，可能包含账户标识或访问凭据，应像密码一样保存。只从可信提供方取得链接，不在公开聊天、截图或问题报告中暴露完整内容。导入前先确认它提供的是完整 Clash 配置、节点列表还是某种专用格式；不同内容需要进入客户端对应的导入入口。

从导入到实际启用

打开配置管理页，使用新增远程配置或导入订阅功能，粘贴完整地址并保存。下载成功后检查配置名称、更新时间和解析提示，再将它设为当前配置。部分客户端把下载、选中和应用分成独立操作，所以列表里出现一个文件，不代表运行中的内核已经使用它。

如果导入失败，先看错误发生在哪一步。网络超时表示请求没有正常完成；认证失败可能与链接失效有关；返回网页则可能是地址指向了登录页或说明页；解析错误通常意味着内容格式不匹配。不要把任意网页链接交给订阅转换，也不要为了调试将私人链接上传到来源不明的在线工具。

成功启用后，检查是否出现可选策略组，切换一个明确的出站，再访问测试页面。若节点列表为空，查看配置是否通过远程代理集合载入节点，以及这些资源是否已经下载。主配置解析成功与远程资源获取成功是两件事，需要分别确认错误提示和日志。

分清远程文件与运行配置

图形客户端常把远程订阅、本地覆盖和界面设置组合成最终配置。订阅文件中写着一个端口，而实际运行端口不同，可能就是界面选项覆盖的结果。排查时应查看客户端提供的运行配置或合并结果，并注意其中可能包含敏感信息；不要只凭下载文件推断当前行为。

需要长期保留的自定义规则，优先放在客户端支持的覆写、合并或扩展配置中。直接编辑远程下载文件，下一次更新可能把修改替换掉。不同客户端的合并规则不完全一致，列表是追加还是整体替换尤其需要验证。先添加一条容易观察的测试规则，确认位置和结果正确，再迁移正式规则。

# 规则片段：合并到现有配置的 rules 列表前部
# example.com 为保留的示例域名
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

这个片段只演示一条规则，不包含节点和完整网络设置。不要用它覆盖整份订阅；已经存在 rules 时，应按客户端的合并方式添加列表项，而不是在同一 YAML 映射中再写一个同名字段。是否命中要通过连接详情检查，不能仅根据编辑器保存成功判断。

制定更新与备份顺序

更新间隔由提供方建议和客户端能力决定。把间隔设得很短不会让节点更稳定，反而可能触发服务端频率限制。可从每天检查一次的节奏开始，重要操作前手动更新并确认结果。节点订阅、远程规则集和客户端程序有各自的更新周期，不应把其中一次成功当作所有组件都已更新。

更新前保留上一份可用配置，并记录当前策略组选择。有些配置更新会移除或重命名节点，导致原选择失效。更新后先检查配置能否解析，再验证常用网站和需要 UDP 的应用。如果出现异常，先恢复旧配置并确认网络恢复，再比较差异，避免一边修改 DNS 一边重装程序。

多设备共享同一链接时，还应核对服务是否限制设备数及客户端格式。配置备份包含的不只是订阅地址，还可能包括本地覆盖、策略组选择和定时任务。同步方案可查多设备配置同步说明；同步前先明确哪些内容由远程维护，哪些只属于当前设备。

代理模式：规则、全局与直连的验证

代理模式决定进入内核的请求如何选择出站，不负责保证请求进入内核。系统代理或 TUN 是入口，规则、全局和直连是后续决策方式。先确认应用已经接入，再切换模式观察差异。如果请求从未出现在连接列表里，改变模式通常不能解决入口之外的问题。

三种模式分别改变什么

规则模式按配置中的规则顺序决定处理方式，适合将不同目标交给不同策略。全局模式通常把进入内核的请求交给全局策略组，适合临时缩小排查范围。直连模式让进入内核的请求直接连接目标。直连不等于退出客户端，TUN 和本地监听仍可能运行，DNS 行为也不能仅凭模式名称判断。

刚开始使用时，先在规则模式下选择一个明确的节点，不要立即依赖自动测速组选路。若页面无法打开，可临时切到全局模式并确认全局组确实选择了该节点。全局能访问而规则不能访问，优先检查规则命中和策略组引用；两者都失败，再检查节点、DNS 与本地网络。

把系统代理设置与模式分开

启用系统代理后，先用遵循系统设置的浏览器测试。浏览器扩展、自定义代理设置和独立配置文件可能覆盖系统选择。命令行工具也可能读取代理环境变量而不是系统代理面板，因此浏览器成功不能直接证明终端已经接入。每种应用都要确认入口，不能只看客户端总开关。

如需验证本地 HTTP 代理，可在确认混合端口确为 7890 时执行下面的命令。端口不同应改用实际值。此命令仅让当前请求显式使用代理，不会替其他程序设置全局环境，也不会配置 UDP 接管。目标使用示例域名，返回结果仍取决于当前网络和所选出站。

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

运行后同步查看连接详情。如果请求出现并显示明确出站，说明入口链路已经建立；若连接被拒绝，先检查监听端口与内核运行状态。若代理入口可连接而远端超时，则继续检查出站日志。不要把终端中的所有错误都归结为节点失效，证书、系统时间和域名解析也可能单独失败。

为测试保留固定条件

测试时固定应用、目标地址和节点，每次只更换模式，并记录最终出站。浏览器缓存或已经建立的长连接可能让旧路径继续生效，必要时关闭对应页面或断开相关连接，再重新请求。不要在一次测试中同时切节点、换 DNS、开 TUN，否则即使恢复访问，也无法判断真正起作用的设置。

节点延迟测试只是对特定测试目标的一次测量，不是所有网站的综合速度。能得到延迟值，不能证明目标服务可用，更不能证明 UDP 转发成功。大型下载、视频连接和实时游戏的网络特征不同，应使用对应应用进行验证，并留意服务端限制、出口策略和本地网络变化。

完成排查后恢复规则模式，再检查常用站点是否进入预期策略组。需要本地访问的打印机、路由器管理页和开发服务，也应列入测试清单。保留一条明确的关闭路径：先关闭系统代理或 TUN，再退出程序。已经建立的可重复测试流程，是下一章调整规则时的基准，而不是仅凭网页偶尔打开来判断配置正确。

规则分流：匹配顺序、策略组与规则集

规则模式下，Mihomo 从上到下检查规则，首条匹配规则决定处理目标。规则越长并不代表分流越准确，顺序与范围才是关键。一个位于前面的宽泛域名规则，可能让后面的精确规则永远没有机会执行。调整前先明确需求：哪个应用访问哪个目标，希望通过哪种出站，以及用什么现象验证。

从少量可观察规则开始

DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀及其子域，DOMAIN-KEYWORD 按域名中的关键词匹配。关键词规则范围容易过大，新手优先使用明确的域名或后缀规则。不要把网页的完整地址直接填进域名字段，规则通常不包含协议头、路径和查询参数。

地址规则如 IP-CIDR 针对目标地址段。GEOIP 依赖对应数据，匹配依据是目标 IP 的数据库归属，而非公司注册地。MATCH 是兜底规则，应放在列表末尾；放得太早会使后续条目失去作用。写地址规则时还要注意是否触发域名解析，避免为了匹配地址而引入额外 DNS 请求。

# 学习片段：展示精确项、地址项与兜底的顺序
# 此示例全部直连，不提供远端代理能力
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

no-resolve 用于避免该地址规则主动触发域名解析；它不表示关闭整个配置的 DNS，也不保证所有局域网流量都符合这一个地址段。家庭、办公和容器网络使用的网段可能不同，添加前应查看实际路由。示例末尾使用直连，是为了展示语法，不应原样替换需要代理出站的完整配置。

让规则引用稳定的策略目标

规则最后一个字段可以是内置动作或已有策略组名称。引用的组名必须与配置完全一致，包括空格和大小写。通常让规则指向稳定的策略组，再在组里换节点，比把许多规则直接绑定到单个节点更好维护。订阅更新删除节点时，稳定组名也能减少需要同步修改的位置。

手动选择组适合确认出站，自动测试组适合在既定候选中按测试结果选择。两者并非简单的好坏关系。自动组所用测试地址、测试间隔和候选范围都会影响结果；策略组还能引用其他组，因此连接详情里的组名可能不是最终远端节点。排查时要沿着组的选择继续查看。

理解远程规则集的边界

规则集通过 rule-providers 声明，再由规则中的 RULE-SET 引用。它的行为类型与文件内容必须对应，域名列表、地址列表和经典规则格式不能随意混用。下载失败、路径不可写或内容格式错误，都可能导致加载失败；看到一个规则集名称，并不等于其中条目已经可用。

大规模规则集适合按用途管理，但引入前应知道维护来源、更新频率和覆盖范围。先保留少量本地关键规则，再增加一个远程集合，检查日志和命中结果。不要一次叠加多套高度重叠的规则后才开始排错，否则很难分清是前置规则截获、集合内容变化，还是最终策略组选择错误。

验证一条规则时，打开目标页面并查看连接中的域名、规则和出站。网页往往还请求图片、登录、接口等多个域名，主域名命中正确不代表所有资源路径一致。若只缺少部分内容，应从失败请求反查对应域名，不要立即把整个应用切到全局模式作为长期方案。

维护规则时给本地改动写简短注释，说明目标和原因，而不是重复字段名称。每次更新配置后检查自定义规则是否仍位于预期位置。与 DNS 相关的异常留到DNS 配置小节继续定位；如果内核看不到域名，仅凭增加域名规则通常不能解决问题，需要先检查请求入口与解析链路。

TUN 接管：路由、DNS 与 UDP 边界

TUN 通过虚拟网络接口接收流量，再交给内核处理，适合不遵循系统代理的应用。它改变的是接管方式，不会替代节点、规则或远端能力。开启前应保证系统代理下已有一套可用配置，并记录当前 DNS、其他 VPN 和虚拟网卡情况。有了这个基准，才能把新出现的问题限定在接管层。

先安装所需服务，再开启功能

桌面客户端可能通过服务模式或辅助进程获得创建接口与修改路由所需权限，具体入口随客户端而异。先按界面完成服务安装，确认状态正常，再启用 TUN。Android 通常通过系统 VPN 授权建立接管。不要把所有客户端都当成同一种权限模型，也不要仅因开关能点击就认为底层接口已经建立。

首次开启时保持默认网络栈选择，不同时叠加严格路由、复杂排除列表与多个 DNS 上游。先检查普通网页，再检查原本无法通过系统代理的应用。内核日志若提示权限不足或创建接口失败，应先处理服务与系统授权；此时切换节点不能修复虚拟接口问题。

# TUN 配置片段，需合并到已有可用配置
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  dns-hijack:
    - any:53

这个片段展示常见字段，不保证适用于每个系统。客户端界面可能覆盖它们，应用后应查看实际运行配置。auto-route 用于自动配置相关路由，auto-detect-interface 帮助选择出站接口；多网卡、虚拟机和特殊拨号环境仍可能需要额外确认。网络栈的可用性与具体行为取决于平台支持。

理解自动路由与严格路由

自动路由让符合条件的请求进入 TUN，但并不意味着设备上的所有连接都必然被接管。路由优先级、排除项、应用绑定接口及其他 VPN 都可能影响结果。严格路由用于收紧接管边界，在不同系统中具有相应的路由或限制行为；它不是速度增强选项，也不应作为所有故障的默认修复开关。

开启严格路由前，测试局域网访问、系统联网检测和办公网络需要的连接。若出现打印机失联或企业服务不可达，先关闭最近新增的路由选项，观察问题是否消失，再按实际网段设计例外。不要凭经验把大量地址段全部排除，否则可能把原本希望接管的流量也绕开。

分别验证 DNS 与 UDP

dns-hijack 将匹配的传统 DNS 请求送入内核 DNS 处理流程，示例针对端口五十三的请求，并不自动解密应用自己的加密 DNS。浏览器安全 DNS或应用内置解析可能沿不同路径工作。开启后若出现域名访问异常，要把 DNS 入口与连接入口分开检查，而不是只观察 TUN 开关。

UDP 应使用实际需要它的应用验证。节点配置允许 UDP，不等于服务器和中间网络都支持所需传输。游戏无法联机时，应检查连接是否进入内核、规则是否选到支持相应能力的出站，以及远端是否返回数据。网页与延迟测试成功不能替代这些验证，也不能证明实时业务一定稳定。

休眠恢复、无线网络切换和插入有线网卡后，出站接口与默认路由可能变化。若只有切网后失败，先重启接管或按客户端方式重建接口，再对比日志。确认 TUN 在常用网络中可稳定启停后，才考虑开机启动。路由器与服务器部署涉及转发、防火墙和回程路径，应作为独立项目处理，不能直接照搬桌面片段。

日常维护：更新、日志与故障回退

稳定使用依赖可追溯的变更，而不是频繁重建环境。至少保留一份可用配置、必要的本地覆盖和当前接管方式记录。客户端、内核、订阅、规则集与地理数据是不同的更新对象，可能由不同入口管理。某个更新按钮执行成功，不表示所有组件都发生变化，更不代表配置行为完全不变。

建立有顺序的更新流程

更新客户端前先阅读变更说明，确认系统兼容性和配置迁移提示。导出或备份配置后，正常关闭网络接管再执行安装。更新后先检查原配置能否加载、监听端口是否保持一致，再验证系统代理与 TUN。若客户端包含独立内核更新功能，应避免在同一轮测试中同时替换程序与内核。

订阅更新后检查节点和组名变化，规则集更新后检查关键目标的命中结果。配置中的远程资源可能下载成功但内容不符合预期，也可能因为路径权限失败而继续保留旧数据。日志与更新时间应一起查看。重要业务之前不宜集中升级多个组件，留出验证和恢复时间比追求同步更新更实用。

按照入口、解析、规则、出站排查

先确认普通网络可以访问预期可达的目标，再确认内核进程和本地监听。随后查看失败请求是否进入连接列表：完全没有记录时检查应用代理或 TUN；有记录时查看域名解析、规则命中和所选出站。最后检查远端握手与目标服务响应。按这个方向排查，可以避免把系统代理残留误判为服务器故障。

日志中的连接被拒绝通常指目标端口没有接受连接，超时表示未在期限内完成操作，解析失败则指向域名处理环节。具体原因仍要结合错误中的地址、端口和阶段判断。证书错误还可能涉及系统时间或服务端名称。不要只复制最后一行错误，应保留同一时间段前后的相关记录。

排查时可临时提高日志详细程度，完成后恢复常用级别，减少持续记录带来的存储和隐私负担。分享日志前移除订阅地址、认证字段、控制接口凭据及可识别的私人信息。截图也可能暴露完整节点地址和账户信息；需要说明现象时，优先保留错误类型、时间与必要的网络阶段。

用回退确认变更影响

出现更新后异常，先恢复上一份配置，必要时恢复先前的接管设置。网络恢复后再逐项比较差异；若恢复仍失败，说明原因可能是本地网络、服务端或其他外部变化。回退不是最终结论，而是用来判断问题是否与本次改动相关。对配置文件做文本差异比较，比依靠记忆寻找字段更可靠。

手机后台断连要区分系统回收、网络切换和远端超时。只有回到应用后立即恢复，才更值得检查后台限制与省电策略。桌面休眠后失效则关注接口、DNS 和路由恢复。测试时记下设备状态与发生时机，不要把所有间歇性故障归结为同一个参数。

需要求助时，说明平台、客户端名称、接管方式、失败目标类型、最近改动和已经完成的测试。不要只提供一句无法上网。可按已连接却打不开网页的排查清单补齐信息，再到常见问题查相应分支。一个能复现的最小案例，通常比整份私人配置更适合交流。

DNS 与进阶：解析链路、控制接口及部署路线

完成前面各章后，再把 DNS 和自动化作为独立主题学习。DNS 不只是给域名查一个地址，还影响规则可见信息、连接目标和网络路径。调整前先记录系统 DNS、浏览器安全 DNS、客户端 DNS 以及 TUN 劫持设置，画清请求由谁接收、向谁查询，避免多个解析层彼此绕行。

Fake-IP 与上游解析的分工

fake-ip 模式向应用返回映射地址，内核借此关联域名与后续连接；它不表示真实目标不存在，也不是远端服务器地址。redir-host 则向应用返回真实解析结果。两者的兼容性与规则可用信息不同，选择时应按应用和接管方式验证，而不是把某个模式当作所有设备的固定答案。

下面是合并到已有配置中的 DNS 片段。回环监听用于限制本地监听范围；若 TUN 或客户端采用自己的 DNS 接入机制，应保留其要求的设置，不要强行覆盖。示例使用的上游仍需从当前网络可达。先验证解析请求能完成，再讨论分流和备用策略。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

nameserver 是常规解析上游列表，不应把填写多个地址简单理解成按行依次切换。使用域名形式的加密 DNS 时，还要考虑解析该上游域名所需的引导链路。节点服务器地址本身若是域名，也存在先解析才能连接的问题；不能让负责解析节点的请求反过来依赖尚未建立的节点连接。

fallback 与 fallback-filter 用于配置备用解析及结果选择条件，不等同于任意请求失败就自动换一个地址。需要按实际解析需求设计，而不是复制多份上游堆叠。某些局域网域名或特定应用不适合映射地址，可研究 fake-ip-filter，但先确认故障确实由解析模式引起，再添加范围明确的例外。

切换模式后，应用可能仍缓存旧地址，浏览器也可能保持既有连接。应重新建立请求，并按系统与客户端提供的方式处理相关缓存，避免将旧状态当作新设置的结果。更完整的参数关系可查nameserver、fallback 与 DNS 劫持说明，每次只引入一个新的解析分支。

控制接口与局域网访问

外部控制接口能够读取状态并执行管理操作，应默认限制在本机，设置访问凭据后再考虑远程管理。不要把控制端口直接暴露到公网。开放本地代理给其他设备使用时，同样要检查监听地址、认证和系统防火墙。允许局域网访问不是单独一个开关，还涉及哪些来源能够真正连接。

配置、日志和备份都可能包含敏感字段，私有仓库也需要合理的访问控制。自动同步前排除不应共享的设备设置，避免把不同设备的端口、路由和权限配置混在一起。自动化任务应能报告失败并保留上一次可用状态，不能在下载到错误页面时直接覆盖正在使用的配置。

按用途选择下一条学习路线

桌面用户可继续学习策略组与规则集维护，移动用户优先处理网络切换和后台稳定性，服务器或路由器用户再进入服务管理、转发与防火墙。后者还需要确认回程路径和接管范围，不能只把桌面配置复制过去就视为部署完成。内核命令行使用前，先查看当前程序帮助并通过配置检查。

每个进阶目标都应附带验收条件：规则能在连接详情中解释，DNS 能说明解析链路，TUN 能稳定启停，更新能恢复旧配置。做到这些之后，再增加自动选路或远程管理。需要重新建立基础流程时返回快速上手教程，需要更换客户端时使用下载中心，保持学习路线与实际操作相互对应。