Clash 从零到进阶
客户端与规则配置

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

先区分界面与执行层

Clash 生态中的客户端与内核不是同一个层次。客户端提供配置管理、策略选择、系统代理开关及日志界面；内核负责监听入口、解析请求、匹配规则，并建立实际出站连接。mihomo 是这一生态中持续发展的内核项目，常被界面客户端集成。看到相似的 Clash 界面，不代表两款客户端支持完全相同的字段，也不代表底层内核及配置处理方式一致。

理解一次访问可以从四个环节入手：应用产生请求，系统或应用将请求交给代理入口，内核按配置决定处理方式，最后通过直连或代理出站访问目标。某个网页能打开，只证明这条访问路径成立；其他应用可能不读取系统代理，其他域名也可能命中不同规则。因此，排查时需要确认入口、匹配结果和出站，而不是只观察一个总开关是否亮起。

节点、策略组与规则分别解决什么问题

节点描述一条代理连接所需的协议、服务器地址、端口与认证参数。策略组把节点或其他可选出站组织成一个引用对象，便于手动选择或按既定机制切换。规则描述某类请求应该交给谁处理。三者之间的关系是规则引用策略组，策略组再选择节点；规则也可以直接引用内置的 DIRECT 或 REJECT，分别表示直连和拒绝。

订阅通常是一个可以更新的远程配置来源，但其内容并不固定。有的订阅返回完整配置，包括节点、规则和策略组；有的只返回节点集合，需要客户端模板补齐其他部分。把节点列表当完整配置使用，常见结果是没有可选策略组，或者存在节点却没有规则引用。导入之前先辨认内容类型，比不断尝试切换模式更有效。

YAML 文件与实际生效配置

配置常以 config.yaml 保存。YAML 使用缩进表达结构，同层键必须对齐，列表项使用短横线，不能用制表符代替空格。冒号后通常需要空格，包含特殊字符的字符串宜加引号。解析通过只说明语法成立，不保证策略组引用、文件路径、网络权限等运行条件都正确。修改后还要查看内核是否接受配置，并观察实际请求的匹配记录。

图形客户端可能同时保存订阅原文、模板、覆写片段和运行时生成文件。磁盘上刚修改的文件未必就是内核正在读取的文件；下一次订阅更新也可能覆盖手动编辑。查阅客户端的配置预览或运行配置入口，确认最终字段来源，并记录界面开关是否具有更高优先级。后续示例应合并到受管理的覆写层，而不是盲目替换整个订阅。

最后还需区分软件与网络服务。安装客户端不会自动生成可用服务器，代码开源也不等于附带连接资源。服务可用性、流量额度和服务商账户状态属于另一层问题。订阅内容含有访问凭据，应按账户资料保存，不要贴进公开讨论、在线转换页面或截图。遇到来源不明的配置，先检查其中的远程资源、监听地址与控制接口，再决定是否导入。

二、选择客户端：平台与使用边界

先确定设备，再比较界面能力

首次安装可优先查看 Clash Plus，再根据平台、桌面环境和已有使用习惯比较其他客户端。选型的第一步不是比较界面截图，而是确认操作系统、处理器架构与安装包格式。桌面客户端适合管理配置与查看连接，移动端通常依赖系统 VPN 接口接管流量，服务器上的纯内核则需要自行管理配置和进程。它们的使用入口不同，不能照搬同一套授权步骤。

从下载页进入对应平台，可以集中查看可选客户端及适用说明。新手应先选择一个仍在维护、能够正常启动且符合设备条件的客户端，完成一条最短连接路径，再比较附加能力。频繁更换客户端会同时改变配置合并、DNS 默认值和系统接管方式，容易把同一个问题误认为多个软件故障，也会增加残留代理设置的排查成本。

按平台理解备选客户端

Windows 可比较 Clash Verge Rev、FlClash 和 Clash Nyanpasu；macOS 可比较 Clash Verge Rev 与 FlClash。Linux 主要查看 Clash Verge Rev 和 FlClash，并核对发行版对应的包格式。Android 可比较 Clash Meta for Android、FlClash 与 Surfboard，但 Surfboard 的配置格式与 Clash YAML 不能直接视为等价，应遵循其自身的导入说明。不能仅凭订阅地址相同就断定所有客户端都能解析。

iOS 优先查看 Clash Plus 的商店详情与设备兼容信息，产品官网为 clashplus.io。移动系统中的 VPN 标记只表示相关网络接口处于启用状态，不表示每个目标都经过代理。实际行为仍取决于客户端支持的规则、排除范围和出站配置。连接验证要回到具体应用与具体目标，不宜用状态栏图标代替测试。

维护状态与配置迁移

Clash for Windows 与 ClashX Meta 属于已停止维护的归档选择，不宜作为新设备的默认起点。归档软件即使能够启动，也可能在新系统授权、协议支持或配置字段方面遇到限制。迁移时先导出配置来源和手动规则，保留旧环境备份，再在新客户端导入；不要直接复制整套应用数据目录，因为数据库结构、路径与加密存储方式未必一致。

需要比较功能时，围绕具体需求逐项核对：是否支持所用订阅格式，是否可预览生效配置，是否提供稳定的覆写入口，TUN 是否要求额外服务，日志是否方便筛选。某款客户端支持某个按钮，不代表其他平台也具有同样实现。尤其是桌面端的系统代理、服务模式和移动端的 VPN 接管，应分别理解，不要只按相同的中文名称推断行为。

普通桌面用户通常不必单独下载 mihomo 内核。客户端已经管理内核启动、配置路径和部分权限；手动替换可能造成控制接口不兼容或启动参数失配。服务器、路由器或需要进程编排的用户才更适合直接运行内核，并承担服务管理与网络隔离工作。选型完成后先固定客户端与配置来源，给下一阶段留下可复现的环境。

三、安装与授权：建立可回退的运行环境

安装前记录现有网络状态

开始安装前，确认系统是否已经运行其他代理、VPN、流量过滤或安全软件。记录当前系统代理、已有 VPN 配置以及必要的企业网络要求，避免多个程序同时修改同一组设置。需要迁移旧客户端时，先正常关闭其系统代理和 TUN，再退出进程。只删除应用文件未必能清除系统代理、服务或虚拟网卡，因此“已经卸载”不能直接作为网络恢复的依据。

安装包应从本站下载入口及对应项目渠道获取，并核对平台与架构。Windows 的系统位数与处理器类型、macOS 的芯片类型、Android 的指令集和 Linux 的软件包格式分别决定可用文件。文件能够解压不等于能够运行，出现架构不匹配提示时应回到下载页重新选择，不要通过修改扩展名或重复解压解决。保留安装来源记录，方便后续更新与回退。

桌面端：区分安装权限与网络权限

Windows 首次启动后，先确认主界面和内核均已运行，再决定是否安装客户端提供的服务组件。系统代理通常与当前用户设置相关，TUN 或后台服务则可能需要更高权限。防火墙提示应结合程序路径、使用网络和监听范围判断，不应为了消除提示而开放所有入站连接。仅本机使用时优先保持回环监听，不必启用局域网访问。

macOS 应按安装包说明将应用放入适当位置，再从系统设置处理明确的首次运行提示。网络扩展、辅助组件、系统代理和钥匙串授权涉及不同权限，不宜把所有弹窗都当成同一类错误。若应用反复请求授权，先核对安装位置与现有同名实例，避免同时运行旧副本。具体处理可参照macOS 网络扩展与钥匙串权限说明，不建议直接关闭整套系统安全机制。

Linux 桌面需要区分软件包安装成功、图形界面启动成功和内核具备网络权限三件事。缺少桌面依赖可能表现为窗口无法打开；权限不足可能只影响 TUN；系统代理是否被应用读取又与桌面环境相关。按发行版说明安装对应格式，先用普通权限启动验证。需要能力授权或服务模式时，使用客户端提供的方式，不要把整个图形程序长期以高权限运行作为默认方案。

移动端：VPN 授权与后台运行

Android 和 iOS 通常会在首次连接时请求添加或启用 VPN 配置。应确认弹窗来自当前安装的客户端，再完成授权。Android 上还应检查电池优化、后台运行和系统自动清理策略：若锁屏后断开、切换应用后停止更新，可能是进程受到限制，而不是节点配置有误。先在前台保持连接测试，再调整必要的后台权限，避免一次开启过多无关权限。

首次启动不要立即叠加多种网络接管方式。先导入配置，用客户端自带日志确认内核正常加载；桌面端再开启系统代理，移动端按正常连接流程授权。测试完成后练习一次正常停止：关闭接管、确认系统代理恢复、退出客户端，再验证直连网络。能够顺利退出与恢复，是后续尝试 TUN 和复杂规则的重要前提，不能只测试“如何打开”。

四、订阅导入：来源、更新与配置覆盖

判断拿到的是链接还是文件

订阅导入通常有远程地址、本地文件和文本粘贴三种入口。远程地址用于定期更新，本地文件更适合备份或静态配置，文本粘贴便于临时验证。导入时选择与内容对应的入口，不要把网页说明地址当成订阅，也不要把一段 YAML 粘贴到只接受网址的输入框。地址中可能包含账户凭据，应完整保存，但不要公开展示或在公共设备上长期留存。

在配置管理页面创建新配置，填写便于区分的名称并导入内容，等待下载与解析结束。完成后还需把该配置设为当前使用项；仅显示在列表里，不代表内核已切换。接着查看策略组是否出现、节点是否可选、日志是否报告加载成功。若加载失败，优先读取错误行和字段名，先解决内容格式，不要反复点击连接来掩盖配置尚未生效的问题。

分清下载失败、解析失败与连接失败

订阅下载失败发生在获取配置阶段，可能涉及域名解析、账户状态、访问限制或订阅服务器响应。解析失败说明已经获得内容，但返回的可能是登录页、错误页面、其他客户端格式，或缩进有误的 YAML。节点连接失败则发生在配置加载之后，需要检查服务器可达性和认证参数。三种情况的时间顺序不同，应先确认失败发生在哪一步，再选择对应的排查路径。

订阅返回完整配置时，先保留其默认策略组和规则，完成基本验证。若只返回节点，应使用客户端支持的模板或提供方说明补齐配置，不能随意拼接陌生模板。模板中的策略组名称必须与规则引用一致，节点来源也要正确接入。出现“策略不存在”之类错误时，重点检查名称、大小写和合并顺序，而不是只确认列表中有没有节点。

覆写与订阅更新的边界

手动配置应尽量放进客户端支持的覆写或合并层。直接编辑下载后的订阅原文，可能在下一次更新时丢失；直接编辑运行时文件，则可能在重启时被重新生成。不同客户端对列表有替换、追加或前置等不同处理，尤其需要观察 rules、proxy-groups 与 dns 的最终结果。不要把一款客户端的合并经验默认套到另一款客户端上。

下面是顶层参数片段，仅用于说明本地设置应与节点内容分离。它没有节点和策略组，不能单独建立代理连接。若客户端已经通过界面管理这些参数，应优先使用对应开关，并在配置预览中核对结果；同时写入界面和文件可能造成启动后反复覆盖，表现为端口或模式“改了又变回去”。

# 顶层设置片段；与已有完整配置合并使用
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

更新订阅前保存当前可用配置和必要的手动选择。更新后比较策略组名称、节点数量变化和日志，不必因为旧选择失效就立即判断整个订阅损坏。提供方删除或重命名节点后，客户端可能回到默认选项；这时重新选择可用出站，并验证常用目标即可。自动更新间隔应考虑服务商限制与实际需求，短时间连续刷新并不会改善服务器质量。

如果订阅地址必须通过已有代理才能访问，需要使用客户端支持的更新下载方式，或先恢复一条可用路径。不要为了更新订阅而长期把所有流量改成全局模式。分享问题时只提供脱敏后的错误内容、导入方式和配置类型，不提供原始地址。关于来源与订阅异常的集中说明，可查看订阅相关疑难解答，再按错误阶段继续定位。

五、代理模式：入口与决策分别配置

规则、全局与直连是决策方式

规则模式按配置顺序为每个请求选择出站，适合长期使用；全局模式把进入内核的请求交给全局策略选择；直连模式则让进入内核的请求直接访问目标。模式改变的是内核收到请求之后的处理方式，不负责保证所有应用都把请求交给内核。因此，全局模式不等于整台设备的全部流量都被接管，开启后仍可能有应用绕过系统代理。

日常建议先使用规则模式，只有在定位规则差异时短暂对比全局模式。如果相同目标在全局模式可用、规则模式不可用，应查看规则命中和被选中的出站，而不是长期保留全局模式当作修复。直连模式也不等于客户端彻底退出：内核、监听端口或 VPN 接口可能仍在运行。需要完全恢复系统网络时，还应关闭相应接管入口。

系统代理：应用是否遵循决定覆盖范围

系统代理通常把系统支持的代理设置指向本机监听端口。浏览器和部分应用会读取该设置，但命令行工具、游戏或自带网络栈的程序可能忽略它。有些应用还使用独立代理设置，需要在应用内配置或通过环境变量指定。遇到“浏览器正常，另一个程序不通”，应先判断程序有没有进入内核连接列表，再判断规则与节点，避免把入口缺失误认为线路故障。

环境变量只影响读取它们的进程，也可能被工具自身配置覆盖。下面命令在类 Unix 终端中仅为这一次请求指定代理，假定本机混合端口确实为示例值。Windows PowerShell 中若使用该验证方式，应明确调用 curl.exe。请求成功只能证明这个命令通过指定入口完成了访问，不代表其他应用已采用相同设置。

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

端口设置：监听地址、类型与冲突

mixed-port 提供 HTTP 与 SOCKS 入口，port 和 socks-port 则分别设置单独的入口。端口号应以实际生效配置为准，示例中的数值不是所有客户端的固定默认值。若日志提示地址已被占用，先查是否存在另一个客户端或旧内核进程，再决定关闭占用程序或修改端口；更改后还要同步更新系统代理和应用内的手动设置。

监听地址决定谁能够连接入口。仅本机使用时，应保持局域网访问关闭，并确认实际绑定范围。开启 allow-lan 后，还要结合绑定地址、防火墙和网络环境限制访问，不应将未受保护的代理入口暴露到公共网络。局域网设备填入的地址应是运行客户端那台设备的局域网地址，而不是指向设备自身的回环地址，同时需要考虑网络隔离与设备休眠。

通过连接记录验证模式

验证时选择一个明确目标，关闭已有连接或使用新的命令请求，再观察连接列表中的域名、匹配规则、策略链和出站。长连接、浏览器连接池和缓存可能让切换后的效果看起来延迟生效，旧连接不一定随模式变化立即重建。保留当前模式和测试时间，有助于在日志中找到对应记录。遇到连接问题可结合连接故障说明逐层检查。

系统代理与 TUN 可以在部分客户端中同时存在，但首次排查宜只保留一个明确入口。双重设置可能让某些请求先经过应用代理，再被虚拟网卡捕获，增加观察难度。先用系统代理验证配置和出站，再按下一阶段需要处理接管范围。入口清楚、模式清楚、测试目标清楚，才能准确判断问题出在接管、匹配还是外部网络。

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

从上到下匹配，命中后停止

规则通常按照从上到下的顺序匹配，请求命中一条规则后就按该条指定的出站处理。规则之间不是投票关系，也不会自动挑选“更精确”的条目。因此，明确的域名例外应放在宽泛规则之前，局域网地址等基础直连项应避免被兜底代理提前覆盖，最终的 MATCH 放在末尾。只在列表下方追加一条规则，可能永远没有机会命中。

DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀及其子域，DOMAIN-KEYWORD 匹配包含关键词的域名。关键词范围往往比预期更大，不宜用短词粗略代表一项服务。IP-CIDR 根据地址段判断，GEOIP 根据 IP 地理数据库判断，GEOSITE 则依赖域名分类数据。数据库存在与标签可用，是相关规则能够加载的前提。

先定义可引用的策略组

策略组名称属于配置接口，规则中的写法必须与定义一致。下面片段定义一个名为 Proxy 的手动选择组，组内只有内置直连出站，用于验证结构与规则引用，尚不具备代理能力。实际使用时，应把已经在 proxies 中定义的节点名或正确配置的来源加入该组。不要把演示组中显示的直连误认为已经选择了代理节点。

# 结构演示片段：Proxy 目前只包含 DIRECT
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Proxy

select 适合明确的手动选择；url-test 按探测结果选择候选项；fallback 侧重按顺序维持可用出站；load-balance 则按其策略分配连接。自动探测访问的是指定测试地址，其结果不等于所有网站的体验，也不能直接代表下载吞吐。应先理解候选集合与触发条件，再决定是否需要自动选择，避免多个嵌套组让最终出站难以追踪。

域名规则与 IP 规则的边界

某些 IP 类规则为了判断目标地址，需要先解析域名；no-resolve 用于避免为该条 IP 匹配主动触发解析，但它不意味着整条访问过程不再使用 DNS。若请求已经携带 IP，仍可进行地址匹配。域名信息能否获取还与应用入口、DNS 模式及嗅探设置有关。看到域名规则未命中时，应先检查连接记录是否真的带有域名，而不是直接增加更多域名条目。

使用 rule-providers 可以把较大的规则集合与主配置分离，但需要正确设置来源、缓存路径、格式和匹配行为。域名集合、IP 集合与经典规则格式不能任意混用；通过 RULE-SET 引用时，名称也必须对应。先用几条本地规则证明分流逻辑正确，再引入远程集合。远程更新失败时还要确认是否已有可用缓存，以及当前加载的内容是否符合预期。

按单个目标验证，不按规则数量判断

新增规则前先写清楚预期：哪个域名或地址、应该交给哪个组、为什么需要例外。保存后重建测试连接，检查命中条目与最终出站；如果结果不符，向上查找更早的匹配项，检查客户端是否把覆写规则追加到了兜底之后。规则越多并不必然越准确，重复和互相遮挡的条目反而会使维护困难。保留用途注释与回退记录，比持续堆叠规则更重要。

涉及国内直连与其他目标代理的配置，可进一步阅读规则分流配置实战。不要将地理数据库当作业务归属的绝对依据，内容分发网络、共享基础设施与跨地区服务都可能出现边界情况。对必要服务使用可解释的域名例外，并将规则验证与 DNS 验证结合，才能形成可维护的分流结果。

七、TUN 与 DNS：扩大接管范围

先保证普通入口可用

TUN 通过虚拟网络接口接收被路由到其中的网络包，用于处理不遵循系统代理的应用。它改变流量进入内核的方式，不会自动修复失效节点、错误认证或有问题的规则。开启前先用明确的代理入口完成一次访问验证，确认配置与出站本身可用。若基础路径尚未成立，同时调整路由和 DNS 只会增加变量，使故障难以定位。

TUN 的实现依赖操作系统、内核能力与客户端权限。桌面端可能需要服务组件或管理员授权，移动端则通常由系统 VPN 接口实现类似接管能力，不能把桌面 YAML 片段原样套用。出现虚拟网卡创建失败或路由设置失败时，应先处理权限和客户端服务状态；此时反复更换节点不会改变本地接口初始化的结果。

路由接管与 DNS 劫持各有职责

auto-route 用于自动设置相关路由，auto-detect-interface 用于自动检测出站接口，dns-hijack 用于把匹配的 DNS 请求交给内置 DNS 处理。以下是桌面 mihomo 的局部结构示例，需要与有效出站配置合并，并由客户端正确管理权限。若界面已经提供 TUN 与 DNS 开关，应核对生成结果，不要同时维护两份互相覆盖的设置。

# 桌面端 TUN / DNS 片段；先确认客户端支持这些字段
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

DNS 覆写与 fake-ip 的含义

DNS 设置决定域名如何解析，也会影响后续规则判断和连接建立。fake-ip 模式为域名分配一个供内部映射使用的地址，内核再利用映射恢复域名并处理连接；这不是目标网站的真实服务器地址。若应用绕开内核直接使用该地址，或旧缓存保留了已经失效的映射，可能表现为特定应用无法连接。因此，切换 DNS 模式后应重建测试连接，必要时处理系统及应用缓存。

部分局域网服务、设备发现或依赖真实解析结果的应用，需要结合 fake-ip-filter 或客户端兼容设置处理。不要遇到异常就把所有域名加入过滤，也不要随意更换整个地址池。先确认失败对象、是否属于局域网、是否只有某个应用受影响，再添加范围尽量小的例外。过滤语义还可能受配置模式影响，应核对所用内核说明与最终生效字段。

劫持常规 DNS 端口不等于能够接管所有加密 DNS。浏览器或应用内置的 DoH、DoT 可能走独立连接，系统专用 DNS 也可能改变实际路径。先确认谁负责解析，再决定统一交由内核处理还是保留应用自身设置。远程 DNS 地址本身也需要可达路径；若使用域名形式的解析服务，还要考虑其域名如何完成初始解析，避免解析链路形成循环。

按路由、解析与出站依次排查

启用后先测试普通域名访问，再测试原本不遵循系统代理的应用，最后验证局域网设备和休眠恢复。出现异常时，观察连接是否进入内核；完全没有记录，优先查路由、排除范围与权限；有记录但域名解析失败，查 DNS；已经选定出站却连接失败，再查节点和目标。排查结束关闭 TUN，确认原网络恢复，避免把残留路由误认为持续的服务故障。

其他 VPN、容器网络、虚拟机和企业隧道可能与 TUN 的路由范围冲突。不要直接删除不认识的系统路由，应先停止本次新增的接管，再比较行为。必要时使用客户端提供的排除路由功能，并明确被排除流量将绕过当前内核。TUN 的目标是补齐入口覆盖，不是让配置失去边界；能解释哪些流量被接管、哪些被排除，才算完成这一阶段。

八、日常维护：日志、备份与更新

用时间线关联请求与错误

维护首先依赖可复现的记录。出现问题时，记下发生时间、使用网络、目标域名、客户端模式以及当时的策略选择，再发起一次明确请求。日志中的错误需要结合上下文理解：连接建立超时、域名解析失败、远端主动关闭和配置解析错误属于不同阶段。单独截取最后一行，往往会丢失真正的前置原因，也容易把正常重试误认为持续故障。

日常可保持适中的日志级别，只有复现问题时临时提高详细程度。详细日志可能包含域名、地址、进程名及配置相关信息，应限制保存与分享范围。复现完成后恢复常用级别，避免长期记录大量访问细节。关于常见错误的阅读方法，可参照Clash 运行日志定位说明，重点关注错误发生的位置，而不是只搜索报错词。

速度慢时拆开测量对象

连接成功不代表速度符合预期。访问缓慢可能来自目标服务、代理服务器负载、出口路径、本地无线网络或应用自身行为。先比较同一设备上的直连与代理路径，再比较同一配置下的不同出站，最后检查本地网络与其他应用占用。策略组探测只说明测试地址的响应情况，不能直接推断大文件吞吐，也不能用一次探测结果代表整个使用时段。

测试要尽量保持目标、时间和网络条件一致。若同时更换节点、切换 DNS、开启 TUN 并修改规则，就无法知道改善来自哪一步。可按照速度慢的分层排查方法逐项比较，并保留必要结论。对于某个网站独有的问题，先检查其匹配规则、内容分发路径与连接复用，不必立即重装客户端或重置所有配置。

备份需要覆盖来源与覆写

有效备份不只是保存一个 YAML 文件。还应记录订阅来源、客户端的配置合并设置、手动规则、策略组选择和必要的系统接管选项。敏感资料应保存在受保护的位置，不应混入公开代码仓库或同步到不可信共享目录。备份后确认能辨认各文件用途，并在变更前建立新的恢复点；无法判断哪份文件实际生效的备份，恢复时仍然需要重新排查。

更新客户端与更新订阅是两种独立操作。客户端更新可能改变界面、内核和权限管理，订阅更新则改变远程配置内容。建议分开执行：先更新一项，完成启动、配置加载、常用目标和局域网测试，再处理另一项。不要根据界面显示变化推断内核已经更新，也不要手动替换应用内文件后忽略兼容性。回退时使用原有安装来源和已保存配置。

网络切换、休眠与正常退出

设备从有线切换到无线、从家庭网络切换到移动热点，或从休眠恢复后，出站接口、DNS 与路由可能发生变化。先观察客户端是否重新检测接口，再尝试正常停止并重新启用接管。若只在某类网络下失败，应比较该网络的认证页、访问限制和其他 VPN，而不是删除全部本地规则。移动端还需确认后台进程未被系统清理。

正常退出前先关闭系统代理或 VPN 接管，确认应用提示停止，再退出程序。若异常退出导致网络不可用，检查系统是否仍指向已停止的本地代理端口，并使用客户端提供的恢复方式处理服务或路由。卸载前也应完成这一流程。维护的目标不是让程序永不退出，而是能够预测它启动、停止和失效时对系统网络的影响。

九、进阶路线：可复用配置与运行边界

按职责拆分，而不是不断扩充主文件

掌握基础连接后，进阶应从配置组织开始。把远程节点来源、策略选择、业务规则和本地环境设置分开管理：节点随订阅变化，策略组表达选择方式，规则表达流量去向，本地覆写负责端口、DNS 与接管。这样更换订阅时不必重写所有规则，迁移设备时也能辨认哪些字段与网络环境有关。拆分的前提是清楚客户端合并语义，而不是仅把文件切成多份。

proxy-providers 与 rule-providers 分别管理代理来源和规则来源，两者不能互相替代。引入前先确认内容格式、更新路径、缓存位置与引用名称，检查首次下载失败时的行为。远程资源会增加启动依赖，应避免所有基础配置都必须通过尚未建立的代理才能获取。已有缓存也不意味着内容始终有效，需要保留明确的更新与恢复路径。

理解组合策略的成本

嵌套策略组适合把业务选择与具体节点分开，但层级过深会隐藏最终出站。可以先建立一个清晰的手动组，再根据实际需要增加自动测试或故障转移。每新增一层，都检查候选集合、测试路径与默认选择。自动切换通常影响新建连接，不能承诺现有会话完全不中断；对长连接应用，应通过实际使用验证，而不是只观察策略组当前显示的名称。

规则集管理也应保留审阅习惯。第三方集合的范围、更新频率与分类逻辑未必符合本地需求，过大的集合还会增加启动和维护成本。先保留必要的本地例外，明确它们位于远程集合之前还是之后，再逐步引入分类。对于业务关键目标，记录预期出站与验证方法，避免远程规则变动后只能凭体验猜测发生了什么。

外部控制接口：只开放必要范围

外部控制接口用于客户端或管理工具读取状态、切换策略及更新配置，其权限高于普通代理入口。只在本机使用时应保持回环绑定，不应为了方便访问而直接暴露到公共网络。下面展示单个顶层字段的结构；它不是要求手动开启接口。图形客户端可能已经自行管理地址与认证，直接改动会造成界面失联或控制冲突，应先查看客户端说明。

# 仅展示回环绑定形式；不替代认证与访问控制
external-controller: 127.0.0.1:9090

需要跨设备管理时，应先设计受保护的访问路径、身份认证、防火墙和最小开放范围，而不是只改变监听地址。代理入口、控制接口与 DNS 监听是不同服务，应分别检查绑定范围和权限。不要将控制接口认证内容写进公开示例、截图或问题报告；本地回环绑定也不能替代对本机应用和脚本的信任判断。

从桌面客户端迁移到纯内核

服务器与路由器环境需要自行承担启动参数、配置路径、文件权限、日志轮转和服务恢复。先在非关键环境用已知配置启动，确认路径与监听范围，再配置开机运行。首次启动不要立即覆盖整台设备的默认路由，尤其是远程管理机器；错误接管可能中断当前管理会话。保留独立恢复通道，并验证重启、网络切换和资源下载失败时的行为。

纯内核配置可使用其测试模式检查加载条件，但应先从所用二进制的帮助输出确认参数，并理解测试范围。语法和引用检查通过，不代表远程服务器可达、路由权限足够或系统 DNS 路径正确。正式运行仍需按入口、解析、匹配和出站逐层验证。不要把客户端生成的文件直接复制到服务器而忽略相对路径、缓存目录及平台差异。

以可解释结果作为进阶标准

完成这一阶段后，应能回答一个具体请求从哪里进入、由谁解析、命中哪条规则、经过哪个策略组以及如何恢复原状。没有明确需求的高级选项可以保持默认，不必为了配置长度而增加复杂度。需要快速操作时回到使用指南，需要定位单项异常时查看疑难解答；把验证结论补进自己的维护记录，逐步形成适合设备与网络环境的配置。