Clash 从零到进阶

一、理解 Clash 核心概念

客户端、内核与服务端的分工

Clash 通常指围绕代理内核构建的一类客户端和配置生态，并不是某一套固定界面。图形客户端负责配置导入、系统代理开关、节点选择和日志展示；内核负责监听本地端口、读取规则并建立连接。mihomo 是这一生态中常见的内核实现。界面能够打开，只能说明客户端启动，不能据此认定内核运行正常，更不能认定远端线路已经可用。

服务端节点是实际提供转发能力的远端入口。客户端安装包本身不会生成可用节点，订阅也不是代理协议，而是一种交付配置或节点信息的方式。排查时应把三者拆开：客户端能否管理配置，内核能否接收连接，节点能否完成远端握手。将所有问题归结为软件安装失败，往往会重复安装，却没有碰到真正出错的环节。

从一次请求看完整链路

应用发出请求后，流量先通过系统代理、应用自己的代理设置或 TUN 进入内核。内核根据目标域名、地址和其他条件选择规则，再把连接交给直连策略或代理组。代理组最终选中一个节点，节点把请求送往目标服务。响应沿相反方向返回。这条链路上，流量入口、规则判断和出口节点是不同层次，开启其中一项并不代表其他层次已经正确。

配置中的 proxies 描述节点，proxy-groups 组织选择关系，rules 决定连接交给哪个策略。规则里引用的名称必须能够找到对应节点、代理组或内置策略。名称相似不等于相同，大小写、空格和标点都可能影响引用。阅读陌生配置时，先找入口端口，再找组名和最终兜底规则，比从第一行逐项背字段更有效。

先区分节点、策略与解析结果

节点名称中的地区通常是提供方标记，不能单独证明出口地址所属地区；延迟测试通常只反映指定探测请求的结果，也不是完整下载速度。代理组是选择节点的方法，不是另一台服务器。DNS 则负责把名称转成地址，并可能影响规则匹配。只有分清这些对象，才能解释为什么切换节点、修改 DNS 和调整规则会产生不同结果，而不是把它们视为同一个开关。

本手册中的配置块都是针对某个字段的片段，除特别说明外，不应当作完整订阅直接导入。已有配置通常还包含节点和客户端专用设置，整份覆盖会丢失这些内容。需要快速理解术语时，可配合名词解释查阅；需要第一次完成连接时，则回到使用指南按顺序操作。先建立可工作的基线，再加入高级功能，能让每次修改都具备明确的比较对象。

二、按平台选择客户端

先选系统，再看操作方式

普通桌面和移动设备用户可先考虑 Clash Plus，再根据平台和工作流比较其他客户端。选择依据应是系统兼容性、配置管理方式、所需协议与网络接管能力，而不是界面截图。安装前先到下载中心确认平台和架构，不要把某个系统上的教程按钮名称机械套到另一系统。相同的规则概念可以通用，但服务安装、网络权限和后台运行方式通常不同。

Windows 可比较 Clash Plus、Clash Verge Rev、FlClash 和 Clash Nyanpasu。Clash for Windows 已停止维护，适合已有环境的归档查阅，不宜作为新设备的默认起点。macOS 可选择 Clash Plus、Clash Verge Rev 或 FlClash；ClashX Meta 同样应按已停止维护的归档客户端看待。维护状态与当前是否还能启动是两回事，尤其要留意新系统权限机制和后续协议兼容性。

Android 可选择 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard。Surfboard 的配置格式与 Clash YAML 存在差异，不能假设同一订阅在所有客户端中都能直接使用。iOS 优先查看 Clash Plus 的商店说明，官网为 clashplus.io。Linux 桌面可考虑 Clash Verge Rev 或 FlClash；无图形界面的服务器和路由器则更适合单独部署 mihomo。

比较功能时核对实际内核

判断协议支持时，应同时核对客户端实际使用的内核和订阅字段。界面里能显示某种协议名称，并不意味着当前内核能解析服务方提供的全部参数。遇到导入报错时，保留错误字段和客户端名称，比只记录软件图标更有帮助。不要为测试兼容性同时运行多个代理内核，它们可能争用端口、系统代理或虚拟网卡，导致原本正确的配置也无法工作。

系统架构决定安装包能否正常运行。Apple Silicon 与 Intel 设备应分别选择对应构建，Windows 和 Linux 也需核对处理器架构。Android 的 ARM64 与 ARM 安装包并非任意互换，无法确认时先查看设备信息和下载页说明。安装失败还可能来自系统最低要求或安装来源限制，不应一开始就修改代理配置，因为这些问题发生在网络转发链路之前。

确定客户端后，先完成一个应用的基本连接，再评估是否迁移。迁移应保留原配置文件、订阅来源和必要的代理组选择记录，不能只复制界面里的节点名称。需要并排比较各平台候选项时，阅读客户端对比；迁移完成后再关闭旧客户端的自启动与系统代理，避免下一次重启时两个程序重新接管网络。

三、安装客户端与检查端口

建立最小可运行环境

从下载中心取得对应系统与架构的安装包，按系统提示完成安装。首次启动先查看配置页、内核状态和日志入口，不要立即同时启用系统代理、TUN、局域网共享和复杂覆写。此时最重要的结果是客户端能够启动内核，并且能找到它实际使用的配置位置。若需要网络扩展或服务权限，应阅读系统提示后授予，而不是反复关闭安全提示来尝试启动。

桌面客户端可能将图形界面与后台服务分开运行。关闭窗口不一定停止内核，退出托盘也不一定卸载后台服务。因此，安装前后都要检查是否已有其他代理程序运行。若界面提示端口占用，先查占用者再处理；不要随机结束所有网络相关进程。移动端出现 VPN 授权时，应确认授权对象确实是刚安装的客户端，并留意系统通常只允许一个常规 VPN 会话占用该入口。

本地端口不是节点端口

mixed-port 是本机应用连接内核的入口，可同时接收 HTTP 与 SOCKS 代理请求。节点的服务端端口则位于订阅的节点定义中，两者用途不同。以下示例将本地入口限制在回环地址，适合仅供当前设备使用。数字是配置示例，不是所有客户端的默认值；给应用填写代理地址时，必须以客户端当前显示的监听端口为准。

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

浏览器和工具使用本机代理时，地址通常填 127.0.0.1，端口填内核的实际监听值。远端节点地址不能填进这里。若确实需要让同一局域网的其他设备使用代理，应单独评估监听地址、访问认证和防火墙范围，不能只把 allow-lan 打开就视为配置完成。对外开放的代理入口可能被其他设备使用，并消耗线路流量。

从启动日志确认服务状态

Windows 可在 PowerShell 中运行 Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue 查看该示例端口的监听和连接信息；Linux 可用 ss -lntp 检查监听者。查询结果为空时，还需确认内核是否启动、端口是否被客户端改写。即使出现监听记录，也要核对进程归属，不能因为同一端口存在就认定监听者一定是当前客户端。

若内核启动后立即退出，优先阅读日志中的第一条配置错误。后续的连接拒绝往往只是启动失败的连带结果。常见原因包括 YAML 缩进、重复字段、无法读取配置文件和组名引用错误。修复一个问题后重新加载，再观察新的首条错误，避免一次改动大量字段。系统权限问题则应返回客户端的服务管理入口处理，而不是在订阅文件里添加无关参数。

安装完成的验收标准是：内核能够持续运行，当前端口有明确归属，日志没有反复重启，系统原有直连网络仍能使用。此时保存配置目录位置和启动方式，下一章再导入订阅。若关闭客户端后网络异常，先检查系统代理是否还指向已经停止的本地端口；恢复直连后再处理安装问题，避免把残留代理误判为整个系统网络损坏。

四、导入订阅与管理配置

先确认订阅交付了什么

订阅地址可能返回完整 Clash YAML，也可能只返回节点列表或其他格式。完整配置通常包含节点、代理组和规则，导入后可形成一套可选择的 Profile；节点集合则可能需要配合主配置中的 provider 才能使用。Base64 只是编码方式，不代表内容必然兼容。导入之前先确认服务方提供的目标格式，不能只看链接能否在浏览器中打开。

在客户端的配置或订阅页面新增远程配置，粘贴完整地址并保存，等待下载完成后选择这份配置作为当前配置。只新增条目但没有激活，是常见的遗漏。激活后检查代理组是否出现，展开组内节点并确认并非全部为空。若客户端提供下载时间和更新时间，应记录最近一次成功状态，但不要把刷新按钮已点击等同于服务器内容已经成功替换。

订阅地址可能包含访问凭据，应按账号信息保管。分享截图时遮住完整地址，向他人提交日志前删除其中的查询参数和认证字段。不要将私人订阅粘贴到不熟悉的在线转换页面；转换服务如果参与处理，就可能读取地址和节点内容。需要格式转换时，优先使用提供方明确支持的输出方式，或在受控环境中完成转换并检查结果。

区分本地修改与远程更新

远程配置的源文件通常会在下次更新时被替换，直接编辑其中的规则不一定能够保留。客户端的覆写、合并或扩展配置功能用于保存本地差异，但各客户端的合并顺序并不相同。使用前先确认是追加还是替换整个数组，并查看最终生效配置。不能因为编辑器中存在一条规则，就认定它已经出现在内核当前读取的文件中。

以下是 mihomo 的远程节点集合片段，仅适用于已经提供 provider 兼容内容的场景。示例域名用于说明结构，不会提供实际节点；使用时必须改为自己的有效地址。对应主配置还需定义引用该 provider 的代理组。下载普通完整订阅时，应优先使用客户端的远程配置入口，不必为了导入而自行拆成多个文件。

proxy-providers:
  remote:
    type: http
    url: "https://example.com/proxies.yaml"
    path: ./providers/remote.yaml
    interval: 3600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote

处理更新失败与多配置切换

订阅更新失败时，先区分下载失败和解析失败。下载失败要检查当前网络、订阅有效性以及请求是否错误依赖尚未工作的代理；解析失败则要看返回内容是否为网页、登录提示或不兼容格式。不要把接口返回的错误页面保存成 YAML 后继续修改缩进。保留上一份可用配置，能让更新失败时仍有明确回退路径。

多套配置应按用途命名，并记录来源、适用客户端和本地扩展位置。切换后代理组名称可能变化，旧的节点选择不一定能继承；要重新检查当前模式和默认组。自动更新间隔应结合提供方要求，不需要频繁手动刷新。具体格式差异见订阅 URL、YAML 与 Base64 说明，多配置组织方式见Profile 管理方法。

五、选择代理模式并验证连接

模式决定策略，不决定流量入口

规则模式按配置中的规则逐条决定流量去向，适合日常分流；全局模式通常将进入内核的代理流量交给全局选择器；直连模式让进入内核的流量使用直连策略。三者决定的是内核如何处理已经收到的连接。若应用根本没有使用系统代理，也没有被 TUN 接管，切换规则或全局模式不会自动使它进入内核，这也是排查时最需要先确认的边界。

系统代理是操作系统向应用提供的一组代理设置，不是对所有网络连接的强制接管。有些应用遵循它，有些使用自己的代理配置，还有些直接连接网络。先在一个明确支持系统代理的浏览器中验证，再扩展到其他应用。不要用某个游戏或命令行工具未走代理的现象，直接推断系统代理开关失效；它们可能根本不读取这一设置。

按入口、规则、出口检查

导入配置后，先在主要代理组中选择一条节点，再开启系统代理并发起新的浏览器请求。观察连接面板是否出现目标域名，检查命中规则和策略链是否与预期一致。已有长连接可能继续使用之前的路径，切换节点后应新建连接再观察。若日志完全没有对应请求，优先查应用入口和代理端口，不要先修改远端节点参数。

命令行可用以下方式显式指定本地 HTTP 代理。示例端口必须与实际配置一致，目标服务本身也必须可以访问。收到 HTTP 响应只能证明这一次请求通过指定入口完成；最终是否走远端节点，还需查看规则和连接记录。若规则选择 DIRECT，即使命令使用了本地代理入口，出口仍然可能是当前网络的直连出口。

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

测试网站时，应把连通性、出口地址和服务可用性分开。页面能打开不代表所有资源都走同一路径，出口地址变化也不代表某个特定服务必然可用。服务方可能依据账号、地区、设备或业务策略限制访问。选择节点时先确认线路能建立连接，再比较实际业务表现；关于延迟与倍率的判断，可阅读Clash 节点选择方法。

Windows UWP 回环与应用例外

部分 Windows 沙盒应用受网络隔离约束，可能不能访问本机回环代理。只有在确认应用使用系统代理、浏览器测试正常且连接未进入内核后，才考虑 UWP 回环例外。若客户端提供回环管理工具，应按具体应用授权，不要批量修改全部应用。回环例外解决的是本地入口访问限制，不能修复订阅失效、节点超时或规则指向错误。

应用有独立代理设置时，应检查它是否与系统设置冲突。停止客户端之前关闭系统代理，避免系统继续连接已停止的端口。若开启全局模式后业务恢复，而规则模式失败，应记录两种模式下的策略链，再转到规则章节定位；若所有节点在显式代理测试中都失败，则应先查节点与网络。首次验收还可参考连接检查清单，不要只依赖一个开关颜色作结论。

六、编写 Clash 自定义规则

从上到下匹配，先命中先决定

规则列表有顺序，不是若干条件的无序集合。内核通常从上向下检查，命中后选择对应策略，因此更具体的例外应放在宽泛规则之前，兜底规则放在末尾。若 MATCH 已经接住全部剩余连接，其后的普通规则便没有机会处理这些连接。修改分流时先确认规则位置，再确认策略名称，不能只看规则语法是否能通过解析。

DOMAIN 用于精确域名匹配，DOMAIN-SUFFIX 用于域名后缀，IP-CIDR 用于地址网段，GEOIP 则依据地理地址数据。域名规则需要内核获得相应名称信息，地址规则依赖目标地址和相关数据。无法仅凭一条域名规则解决所有访问方式，特别是应用直接请求 IP、使用独立解析或连接复用时，更要结合连接面板观察实际目标。

先用小范围例外验证顺序

下面的片段表示文档域名直连、代码托管域名交给 PROXY，再处理中国地址与剩余流量。PROXY 必须已经在实际配置中定义。网段规则的 no-resolve 用于避免为了这一条地址匹配额外触发域名解析，不应理解为关闭整个配置的 DNS。示例只是说明顺序，是否适合当前网络，应根据业务目标逐条确认。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

新增规则后重新载入配置，再发起一条新连接。查看命中规则、目标域名及最终代理组，确认修改实际进入了运行配置。如果命中的是更前面的规则，就调整顺序或缩小上游条件；如果始终出现 IP 而不是域名，就检查应用解析方式和 DNS 链路。遇到整站多个域名共同参与的业务，不要只为主页面加一条规则，还应观察登录、接口和资源域名的连接。

规则集合与本地覆写的边界

规则数量增加后，可以通过 rule-providers 引用规则集合，并在 rules 中使用 RULE-SET。集合的行为类型应与内容一致，域名列表、地址列表和经典规则不能随意混用。远程集合更新失败时，内核可能继续使用已有缓存，因此界面显示某个集合存在，不一定代表刚刚下载成功。应同时检查更新时间、日志和具体连接命中结果。

订阅规则与本地规则合并时，最重要的是最终排列顺序。有的覆写会替换完整 rules 数组，有的只在前后插入；把例外追加在 MATCH 后面通常达不到目的。长期维护建议将本地规则缩减到明确的个人差异，并记录添加原因。整份复制外部规则可能带来重复条件和过时分类，出错时也难以判断应该修订哪一层。

规则测试应同时包含一条应直连请求和一条应代理请求，防止修好一个站点却改变其他业务。若选择 REJECT，要确认被拒绝的确实是目标连接，而不是登录依赖。共享配置前删除私人域名和内网结构。熟悉常用匹配后再尝试进程规则等平台相关条件，不同系统对进程识别的支持和权限要求有差异，不能把一台设备的结果视为全平台保证。

七、配置 TUN 与 DNS

TUN 接管与系统代理的差异

TUN 通过虚拟网络接口和路由接收流量，可覆盖部分不遵循系统代理的应用，但它不是节点加速选项。启用后，流量入口和 DNS 路径都会发生变化，因此应在普通代理已经可用后再开启。不同系统可能需要后台服务、管理权限或网络扩展授权；移动端通常使用系统 VPN 接口。具体可用字段取决于客户端采用的内核及其开放的设置入口。

先确认当前没有另一个 VPN 或 TUN 程序控制同类路由，再启用客户端的 TUN 开关。记录启用前的本地网络、内网域名和主要业务是否正常，随后逐项比较。企业 VPN、虚拟机网段和远程管理链路可能与自动路由冲突。不要在唯一的远程会话中直接切换路由接管方式，应先准备本地控制台或独立回退通道，避免失去管理连接。

把 DNS 当作完整链路处理

DNS 不只是配置一个服务器地址，还涉及谁发起查询、查询从哪条路径出去、回答如何交给应用，以及规则何时使用解析结果。fake-ip 模式会给域名分配用于映射的虚拟地址，再由内核关联真实目标；它不是节点出口地址。某些内网服务或设备发现机制需要真实地址，应按实际问题设置例外，而不是一次性给所有域名关闭映射。

下面是 mihomo 的学习片段，展示 TUN 接管与内置 DNS 的关联。DNS 监听限制在本机回环地址，示例上游的可达性仍取决于当前网络。只应在保留已有节点、规则和客户端必要设置的前提下合并；若界面已有 DNS 与 TUN 管理项，优先从界面调整并核对最终配置，避免同一字段被两处反复覆盖。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

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

dns-hijack 中的端口设置针对相应传统 DNS 请求，不代表能够自动处理所有加密 DNS 通道。浏览器或应用若自行使用加密解析，可能改变域名可见性和规则判断条件。排查时应记录这些设置，临时统一解析路径后比较结果。DNS 上游若需要代理才能访问，还要避免代理节点自身解析又依赖同一条尚未建立的代理链路。

按症状回退，不同时改多层

TUN 开启后全部应用失去连接，应先关闭 TUN，确认原来的系统代理基线是否恢复，再检查路由、权限和日志。只有域名访问失败而直接地址可达时，重点查看 DNS；只有内网服务失败时，检查私有网段路由和内网解析；只有某个应用异常时，观察其协议与连接路径。一次只调整一个层次，才能知道恢复来自哪项修改。

停止 TUN 后应检查虚拟接口、路由和系统 DNS 是否已恢复正常。不要因网页恢复就忽略后台应用的旧连接，也不要长期叠加多个网络接管工具来“补漏”。可靠的验收包含普通网页、非系统代理应用、内网访问和休眠唤醒后的重连。若当前使用只需要浏览器代理，保留更简单的系统代理方式即可，没有必要为启用高级选项而扩大维护范围。

八、维护配置与排查异常

保留可回退的工作基线

日常维护的目标是知道当前正在使用什么，并能在修改失败后恢复。至少记录客户端名称、内核来源、当前 Profile、本地入口端口和覆写位置。备份时区分远程源配置与个人扩展，尤其要保存不能从订阅重新取得的规则。备份文件可能包含节点凭据和订阅地址，应存放在受控位置，不要上传公开代码仓库或随意发给他人排查。

客户端更新、内核更新和订阅更新是三个独立变化。更新客户端可能改变服务管理与合并逻辑，更新内核可能改变字段支持，订阅更新则可能改变节点、组名与规则。出现异常时先确认最近改变了哪一层。不要在同一轮排查中同时升级客户端、替换订阅并改写 DNS，否则即使网络恢复，也很难解释原因或复现稳定配置。

把无法上网拆成具体症状

完全没有连接记录，通常先检查应用是否进入本地入口，以及系统代理是否指向正确端口。已有记录但节点连接超时，重点检查节点状态、远端地址可达性和当前网络限制。出现名称解析失败，则检查 DNS 请求和节点地址解析。收到明确的 HTTP 错误响应时，说明连接可能已经到达某个服务，应继续区分代理认证、目标服务拒绝和账号业务限制。

网络切换和休眠唤醒后，旧连接可能仍依赖已经失效的接口。先新建请求，再尝试重启内核，不必立即删除配置。如果公共网络需要网页认证，先完成接入认证，再恢复代理；否则订阅更新和节点探测可能同时失败，看起来像所有线路突然不可用。移动设备还应检查后台运行限制，确认系统是否在锁屏后停止了客户端进程或网络会话。

日志要足够定位，也要控制范围

平时可使用信息级日志，需要定位时短时提高详细程度，复现一次后恢复。长期开启大量详细日志会增加磁盘写入，也可能记录域名、路径和连接元数据。提交问题时附上操作顺序、系统平台、错误时刻和相关几行日志即可；删除订阅、认证内容和私人网络信息。只有“连不上”而没有入口、策略和错误类型，通常无法得到可执行的判断。

节点探测成功而业务失败时，应使用同一业务进行对照，并检查它是否使用 UDP、多个域名或独立解析。探测地址和业务服务不是同一目标，结果不同并不矛盾。也不要把全局模式作为长期掩盖规则问题的办法；可以短时比较路径，但应最终恢复所需模式并修正对应条件，避免内网、更新服务和其他应用被意外改道。

一轮维护结束后，关闭不再需要的调试功能，清理重复自启动项，并确认退出客户端时系统能够回到预期状态。将有效修改写成简短记录，例如调整了哪条规则、针对什么症状、如何验证。下次遇到类似问题时先查这份记录，而不是再次复制整份陌生配置。稳定配置的价值不在字段多，而在每项修改都有可观察的原因和结果。

九、建立可验证的进阶路线

从单设备走向可维护配置

完成前八章后，进阶应围绕明确需求展开。经常手动切换节点，可研究代理组决策；规则重复维护，可研究规则集合；需要服务常驻运行，再学习命令行和服务管理。不要把外部配置中的每个字段都复制到自己的环境。一个选项在路由器上有意义，不代表在移动设备上同样适合；依赖条件、权限和回退方式都应先弄清楚。

代理组中的 select 适合明确手动选择，url-test 根据指定探测结果比较候选节点，fallback 则按可用性与顺序选择。自动选择不是业务质量保证，探测请求成功也不代表所有目标服务可用。配置时应明确探测地址、检查间隔和候选范围，避免为了观察排名而频繁探测。需要业务地区稳定时，手动固定合适线路可能比频繁自动切换更符合目标。

命令行部署先验证，再常驻

Linux 无界面环境应先在前台验证配置，确认日志与文件路径，再接入 systemd 等服务管理方式。程序工作目录和配置目录不能混淆，规则集合的相对路径也需要稳定的落点。以下命令假定 mihomo 已位于可执行路径，且当前目录已有完整的配置文件。语法测试通过只说明配置可被读取，并不保证节点、DNS 和目标业务都能连接。

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

前台运行正常后，再按系统规范设置服务用户、工作目录、配置路径和重启策略。默认不要使用高权限账户处理所有任务；若 TUN 确需特定网络能力，应按部署环境授予必要权限。查看服务日志时区分进程退出与网络请求失败，错误配置导致的无限重启不会自行修复。具体桌面与命令行差异可参考Linux 部署 Clash 的两种方式。

管理接口与共享网络单独评估

外部控制接口是管理入口，不是普通代理入口。需要控制面板时，应优先限制在本机或受控网络，并配置适当认证；不要直接暴露到公共网络。开放局域网代理也应有独立的访问范围和防火墙规则。管理接口、订阅凭据和代理认证分别保护不同对象，设置其中一种并不会自动保护另外两种，部署时应分别检查实际监听地址。

路由器或网关部署会影响其他设备，风险范围明显大于单机。先建立测试设备和旁路回退方案，确认网段、DHCP、DNS 与出口路由的关系，再逐步扩大接管范围。IPv4 正常不代表 IPv6 路径相同，UDP 正常也不能由一次网页测试推导出来。每次扩大范围都应覆盖直连业务、代理业务与内网业务，不能只验证一个外部站点。

最后建立一张属于当前环境的验收清单：内核启动、订阅更新、直连规则、代理规则、DNS、网络切换和退出恢复。每次修改只改变一个主要变量，保留修改前后的日志与配置差异。若实验失败，先恢复已知可用状态，再整理原因。需要重新走最短连接流程时返回使用指南；需要换客户端时先看下载中心，不要把迁移软件当作所有网络问题的统一解决办法。