Clash 使用手册

一、核心概念与流量路径

客户端、内核、节点与订阅

Clash 不是单一安装包的名字。在实际使用中，图形客户端提供配置页、代理页、连接列表和系统开关；内核负责接收连接、解析目标、匹配规则并建立出口连接。mihomo 是这一生态中常见的内核。界面看起来相似，不代表内核功能完全相同；某个字段能否生效，应同时确认客户端如何生成配置、内核是否支持该字段。

节点是一组连接远端服务的参数，通常包括服务器地址、端口、协议与认证信息。客户端本身不等于节点服务，完成安装也不会自动获得可用线路。订阅则是取得配置或节点集合的一种更新入口。订阅链接经常附带访问凭据，应按密码保管；截图、日志和求助文本中都不应公开完整链接。

配置文件把这些对象组织起来：入站端口接收本地流量，节点描述远端出口，策略组把出口编成可选择的集合，规则决定某次连接交给哪个集合。订阅可能提供整份配置，也可能只提供节点列表。导入成功后，要确认实际生成了哪些对象，不能只凭配置页出现一个名称就认为连接准备已经完成。

先看接管，再看分流

一次访问可以拆成两件事。第一件是应用流量有没有进入内核，通常由系统代理、应用自己的代理设置或 TUN 完成。第二件是进入以后如何出站，由规则、策略组和节点决定。因此，连接列表完全没有记录，与记录已经出现但远端超时，是不同层面的故障。前者先查接管，后者再查规则、解析与出口。

系统代理只是向愿意遵循系统设置的应用提供代理地址，不是为全部网络连接铺设一条必经通道。浏览器可能遵循它，某些游戏、命令行工具或后台服务则可能忽略。TUN 通过虚拟网卡与路由扩大接管范围，但同样受路由排除、应用行为和系统权限影响。判断接管是否成功，要查看连接记录，而不是只看开关颜色。

用四个检查点建立判断依据

开始排错时，依次确认当前配置已启用、内核已经运行、应用连接进入内核、命中的策略能够完成访问。每一步都应保留一个可观察结果，例如配置页的活动状态、日志中的监听信息、连接页的目标域名和策略链。缺少哪个证据，就停在对应层检查，不要同时修改 DNS、节点和规则，让变化互相掩盖。

还要区分延迟测试与业务访问。客户端测试通常只对某个测试地址发起请求，结果能说明该测试路径是否完成，却不能证明所有网站、视频服务或登录接口都可用。后续验证应使用实际需要的应用，并记录时间、网络环境和错误表现。这样比较不同设置时，才知道改变的是同一条访问路径，而不是两个不相关的场景。

二、客户端与平台选择

按系统、架构和维护状态筛选

首次使用优先考虑 Clash Plus，再按平台比较其他客户端。选择时先确定系统与处理器架构，而不是从界面截图开始。Windows 的常见设备是 x64，部分设备使用 ARM64；macOS 要区分 Intel 与 Apple Silicon；Android 还需要确认安装包支持的指令集。架构不匹配可能表现为无法安装、启动失败或依赖转译，不能仅凭文件扩展名判断。

系统版本要求以下载页和客户端当前说明为准。不要因为同为 Windows 或 Android，就假设所有系统代际都能运行同一个安装包。下载前还应确认安装权限、磁盘空间和是否允许创建虚拟网卡。单位管理的设备可能限制网络扩展与服务安装，此时优先向设备管理员确认政策，不应把权限限制当作节点故障反复更换线路。

桌面与移动端的差异

Windows 用户通常先用系统代理完成浏览器验证，再决定是否启用 TUN。macOS 除了芯片架构，还要留意系统对应用和网络扩展的授权提示。Linux 桌面环境对系统代理的支持并不一致，某个开关生效不代表终端程序也会遵循。服务器或路由器可直接运行 mihomo，但需要自行负责服务启动、配置路径、监听范围和日志管理。

Android 客户端通常通过系统 VPN 接口接管流量，因此不能照搬桌面的系统代理操作顺序。首次启动需要确认 VPN 授权，持续运行还受省电策略影响。Surfboard 的配置语法与 Clash YAML 不同，选择前要确认订阅提供兼容格式，不能只修改文件后缀。相关后台设置可参阅安卓耗电与后台保活说明。

iOS 可选择 Clash Plus，通过App Store 产品页查看系统要求，产品官网为 clashplus.io。授权 VPN 配置后，还需要导入兼容配置并验证实际访问。手机上的 VPN 标志只表示相关网络接口处于使用状态，不足以证明订阅有效或所选出口可达。

把迁移成本纳入选择

Clash for Windows 与 ClashX Meta 已停止维护，适合作为已有环境的归档参考，不作为新设备的默认起点。旧客户端能够启动，不表示它支持当前订阅使用的协议和字段。迁移时先记录原来的规则、策略选择与局域网设置，再在新客户端独立导入配置；不要直接覆盖旧目录，以免丢失恢复所需的信息。

一个设备上可以保留多个客户端用于比较，但验证时只运行一个负责接管的实例。多个系统代理开关、VPN 接口或 TUN 路由同时工作，会让流量归属难以判断。平台安装入口统一放在客户端下载页；确定候选后先完成最小连接测试，再比较快捷键、覆写方式和连接面板，不必一开始就迁移全部高级设置。

三、安装与初始检查

安装前记录本机网络状态

先退出正在运行的代理客户端和 VPN，确认普通网络本身能够访问日常使用的站点。记录系统代理是否已经启用、是否有手工配置的 DNS，以及设备是否连接企业网络。这样安装后出现异常时，才有明确的恢复目标。若设备原本依赖单位提供的代理访问网络，不要直接清空原设置，应先保存地址与端口，并确认是否允许并行使用其他网络工具。

从下载页取得与架构对应的安装包，按照系统安装流程完成部署。桌面端的安装权限和日常运行权限是两件事：安装服务可能需要管理员授权，普通系统代理运行不一定需要。不要为了排除所有可能性而让客户端长期以最高权限运行。需要 TUN 时再按客户端说明安装辅助服务，并确认服务来源与安装目录属于当前客户端。

首次启动时先找到配置、代理、连接和日志四个区域。配置页决定当前使用哪份文件；代理页选择策略组出口；连接页显示流量是否进入内核；日志页提供加载与连接错误。具体位置可对照客户端界面分区说明。此时可以暂不启用开机自启、局域网共享和 TUN，减少初始变量。

确认监听端口与系统代理

导入有效配置后，查看内核是否正常启动、混合端口是否已监听。混合端口通常可同时接受 HTTP 与 SOCKS 代理请求，具体端口由活动配置决定。下面是一个独立的入站与直连验证配置，不包含代理节点，不能用于验证远端代理服务。使用前确认本机端口没有被其他进程占用，测试结束后切回自己的配置。

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

rules:
  - MATCH,DIRECT

系统代理的服务器地址应指向本机监听地址，端口应与当前内核一致。只修改 YAML 里的端口，不一定会同步修改客户端写入系统的代理项。端口冲突时可以在客户端支持的设置位置调整，但调整后要重新确认两端一致。多个配置之间切换，也可能改变有效端口，因此不要凭记忆把所有应用都固定指向一个旧值。

有 curl 的环境可执行下面的命令，显式指定本地 HTTP 代理。能够收到 HTTP 响应，说明这一请求至少经过了指定入站并完成访问；远端返回的业务状态仍需单独判断。如果浏览器失败而该命令成功，应优先检查浏览器代理扩展、独立代理设置和已有连接，而不是马上重装客户端。

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

Windows UWP 回环与例外情况

部分 Windows 应用容器受到回环访问限制，不能像普通桌面程序一样连接本机代理。典型表现是浏览器正常，某个商店应用却没有连接记录。先确认该应用确实使用系统代理，再考虑客户端提供的 UWP 回环工具。只为确有需要且可信的应用设置豁免，记录修改项；回环豁免不是修复全部商店应用网络故障的通用开关。

初始检查完成的标准是：配置加载正常、监听端口明确、测试请求有记录、退出后网络能恢复。如果客户端异常退出后浏览器仍指向本地端口，先关闭残留的系统代理，再检查后台进程。安装问题与节点问题要分开记录；前者解决程序能否运行，后者解决活动配置能否建立预期的出口连接。

四、订阅导入与配置管理

识别订阅内容，再选择导入方式

在配置页使用新建远程配置、从链接导入或类似入口，粘贴服务提供方给出的兼容订阅链接，并设置便于辨认的本地名称。复制时注意不要混入空格、换行或聊天软件附加的标点。导入前确认链接的用途：网页管理地址、购买页面和订阅地址不是同一种资源，能在浏览器打开网页也不能证明它就是内核可解析的配置。

下载完成后，查看配置是否包含节点、策略组和规则。有些链接只返回编码后的节点集合，需要客户端明确支持这种导入方式；有些则返回完整 YAML。遇到格式错误，先读报错行附近的内容，判断收到的是配置还是登录页、错误页。不要把带凭据的订阅交给不明在线转换服务，转换行为本身意味着对方可以取得订阅内容。

启用配置与导入配置是两个动作。配置列表新增一项后，还要将其设为活动配置，等待内核重新加载，再到代理页检查策略组是否出现。若客户端提示加载失败，应保留上一份可用配置，不要连续导入多个同名副本。先确认本次下载内容是否完整、字段是否兼容，再决定修正格式还是联系配置提供方。

把远程来源与本地调整分开

远程配置更新时，直接写在订阅文件里的修改可能被覆盖。需要长期保留的局域网规则、DNS 设置或策略补充，优先使用客户端支持的覆写、合并或脚本扩展功能。它们的合并顺序并不统一，尤其要注意规则是追加还是前置、列表是替换还是合并。保存后查看最终生效配置，而不是只检查编辑框里的原始文本。

若暂时不使用覆写机制，可以复制一份本地配置用于练习，但要明确本地副本不会自动同步远程节点变化。建议为原始订阅、测试副本和已验证副本使用不同名称，并记录最近改动的目的。这样某次更新导致异常时，可以判断是上游内容变化，还是本地规则覆盖了原有行为，不必从零重建整个配置。

订阅更新失败的分支处理

首先区分下载失败与解析失败。下载失败可能来自网络不可达、证书时间异常、链接失效或服务端拒绝；解析失败则通常发生在已经收到内容以后。查看日志中的错误类型与时间，不要只看一个红色状态。设备时间明显错误时，先校准时间；若服务返回权限或额度相关提示，应在服务管理页面确认账号状态，而不是重复修改 DNS。

还要检查更新请求走哪条路径。部分客户端允许选择直连更新或通过当前代理更新；当前配置已经失效时，依赖它更新就可能形成启动依赖。可在可信网络下尝试另一种更新路径，但不要假定所有客户端入口相同。一次只改变更新方式，保留其余设置，确认是下载阶段恢复后再检查新配置的可用性。

更新成功后不能直接结束检查。上游可能重命名节点、调整策略组或改变规则，旧的手动选择可能因此失去引用。查看活动配置、策略组选项和实际连接各一次，再进行日常访问。需要简短操作顺序时可回到订阅导入指南；本章的维护原则是让远程来源可更新、本地差异可追踪、出现问题可回退。

五、代理模式与策略组

规则、全局与直连的作用边界

规则模式按照配置中的规则决定出口，适合需要区分本地服务、普通站点和代理目标的日常场景。全局模式通常将进入内核的连接交给全局策略，便于判断问题是否来自分流。直连模式则让进入内核的连接使用直接出口。模式只影响已经进入内核的流量；全局模式不会自动让忽略系统代理的程序被接管，也不会替代 TUN。

排错时可以短暂切换全局模式作对照：若同一目标在全局下正常、规则下失败，先看规则命中和策略组选择；若两者都失败，继续检查节点、解析与网络。比较时保持节点一致，并重新建立连接。已经存在的长连接可能继续沿用原来的出口，单纯点击刷新不一定会创建新连接，可以关闭相关应用后再测试。

直连模式也不是“关闭客户端”。系统代理和 TUN 仍可能处于启用状态，连接仍由内核接收和处理。要恢复不经客户端的原始网络路径，需要关闭对应接管功能，并确认系统代理与 VPN 接口状态。理解这个区别，能避免客户端仍占据网络路径时误判系统网络损坏，也能解释为什么直连模式下连接列表仍有记录。

策略组：选择出口，不只是选择节点

策略组可以包含节点，也可以引用其他策略组。手动选择组适合固定出口；自动测试组会按测试结果选择候选；故障转移组按设定顺序寻找可用项。自动选择的具体行为还受到测试地址、间隔、容差和内核实现影响。不要把自动策略理解为对所有目标都最快，它只依据配置指定的探测条件做出选择。

下面是可放入已有有效配置的策略组片段。练习时只有直连与拒绝两个内置策略，因此能够加载但不提供远端代理。实际使用应在已确认的节点集合中加入候选，并让规则引用相同的组名。名称的大小写、空格和字符必须保持一致，规则引用一个不存在的组时，可能导致配置校验失败或无法完成预期分流。

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,出口选择
  - MATCH,DIRECT

配置里出现 PROXY，并不表示这是内核强制保留的唯一代理名称。它经常只是作者自定义的策略组名，也可以叫出口选择或其他名称。理解名称与功能的关系后，再看多层策略就更清楚：业务规则先进入业务组，业务组再选择地区组，地区组最后选中节点。排错时要展开完整策略链，不能只看第一层组名。

按用途验证节点选择

节点选择要同时考虑实际可达性、业务地区要求、线路稳定性和服务侧的流量计费规则。延迟低只表示探测路径较短或响应较快，不代表持续下载带宽一定更高。测试视频、会议或游戏时，应观察实际业务在一段时间内的表现，不要把不同时间、不同网络环境下的单次结果直接排列比较。

某些业务对出口变化敏感，自动策略在后台换节点可能触发重新验证或会话失效。此时可为该业务设置单独的手动选择组，保持出口稳定，再让普通浏览使用自动选择。更多对照方法见节点延迟、倍率、地区与协议的选择说明。先确保一个节点稳定可用，再增加策略层级，维护成本会低得多。

六、规则分流与匹配验证

按从上到下的顺序读取规则

规则分流的基本原则是从上到下匹配，先命中的规则决定连接交给哪个策略。因此，精确例外一般放在宽泛规则之前，最终兜底放在最后。若一个域名已经命中前面的后缀规则，后面更具体的条目通常没有机会生效。新增规则前先读已有顺序，避免以为多写一条就会覆盖旧行为。

域名规则依赖内核获得目标域名。应用若直接连接 IP，或者目标信息在接管路径中丢失，预期的域名规则可能无法命中。此时连接页可能只显示目标地址，需要结合 DNS 模式、嗅探能力与应用行为判断。不要一看到规则未命中就扩大整个网段的代理范围，那可能把本地设备或原本直连的服务一起带入代理出口。

建立最小规则，再逐项扩展

练习时先使用容易观察的域名规则和直连兜底，确认顺序与目标信息正确，再加入代理组。下面的片段用于已有配置中的规则区，保留回环和常见私有地址直连，并用示例域名验证后缀匹配。它不是完整的局域网地址清单，也没有覆盖全部 IPv6 场景，不应被当作所有网络环境通用的最终模板。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

no-resolve 用于避免为了当前 IP 规则主动触发域名解析，不意味着整份配置停止使用 DNS。若连接目标已经是 IP，仍可参与地址段匹配；如果当前只有域名且尚未获得地址，这条规则可能不会命中。地理规则则还依赖数据库与解析结果，应以目标 IP 的数据库归属为准，而不是据站点运营主体所在地推断。

使用远程规则集时，需要额外确认提供器名称、格式、行为类型和更新时间。规则集存在本地缓存，不代表它已经成功更新；更新成功，也不代表它覆盖目标站点的全部关联域名。主网页、登录、图片与接口可能分属不同域名。应根据实际连接记录补充必要条目，而不是只添加浏览器地址栏里的一个域名。

以连接记录验证，不靠出口网页猜测

保存规则后重新加载配置，发起一个新请求，在连接页查看目标、命中规则、策略链与最终出口。出口地址查询只能提供这一次查询请求的出口，不能证明另一个应用使用相同策略。对比时最好选择可重复的单个操作，例如重新打开某个页面或发起一次命令行请求，并在记录出现后立即查看匹配信息。

如果自定义规则保存后消失，检查是否直接编辑了远程订阅，或者覆写在合并时被替换。如果规则保留但不命中，检查先后顺序、域名可见性与旧连接复用。如果已命中正确策略却访问失败，再转向节点与 DNS，不要继续堆规则。分层依据可结合网速慢的分层排查顺序使用，避免把所有网络现象都归因于分流。

七、TUN 与 DNS 配置

在系统代理稳定后扩大接管范围

TUN 适合需要接管不遵循系统代理的应用，但它会引入虚拟网卡、路由和 DNS 路径等新变量。桌面端应先用系统代理确认配置与节点可用，再按客户端说明安装服务或授予网络权限。移动端通过系统 VPN 接口工作的方式与桌面服务不同，不要机械寻找同名按钮。能够创建接口与能够正确转发流量，也需要分开验证。

启用前记录现有 VPN、虚拟机网络与容器网络，避免重叠路由导致连接绕行。启用后先访问一个普通域名，再检查局域网设备、工作所需网络和原有 VPN。若只有局域网访问失败，先查直连规则、排除路由和目标网段，而不是更换远端节点。访问单位内部域名时，还可能需要保留专用 DNS 的解析路径。

DNS、Fake-IP 与目标识别

DNS 将域名转换为地址，但代理连接不一定只由系统 DNS 决定。应用自带解析、浏览器安全 DNS、系统解析和内核 DNS 可能同时存在。排错时先明确请求到底交给谁处理，再决定修改哪个设置。只更换上游地址却没有让请求进入内核 DNS，往往不会改变实际结果；加密 DNS 的首次连接还可能需要引导解析。

Fake-IP 模式向应用返回一个用于映射的地址，内核保存它与域名之间的关系，随后据此恢复目标并匹配规则。这个地址不是远端服务器的真实公网地址，不能直接用于判断服务器位置。某些依赖真实地址、广播发现或特殊解析行为的应用可能需要过滤例外。对比原理可读Fake-IP 与 Redir-Host 说明。

下面是面向支持这些字段的 mihomo 桌面环境的独立直连测试配置。DNS 监听使用本机高端口，TUN 自动路由与接口探测仍需要系统权限。它只用于理解字段与检查接管，不包含代理节点；企业内网、其他 VPN 或特殊路由环境应先评估冲突，不要直接覆盖正在工作的完整配置。

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

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
    - 8.8.8.8

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

rules:
  - MATCH,DIRECT

分别验证路由与解析

dns-hijack 接收匹配的 DNS 流量，但应用通过 HTTPS 等方式自行解析时，不会因为配置了普通 DNS 端口劫持就自动被替换。auto-route 负责自动设置相关路由，auto-detect-interface 尝试识别出口接口；多网卡、虚拟网络或默认路由变化时仍可能需要人工检查。字段存在不代表当前环境一定能自动选对出口。

浏览器正常而其他应用失败时，查看应用请求是否进入连接页；域名失败但已知地址可达时，重点查解析；启用 TUN 后全部断网时，先关闭 TUN 恢复原路径，再检查服务权限、默认路由和重复接管。修改 DNS 模式以后，应重新建立应用连接，必要时清理对应缓存，避免用旧映射验证新设置。

最终验收不仅是网页能打开，还包括休眠唤醒、网络切换与客户端退出后的恢复。若关闭 TUN 后仍异常，确认辅助服务和虚拟接口是否正常退出，并检查系统代理是否残留。接管范围越大，恢复路径越重要；保留一份已验证的系统代理配置，能在复杂网络故障时提供清楚的对照基线。

八、日常维护与恢复

把更新分成三类

客户端更新、内核更新和订阅更新解决的问题不同。客户端更新可能改变界面、服务和配置生成方式；内核更新影响协议与字段支持；订阅更新改变节点、策略或规则内容。一次维护尽量只更新一类，验证稳定后再进行下一类。若三者同时变化，出现问题时很难确认应该回退哪一部分，也容易误把配置差异当作程序缺陷。

更新前保留活动配置、覆写内容和关键设置，记录系统代理端口、当前策略选择、TUN 状态与服务安装情况。备份应能还原实际运行状态，而不只是保存一张界面截图。更新后核对最终生效配置，尤其关注被客户端自动管理的字段；某些客户端会以界面设置覆盖 YAML，因此只比较源文件不能反映全部变化。

回退也要分层进行。订阅变化可先切回本地已验证副本；覆写错误可暂时停用该扩展；客户端更新异常则按对应安装说明处理程序与服务。不要直接把旧程序覆盖到新配置目录，配置结构或数据库可能并不兼容。测试旧环境时使用独立备份，并确保没有两个实例同时占用同一端口或网络接口。

开机自启与后台运行

开机自启通常只表示启动客户端，不一定保证内核、订阅和系统代理都已经就绪。应先在手动启动场景完成验证，再打开客户端提供的自启选项。下次重启后依次确认程序出现、活动配置正确、接管已按预期启用，最后测试实际访问。如果系统代理先开启而内核尚未监听，启动阶段可能短暂无法访问网络。

休眠唤醒与网络切换是另一组必要测试。无线网络切换到有线、手机热点或不同路由器后，默认网卡和 DNS 可能改变，TUN 需要重新识别路径。若每次唤醒都失败，记录接口变化与日志时间，再尝试按顺序重启接管或内核。不要把周期性故障简单归为节点不稳定，否则会漏掉本机路由恢复问题。

Android 后台运行要结合厂商省电策略设置。先允许必要的后台活动，观察锁屏后是否断开，再决定是否加入电池优化白名单。不要一次开放所有应用权限，也不要为了减少常驻提示而破坏系统要求的前台运行机制。耗电应在相近亮度、网络与使用时长下比较，并区分屏幕、无线信号和代理流量各自的影响。

建立有限日志与恢复清单

日常日志使用 info 等适当级别即可，遇到明确问题时再临时提高详细程度。记录发生时间、目标应用、错误表现和当时使用的配置，有助于缩小检索范围。日志可能包含访问域名、节点地址和认证相关内容，公开前需要检查。定位结束后恢复常规级别并清理不再需要的诊断文件，避免长期积累敏感访问记录。

遇到“Clash 无法上网”，先关闭接管并验证原始网络，再恢复已知可用配置，随后检查节点与订阅状态。若原始网络也失败，应先处理本机连接、路由器或运营商问题。若仅一个应用失败，查看其代理行为与连接记录；若全部代理目标失败但直连正常，再重点检查节点、服务状态和出口连接。

局域网共享尤其需要定期复查。开启允许局域网连接，会改变其他设备接触本地监听端口的机会，不能仅凭“连接家用无线网络”就忽略访问边界。确需共享时设置认证、限制防火墙来源范围，并在更换网络后重新确认。维护的目标不是始终打开全部功能，而是清楚知道哪些功能正在影响当前设备的网络路径。

九、进阶路线与独立排错

先管理配置差异，再引入自动化

进阶配置的起点是能解释当前文件，而不是继续叠加更多来源。先区分由订阅维护的部分、由客户端生成的部分和本地手工维护的部分，为每一类确定唯一修改位置。若同一个 DNS 字段同时出现在界面设置、订阅文件和覆写中，先确认最终优先级，再做调整，否则每次重启都可能出现“修改失效”的错觉。

下一步可以学习节点提供器与规则提供器，把连接参数、策略逻辑和业务规则拆开管理。拆分有助于独立更新，但也引入名称引用、路径、缓存与下载依赖。首次使用时只拆一个小集合，确认下载成功、格式正确、策略能够引用，再迁移其余内容。不要把所有远程资源同时加入，最后只凭一次启动结果判断是否完成。

自动测试和故障转移也应从业务需要出发。对于希望保持会话的登录服务，频繁切换可能比稍高延迟更不合适；对于一般浏览，可接受自动选择带来的出口变化。测试间隔要兼顾流量与探测及时性，测试地址要能稳定代表所需路径。不同策略组重复探测同一批节点，还可能增加不必要的后台请求。

把复现过程做成小实验

排查复杂问题时先写出预期：哪个应用、哪个目标、应命中哪条规则、最终应走哪个出口。随后选择一个最小操作，例如新开浏览器窗口访问固定页面，或使用显式代理命令发起请求。每轮只改变一项条件，并记录是否有连接、命中什么规则、在哪个阶段报错。这样得到的结论可重复，也方便向他人准确描述。

可以用三个环境作对照：关闭接管的原始网络、系统代理下的已知可用配置、TUN 下的同一配置。原始网络正常而系统代理失败，重点查入站与出口；系统代理正常而 TUN 失败，重点查路由与解析接管。只有特定域名失败时，检查关联域名、业务限制和规则链，不必重新安装整套软件。

扩展到服务器与远程管理之前

直接运行 mihomo 时，图形客户端原来代办的工作需要自己完成，包括配置目录、工作目录、服务用户、日志轮转与失败重启。先在前台验证配置能够加载，再将其纳入系统服务。服务启动成功并不等于流量接管完成，还要核对监听地址、路由和权限。路由器上还需考虑存储空间、架构与原有防火墙规则。

远程控制接口能查看连接并修改策略，应仅在明确需要时启用，并限制在本机或受控网络内，使用访问认证。不要为了连接手机面板直接暴露到公网，也不要把控制端口与代理入站端口混为一谈。共享配置前移除认证信息；远程管理故障时优先检查访问范围与认证，而不是扩大监听范围来碰运气。

完成这一阶段的标志，是能够说明一次请求如何进入内核、如何获得目标信息、如何命中规则以及如何到达出口，并能在失败时定位其中一层。需要重新走最短操作流程，可查看连接验证指南；需要进一步理解具体机制，可从专题文章继续查阅。每学一个新功能，都保留验证记录与回退方法，再进入下一项配置。