Clash 系统教程：
安装、分流与维护手册

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

先分清界面和执行层

Clash 生态中的客户端通常由图形界面和代理内核组成。界面负责导入订阅、显示策略组、修改设置以及申请系统权限；内核负责监听本地端口、解析连接信息、匹配规则并建立出站连接。看到界面启动，不代表内核已经正常运行；看到内核运行，也不代表系统流量已经送入代理。排错时分开判断这两层，比反复重装更有效。

mihomo 是这一生态中常用的内核。不同客户端可能打包不同内核，也可能限制可修改的字段。同一份配置能否跨端使用，取决于协议、规则类型、内核功能和平台能力是否兼容，而不是文件扩展名是否相同。跨端迁移时先复用订阅和策略结构，再检查端口、文件路径、网卡名称等设备相关设置，不要直接覆盖全部本地偏好。

一条连接经过哪些环节

可以把工作流程理解为四步：应用发起请求，流量进入本地代理入口，内核根据模式与规则决定出站，最后由直连或远端代理访问目标。系统代理与 TUN 主要解决第二步，规则和策略组解决第三步，节点协议负责第四步。网页失败可能发生在任意一步，因此“更换节点”只是一个排查分支，不能替代对入口与解析过程的检查。

配置文件描述这些环节之间的关系。proxies 定义具体代理，proxy-groups 把代理组织成可选择或自动测试的集合，rules 按顺序把连接交给某个策略。订阅可能包含完整配置，也可能只包含节点信息；只有节点信息时，客户端还需要模板补齐策略组和规则。订阅可以解析，不等于它已经具备完整的分流逻辑。

节点是远端服务的连接参数，策略组是节点的组织方式，两者不要混用。一个名为 Proxy 的策略组，可以选择某个节点，也可以指向其他策略组；直连策略 DIRECT 则表示目标连接不经过远端代理。组名通常由配置作者定义，没有统一的中文名称。后续示例使用 Proxy，只用于说明引用关系，实际修改必须对应自己的配置。

本地端口和 DNS 的位置

本地监听端口相当于应用进入内核的入口。混合端口可以在同一端口接受常见的 HTTP 代理和 SOCKS 代理连接，但不会自动接管所有程序。DNS 则把域名转换为地址，并影响域名规则能否及时判断。浏览器使用自己的加密解析、系统使用另一个解析器时，同一目标可能走出不同路径，日志中的域名与实际连接地址需要结合观察。

准备开始前，还要区分软件和网络服务。安装客户端不会自动产生可用的远端代理；可用连接需要自行持有且有权使用的配置。订阅地址经常带有访问凭据，应当像密码一样保存。截图、日志和求助内容都可能暴露它，分享前需移除完整链接、账户标识及节点认证信息，仅保留与问题有关的字段和错误现象。

本章的完成标准不是记住全部术语，而是能够回答三个问题：当前使用哪个客户端和内核，配置从哪里加载，应用通过什么入口进入内核。把这三项记录下来，后面遇到系统代理没有生效、规则不命中或订阅更新失败时，才能选择正确的检查方向，而不是同时切换多个开关。

二、选择客户端：先看平台，再看需求

优先选择能够持续维护的日常入口

客户端选择先看设备系统、处理器架构和使用场景，再看外观。首次使用可以优先了解 Clash Plus，按客户端下载页的系统分组选择安装入口。需要频繁编辑配置、查看连接或使用特定内核功能时，再比较其他客户端。不要仅凭某篇旧教程中的截图选型，菜单相似并不表示当前系统支持情况和权限流程仍然一致。

桌面端常见需求包括托盘常驻、系统代理、开机启动、配置覆写和 TUN；移动端更关注系统 VPN 授权、后台运行以及休眠后的连接恢复。先写出真正需要的两三项功能，再查对应客户端的说明。没有计划使用的高级开关不必成为选择依据，功能越多并不意味着首次配置越简单，也不保证与其他网络软件更兼容。

架构、配置兼容与历史客户端

处理器架构和操作系统名称是两个维度。macOS 的 Apple Silicon 与 Intel 安装包不能仅按文件名中的 Mac 判断；Android 的 ARM64 与 ARM 包也应依据设备能力选择。Windows 设备若采用 ARM 处理器，需要查看应用明确列出的支持方式，不应把所有桌面安装包都当作原生适配。下载页没有列出的架构，不要自行猜测安装包地址。

Clash for Windows 与 ClashX Meta 属于已停止维护的历史选项，适合识别旧教程或迁移既有环境，不宜把归档包当成持续更新的默认方案。寻找 Clash for Windows 替代时，重点检查新客户端能否读取现有配置、如何保存覆写，以及退出时是否恢复系统代理。迁移完成后再移除旧程序，避免两个客户端同时争用同一监听端口。

客户端能够导入一个文件，不代表里面每项功能都会生效。订阅中的协议、规则提供器、脚本或内核专用字段可能超出目标应用的支持范围，Surfboard 等应用也需要使用它明确支持的配置格式。导入报错时先读字段名称与行号，不要把不兼容的配置反复提交。必要时向配置提供方索取对应格式，而不是依赖不明转换服务处理凭据。

为迁移建立最小记录

切换客户端之前，记录当前订阅名称、模式、策略组选择以及哪些应用依赖手动代理。同时保存自己添加的规则，区分它们是直接写在订阅文件里，还是由客户端覆写机制管理。远程订阅文件在更新后可能被替换，只有保存在正确位置的本地修改才容易迁移。记录应保存在本地，不要把完整订阅链接贴进公开笔记或截图。

iOS 的 Clash Plus 可通过下载页进入 App Store，产品官网为 clashplus.io。移动系统通常通过 VPN 配置承载流量接管，与桌面的系统代理开关不是一一对应关系。学习跨平台教程时，应对照功能目的理解操作，不要在手机上寻找桌面独有的混合端口菜单，也不要在桌面照搬手机的后台权限路径。

这一阶段只需要确定一个主用客户端和一个回退方案，不建议同时试装多个常驻代理。先用主用客户端完成后续安装与导入，确认能恢复正常网络后，再研究其他界面的差异。选择结果应当能够说明理由：设备支持、配置兼容、必要功能齐全，并且遇到异常时能找到日志和退出入口，而不是只依据名称或界面配色。

三、安装检查：建立可回退的运行环境

安装前先清理冲突条件

安装前先退出其他代理客户端、游戏加速器和可能修改系统网络的工具，再记录当前是否存在手动代理、企业 VPN 或特殊 DNS。这里的退出应包括后台进程，而不只是关闭窗口。多个程序同时改变路由和代理设置时，界面可能各自显示正常，但真实流量会交给另一套入口。保留原有网络设置截图，可以在测试结束后恢复工作环境。

从下载页选择适合系统与架构的包，阅读客户端自己的安装提示。安装版、便携版和压缩包的存储位置可能不同，便携运行也不代表全部数据都保存在程序目录。首次启动前确认配置目录是否可写，避免把程序放在只读路径或受严格限制的系统目录。需要安装服务时，应理解它是为了提供网络权限，而不是连接远端代理的凭据。

按平台完成必要授权

Windows 首次运行时，先确认主界面与托盘入口都能打开，再查看内核是否启动。防火墙提示需要按实际使用范围处理，不要为了省事允许所有网络访问。仅供本机使用时，不必开启局域网监听。TUN 所需的服务或管理员权限可以等到基础连接成功后再配置，这样首次失败时更容易区分安装问题和高级接管问题。

macOS 应按应用提示完成首次打开与系统授权。涉及网络扩展、辅助服务或钥匙串时，先确认提示来自正在安装的应用，不要盲目批准来源不明的请求。遇到“已损坏”或扩展无法启用，应检查下载来源、系统兼容和系统设置中的拦截信息；不要直接关闭整套系统安全机制。具体授权分支可参考macOS 安装与权限处理。

Android 与 iOS 在首次连接时通常会申请系统 VPN 权限。设备上已有其他 VPN 时，需要确认是否会被替换或暂停。Android 若长时间锁屏后断开，再检查电池优化与后台限制，先不要一次开放全部权限。Linux 则应确认软件包格式与发行版匹配，并按客户端说明安装桌面依赖和服务；图形界面能打开，不等于权限服务已经正常运行。

先验证本地入口，再开启自动启动

进入设置后，找到实际监听地址和端口并记录。教程常用的端口只是示例，可能被其他进程占用，也可能被客户端改写。端口冲突通常表现为内核启动失败或日志出现地址已被占用。此时先退出旧客户端，再确认冲突来源；不要随机更换多个端口，否则浏览器、终端或系统代理中的旧设置会继续指向失效入口。

# Windows PowerShell：查看示例端口的监听状态
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux：查看示例端口的监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

上面的命令用于诊断，不会自动启动代理。没有输出可能只是尚未监听；命令不存在也可能是系统未安装对应工具。发现进程后先确认归属，再决定退出哪个程序，不要直接结束不认识的系统服务。监听地址若是本机回环地址，其他设备无法连接，这是合理的本地默认边界，不应为了“修复网络”随意改为对外开放。

最后做一次回退测试：不导入复杂配置，先确认客户端能够正常退出，关闭后原来的直连网络仍可使用。然后重新启动，检查内核日志和监听端口是否一致。这个看似简单的步骤可以提前发现系统代理残留、权限服务异常和端口占用。保留这套基础环境，下一章只增加订阅，不同时调整 DNS、TUN 和局域网共享。

四、订阅导入：区分下载、解析与启用

选择导入方式并确认内容类型

订阅是客户端定期获取配置的一种方式，常见入口位于“配置”“订阅”或“Profiles”。从提供方复制完整链接后，选择从 URL 导入，为配置设置便于辨认的名称，再执行下载。链接中的查询参数可能用于身份认证，复制时遗漏尾部字符、带入空格或换行，都可能导致请求失败。不要把订阅链接直接放进搜索引擎或公开在线检测页面。

本地文件导入适合已有完整 YAML 配置的情况。先确认拿到的是配置正文，而不是网页登录页面、说明文字或压缩文件。订阅请求返回成功，也可能只返回账户登录页；下载成功与解析成功是两个判断点。若客户端提示格式错误，可查看文件开头和报错行附近的结构，但分享内容前必须去除认证字段，避免以排错为由暴露整份配置。

YAML 依赖缩进表示层级，通常使用空格而不是制表符。冒号后需要正确分隔，列表项要保持相同缩进。编辑时保留原有编码和结构，不要把中文标点当成语法符号。含特殊字符的字符串可以按 YAML 规则加引号，但不能机械地给所有字段包上引号。报错行经常只是解析器发现问题的位置，真正缺失的缩进或引号可能在前一行。

导入之后还要选择活动配置

配置出现在列表中，只说明客户端已经保存了它。继续点击“启用”“使用”或对应的活动标识，等待内核重新加载，再进入代理页面查看策略组。若当前仍显示旧组名，很可能只是下载完成但没有切换。检查活动配置名称、更新时间和加载错误，比立即删除重建更稳妥。多个配置并存时，给名称加上用途说明，避免日常误选。

完整配置通常会提供节点与策略组。先展开主要策略组，确认里面确实有可选择的出站，再选择一个有权使用的节点进行测试。节点名称可见不代表服务可用；凭据过期、远端不可达或协议不兼容，都可能在建立连接时才出现。也不要把延迟测试失败直接等同于所有网络失败，测试地址、测试方法与实际业务访问可能不同。

订阅更新与客户端更新是两件事。前者改变节点、规则或策略结构，后者改变程序和内核能力。远程更新可能覆盖直接编辑过的文件，因此长期规则应放在客户端提供的覆写、合并或本地扩展位置。先确认合并顺序，再做少量测试：有些机制整体替换数组，有些机制支持前置或追加，名称相近也不保证行为一致。

为更新失败建立分支判断

更新失败时，先区分请求没有完成、服务器拒绝访问与内容无法解析。请求超时需要检查当前网络、域名解析及更新是否依赖代理；拒绝访问应检查链接完整性、账户状态和提供方说明；解析失败则检查返回内容与内核支持范围。不要看到任何错误都归结为节点故障，因为订阅下载可能走的是另一条网络路径。

遇到首次导入必须通过代理才能下载的情况，可以使用提供方允许的本地配置导入方式，先建立基础连接，再测试更新路径。不要为解决一次下载问题，把订阅交给不清楚数据处理方式的转换站。订阅提供器和规则提供器还可能分别下载外部文件，主配置加载成功后，仍要查看这些资源是否就绪，尤其是首次启动和离线恢复时。

本章完成后，应能在配置列表指出当前活动项，在代理页找到主要策略组，并能解释更新失败发生在下载还是解析阶段。把最后一次可用配置保存在本地，同时记录自定义修改的位置。下一章先使用已有策略验证模式，不立即扩展规则；这样当访问结果变化时，才能明确变化来自模式切换，而不是订阅内容同时更新。

五、代理模式：入口和出站分开判断

规则、全局、直连解决什么问题

代理模式决定进入内核的连接如何选择出站。规则模式按配置中的规则逐条匹配，适合日常按目标分流；全局模式把进入内核的连接交给全局策略选择；直连模式让这些连接直接访问目标。三种模式都以流量已经进入内核为前提。没有被系统代理、手动代理或 TUN 接管的应用，不会仅因为切到全局模式就自动改变路径。

初次验证可先选择规则模式，检查主要策略组是否选中了可用节点，然后打开一个明确需要代理的目标与一个正常直连目标。两者都测试，是为了防止只验证单一网站就误判全部网络正常。出现失败时再短暂切换全局进行对照；若全局可用而规则模式失败，应优先看规则命中和策略组引用，而不是立即重装客户端。

全局模式不等于所有设备流量都被代理，也不保证 DNS 请求采用同一出口。它只改变内核对已接收连接的策略决策。某些客户端的全局选择与日常 Proxy 策略组相互独立，切换后要检查全局策略当前指向哪个出站。完成测试后恢复原模式，并重新验证业务，避免长期使用临时测试设置却忘记实际分流需求。

系统代理是入口，不是模式

系统代理开关修改操作系统提供给应用的代理信息。浏览器通常会遵守，但游戏、部分更新程序、终端工具或自带网络实现的应用可能不会。某个程序直连并不必然说明规则错误，它可能根本没有访问本地代理端口。先在连接列表中寻找对应进程和目标；没有记录时，应该检查入口，而不是继续调整已无法影响该连接的规则。

需要独立测试本地 HTTP 代理时，可以使用下方命令。这里的端口仅是示例，必须替换为客户端实际监听的混合端口或 HTTP 代理端口。命令显式指定入口，因此不依赖终端是否读取系统代理。测试成功只说明这条请求经由该入口完成，不能证明浏览器、其他协议或所有目标都已经使用相同路径。

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

用连接记录确认判断

观察一次请求时，依次记录来源应用、目标域名或地址、命中规则、策略组以及最终节点。若请求走了 DIRECT，先看是否符合配置；若命中正确策略但失败，再检查节点连接与解析。连接列表通常会合并或快速移除短连接，可以先打开日志再复现。不要只凭托盘颜色或一个总开关判断真实出口，它们表达的状态可能只是服务运行中。

切换模式后，已经建立的长连接不一定立即迁移。浏览器连接复用、聊天程序长连接和视频流都可能继续使用原路径。对照测试时应新建请求，必要时关闭对应应用再打开；若客户端提供关闭连接功能，也要注意它会中断正在传输的任务。不要连续快速切换模式并观察同一条旧连接，这样容易得到相互矛盾的结果。

本章建议形成固定测试顺序：确认内核监听，确认应用进入内核，确认模式，再确认出站。直连模式也不是退出软件的替代品，程序仍可能保留系统代理入口。结束测试应按客户端流程关闭接管并检查系统恢复。遇到“已连接却打不开网页”，可结合订阅、端口与系统代理排查清单逐项定位。

六、规则分流：顺序、策略组与本地覆写

从一组可以解释的规则开始

规则通常从上到下匹配，命中后交给对应策略，因此顺序和内容同样重要。精确例外应放在宽泛规则之前，兜底规则应放在末尾。只新增规则而不检查位置，可能永远不会生效；把 MATCH 放在前面，后续规则就无法承担预期分流。学习时先理解几条规则的边界，再引入大型规则集合，避免遇到异常时无法解释命中原因。

DOMAIN 匹配指定域名，DOMAIN-SUFFIX 匹配该域名及其子域名，DOMAIN-KEYWORD 则按域名中的关键词匹配。关键词规则覆盖面更宽，容易把不相关服务纳入同一策略。IP-CIDR 针对地址网段，GEOIP 依赖地理数据库，判断结果不等于服务的实际运营地域。域名规则与地址规则使用不同信息，应根据真实连接记录选择，而不是互相替代。

# 合并到已有配置中；Proxy 必须是已经存在的策略组
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-SUFFIX,google.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

这段示例只展示规则块，不包含远端节点，不能独立建立代理。no-resolve 表示这条地址规则不主动为了匹配域名连接而触发解析，并不是全局关闭 DNS。局域网直连还需要结合实际网段和 TUN 路由检查，单独列出一个私有网段不代表覆盖所有内部网络。企业环境中可能存在自定义地址段，应以实际网络设计为准。

策略组让规则与节点解耦

规则指向策略组，可以在不改动规则的情况下切换节点。选择型策略组由用户决定当前出站，自动测试型策略组按配置的测试结果挑选，故障转移型策略组按顺序寻找可用成员。它们解决的问题不同：测试延迟较低不等于下载吞吐更高，测试目标可达也不代表业务域名可达。应根据用途选择，而不是把所有组都改成同一种类型。

修改组名时必须同步检查规则、其他策略组与覆写中的引用。组名不一致可能导致加载失败，或者使原本期望的引用失效。先复制一份可用配置，在单个策略组中测试成员与选择，再扩大修改范围。还要避免组与组之间形成循环引用；如果客户端报出循环依赖，沿引用链逐个检查，而不是通过删除错误提示涉及的任意节点来绕过。

更新安全的自定义方式

长期自定义应优先使用客户端支持的覆写或合并功能。先确认新增规则被放在订阅规则之前还是之后，再加入一条容易验证的测试规则。如果合并机制直接替换整个 rules 数组，原有分流可能全部消失；如果只在末尾追加，新增规则又可能落在 MATCH 后面。保存前查看合并结果，比只查看编辑框中的片段更可靠。

规则提供器可以把大量规则放在单独资源中，再通过 RULE-SET 引用。使用前需要理解提供器的格式、行为类型和更新方式，域名集合与完整规则集合不能随意互换。资源下载失败时，主配置可能仍能加载，但分流结果会发生变化。检查日志中的资源状态和缓存情况，确认问题不是提供器尚未就绪，再讨论单条规则的准确性。

实际排错可固定一个目标，先观察域名是否可见，再查看命中条目与最终策略。若只看到地址，要考虑应用直接连接地址、解析缓存或流量接管方式的影响；若规则正确但服务仍异常，则可能还有其他域名、内容分发地址或登录接口需要同时访问。不要为解决一个应用就直接把所有流量改为全局，先缩小例外范围并记录修改理由。

完成本章后，应能解释一条请求为什么命中当前规则，以及切换策略组会影响哪些目标。保存规则修改前后的差异，重新加载后用新连接验证。若结果与预期不符，先回退这一条修改，再检查下一层；保持小步变更，可以避免把订阅更新、DNS 调整和分流实验混成同一个故障。

七、TUN 模式：接管范围、权限与 DNS

什么时候需要 TUN

TUN 通过虚拟网络接口与路由把流量送入内核，适合不遵守系统代理的应用，也常用于统一处理更多网络流量。它与系统代理的主要区别是接管位置，而不是“更快”或“更高级”。实际覆盖仍受路由排除、应用绕过、协议支持和平台限制影响，不能把开启 TUN 理解为每一个数据包都会采用同一远端出口。

开始之前，应已经完成订阅可用、规则合理和普通入口可用的验证。先保存当前配置，退出其他 VPN，确认远程办公、虚拟机与容器网络是否依赖特殊路由。若设备通过远程连接管理，贸然改变默认路由可能导致管理连接中断，应提前准备本地控制或回退方式。TUN 排错建立在基础代理可用之上，不能用来掩盖不可用的订阅。

逐项启用，不叠加修改

按照客户端提示安装权限服务或完成系统授权，开启后查看虚拟接口、路由与内核日志。部分客户端会自动协调系统代理，另一些允许两者并存，行为以客户端说明为准。为了对照效果，可以先在单一接管路径下测试，确认目标应用是否出现连接记录，再决定是否保留另一种入口。不要盲目同时打开所有网络增强选项。

# mihomo 配置片段，需与现有配置及客户端管理方式协调
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

示例中的自动路由负责添加接管路径，自动识别接口用于寻找出站网卡，DNS 劫持条目用于接收匹配的 DNS 流量。实际可用字段与行为取决于内核和系统；若客户端已有 TUN 设置页面，应优先用它管理，避免界面与文件互相覆盖。单独复制这个片段不能补齐完整 DNS 服务，也不能保证所有平台使用相同的栈实现。

DNS 决定域名如何参与分流

DNS 是 TUN 场景的重要配套。Fake-IP 模式把域名映射到虚拟地址，让内核在后续连接中关联原域名；传统真实地址解析则直接返回目标地址。两者有不同的兼容边界，不能仅以一次网页打开速度判断优劣。某些依赖真实地址的设备发现、内部服务或应用需要例外处理，调整前应确认问题确实来自解析模式，而不是规则或路由。

fake-ip-filter 用于列出不采用虚拟地址返回的域名，但它不是通用的代理绕过清单。返回真实地址之后，连接仍会继续参与规则判断。把一个域名加入过滤列表，并不自动保证直连；若服务需要直连，还要检查规则与路由。关于地址映射过程，可继续阅读Fake-IP 模式与虚拟地址池，再选择最小范围的例外。

DNS 劫持也不等于拦截所有解析方式。应用自带的加密 DNS 可能通过普通 HTTPS 或其他连接发送，不能只凭端口五十三的接管判断它已经进入内核 DNS。遇到域名规则表现不一致时，检查浏览器安全 DNS、应用内解析和系统缓存。不要同时修改系统 DNS、内核解析器与浏览器设置，应每次只改变一处并重新建立连接。

还要测试网络切换：从有线切到无线、从 Wi-Fi 切到移动网络、休眠后恢复时，原来的出站接口可能变化。若普通代理可用而 TUN 失败，检查默认接口、路由残留、权限服务和 DNS 接管，再决定是否重启客户端。更完整的取舍见TUN 与系统代理覆盖范围对比。本章的完成标准是接管有效、内部网络正常、关闭后可以恢复原网络。

八、日常维护：更新、测速与故障记录

把配置更新和程序更新分开

稳定使用后，维护重点是控制变量。订阅更新、客户端更新、内核切换和系统升级不要集中在同一次操作中完成。先记录当前活动配置、模式与策略选择，完成一种更新后重新测试，再进行下一种。这样发生故障时，能够把变化关联到具体操作。只记录“昨天能用、今天不能用”，通常不足以区分远端服务变化和本地环境变化。

更新订阅前，确认本地自定义规则已经保存在不会被替换的位置，并保留一份可用配置。更新后检查策略组名称、成员和主要规则是否变化，原来选中的节点可能已经被移除。客户端升级则应阅读功能与兼容说明，留意配置目录、权限服务和内核参数是否变化。不要让旧进程与新程序同时运行，否则界面与实际监听进程可能不属于同一套安装。

测速结果只回答有限问题

Clash 节点测速通常针对指定测试地址，反映一次请求的响应表现，不等于持续下载速度，也不代表所有网站的体验。测试失败可能来自测试目标本身、解析路径或请求超时设置。比较节点时应使用一致条件，观察同一目标在相近时间的结果，再结合实际业务验证。频繁刷新测试不仅增加请求，也容易把短时抖动当成长期质量差异。

自动测试策略组同样受测试目标与间隔影响。过短间隔可能让选择频繁变化，长期连接却不会随每次变化立即迁移。若某个业务对出口稳定性有要求，手动固定可用出站可能更合适；若更关注可达性，则需要合理的故障转移。不要根据一个延迟数字就断定节点适合视频、会议或大文件传输，这些场景依赖的指标并不相同。

按链路保存排错证据

发生故障时，先确认不经过代理的基础网络是否正常，再检查订阅有效性、内核监听、系统入口、规则命中与 DNS。记录一个可稳定复现的目标和具体时间，不要同时测试十几个应用再把结果混在一起。日志先用常规级别，确需进一步定位时才短暂提高详细程度；排查完成后恢复，避免日志持续增长并积累不必要的访问记录。

连接被拒绝与连接超时的含义不同。前者常提示本地端口没有监听、远端服务拒绝或防火墙主动拒绝；后者可能涉及丢包、路由、目标不可达或解析等待。错误文字只是线索，不是最终结论。应结合发生位置判断：本地入口拒绝时更换远端节点通常没有帮助，规则已命中但远端握手失败时，反复开关系统代理也不会修复认证问题。

整理求助材料时，保留客户端与系统名称、使用模式、复现步骤、目标类型以及脱敏错误。删除订阅链接、节点地址中的账户参数、密码和可识别个人的信息。日志可能含访问域名，截图中的二维码也可能等同凭据。若已经公开了完整订阅，应到服务提供方重置相关访问凭据，仅删除帖子不能消除已被复制的风险。

定期清理不再使用的配置、过时规则和测试用系统代理，备份则保留可用配置与本地修改说明。退出客户端后确认系统网络恢复，休眠和重启后确认活动配置仍正确。遇到相似故障时，优先查自己的变更记录，再参考本站使用文档与排查文章。本章的目标不是频繁维护，而是用少量记录让每次恢复都有明确路径。

九、进阶路线：从可用配置到可解释配置

先建立实验副本与观察方法

完成前八章后，进阶不应从堆叠更多参数开始，而应从解释现有行为开始。复制一份可用配置作为实验副本，给每次修改写清目的、预期结果和回退方式。测试时只改变一个变量，用同一目标建立新连接，记录命中规则与最终出站。只有能说明修改前后差异，才算真正掌握该参数，而不是碰巧得到一次可用结果。

第一阶段适合整理配置结构：把远端订阅内容、本地规则、策略组偏好和设备设置分开管理。确认哪些字段由客户端生成，哪些来自远程配置，哪些由覆写添加。若不知道最终配置是怎样合并出来的，就先学习客户端的合并顺序，不急于引入复杂脚本。配置规模增大后，清楚的来源边界比缩短文件长度更有价值。

按依赖顺序学习 DNS 和提供器

第二阶段可以深入 DNS。先理解基础解析器、代理域名解析与目标域名解析分别服务于哪个环节，再研究 nameserver、fallback 及其筛选条件。不要把多个加密解析地址简单堆在一起就认为更可靠；解析器自身的域名可能还需要引导解析，访问路径也可能依赖尚未建立的代理。依赖循环会让配置看似完整，启动时却一直等待。

具体字段可结合DNS 的 nameserver、fallback 与劫持配置详解逐项阅读。需要注意，fallback 的用途与判断方式取决于配置及内核实现，不宜机械理解为主解析器失败后才启用的备用列表。先建立可重复的域名测试，再观察解析结果、规则命中与连接表现，避免只看返回地址就下结论。

第三阶段再引入代理提供器和规则提供器。它们能把更新频繁的资源从主配置拆开，但也增加下载、缓存与启动依赖。应分别确认资源来源、格式、存储路径及更新间隔，检查首次下载失败时是否有可用缓存。不同设备的路径权限并不相同，桌面端可用的相对目录放到移动端或服务环境后，可能需要由客户端重新管理。

服务器、路由器与控制接口的边界

第四阶段才考虑在服务器或路由器运行 Mihomo 内核。这类环境没有桌面界面代为处理权限、服务启动与系统恢复，需要自行管理配置路径、运行用户、日志和路由。先验证本机显式代理，再设计局域网入口与防火墙范围，不要直接替换默认网关。路由器还涉及处理器架构、内存和系统组件，不能只按压缩包名称判断适用性。

控制接口用于查看状态或管理内核，不是普通代理入口。需要远程访问时，应限制监听范围并设置认证，再结合防火墙和受保护的管理通道。不要将控制接口直接开放到公共网络，也不要在公开配置仓库中保存认证字段。局域网代理共享同样需要明确使用者与访问边界，允许局域网连接只是入口设置，不会自动形成完整的访问控制。

当需要处理企业内网、分应用规则、双网络出口或 IPv6 时，先写出预期路径：哪类流量进入内核，哪类必须保留直连，解析由谁完成，断开代理后应是什么状态。IPv6 需要同时考虑地址、解析与路由，不应仅开一个字段就认定支持完整。涉及单位网络策略或受管理设备时，先取得授权，不要通过代理配置绕过既有访问限制。

最终应形成一套可解释的个人配置：每个策略组用途明确，每条例外有原因，每个后台服务知道如何停用，更新失败有回退。首次连接仍可回到快速上手文档，更换设备则回到客户端下载页。把学习成果落实为少量清晰规则与稳定操作流程，比长期复制不理解的配置片段更容易维护，也更容易判断下一次网络异常究竟发生在哪一层。