Clash 从零到进阶完整使用手册

一、核心概念：先区分客户端、内核与订阅

三个组成部分承担不同工作

日常所说的“Clash”可能指图形客户端、代理内核，也可能泛指兼容 Clash 配置格式的一组工具。开始操作前先把三者拆开：客户端提供窗口、托盘菜单、配置管理和系统权限入口；内核读取配置、监听本地端口、执行规则并建立网络连接；订阅服务提供服务器信息、策略组和规则内容。安装客户端并不会自动获得可用线路，导入订阅也不等于已经让应用流量经过代理。

例如 Clash Plus、Clash Verge Rev、FlClash 和 Clash Nyanpasu 都属于带图形界面的客户端。客户端可能集成 mihomo 等内核，也可能允许切换内核。mihomo 与曾使用的 Clash Meta 名称存在沿革关系，它负责识别配置字段、处理 DNS、执行规则和 TUN。界面中显示的开关最终会转换为内核参数或操作系统网络设置，因此同一个功能在不同客户端里的名称和位置可能不同，实际判断应以生成的配置和内核日志为准。

订阅则是独立来源。订阅地址通常由使用者选用的服务提供，本站与客户端项目都不会因为安装完成而自动提供订阅。一个订阅可能包含节点、代理策略组、远程规则集和 DNS 设置，也可能只包含最基本的节点列表。遇到“客户端能打开但没有可选策略”时，应先确认订阅内容是否完整，而不是反复重装客户端。

流量从应用到出口的基本路径

系统代理场景下，应用读取操作系统的 HTTP 或 SOCKS 代理设置，把请求交给客户端监听的本地端口。内核随后按配置模式处理请求：规则模式从上到下检查规则，第一条匹配项决定使用 DIRECT、REJECT 或某个策略组；全局模式通常把大多数可代理流量交给指定策略组；直连模式则让受支持的流量直接访问目标。TUN 模式会建立虚拟网络接口，在更靠近网络层的位置接管流量，但仍需经过 DNS、路由和规则求值。

因此，“客户端已启动”“本地端口正在监听”“系统代理已开启”“目标应用确实采用系统代理”“规则选择了可用出口”是五个不同状态。浏览器能够访问某个页面，只能说明浏览器当前路径成立，不能证明终端、游戏或虚拟机也在使用相同路径。排查时应沿着应用设置、操作系统代理、本地监听端口、内核规则、远端连接依次确认，不应只观察客户端主界面的一个状态标记。

建立可验证的最小认知

首次使用不必立即修改大量 YAML。先完成一个最小闭环：安装适合平台的客户端，导入来源明确的订阅，选择配置和策略组，开启一种流量接管方式，再用浏览器与终端分别验证。完成闭环后再学习规则覆盖、DNS 和 TUN，能避免同时引入多个变量。后续每次修改也遵循相同原则：一次只改一层，保留修改前配置，并记录变化后出现的日志或访问结果。

二、选择客户端：按平台与维护方式判断

先选操作入口，再看高级能力

客户端选择应从操作系统、安装方式和日常维护习惯出发，而不是把不同项目当作简单的性能排名。初次使用者可以优先选择 Clash Plus，它覆盖常见桌面与移动平台，适合从图形界面完成订阅管理、策略选择和连接控制。需要在 Windows、macOS 或 Linux 上管理多份配置时，也可以比较 Clash Verge Rev 与 FlClash；Windows 用户还可看到 Clash Nyanpasu。归档客户端可能仍能运行，但不适合依赖持续兼容更新的新环境。

Android 平台除 Clash Plus 外，还可根据设备架构和操作习惯考虑 Clash Meta for Android、FlClash 或 Surfboard。iOS 的主要入口是 Clash Plus。Linux 桌面用户可选择 Clash Verge Rev 或 FlClash；服务器、路由器和无桌面环境更适合直接部署 mihomo 内核。完整的平台入口与当前安装包应从下载页进入，避免将桌面客户端安装步骤套用到命令行内核。

核对系统架构与包格式

Windows 常见设备使用 x64 架构，应根据下载页实际提供的构建选择安装包。macOS 需要区分 Apple Silicon 与 Intel：在“关于本机”中查看芯片或处理器信息，Apple 芯片选择 ARM 构建，Intel 处理器选择 x64 构建。Android 可在设备信息或可靠的硬件信息页面确认 ARM64、ARM 或通用包；大多数较新的设备使用 ARM64，但不能只凭系统版本推断。

Linux 还要匹配发行版包管理方式。Debian、Ubuntu 及其衍生系统通常使用 .deb，Fedora、RHEL 系列通常使用 .rpm。若使用独立内核压缩包，需要自行准备配置目录、服务文件和更新流程。图形客户端与裸内核的差别不仅是有没有窗口：前者往往代为处理权限申请、系统代理写入和内核生命周期，后者要求使用者明确管理启动用户、工作目录、日志和重启策略。

评估功能时查看实际工作流

如果只需要浏览器和常规桌面应用使用代理，稳定的系统代理控制与订阅更新比复杂覆写功能更重要。如果需要接管不读取系统代理的应用，应确认客户端对 TUN、权限安装和路由恢复的实现。如果经常维护多份订阅，则要检查配置切换、覆写、订阅更新和备份入口是否清楚。不要因为界面出现某个开关就假定当前内核支持全部字段；高级配置能力最终受内核版本、配置格式和操作系统限制共同影响。

选型结束的标准不是找到功能最多的客户端，而是确认安装包与平台匹配、常用入口能够理解、订阅可维护、故障时能查看日志。若仍难判断，可阅读按平台和使用习惯选择客户端，再回到下载页完成安装。

三、安装与权限：建立可恢复的运行环境

桌面系统的安装顺序

安装前先退出同类代理程序，记录当前系统代理设置，并确认安装包与系统架构一致。Windows 安装后首次运行时，防火墙可能询问网络访问范围；只为实际需要的网络类型授权，不需要为了本机代理监听开放公网入站。若客户端提供“服务模式”或辅助服务，它通常用于取得修改路由、运行 TUN 或随系统启动所需的权限，应从客户端内置入口安装，不要单独从未知位置获取服务组件。

macOS 将应用放入“应用程序”目录后再首次启动，避免从下载目录长期运行导致路径与权限记录变化。系统可能依次出现应用安全确认、网络扩展、VPN 配置或钥匙串访问提示，这些提示对应不同能力：VPN 配置通常与 TUN 或 Network Extension 有关；钥匙串提示可能用于保存凭据；网络扩展用于接管网络流量。应根据准备使用的功能授权，而不是把所有提示视为同一种安装错误。具体处理可参考macOS 权限说明。

Linux 图形客户端使用发行版包安装后，应从桌面菜单启动一次并观察日志目录是否可写。使用 .deb 文件时，可以在文件所在目录执行：

sudo apt install ./client-package.deb

上面的文件名应替换为已经下载的实际包名。包管理器会解析依赖，通常比直接调用底层安装命令更便于处理缺失组件。RPM 系统应使用对应发行版的包管理命令。无桌面环境部署 mihomo 时，不应照搬图形客户端的目录；需要单独创建配置目录、确定运行账户，并限制控制端口的可访问范围。

移动平台的系统授权

Android 与 iOS 通常通过系统 VPN 接口接管流量。首次连接时出现的 VPN 授权是操作系统建立虚拟网络通道所需步骤，不表示订阅已经验证成功。Android 还应检查电池优化与后台活动策略：若客户端在锁屏后被系统停止，连接会中断或无法按计划更新。允许必要的后台运行后，再观察不同网络之间切换时能否恢复，不要一开始就同时启用常驻 VPN、按应用分流和复杂 DNS 覆写。

部分 Android 系统允许设置“始终开启的 VPN”或限制未经过 VPN 的连接。开启这些系统级选项之前，先确认客户端能在普通模式下稳定连接，并准备好关闭入口。否则当订阅失效或 DNS 配置错误时，设备可能表现为所有应用都无法联网，而使用者又难以区分是代理失败还是系统强制策略仍在生效。

首次启动后的基线检查

安装完成后先不要启用 TUN。打开客户端日志或运行状态页，确认内核能够启动、配置目录可读写、本地监听端口没有冲突。常见监听包括 HTTP、SOCKS 或 mixed 端口，具体值以当前配置为准。如果日志出现“address already in use”一类信息，说明端口已被其他进程占用，应关闭旧代理程序或调整端口，而不是反复点击连接。

接着检查退出行为。关闭窗口可能只是隐藏到托盘，真正退出需要使用托盘菜单；卸载或切换客户端前，应先关闭系统代理和 TUN，再退出内核。这样可以让客户端恢复路由与系统代理状态。若发生异常退出，可进入操作系统网络设置手动确认代理地址是否仍指向本地端口，并检查是否残留虚拟网络接口。

无桌面 Linux 的服务化原则

在服务器上运行 mihomo 时，应先以前台方式加载配置并阅读错误信息，确认通过后再交给 systemd。服务文件应指定明确的执行文件、工作目录和配置目录，使用具备最低必要权限的账户。配置中若开启外部控制接口，监听地址优先限定在本机；确需远程管理时，应通过受控网络和访问控制提供入口。更完整的桌面与服务部署差异可查看Linux 部署说明。

四、订阅配置：导入、选择、更新与覆写

导入只是取得配置

订阅地址通常返回一份客户端可读取的配置或节点集合。导入时，在客户端的配置、订阅或 Profiles 页面选择“从 URL 导入”，粘贴来源明确的地址，等待客户端下载并解析。导入成功后还要将该配置设为当前使用配置，再检查策略组是否有可选项。若配置列表里出现名称但切换后内核报错，应查看解析日志，定位具体字段，而不是把“下载成功”当作“配置可运行”。

订阅地址可能具备访问权限，应视为敏感信息，不应发到公开截图、日志分享页或问题讨论区。需要排查时，可以隐藏地址与节点凭据，只保留错误字段、规则结构和相关日志。若地址失效、返回登录页面或被网络重定向，客户端可能报告 YAML 解析错误；此时先用服务方提供的管理入口确认订阅状态，不要随意修改解析失败的响应内容。

理解完整配置的主要结构

一份常见配置会包含监听端口、运行模式、DNS、节点、策略组与规则。以下片段展示最小结构关系，其中服务器地址与认证内容仅为示例，不能直接用于连接：

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: Example-Node
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: demo-user
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

mixed-port 同时接受常见 HTTP 与 SOCKS 代理请求；mode: rule 表示按规则求值；proxy-groups 定义名为 PROXY 的策略组；最后一条 MATCH 接收前面没有匹配的流量。这里的 PROXY 不是内核自动生成的出口，删掉策略组却保留 MATCH 会产生引用错误。no-resolve 表示处理该 IP 规则时不主动为了匹配而解析域名，并不等于关闭全部 DNS。

更新订阅前区分远程内容与本地修改

直接编辑订阅生成的配置通常只能暂时生效。下一次更新时，客户端会用远程内容覆盖本地副本，手动加入的规则、DNS 或策略组选项可能消失。需要长期保留的修改，应优先使用客户端提供的覆写、合并或脚本机制；如果客户端没有稳定覆写功能，就把修改后的配置保存为独立本地文件，并接受它不会自动跟随订阅更新的维护成本。

更新前记录当前可用配置、策略组选择和关键覆写。更新完成后先检查配置能否解析，再确认节点列表与策略组引用，最后恢复流量接管。不要在连接异常时连续触发多次更新，因为服务端响应、网络缓存与客户端写文件可能同时变化，反而难以确定是哪一次内容造成错误。订阅频率也不宜无依据地设得过短，应采用服务方允许的合理间隔。

配置验证要分三个层次

语法验证只说明 YAML 能被解析；引用验证还要确认策略组、节点与规则目标都存在；运行验证则检查端口、DNS、权限和远端连接。客户端提示“配置有效”后仍无法访问并不矛盾，因为它可能只完成前两层。保存修改后应重载配置并阅读第一段日志，先处理最早出现的错误。更多订阅导入中的常见问题可在帮助中心按“安装配置”分类查找。

五、代理模式：规则、全局与直连的作用边界

模式决定内核如何选择去向

规则模式、全局模式和直连模式是内核处理已进入代理链路流量的方式，不等同于系统代理、TUN 或 VPN 开关。系统代理与 TUN 决定哪些流量有机会进入内核，运行模式再决定这些流量使用哪个出口。将模式切换为全局，并不能让一个完全不读取系统代理的程序自动进入内核；同样，开启 TUN 后选择直连模式，流量可能经过虚拟接口和内核判断，最终仍从本地网络直连。

规则模式通常适合日常使用。内核按规则列表从上到下检查目标域名、IP、端口或规则集，第一条命中后停止继续求值。规则可以指向 DIRECT、REJECT 或自定义策略组。规则质量会直接影响结果：过宽的规则放在前面可能遮住后面的精细规则，缺少兜底规则则可能导致不同配置产生难以预测的行为。

全局模式用于临时判断规则是否造成访问问题，或在明确需要统一出口的短时场景使用。进入全局模式后，客户端通常要求选择一个全局策略组或节点。排查时若全局模式可用而规则模式失败，应检查目标命中了哪条规则、策略组是否可用，而不是立即认定节点本身失效。长期使用全局模式会绕过原有分流意图，也可能让局域网或本应直连的资源走向错误出口。

直连模式可用于快速恢复本地网络、比较代理前后结果，或者在保留客户端运行的同时暂时停止代理转发。它不是退出客户端的替代方式：系统代理仍可能指向本地端口，TUN 仍可能保持接口与路由，只是内核选择 DIRECT。维护或卸载前应关闭流量接管并退出内核，而不是只切到直连。

系统代理适合遵循代理设置的应用

开启系统代理后，客户端一般把操作系统代理地址设置为回环地址与本地端口，例如 127.0.0.1:7890。浏览器和部分桌面应用会读取该设置，终端程序则经常需要单独配置环境变量。某些应用有自己的代理选项，可能覆盖系统设置；还有一些程序使用原始网络连接，完全忽略系统代理。因此出现“浏览器正常、终端失败”时，应先检查终端环境，而不是切换规则模式。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

curl -I https://example.com

端口必须与客户端当前监听一致。只为当前终端会话设置变量便于测试；确认结果后再决定是否写入 shell 配置。使用 sudo、容器或远程会话时，环境变量可能不会自动继承。本机回环地址在容器内部通常指向容器自身，不能直接照搬宿主机地址。

用对照实验确定问题所在层级

可靠的模式测试应保持节点与接管方式不变，只切换一个变量。先在规则模式记录目标命中的规则，再切到全局模式并选择同一个实际出口。如果两者都失败，应查看本地端口、DNS、节点连接和系统时间；如果只有规则模式失败，检查规则顺序与策略组；如果浏览器成功而终端失败，检查应用代理设置。详细的分层方法可参考浏览器与终端代理排查。

六、规则分流：从上到下理解匹配与策略组

第一条匹配规则决定结果

规则分流的核心不是规则数量，而是顺序、匹配条件和目标策略是否一致。内核从列表顶部开始检查，请求命中一条后通常不再继续。一个宽泛的域名后缀规则如果放在前面，会覆盖后面针对具体子域名的规则；大范围 IP 规则也可能抢先处理原本希望交给其他策略组的地址。因此，自定义规则应从具体到宽泛排列，最终由 MATCH 或等价兜底接收未匹配流量。

rules:
  - DOMAIN,blocked.example,REJECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

DOMAIN 匹配完整域名，适合单一主机；DOMAIN-SUFFIX 匹配指定域及其子域；IP-CIDR 按地址范围匹配；MATCH 作为兜底。上例会先拒绝指定域名，再让 example.org 及其子域直连，让私有地址范围直连，其他请求交给 PROXY。PROXY 必须是已经定义的策略组名称，若实际配置使用“节点选择”等其他名称，规则目标也必须完全一致。

策略组负责把规则结果变成可选出口

规则通常不直接绑定某个固定节点，而是指向策略组。select 组让使用者手动选择；其他组类型可能按可用性或预设逻辑选择成员，具体支持取决于内核。策略组可以包含节点、DIRECT 或其他策略组，但嵌套关系应保持清晰，避免多个组互相引用。修改组名时，要同步检查所有规则和其他策略组中的引用。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Example-Node
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Example-Node
      - Backup-Node
    url: https://www.gstatic.com/generate_204
    interval: 300

这个示例说明结构关系，并不代表任何订阅一定包含相同节点。url-test 会按指定 URL 进行可用性测试，测试结果只反映该探测目标与当时网络条件，不能替代对实际业务目标的验证。测试间隔过短会增加连接与日志开销。对于重要访问，应优先选择行为可理解的策略组，并在发生问题时确认当前组最终选中了哪个成员。

域名规则与 IP 规则受到 DNS 路径影响

域名请求进入内核后，可以直接参与 DOMAIN 类规则；当应用只提交目标 IP，或规则需要按 IP 判断时，DNS 解析和连接阶段的地址信息会影响匹配。no-resolve 用于阻止某条 IP 规则为了匹配域名而主动触发解析，它有助于减少不必要的 DNS 查询，但不会关闭配置中的 DNS 服务。若同时使用 fake-ip、域名嗅探或复杂 DNS 分流，应先理解客户端生成的完整配置，再添加规则。

局域网地址一般应在宽泛代理规则之前处理，避免访问路由器、打印机或本地服务时被交给远端出口。常见私有地址包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16，但企业网络可能使用更多内部域名和地址范围。不要机械复制公共规则集后就假定适用于当前网络，应根据实际内网范围补充并测试。

远程规则集与本地规则各有维护成本

远程规则集便于集中更新，但可用性依赖下载地址、格式和更新策略。本地规则更容易审计，却需要自行维护。采用远程规则集时，应查看它处理的类别、默认出口和更新失败时的行为；采用本地规则时，应为每组规则写清用途，并避免堆积重复项。规则越多不代表分流越准确，过期域名、重叠范围和不可达规则都会增加排查成本。

调整规则的安全流程是：复制当前配置，新增一条具体规则，重载并测试目标，同时测试一个不应受影响的目标。确认无误后再继续。若订阅更新会覆盖规则，应把修改迁移到客户端的覆写层，并记录规则需要位于远程规则之前还是之后。

七、TUN 模式：接管范围、DNS 与路由排查

TUN 解决的是流量进入内核的问题

TUN 模式通过虚拟网络接口与系统路由接管更多 IP 流量，适合不读取系统代理的应用、部分命令行工具和需要统一接管的场景。它并不会提升节点本身的连接质量，也不会替代规则与策略组。流量进入 TUN 后，仍要经过 DNS 解析、路由判断、规则求值和出口连接。若规则指向 DIRECT，最终仍可直连；若配置或权限错误，影响范围可能比系统代理更广。

首次启用前，先在系统代理模式下确认订阅、节点和规则基本可用，再关闭其他 VPN、代理或网络过滤工具，记录当前 DNS 与默认路由。客户端可能要求安装服务、授权 VPN 配置或启用网络扩展，应从正式界面完成。启用后先测试局域网地址、常用域名和一个不使用系统代理的程序，确认三类路径都符合预期，再考虑开机启动或始终开启。

常见配置字段的作用

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

auto-route 让内核尝试写入必要路由，auto-detect-interface 用于识别当前出站接口，dns-hijack 指示接管指定 DNS 流量。stack 的可用值与行为受内核和平台影响，不应脱离当前客户端文档盲目切换。示例中的公共 DNS 只用于说明字段结构，实际选择应结合网络可达性、隐私要求与订阅配置。若订阅已提供完整 DNS 段，不要同时叠加另一套未经验证的覆写。

fake-ip 会为域名返回保留范围内的映射地址，再由内核恢复域名并应用规则。它有助于保留域名信息，但某些局域网服务、需要真实地址的应用或特殊协议可能需要加入过滤范围。出现局域网设备无法发现、应用识别到异常地址时，应先检查 fake-ip 过滤与局域网直连，而不是立即关闭全部 DNS 功能。

路由冲突比节点问题更常见

同时运行企业 VPN、虚拟机网络、容器网络或另一款代理时，各工具可能争用默认路由、DNS 或虚拟接口。表现包括启用 TUN 后完全断网、仅内网失效、休眠恢复后无法连接、切换 Wi-Fi 后流量仍走旧接口。排查时先关闭其他接管工具，关闭 TUN 并确认基础网络恢复，再单独启用 Clash。若单独运行正常，再逐一恢复其他工具并观察冲突出现的时点。

Windows 可查看路由表与网络适配器，macOS 可检查网络服务和 VPN 配置，Linux 可使用系统命令检查路由与规则。诊断重点不是复制全部输出，而是比较启用前后默认路由、DNS 指向和新增接口。Linux 常用检查命令如下：

ip addr
ip route
ip rule
ss -lntup
resolvectl status

不同发行版可能不提供全部命令。ss 可确认本地端口，ip route 与 ip rule 用于观察路由，resolvectl 适用于采用 systemd-resolved 的环境。不要在不了解用途时批量删除路由规则；先关闭客户端让它执行清理，再重启网络服务或系统，最后才考虑手动恢复。

DNS 故障要区分解析与连接

能访问 IP、不能访问域名，通常应优先检查 DNS；域名能解析但连接失败，则继续检查规则、出口和防火墙。可使用 nslookup、dig 或系统自带解析工具，比较系统解析结果与客户端日志。若日志里完全没有目标请求，问题可能发生在应用、系统路由或 DNS 到达内核之前；若能看到请求但策略错误，则回到规则与 DNS 配置检查。

TUN 稳定运行的判断应覆盖启动、关闭、休眠恢复、网络切换和局域网访问。只有一次网页访问成功不足以证明路由清理和 DNS 恢复正常。移动设备还应测试后台与锁屏行为，桌面系统则要验证退出客户端后代理与路由没有残留。

八、日常维护：更新、备份、日志与故障恢复

把客户端、内核和订阅分开更新

客户端更新、内核更新与订阅更新是三条不同链路。客户端更新可能改变界面、权限辅助组件和配置存储；内核更新可能改变字段支持、默认行为和协议能力；订阅更新会改变节点、策略组与规则。日常维护应记录是哪一层发生变化，避免同一天同时更新三层后无法定位回归问题。稳定使用时，可以先备份配置，再更新订阅并验证；需要更新客户端或内核时，单独安排一次测试。

更新前保存订阅地址、当前策略选择、本地覆写和重要自定义规则。仅复制订阅生成的 YAML 还不够，因为客户端可能把覆写、策略选择和界面设置放在其他文件或数据库中。优先使用客户端提供的导出功能；没有导出功能时，分别记录可重建的信息。备份应放在客户端数据目录之外，防止卸载或清理缓存时一并删除。

日志要围绕一次可复现操作读取

有效日志需要明确时间范围与触发动作。先把日志级别设为常规信息级别，清空或记住当前时间，然后执行一次失败操作，立即查看对应片段。重点寻找配置加载、DNS 查询、规则匹配、策略选择、连接建立和超时信息。长期开启过于详细的调试级别会产生大量记录，也可能包含目标域名等使用信息，应只在排查期间启用，完成后恢复。

分享日志前应移除订阅地址、认证字段、控制接口凭据和节点连接信息。保留错误类型、目标类别、规则名称与必要上下文即可。单独截取最后一行往往会丢失真正原因，例如连接失败可能由前面更早的 DNS 错误触发。排查时优先处理时间顺序上的第一个异常，而不是日志中重复次数最多的后续错误。

建立分层恢复顺序

遇到无法联网时，先恢复基础网络，再恢复代理。关闭 TUN，关闭系统代理，切换到直连或完全退出客户端，确认操作系统能够正常解析和访问。基础网络恢复后，启动客户端但暂不开启接管，确认配置加载与本地端口；随后开启系统代理并测试浏览器；最后才启用 TUN。这个顺序能把权限、配置、节点和路由问题拆开。

若只有某个站点或应用失败，先不要重装。比较同一目标在直连、规则与全局模式下的结果，检查日志中的命中规则，再确认应用是否有独立代理设置。若所有节点同时失败，检查订阅状态、系统时间、DNS 与当前网络限制；若只有一个节点失败，切换同策略组中的其他成员，并把问题限定在该出口。常见问答可继续查阅帮助中心。

清理配置要保留回退点

配置长期累积后，重复订阅、失效覆写和旧规则可能互相影响。清理时先复制当前可用配置，然后停用而不是立即删除可疑项。确认一段时间没有依赖后再移除。不要把客户端缓存、配置数据库和内核目录一次性全部删除，因为这会同时丢失故障证据与可回退状态。若确需重置，先导出必要内容，再从最小配置开始验证。

对于归档客户端，维护重点是迁移而不是继续堆叠临时修补。先选择仍在维护且支持当前平台的客户端，导入原订阅，确认基本连接，再迁移本地规则与 TUN 设置。不要直接覆盖旧客户端目录，也不要让两个客户端同时控制系统代理或路由。迁移完成后，关闭旧客户端的开机启动并确认系统只保留一条明确的接管链路。

九、进阶路线：从会使用到能独立诊断

先掌握配置读取，再学习复杂覆写

进阶的第一步不是收集更多配置片段，而是能读懂当前生效配置。应能找到监听端口、运行模式、DNS、策略组、规则与 TUN 段，并回答请求从哪个入口进入、命中哪条规则、使用哪个策略组、最终选择什么出口。客户端界面隐藏了部分默认值时，可以查看导出的配置或内核日志，但不要直接编辑程序自动生成文件，除非清楚它会在何时被覆盖。

第二步是建立可维护的覆写层。把局域网直连、特定域名策略、DNS 例外和策略组调整分成独立目的，每次只加入一组。规则名称和注释应描述原因，而不是只写临时编号。订阅更新后自动合并的内容要检查插入位置，因为同一条规则放在列表顶部与末尾可能得到完全不同的结果。若客户端支持 YAML 合并，应确认数组是追加、前置还是整体替换。

理解 mihomo 能力与配置兼容边界

mihomo 在 Clash 配置生态基础上扩展了协议、DNS、规则与运行能力，但具体字段仍受当前内核构建和客户端集成影响。迁移旧配置时，应先用目标内核进行语法检查，再核对已弃用字段、规则提供器、DNS 增强模式和策略组行为。不要仅凭文件扩展名相同就认为配置可直接互换。相关背景可阅读mihomo 与原版 Clash 的差异说明。

服务器和路由器部署还涉及运行用户、网络命名空间、防火墙转发与持久化路由。桌面端的“开启 TUN”按钮往往代为完成权限与路由操作，裸内核则需要部署者明确承担这些工作。进阶部署前，应先在普通用户空间验证配置加载、DNS 与代理端口，再逐步加入透明接管和开机服务，避免把配置问题与系统网络问题叠加。

用最小复现替代大范围试错

遇到复杂问题时，复制一份配置并缩减到一个入口、一个可验证节点、一个策略组和少量规则。确认最小配置可运行后，再逐段恢复 DNS、规则集、TUN 与覆写。每恢复一段就执行固定测试：配置加载、域名解析、直连目标、代理目标、局域网目标和关闭后的网络恢复。这样可以把故障定位到具体配置块。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,PROXY

这份片段只用于验证内核结构与本地监听，不包含可用代理节点。由于 PROXY 组只含 DIRECT，所有兜底流量最终直连。加入真实订阅节点前，先确认配置能加载、端口能监听和规则日志可见，再逐步添加节点。这样即使连接失败，也能确定不是 YAML 结构或本地端口造成。

建立固定的诊断工具箱

桌面与服务器都应掌握几类基础工具：查看监听端口、解析域名、发起 HTTP 请求、检查路由、查看进程和读取服务日志。Windows 可使用系统网络命令与 PowerShell，macOS 和 Linux 可使用 curl、dig 或 nslookup、netstat 或 ss。工具的价值在于回答明确问题，例如“7890 是否监听”“域名解析到什么地址”“请求是否采用代理”，而不是一次导出全部系统信息。

诊断时为每个测试写下预期结果。访问局域网地址预期 DIRECT，访问测试域名预期某策略组，关闭客户端后预期系统代理被清理。实际结果与预期不同，再查看对应层的日志。没有预期的测试容易陷入“网页能开就是正常”的模糊判断，也无法发现本应直连的流量被错误代理。

形成可持续的学习顺序

完成本手册后，可以按“配置结构—规则顺序—DNS 路径—TUN 路由—服务化部署”的顺序继续深入。每个阶段都应保留一个可工作的基线配置，并把实验内容放在副本中。先理解单机请求路径，再研究远程规则集、复杂策略组和路由器透明代理；先能恢复网络，再启用开机自动接管。

当问题涉及特定平台权限时，回到安装章节；涉及单个应用不生效时，回到代理模式章节；涉及目标走错出口时，回到规则章节；涉及启用后整体断网时，回到 TUN 与 DNS 章节。若只需要重新完成一次基础连接，可转到快速教程；若需要更换客户端或重新下载安装包，使用客户端下载页。这种按层回查的方式比反复重装更容易保留证据并得到可复现结果。