Mihomo 配置手册

一、核心概念与客户端选择

内核、界面与服务来源

Mihomo 是负责解析配置、匹配规则和建立出站连接的代理内核，Clash Meta 是其生态中常见的历史称呼。客户端则提供图形界面、配置管理和系统集成。点击界面上的系统代理或策略组选项，最终会改变内核的运行状态或相关系统设置。因此，界面显示已经启动，只能证明进程运行，不能单独证明订阅有效、出口可用或所有应用都已经接入代理。

完整链路包含应用、流量入口、规则、策略组与出口。应用先通过系统代理或 TUN 把请求交给内核；内核根据模式决定是否使用规则；命中的规则把连接交给直连、拒绝或某个策略组；策略组再选择实际出口。订阅通常提供出口参数及部分规则，但客户端本身不等于网络服务。下载并安装客户端之后，仍需准备合法可用的配置来源，或自行部署与维护相应服务。

按平台确定安装入口

首次选择可先考虑 Clash Plus，再根据平台和工作方式比较其他客户端。Windows 还可选择 Clash Verge Rev、FlClash、Clash Nyanpasu；macOS 可比较 Clash Verge Rev 与 FlClash；Android 可比较 Clash Meta for Android、FlClash 或 Surfboard。Surfboard 的配置体系与 Mihomo 并不完全相同，不能仅因同属代理工具就直接导入同一份 YAML。具体入口集中在下载中心。

维护状态与能力边界

Clash for Windows 与 ClashX Meta 已停止维护，适合了解旧环境或迁移历史配置，不宜仅因为旧教程使用它们就默认沿用。Linux 桌面用户可先比较 Clash Verge Rev 与 FlClash；服务器和路由器用户再考虑直接运行 Mihomo 内核。后者需要自行管理进程、配置目录、监听地址与路由，不具备图形客户端自动处理系统集成的全部便利。

iOS 使用 Clash Plus 时，可通过其官网 clashplus.io了解应用信息，再从App Store 页面安装。不同平台客户端即使名称相同，界面入口与系统能力也可能不同。学习时应优先识别设置的作用，而不是机械寻找完全相同的按钮位置。

本阶段的完成条件是能够回答三个问题：当前运行哪个客户端，实际由哪个内核或网络组件处理连接，配置由谁提供与更新。进一步比较时，关注订阅兼容性、规则覆盖方式、日志可见性和配置备份，而不是只看界面相似程度。遇到“支持某协议”的描述，还应确认当前平台和当前实现是否支持订阅使用的具体参数；协议名相同并不代表所有扩展字段均可互换。

二、安装、权限与初始环境

安装前确认架构与旧设置

先在系统信息中确认设备架构，再选择安装包。Windows 常见设备使用 x64，也有 ARM 设备；macOS 需要区分 Apple Silicon 与 Intel；Linux 除架构之外还需区分发行版接受的包格式。不要通过文件大小猜测兼容性。安装器能够打开，也不代表随附内核一定能在当前系统运行；若启动后立即退出，应先检查架构和系统要求，再看应用日志，而不是立即修改订阅。

若设备安装过其他代理客户端，先退出旧客户端并检查系统代理是否仍指向旧端口。关闭窗口不一定等于退出后台进程，托盘图标、菜单栏图标和系统服务都可能继续工作。首次验证只保留一个负责接管流量的客户端，避免两个程序反复修改系统代理，或两个 TUN 设备争用默认路由。旧配置可以保留备份，但不应在未知状态下同时启用。

桌面平台的权限顺序

Windows 上先以普通方式安装并启动，确认基础界面可以打开。仅在安装服务或启用需要提升权限的网络功能时，按客户端提示授权。系统代理通常不需要把整个应用长期以管理员身份运行；TUN 或服务模式则可能依赖特权辅助组件。若提示端口占用，应查明哪个进程正在监听，修改一方端口后同时更新系统代理目标，不能只改 YAML 而保留旧的系统入口。

macOS 首次启动时，按系统提示核对应用来源与权限用途。客户端可能安装辅助服务，部分实现使用网络扩展，具体流程取决于应用。钥匙串弹窗与网络扩展授权不是同一件事：前者可能用于保存敏感信息，后者允许系统网络接管。对话框出现时先阅读请求来源，不要把所有提示一概视为必须放行。相关路径可参阅macOS 权限与钥匙串说明。

Linux 图形客户端能否写入系统代理，取决于桌面环境和应用实现；命令行程序也未必读取桌面代理设置。安装后先确认内核进程存在、配置加载成功和本地端口监听，再测试某个明确支持代理的应用。直接运行内核时应为配置目录设置合适的读写权限，避免为了省事对整个目录开放所有用户写入。服务账户、工作目录和相对路径不一致，常会造成交互运行正常而后台启动失败。

移动设备与最小启动配置

Android 首次建立 VPN 连接时会请求系统授权，这代表流量入口已获许可，不代表远端出口有效。系统通常只允许一个普通 VPN 连接占用该位置，已有企业 VPN 或其他网络工具可能产生冲突。后台省电策略还可能暂停客户端，应在确认确有断连问题后调整相应限制。iOS 同样要根据应用引导完成 VPN 配置授权，再返回客户端查看是否存在配置加载错误。

# 本地入口示例，不包含代理出口
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

上面的片段用于理解基本参数，不是可提供代理服务的完整配置。mixed-port 接受 HTTP 和 SOCKS 请求；allow-lan: false 限制局域网访问意图，仍需结合实际监听地址与防火墙确认暴露面。先保持本机使用，暂不开放局域网共享。完成安装的判断应是界面、内核和本地入口均正常，且退出客户端后能够恢复原来的网络状态。

三、订阅导入与配置生命周期

区分订阅地址和实际配置

订阅链接是获取配置的入口，下载得到的内容才是内核实际解析的配置。链接可能返回完整 YAML、仅包含代理出口的集合，或其他客户端使用的格式。导入前应确认提供方明确支持当前客户端及其内核。浏览器能打开链接只能证明收到响应，不能证明响应就是有效配置；登录页面、余额提示和访问限制页面也可能以正常网页形式返回。

在客户端找到配置或订阅管理入口，新增远程配置，为其设置能辨认来源的名称，再粘贴地址并执行下载。完成后先查看更新时间、解析结果和是否生成策略组，再把它设为当前配置。不同客户端会把“下载成功”和“启用成功”分成两个动作，只有文件已经保存并不意味着内核已经切换。可通过当前配置名称和启动日志交叉确认，避免一直编辑并未启用的文件。

建立配置来源的分工

远程订阅通常由提供方维护，直接修改下载缓存可能在下一次更新时被覆盖。需要长期保留的规则、DNS 或入口设置，应使用客户端提供的覆写、合并或扩展机制；机制名称与执行顺序因客户端而异。先确认它是整体替换某个字段，还是在原列表之前或之后插入。对于规则列表，追加到末尾的规则可能落在 MATCH 后面，语法正确却永远无法生效。

把配置分成来源层、个人覆盖层与运行态三部分更容易排查。来源层回答订阅下载了什么；覆盖层回答本地追加或替换了什么；运行态回答内核最终收到什么。遇到界面中某项与 YAML 不一致时，应查看最终配置或日志，而不是只看订阅原文。部分客户端会在启动时注入端口、控制接口等字段，因此运行配置与远程原始文件存在差异并不一定是错误。

# 局部示例：两个常见顶层字段
mode: rule
log-level: info

# 规则引用的 PROXY 必须已在完整配置中定义
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

处理导入与更新失败

若出现解析错误，先保存报错中的字段名与行号。YAML 使用空格表达层级，不能把制表符混入缩进；列表项前的短横线、冒号后的空格以及字符串中的特殊字符也会影响解析。报错行有时只是解析器发现问题的位置，真正原因可能在前一行缺少引号或层级错误。应从错误附近逐段检查，避免把整个文件重新排版后丢失最初的线索。

若下载失败，区分域名无法解析、连接超时、证书错误、授权失效和返回内容不符。订阅请求可能由客户端自身或内核执行，不一定与浏览器走同一条网络路径。只有在提供方说明需要特定请求标识时才调整 User-Agent，不能把随机更换标识当作通用修复。详细分支见订阅解析失败自查；首次导入流程也可对照订阅导入步骤。

更新前保留最近一份可用配置，更新后核对策略组引用是否仍有效。提供方可能调整出口名称，固定选择的旧成员因而失效；如果客户端保留了历史选择，需要重新进入策略组确认。不要只因刷新动作成功就认定更新完成，应测试实际连接并查看命中策略。对经常变化的订阅，个人规则宜引用稳定的策略组名，而不是直接引用易变的出口名称。

四、代理模式与策略组

先分清入口与出站决策

系统代理、TUN 和 Rule 不是同一层的选项。前两者决定应用流量怎样进入内核，Rule 则决定进入之后如何分流。因此，“已经切到全局却仍有应用不走代理”并不矛盾：该应用可能根本没有使用系统代理，也没有被其他入口接管。排查时先在连接面板中寻找对应请求；如果完全看不到连接，应检查入口，而不是继续切换出口或调整规则顺序。

日常使用一般从 Rule 开始。Global 适合作为短时间的诊断对照，但不会自动解决订阅失效、入口冲突或 DNS 错误。Direct 也不是退出客户端，它仍可能保留入口接管和内核解析行为。若要判断问题是否由整个代理环境引起，应进一步退出客户端并恢复系统设置；只切换 Direct，无法排除 TUN 路由或客户端 DNS 仍然参与处理的情况。

理解策略组的引用关系

策略组是规则和实际出口之间的中间层。select 允许手动选择成员；url-test 根据检测结果选择成员；fallback 按顺序寻找可用成员；load-balance 按配置的分配策略安排连接。自动组的检测结果只反映检测地址与检测方式，不能直接代表某个业务网站一定可用，也不宜把某个显示值当作所有场景的质量结论。

# 将此组加入已有完整配置的 proxy-groups 列表
# 这是仅含直连选项的结构示例，不会新增代理出口
proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手动选择

示例中规则引用的是组名，组再引用内置的 DIRECT。实际订阅可以把已定义的出口名称加入成员列表，也可以引用另一个策略组，但必须避免相互引用形成循环。名称通常需要精确匹配，大小写、空格和符号都应保持一致。修改组名时，要同时修改 rules 中的引用和其他组的成员；只改显示名称会造成目标不存在，可能直接阻止配置加载。

用单个请求验证选择

切换策略组后，新连接通常会采用新选择，但已经建立的长连接可能继续使用原来的出口。浏览器连接池、下载任务和即时通信连接都可能持续存在。验证时关闭相关页面或任务，再发起一次新请求，查看连接面板中的规则、策略链和出口；必要时只关闭与该业务相关的连接，不必每次清空所有连接，以免影响其他工作。

还需注意一个界面中可能同时出现全局策略组和订阅自定义策略组。在 Rule 模式下，真正起作用的是命中规则引用的目标，不一定是最上方正在显示的组。若更换出口后业务完全没有变化，应沿着连接记录中的策略链逐层确认，而不是假设客户端没有保存选择。更换为另一个同名来源的配置后，也应核对组成员是否发生变化。

完成本阶段后，至少做一次受控对照：保持入口不变，用同一个网站分别测试 Rule 与 Global，记录它们最终走向。如果 Global 可用而 Rule 不可用，再检查规则命中和组选择；如果两者都失败，先验证出口或解析。这种对照不是长期设置建议，而是把故障范围从整条链路缩小到一个环节。术语可补查策略组说明。

五、规则分流与匹配顺序

首条命中决定去向

Mihomo 的常规规则按从上到下的顺序评估，首条命中后使用对应目标。因此优先级首先来自位置，而不是规则类型的名称。精确域名规则不会天然越过上方已经匹配的宽泛规则；末尾的 MATCH 则负责兜底。编写规则时应先放明确的例外，再放较宽的分类，最后放默认出口，并在连接面板中验证实际命中的那一条。

DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配域名及其子域；DOMAIN-KEYWORD 按关键词匹配，范围更宽，容易误中。IP 类规则用于目标地址，进程类规则依赖平台支持和进程识别条件。不要因为某个网站有一个已知地址，就把它永久写成单个 IP 规则；内容分发、地址轮换与共享主机都可能让这种写法覆盖不足或影响其他服务。

# 局部规则示例；PROXY 须为已有策略组
rules:
  - DOMAIN,router.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这里的 example.com 是用于说明语法的保留示例域名，应按实际业务替换。no-resolve 表示这条 IP 规则不主动为域名触发解析，并不等于关闭所有 DNS 请求；如果连接本来已有目标地址，仍可能按地址匹配。GEOSITE 与 GEOIP 使用本地数据文件，分类名称必须存在。加载成功只能证明语法与数据可用，不能证明分类内容恰好符合当前业务需求。

从内置分类过渡到规则集

当手写列表变长，可通过 rule-providers 把规则数据与主配置分开。提供器描述来源、保存位置、更新周期和内容行为，rules 再通过 RULE-SET 引用。domain、ipcidr 与 classical 对内容格式有不同要求，不能只改扩展名就互换。规则集文件中的条目通常不包含最终策略，策略由引用它的 rules 行指定。

# 本地规则集示例：相对路径基于内核工作目录
rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,PROXY

# 保存为 rules/local-domains.yaml
payload:
  - '+.example.com'

使用本地文件能先验证格式和匹配，不必同时排查远程下载。确认正确后再考虑远程来源，并核对来源维护方式与适用范围。远程规则集更新失败时，旧缓存可能继续生效；若没有缓存则可能无法加载。主配置成功更新与规则集成功更新是两件事，需要分别查看日志。不要把多个用途高度重叠的规则集盲目叠加，否则很难判断究竟哪一组决定了结果。

用证据定位分流偏差

排查顺序是确认请求进入内核、查看目标域名与地址、记录命中规则、确认目标组选择。若连接只显示 IP，应检查应用是否自行解析、DNS 是否绕开内核，以及域名嗅探是否满足条件。嗅探可能补充域名信息，但并非所有协议都能恢复原始主机名，不能把启用嗅探当作所有域名规则失效的统一解法。加规则前先弄清内核实际掌握了哪些信息。

某些网站同时访问登录、资源、接口和媒体域名，只给首页域名加规则可能只修复页面的一部分。应围绕一次明确操作观察相关失败连接，再补充必要范围，避免使用过宽关键词让无关业务被一并接管。有关类型与顺序可参阅自定义规则与优先级，需要组合分类时再读GEOSITE 与规则集分流配置。

六、DNS、Fake-IP 与 TUN

解析与连接是两条相关链路

DNS 把域名转换为地址，代理负责承载后续连接，两者路径不一定一致。浏览器可能使用加密 DNS，系统可能缓存旧结果，应用也可能内置解析器。因此，网站打不开不能直接等同于出口故障。应先观察是否获得地址，再看连接是否进入内核，最后检查实际出站。对比不同网络时，应保持同一个客户端配置，避免网络和配置同时变化而无法定位原因。

Fake-IP 为域名分配虚拟地址并维护映射，后续流量到达内核时可关联到原始域名。它不代表网站真实地址，也不能拿这个虚拟地址直接判断地理位置。redir-host 则返回解析得到的真实地址，适合需要真实地址行为的特定环境，但规则判定可能更依赖域名映射与解析结果。两者不存在对所有应用都成立的统一优胜关系，应根据局域网、游戏或企业内网需求验证。

# DNS 局部示例；仅监听本机
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - 'localhost'
  nameserver:
    - https://1.1.1.1/dns-query

上例只创建一个本地 DNS 监听入口，并不会自动让系统把查询发到该端口。系统 DNS、TUN 劫持或客户端集成功能还需另行衔接。示例上游也必须在实际网络中可达，不能把加密协议本身当作可达性保证。fake-ip-filter 用于让指定域名不返回虚拟地址，应只为确有兼容问题的域名添加例外；范围过大会改变原有分流行为并增加排查难度。

TUN 接管的前提与限制

TUN 通过虚拟网络接口接收 IP 流量，适合不遵循系统代理的程序。启用前要确认权限、驱动或辅助服务已就绪，并检查其他 VPN 是否仍在运行。auto-route 用于配置相应路由，auto-detect-interface 尝试识别出站接口；在多网卡、热点和企业网络中仍需核对实际结果。TUN 不是绕过权限、出口协议限制或防火墙的万能开关。

# TUN 局部示例，需结合平台与 DNS 配置使用
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns-hijack 中的常规 DNS 端口匹配不能覆盖应用自建的全部加密解析连接。系统代理与 TUN 也不一定需要同时启用，应按客户端建议选用，避免入口叠加后难以解释链路。启用后先测试普通网页，再测试目标应用和局域网服务；如果打印机、共享目录或企业内网异常，检查是否需要路由排除或域名例外，而不是直接把所有流量改成直连。

识别 DNS 泄漏与内网冲突

所谓 DNS 泄漏，应以预期解析路径为基准判断：哪些查询应由哪个解析器处理，是否有请求绕开这一路径。测试网页展示某个解析器名称，只能作为线索，不能单独证明所有查询都经过或绕过代理。应结合系统 DNS、客户端日志、浏览器安全 DNS 设置以及必要的网络抓包，确认具体请求的去向。测试时也要区分 IPv4 与 IPv6，不能只检查一种地址族就下结论。

若企业内网使用专用 DNS，公共解析器可能无法解析内部域名。此时应针对内部后缀设置解析策略，并保证对应 DNS 地址可以沿正确接口到达。发生循环时，表现可能是解析请求依赖代理，而代理服务器域名又依赖同一条未建立的解析路径；需要为代理服务器解析准备可独立工作的路径。Fake-IP 的更多边界见Fake-IP 与 redir-host 区别。

七、日常维护与故障定位

建立可恢复的配置基线

稳定使用后，保存一份包含客户端设置、个人覆写和规则文件的备份。订阅链接本身不是完整备份，因为远端内容可能变化，本地策略选择与扩展规则也可能不在订阅中。备份应区分可公开的规则和包含账户认证的配置，敏感部分保存在受控位置。记录当前使用的入口方式、DNS 模式以及特殊路由，比只保存一张界面截图更有利于恢复环境。

更新应拆成客户端、内核、订阅和规则数据几个维度。客户端更新可能改变界面与系统集成，内核更新可能改变字段支持，订阅更新则主要影响出口和配置内容。一次只更新一个维度并做基本验证，能够在出现异常时明确回退对象。不要在工作中断时同时更新所有组件，然后仅凭“更新后不能用”尝试恢复；这样的信息不足以区分兼容问题与服务变化。

按链路顺序排查无法上网

首先判断影响范围：是全部应用、单个程序，还是某个网站的某项功能。再确认不经过客户端时网络是否正常。若基础网络也不可用，应先处理 Wi-Fi、蜂窝网络、认证门户或系统网络状态。客户端运行时检查内核是否启动成功、当前配置是否正确、端口是否监听。若目标请求没有出现在连接列表中，优先检查系统代理、应用代理设置或 TUN，而不是替换出口。

请求已经进入内核后，查看解析结果、命中规则和最终出口。如果同一个出口对多个站点都失败，可检查服务状态、认证参数与远端可达性；如果只有一个站点失败，应检查规则、站点依赖域名与协议差异。HTTP 错误响应意味着已经收到应用层结果，不能简单归类为网络完全不通。证书错误也应先核对系统时间、目标域名和中间设备，不要通过关闭证书验证掩盖原因。

# 验证本地 HTTP 代理入口，端口需与实际配置一致
curl -I --proxy http://127.0.0.1:7890 https://example.com

# 验证 SOCKS 入口，并让代理端处理域名
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

这些命令只验证指定入口和指定站点，不代表所有程序均已接管。在 PowerShell 中如遇到命令别名差异，可使用 curl.exe。socks5h 与普通 SOCKS 地址写法在域名解析位置上有区别，对照时应记录所用形式。不要只比较两条命令是否成功，还要结合日志确认它们走了哪条规则，避免一条直连、一条代理却被当作同条件测试。

日志、缓存与退出恢复

日常保持 info 等适当日志等级，临时排查再提高详细程度。记录一次失败操作的时间、目标和错误信息，比长时间积累大量日志更有效。分享前去除订阅地址、认证字段、内网主机名和可能暴露业务信息的请求路径。详细日志也可能增加资源开销，问题定位完成后应恢复原等级，避免长期保存不必要的连接细节。

修改 DNS 或模式后，已有缓存与长连接可能使结果暂时不变。应先关闭相关连接，再按需要刷新系统或应用缓存，不必直接删除整个客户端目录。若退出客户端后仍无法访问，检查系统代理是否残留指向已关闭的本地端口、TUN 路由是否恢复以及 DNS 是否仍指向不可用地址。快速核对可参阅系统代理设置与连接验证。

八、进阶配置与验证路线

先模块化，再增加自动化

进阶不等于把所有功能全部打开，而是能解释每一段配置的输入、输出和失败行为。已有一份稳定配置后，可先把个人规则从订阅中分离，再把较大的规则列表整理为独立提供器，最后考虑出口提供器与自动策略。每拆出一个模块，都要验证路径、名称引用与加载顺序。模块化的目标是缩小修改范围，而不是让一份简单配置变成难以追踪的多层引用。

proxy-providers 与 rule-providers 解决的问题不同：前者提供代理出口集合，后者提供匹配条件集合。它们通常由策略组和 rules 分别引用。不要把完整客户端订阅不加判断地当成出口提供器文件；即便包含 proxies，也可能同时包含界面所需的其他段落，实际解析方式需要核对。对于来源不明确的远程文件，应先在本地查看结构，再接入自动更新流程。

为策略建立测试矩阵

验证应覆盖不同类别，而不是只打开一个常用网站。准备本地网关、局域网服务、需要直连的站点、需要代理的站点以及目标业务应用，分别记录预期入口、规则和出口。涉及 IPv6 时还要观察地址族选择；涉及 UDP 时确认入口和远端协议都支持。网页能打开只证明其中一条 TCP 链路成立，不代表语音、游戏或其他基于 UDP 的功能也已正常。

测试时使用可重复的操作，例如重新打开同一个页面、重新建立一次语音连接或访问固定的内网服务。把预期结果写清楚后再修改参数，能够防止“感觉变快”或“偶尔成功”被误认为配置正确。对于自动选择组，还应观察检测失败后的行为、成员更新后的引用和网络切换后的恢复，确认它的自动化符合实际需要，而不只是界面显示正常。

命令行内核与控制接口

准备脱离图形界面运行内核时，先理解工作目录和配置文件路径。相对路径通常以工作目录为基准，规则文件、缓存和数据文件都可能受其影响。把配置复制到服务器却没有复制本地提供器文件，是常见迁移失败原因。先在前台检查配置和日志，再配置服务托管；服务启动账户的权限与交互登录账户可能不同，需要分别验证读写目录和网络能力。

# 在已安装 mihomo 的环境中检查配置
mihomo -t -d ./mihomo-work -f ./mihomo-work/config.yaml

# 检查通过后以前台方式运行
mihomo -d ./mihomo-work -f ./mihomo-work/config.yaml

配置检查能够发现语法与部分引用问题，但不能证明订阅地址、DNS 上游和所有出口在运行时可达。前台运行完成测试后，再将同样的参数写入所用系统的服务配置。若启用外部控制接口，应限制监听范围并配置访问保护，不要为了远程面板方便而直接暴露到公共网络。接口权限通常允许修改运行状态，其风险与普通只读网页并不相同。

把排查结果沉淀为变更记录

每次变更记录原因、涉及字段、验证对象与回退方法。复杂配置应保留一份最小可运行基线：入口明确、策略组少、规则路径清楚。出现异常时将新功能逐项移除，与基线比较，而不是从网络上不断叠加来历不明的配置段。对配置格式仍有疑问，可回看订阅与配置格式；需要重新梳理首次操作时返回快速上手教程。

本手册的最终完成条件不是记住所有字段，而是能够沿应用入口、域名解析、规则命中、策略选择和实际出口解释一次连接。下一步只学习当前业务确实需要的能力，例如独立规则集、按域名指定解析器或服务器进程托管。保持配置可读、结果可验证、修改可回退，比持续增加参数更有利于长期维护。