Clash 从零到精通使用手册

先理解 Clash 的核心概念与流量路径

客户端、内核和配置文件不是同一层

日常所说的 Clash 往往同时指代三类对象。第一类是带图形界面的客户端，例如 Clash Plus、Clash Verge Rev、FlClash 与 Clash Nyanpasu；它们负责配置管理、托盘菜单、系统代理开关、服务安装和日志展示。第二类是处理网络连接的内核，当前常见客户端多使用 mihomo，内核负责监听端口、解析规则、选择策略、建立代理连接以及处理 DNS。第三类是 YAML 配置文件，其中描述端口、节点、策略组、规则和 DNS 行为。

这三个层次必须分开判断。界面能够打开，只能说明客户端程序启动了；内核显示运行，才说明本地代理端口已经开始监听；浏览器能够访问目标网站，则还要求系统流量确实进入该端口、规则选择了有效策略、节点连接成功并且 DNS 解析正常。许多“Clash 已启动但没有网络”的问题，实际发生在内核之后的某一层，而不是安装程序本身。

配置文件也不等同于订阅。订阅地址通常由服务提供方生成，客户端访问该地址后取得一份配置内容，再将其保存为本地配置。单节点链接只描述一个服务器，不能天然包含完整的策略组和分流规则；本地 YAML 文件则是已经成形的配置，可以直接导入，但后续是否自动更新取决于客户端如何管理它。需要进一步辨别格式时，可参阅订阅链接、YAML 配置与常见导入格式说明。

从应用请求到最终出口的完整链路

以浏览器访问一个 HTTPS 网站为例，域名首先需要被解析为地址。随后浏览器建立 TCP 或 QUIC 连接，系统根据代理设置或虚拟网卡路由，将连接交给 Clash。内核读取目标域名、目标地址、端口和进程等信息，从上到下匹配规则；命中规则后，把请求交给对应策略组。策略组可能直接选中某个节点，也可能继续引用另一个组，最终得到“代理”“直连”或“拒绝”等动作。

因此，排查时应按链路顺序观察：应用是否遵循系统代理，或者流量是否由 TUN 接管；本地监听端口是否存在；域名是否被正确解析；规则是否命中预期条目；策略组是否选中了可用出口；远端节点是否能够建立连接。跳过中间层直接反复更换节点，可能暂时掩盖问题，却无法解决错误的系统代理、DNS 或规则配置。

选择客户端并完成各平台安装

先按平台与接管需求选型

图形客户端的核心作用不是改变订阅内容，而是降低配置管理与系统接管的复杂度。本站下载清单中，Clash Plus 作为 Windows、macOS、Android 与 iOS 的首推入口，适合希望在多个常用平台保持接近操作路径的用户。Windows 和 macOS 还可选择 Clash Verge Rev、FlClash；Windows 可使用 Clash Nyanpasu，并保留已停止维护的 Clash for Windows 归档入口；macOS 另有已停止维护的 ClashX Meta。Android 可选择 Clash Meta for Android、FlClash 或 Surfboard，Linux 桌面可选择 Clash Verge Rev 与 FlClash。

选择时不要只看界面外观。需要重点确认的是：当前系统架构是否有对应安装包、客户端是否支持所需内核、是否能够安装系统服务、是否提供 TUN 接管、订阅更新和日志查看是否清晰。只需要浏览器和少量遵循系统代理的程序时，普通系统代理已经足够；需要接管命令行、游戏启动器、虚拟机辅助程序或不读取系统代理的应用时，应优先选择能够稳定管理 TUN 的客户端。

服务器和路由器用户通常直接运行 mihomo 内核，但这条路线要求自行管理配置文件、进程权限、启动服务和日志轮转。普通桌面用户没有必要为了“更轻量”而跳过图形客户端，因为后续维护成本通常高于节省的界面资源。完整包清单、平台入口与停止维护状态以客户端下载页为准。

Windows、macOS 与 Linux 的安装重点

Windows 安装前应确认旧代理程序是否仍在运行。多个程序同时监听相同端口时，新内核会启动失败；多个程序轮流修改系统代理时，则会出现界面显示开启、系统实际指向另一个端口的情况。退出旧客户端后再安装新客户端，首次启动先允许应用通过系统安全提示。若要使用系统服务或 TUN，通常还需要在客户端内完成服务安装，并接受系统权限确认。服务安装成功与 TUN 已开启是两个不同状态，不应混为一谈。

macOS 安装后若提示应用来源或网络扩展权限，应在系统设置中完成确认。Apple Silicon 与 Intel 使用不同架构的软件包，下载时要根据“关于本机”中的芯片信息选择。系统代理只处理遵循 macOS 代理设置的连接；启用增强接管功能时，系统可能要求添加 VPN 配置或授权网络扩展。若授权被拒绝，先回到隐私与安全、网络或 VPN 相关页面重新确认，不要连续重复点击启动按钮。

Linux 的差异主要来自发行版包格式、桌面环境和权限模型。Debian、Ubuntu 一类系统通常使用 deb 包，其他发行版可选择客户端提供的兼容格式。安装后若界面可以启动但无法接管流量，应检查桌面系统代理是否真的写入、当前会话是否读取了相关设置，以及 TUN 所需的网络管理权限是否存在。服务器环境中运行内核时，配置目录和日志目录应由专用服务账户访问，避免长期以交互式终端进程维持运行。

Android 与 iOS 的接管方式

Android 客户端通过 VpnService 建立本地 VPN 接口，将设备流量交给内核处理。首次连接时系统会显示 VPN 授权窗口，只有确认后才能接管流量。锁屏后断连、切换网络后停止工作，多数与系统省电策略、后台限制或厂商的自动清理机制有关。应允许客户端后台运行，并根据系统设置将其加入电池优化例外。具体路径因厂商而异，可继续阅读Android VpnService、后台运行与省电设置。

iOS 通过系统 VPN 配置工作，安装 Clash Plus 后首次启用需要确认添加 VPN 配置。系统状态栏显示 VPN 标识，只表示配置已连接，最终能否访问还取决于订阅、策略和节点。移动平台从 Wi-Fi 切换到蜂窝网络时，原有连接会重建，短暂断开属于网络切换过程；如果长时间不能恢复，应先停止连接、等待系统 VPN 状态完全消失，再重新启动，而不是反复导入同一份订阅。

导入订阅并读懂基础配置结构

区分订阅地址、节点链接与 YAML 文件

订阅地址通常是一个 HTTPS URL，访问后返回可供 Clash 使用的配置或经过编码的节点列表。它的价值在于可以更新：服务方调整节点、策略或规则后，客户端重新拉取即可取得新内容。本地 YAML 文件是一份静态快照，适合备份、自定义或离线管理，但不会因为原始订阅发生变化而自动同步。单节点链接只包含协议、服务器、端口与认证信息，导入后仍可能需要手动建立策略组和规则。

导入前应确认地址完整，没有被聊天软件截断，也没有在复制时混入首尾空格。将订阅地址粘贴到客户端的订阅或配置导入入口，而不是浏览器地址栏的搜索框。导入成功后，先查看配置名称、更新时间和代理组是否出现，再将该配置设为当前启用项。只有“下载成功”而没有“切换为当前配置”，内核仍可能继续使用上一份文件。

导入失败时，错误大致分为三层。网络层错误包括连接超时、域名无法解析和证书错误；服务层错误包括授权失效、访问被拒绝或返回网页提示；配置层错误则包括 YAML 缩进错误、字段类型不符和引用不存在的策略组。客户端日志若显示 HTTP 状态问题，应先确认订阅本身；日志若指出某一行解析失败，则要检查配置内容，而不是更换代理节点。

基础配置中最值得先认识的字段

一个可运行的配置通常包含本地监听参数、代理节点、策略组、规则和 DNS 设置。图形客户端可能把部分全局字段放在自己的设置数据库中，因此导出的配置不一定包含所有界面开关。下面示例展示基础结构，不包含真实服务器信息；其中代理节点部分仅用于说明字段关系。

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

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,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

mixed-port表示同一个本地端口同时接受 HTTP 与 SOCKS 连接，便于手动为应用填写代理地址；端口只在本机监听时，常用地址是 127.0.0.1。allow-lan控制局域网其他设备能否连接当前设备的代理端口，日常仅本机使用时保持关闭更清晰。mode决定整体匹配模式，通常使用 rule。log-level影响日志详细程度，正常使用保持 info，排错时短暂调高后应恢复，避免长期积累大量日志。

proxies定义具体出口，proxy-groups把多个出口组织成可选择或自动测试的策略，rules则把流量交给策略组。规则引用的策略名称必须与组名完全一致，包括大小写和符号。若把组名从 PROXY 改成其他名称，所有引用该名称的规则也要同步修改，否则配置验证会失败。

更新、覆盖与本地修改之间的关系

订阅更新通常会重新下载远端内容并覆盖缓存，因此直接编辑订阅生成的 YAML，下一次更新后可能丢失。需要长期保留的自定义内容，应优先使用客户端提供的覆写、合并、脚本处理或全局扩展功能；如果客户端没有这些能力，可以复制一份本地配置独立维护，但之后必须自行同步节点变化。

更新失败时不要立即删除原配置。先保留最后一次可用缓存，检查订阅地址是否仍有效，再尝试手动刷新。若更新后的配置突然无法使用，可以切回旧缓存，对比代理组、规则和 DNS 区域发生了什么变化。良好的客户端会把“远端订阅”“本地缓存”和“当前启用配置”区分开，理解这三个状态能避免误删唯一可用配置。

掌握系统代理、运行模式与连接验证

系统代理与 Clash 运行状态的区别

客户端启动内核后，本地会出现 HTTP、SOCKS 或混合代理端口，但操作系统不会自动把所有流量送进去。系统代理开关的作用，是把本地代理地址写入 Windows、macOS 或桌面环境的网络设置。浏览器等遵循系统代理的程序随后会连接该端口；忽略系统代理的程序仍然直连。因而“内核正在运行”和“系统代理已开启”是两个独立条件。

手动配置应用代理时，服务器地址通常填写 127.0.0.1，端口填写配置中的 mixed-port、HTTP 端口或 SOCKS 端口。不要把远端节点端口直接填到浏览器，远端协议不一定是浏览器支持的 HTTP 代理。若客户端修改过本地端口，系统代理和应用内手动设置也必须保持一致。

部分命令行程序不会自动读取桌面系统代理，而是读取环境变量。临时测试时，可以在当前终端设置代理变量；关闭终端后变量通常失效，适合用来判断程序是否能通过本地端口连接。

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

Windows PowerShell 中可为当前会话设置对应环境变量，应用关闭后再清理。长期把代理变量写入系统环境前，应确认端口不会随客户端切换而变化，否则客户端未启动时，依赖这些变量的工具会持续尝试连接一个不存在的本地端口。

规则、全局与直连模式分别解决什么问题

规则模式按照配置中的规则自上而下判断，是日常使用的主要模式。它可以让局域网、常用本地服务或指定域名直连，将需要代理的连接交给策略组，并对不希望访问的目标执行拒绝。规则模式的效果取决于规则质量和排列顺序，出现单个网站走错出口时，应查看规则命中，而不是先切换整个运行模式。

全局模式通常把所有进入内核的流量交给指定策略组，适合做短时对照测试。如果规则模式无法访问、全局模式可以访问，说明节点和基础链路大致正常，问题更可能位于规则、策略组引用或 DNS 映射。全局模式不等于系统所有流量自动被接管；没有进入代理端口或 TUN 的连接，仍然不会被它处理。

直连模式让进入内核的流量直接访问目标，适合判断异常是否与代理出口有关。如果直连模式也无法访问，需要进一步检查 DNS、系统网络、目标服务或本地防火墙。排错结束后应恢复规则模式，避免把临时测试状态误当成长期配置。

用连接记录和日志完成闭环验证

仅凭网页“能打开”不足以验证分流正确。客户端的连接页通常能显示目标域名、目标地址、规则链和最终策略。访问一个测试目标后，观察它是否出现在连接列表中：没有记录，说明流量可能未进入内核；有记录但走向错误策略，说明规则或策略组选择有问题；策略正确但连接失败，则继续查看节点、协议握手和 DNS 日志。

日志应从第一条明确错误向前后阅读，而不是只看最后一行。端口占用往往在内核启动阶段出现，配置引用错误会在加载阶段出现，节点超时则发生在实际建立连接时。日志中的一次失败也可能来自后台程序，不一定对应正在测试的浏览器，因此最好先清空或记住时间点，再执行一次单一测试动作。

建立可维护的规则、策略组与 DNS 配置

规则从上到下匹配，顺序就是优先级

Clash 规则的基本结构是“类型、匹配内容、目标策略”。例如 DOMAIN-SUFFIX,example.com,PROXY 表示目标域名以 example.com 结尾时交给 PROXY；IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 表示指定地址段直连，并且匹配这一条时不主动触发域名解析；MATCH,PROXY用于接收前面所有未命中的连接，通常放在规则列表最后。

由于内核遇到第一条匹配规则后就停止继续查找，更具体的例外应放在更宽泛的规则之前。例如需要让某个子域名代理，而其余同一主域名直连，就应先写子域名规则，再写主域名后缀规则。把 MATCH 放到中间会使其后的规则永远没有机会命中。调整大型规则集时，先判断目标属于域名规则、地址规则还是进程规则，再确认是否被前面的宽规则提前截获。

rules:
  - DOMAIN,api.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,media,MEDIA
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,FINAL

DOMAIN匹配完整域名，适合精确例外；DOMAIN-SUFFIX覆盖主域名及其子域名，是常用类型；DOMAIN-KEYWORD范围较宽，容易误伤名称相似的域名，应谨慎使用。IP-CIDR和 IP-CIDR6直接匹配目标地址，适合局域网与明确网段。进程规则依赖操作系统和流量接管方式，系统代理场景不一定总能取得可靠的进程信息，使用前应在连接记录中确认。

策略组负责出口决策，不只是节点列表

策略组可以理解为规则与具体节点之间的决策层。select组由用户手动选择，结果稳定、便于排错；url-test会按指定测试地址和间隔测量候选节点，选择满足条件的结果；fallback通常按可用性顺序切换；load-balance按策略将连接分配给多个候选项。不同内核和客户端对高级参数的展示方式可能不同，应以配置验证结果为准。

proxy-groups:
  - name: FINAL
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

  - name: MANUAL
    type: select
    use:
      - main-provider

  - name: AUTO
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

自动测试只反映客户端到测试目标的连接情况，不代表所有网站体验完全一致。测试地址、节点出口和目标服务之间的网络路径可能不同，视频、下载和网页浏览对带宽、抖动与连接复用的要求也不同。日常可以用自动组提供基线，再保留手动组用于特定目标或故障切换。策略组之间可以互相引用，但应避免形成循环引用。

订阅中若使用 provider 管理节点，use引用的是 provider 名称，不是单个节点。服务方新增节点后，provider 更新即可进入相关策略组；如果策略组只写死节点名，新节点不会自动出现。修改前应先看客户端是否提供可视化覆写，避免直接编辑远端订阅缓存。

DNS 决定内核能看到什么目标信息

DNS 问题常表现为网页长时间等待、部分域名打不开、规则命中地址而不是域名，或者系统检测到解析路径与预期不一致。Clash DNS 模块可以接管解析请求，将不同域名交给指定上游，并配合规则提供域名信息。常见增强模式包括 fake-ip 与 redir-host。fake-ip 会先返回保留地址，再由内核在连接阶段还原真实域名，通常能保留更完整的域名匹配能力；但少数局域网设备、特殊应用和连通性检测可能需要加入过滤列表。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"

示例中的上游仅用于展示语法，实际选择应考虑所在网络的可达性、解析结果和隐私需求。DNS 监听地址如果只供内核或本机使用，应限制在本地地址。开启 TUN 后通常还会使用 DNS 劫持把系统的 53 端口请求导入内核；此时若系统中还有其他 DNS 过滤程序、加密 DNS 客户端或安全软件同时接管，容易形成争抢或循环。

判断 DNS 是否异常时，先区分“域名没有解析结果”和“已经得到地址但连接失败”。前者查看 DNS 日志、上游可达性与系统缓存，后者查看规则命中、目标地址和节点连接。修改 DNS 后应重启内核，并根据系统情况清理缓存，再用一个此前未访问过的域名测试。若担心解析路径，可继续查看 FAQ 中的相关排查项，并阅读站内关于 Clash DNS 与连接异常的问答。

配置 TUN 接管并处理权限与路由冲突

TUN 解决哪些系统代理覆盖不到的问题

系统代理依赖应用主动读取操作系统代理设置。浏览器和多数桌面应用通常支持，但命令行工具、部分游戏、虚拟机组件、UDP 应用和自行实现网络栈的程序可能完全忽略。TUN 模式创建一个虚拟网络接口，通过系统路由把连接送入 Clash，因此覆盖范围更广，也能处理更多 UDP 与非代理感知应用。

TUN 并不天然比系统代理更快。它增加了虚拟网卡、路由、DNS 劫持和协议转换等环节，优势是接管完整，而不是减少网络距离。仅需浏览器代理时，系统代理更简单；明确存在应用绕过、需要 UDP 或希望统一管理系统流量时，再开启 TUN。排错时也建议先让普通代理工作，再增加 TUN，这样可以把节点问题和系统路由问题分开。

理解常见 TUN 参数

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

dns:
  enable: true
  enhanced-mode: fake-ip

stack指定 TUN 使用的网络栈实现，常见值包括 system、gvisor 或 mixed，具体可用项取决于内核。system 通常利用系统网络能力，兼容性与性能受平台实现影响；gvisor 在用户空间处理更多网络逻辑，某些环境下隔离更明确；mixed 会按协议采用组合方式。没有明确故障时，应保持客户端默认选择，不要仅根据名称推断性能。

auto-route让内核自动写入所需路由，auto-detect-interface尝试识别实际联网接口，适合 Wi-Fi、有线网络之间切换。strict-route用于加强路由约束，减少流量绕过，但在存在虚拟机、容器、企业 VPN 或特殊局域网路由时可能需要额外调整。dns-hijack把指定 DNS 请求导入 Clash DNS，避免应用直接使用系统 53 端口绕过分流。

不同平台的权限与冲突来源

Windows 上启用 TUN 往往依赖管理员权限、系统服务或驱动组件。客户端显示服务未安装时，应先在设置中完成服务安装，再重新启动内核。若虚拟网卡创建失败，检查其他 VPN、网络加速器和安全软件是否也在管理路由或过滤驱动。不要同时开启两个全局 VPN 接管程序，它们可能不断重写默认路由，表现为连接周期性中断。

macOS 通常通过系统网络扩展或 VPN 配置实现接管。首次启用时应完成系统授权；如果配置残留导致无法重新建立，可以先在系统网络设置中停用旧 VPN 项，再由客户端重新创建。Android 与 iOS 本身就是通过系统 VPN 接口接管，同一时间通常只能有一个主要 VPN 配置处于活动状态，切换客户端前要先断开当前连接。

Linux 上直接运行内核时，需要创建 TUN 设备和修改路由的能力。使用 systemd 管理服务时，可按发行版安全策略授予必要的网络能力，而不是依赖一个长期保持打开的管理员终端。容器环境还要显式提供 TUN 设备与网络管理权限；如果主机已有防火墙规则，应确认内核写入的路由和转发规则没有被随后覆盖。

局域网、虚拟机和企业 VPN 的边界

开启 TUN 后无法访问打印机、路由器管理页或 NAS，通常是局域网路由被接管。先确认私有地址段是否保持直连，例如 IPv4 的常见局域网范围和 IPv6 本地地址；再检查严格路由是否阻止了特定接口。企业 VPN 可能只把内部网段导向专用接口，Clash 若覆盖该路由，会造成内部域名或办公系统不可达。解决时应明确哪些网段必须留给企业 VPN，而不是简单关闭全部分流。

虚拟机与容器可能通过独立网桥访问网络。宿主机 TUN 是否接管这些流量取决于路由、转发和网络模式，不能只看宿主机浏览器结果。出现冲突时，记录启用 TUN 前后的路由表变化，暂时关闭自动路由做对照，再决定添加排除网段或调整接口优先级。

建立日常维护、迁移与故障排查流程

日常更新不等于同时更新所有部分

Clash 环境通常包含客户端程序、代理内核、订阅配置和规则数据四类可更新对象。客户端更新可能改变界面和系统集成；内核更新可能影响协议、规则语法或 TUN 行为；订阅更新主要带来节点与服务方配置变化；规则集更新则改变分流结果。把这些更新安排在同一时间，一旦出现异常就难以确定来源。

更稳妥的做法是保持最后一次可用配置，先更新订阅并验证，再更新客户端或内核。重要设备更新前记录当前使用的配置名称、代理模式、策略选择、监听端口、DNS 模式与 TUN 状态。客户端支持导出设置时可以保留一份备份，但备份中可能包含订阅地址或认证信息，应放在受控位置，不要上传到公开仓库或公开问题截图。

订阅更新频率应与实际变化相匹配。过于频繁地刷新不会改善节点质量，反而可能在临时网络波动时不断产生失败记录。更新后发现策略组为空，应检查 provider 是否加载成功、节点过滤条件是否过严，以及订阅返回格式是否变化。不要在没有备份时删除旧配置重新导入，因为旧缓存本身就是重要的对照样本。

按层排查“完全不能上网”

第一步检查系统基础网络：关闭系统代理和 TUN 后，直连网络是否正常。如果直连也失败，先处理 Wi-Fi、有线连接、网关或系统 DNS。第二步启动 Clash 内核但不接管系统，查看是否存在配置解析错误和端口冲突。第三步开启系统代理，用浏览器访问测试站点并观察连接记录。没有连接记录时检查系统代理地址；出现记录后再看命中策略和节点错误。

若所有节点都超时，应判断是订阅过期、节点整体不可达，还是本地网络阻断。切换到同一配置中的直连策略可帮助确认本地网络，选择不同地区或不同协议的节点可帮助判断单一出口问题。若只有一个节点失败，不应修改整个 DNS 与规则配置。若全部节点立即返回认证错误，则应回到订阅状态和服务授权检查。

HTTPS 证书错误要与普通连接失败分开处理。先检查系统日期、时区和证书链，再确认是否启用了会检查 HTTPS 的安全软件或中间代理。Clash 的常规转发并不要求为普通 HTTPS 网站安装站点证书。详细判断顺序可参阅代理环境中的 HTTPS 证书报错处理。

按现象排查部分网站或部分应用

只有单个网站异常时，先打开连接记录，确认域名、命中规则和最终策略。如果规则走错，调整更具体的域名规则；如果策略正确但连接失败，尝试同组内其他节点；如果连接记录只有地址没有域名，检查 DNS 接管和 fake-ip 行为。目标使用 QUIC 时，UDP 支持也可能影响结果，可短时禁用浏览器 QUIC 做对照，但不应把对照设置当作永久结论。

浏览器正常、命令行或其他应用不正常，通常说明应用没有遵循系统代理。先查应用是否支持手动 HTTP 或 SOCKS 代理，再用环境变量测试；需要长期统一接管时考虑 TUN。只有移动应用锁屏后断开，则检查后台运行和省电限制。只有局域网资源不可达，则检查私有网段直连、TUN 严格路由和 DNS 对本地域名的处理。

代理关闭后系统仍无法联网，常见原因是客户端异常退出后系统代理残留。进入系统网络设置确认代理地址与开关，关闭失效的手动代理；若曾使用 TUN，则确认虚拟 VPN 已断开、默认路由恢复。重启客户端再通过正常按钮关闭接管，有时比直接结束进程更容易让系统设置恢复。

收集有效日志而不是整页截图

提交问题前记录操作系统、客户端名称、当前接管方式、故障开始时间和最小复现步骤。日志保留错误前后的一小段即可，并处理订阅地址、服务器地址、用户名和认证字段。界面截图应包含状态与错误区域，不必把无关桌面内容一并发送。能够说明“关闭 TUN 正常、开启后失败”或“全局正常、规则模式失败”的对照结果，比笼统描述“用不了”更有价值。

更多短问题可在常见问题页按基础认知、安装配置、使用技巧和故障排查分类查询。若界面中的代理页、配置页和日志页不熟悉，可阅读Clash 客户端界面功能速览，先找到对应状态，再按本章链路定位。

从稳定可用走向进阶配置与长期维护

先形成模块化配置思路

进阶配置的目标不是堆积更多规则，而是把节点来源、策略决策、规则来源、DNS 和系统接管拆成可独立验证的模块。节点可以由 proxy provider 管理，规则可以由 rule provider 管理，固定的策略组和全局设置保留在主配置中。这样更新节点时不会覆盖自定义策略，更新规则时也不需要重新复制整份配置。

模块化之前，先为每个策略组定义明确职责，例如“手动选择”“自动选择”“媒体服务”“开发服务”“最终出口”。组名应稳定、容易在日志中识别，不要频繁使用仅靠符号区分的相似名称。规则引用职责组，而不是直接引用某个短期节点；节点变化时只需调整组成员，规则层保持不动。

远程 provider 应设置合理更新间隔，并保留本地缓存。规则来源暂时不可达时，内核仍可使用缓存启动；如果把所有关键内容都依赖一次实时下载，网络恰好异常时可能无法完成启动。外部资源的格式与 behavior 必须匹配，例如域名集合、IP 网段集合和经典规则格式不能随意混用。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-network.yaml
    url: https://example.com/rules/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,FINAL

示例地址只用于展示结构。实际使用远程规则前，应确认来源、内容更新方式和可用格式。规则集不是越大越好：大量重叠条目会增加理解和排错成本，错误分类还会把本应直连的连接送入代理。优先维护与自己使用场景相关的少量例外，再选择边界清楚的通用规则来源。

理解 mihomo 扩展能力的适用边界

mihomo 在原版 Clash 配置思路上扩展了更多协议、规则类型、DNS 能力、provider 选项和 TUN 行为。迁移旧配置时，应先验证基础字段和策略组，再逐步引入新能力，而不是直接把多个来源的片段拼到一起。不同客户端内置的内核构建、默认参数和覆写机制可能存在差异，同一份片段在一个客户端可用，不代表另一个客户端会以完全相同方式加载。

需要系统了解兼容关系、扩展规则与迁移重点，可阅读mihomo 内核特性与原版 Clash 差异解析。学习时建议以客户端实际生成的运行配置为准：界面保存的设置可能在启动时合并进订阅配置，最终送给内核的内容才决定真实行为。

为配置变更建立验证与回退机制

长期维护应保留三类文件：一份确认可启动的基线配置、一份当前使用配置、一份正在修改的测试配置。修改后先执行客户端提供的配置检查，再启动测试；确认内核启动、系统代理、规则命中、DNS 和 TUN 均正常后，才替换当前配置。文本配置可以使用本地版本管理记录差异，但认证信息和订阅地址不应进入公开仓库。

每次变更写下目的，例如“让开发域名走指定策略”“排除家庭局域网”“为不遵循系统代理的应用开启 TUN”。如果无法用一句话说明目的，往往意味着一次修改混入了过多变量。出现回归时，根据记录恢复上一状态，再把修改拆小。可维护性来自稳定的命名、清楚的职责与可回退步骤，而不是配置文件长度。

建议的进阶学习顺序

第一阶段应熟练使用规则模式、手动策略组和连接记录，能够解释一次访问为何走向某个出口。第二阶段学习 DOMAIN、IP-CIDR、RULE-SET 与 provider，建立少量自定义分流。第三阶段理解 DNS 请求路径、fake-ip 和域名嗅探，能够区分解析问题与连接问题。第四阶段再研究 TUN 路由、局域网排除、IPv6 和多 VPN 共存。最后才考虑自动测试、负载分配、脚本覆写与复杂规则集。

完成这条路线后，遇到问题时不再需要反复重装客户端，而是能够按应用接管、内核监听、DNS、规则、策略和节点的顺序定位。需要更换客户端时，也能明确哪些内容属于订阅，哪些属于本地设置，哪些依赖具体平台。若当前目标只是完成首次连接，回到快速使用指南按最短流程操作；若准备重新选型，可查看Clash 客户端选型指南和全平台下载入口。