Clash 从零到精通使用手册

第一章

核心概念：先看清一条连接经过什么

客户端、内核与配置文件的分工

Clash 生态通常由三个部分组成：图形客户端负责按钮、配置管理和系统权限；Mihomo 等内核负责监听端口、解析规则、建立代理连接与转发流量；配置文件负责描述节点、策略组、规则、DNS 和 TUN 参数。用户在界面里点下“系统代理”或“TUN 模式”，实际动作是客户端修改系统网络设置，再把对应参数交给内核执行。理解这层关系后，排障就不会只盯着界面上的连接开关。界面显示运行中，只能说明内核进程已经启动，并不等于订阅有效、策略选对、DNS 正常或目标应用已经进入代理路径。

图形客户端与内核也不是同一个版本概念。客户端更新通常带来界面、平台适配和配置管理能力，内核更新更关注协议、规则行为、DNS 与网络栈。部分客户端内置内核更新入口，部分客户端把内核随安装包一起发布。日常使用不必追逐每次更新，但遇到配置字段无法识别、协议握手失败或新系统兼容问题时，应分别确认客户端与内核状态，而不是把两者混成一个“Clash 版本”。

流量入口、策略判断与出口

一条典型连接可以拆成四步。第一步，浏览器或应用把请求交给系统代理端口，或者由 TUN 虚拟网卡截获；第二步，内核解析目标域名、IP、进程或网络类型；第三步，规则从上到下匹配，并把请求送进某个策略组；第四步，策略组选择具体代理节点、直连或拒绝动作。任何一步断开，表面都可能表现为网页打不开。系统代理未开启属于入口问题，规则顺序错误属于判断问题，节点不可用属于出口问题，DNS 返回异常则可能发生在判断之前。

常见监听端口包括 HTTP、SOCKS5 与 mixed-port。HTTP 端口适合显式支持 HTTP 代理的程序，SOCKS5 端口适合支持 SOCKS 的工具，mixed-port 可以在一个端口同时接受两类请求。多数图形客户端已经管理这些端口，普通用户不需要自行修改。只有在端口被其他程序占用、局域网设备需要接入，或命令行工具需要手动指定代理时，才需要查看当前监听地址与端口。监听在 127.0.0.1 时仅本机可访问；开放局域网访问会扩大可连接范围，应同时确认防火墙与访问控制。

配置、订阅与运行状态不是一回事

订阅是远端维护的一份配置来源，配置文件是客户端下载后保存在本地的具体内容，运行状态则是内核加载某份配置后的结果。订阅地址可以正常访问，但返回内容未必符合当前内核语法；配置可以解析成功，但其中节点可能失效；节点可以建立连接，但规则仍可能把目标请求送到直连。检查时应依次确认“订阅是否更新成功—配置是否加载成功—策略组是否有可选项—请求是否命中预期规则—出口是否可用”。按层次检查比反复切换总开关更快。

完成本章后，先记住一个判断原则：连接问题不是单一开关问题。后续每项设置都应放回“入口、判断、出口”这条路径中理解。这样无论使用 Windows、macOS、Android、iOS 还是 Linux，界面名称即使不同，排查顺序仍然可以保持一致。

第二章

选择客户端：按平台、权限与维护方式决定

首选图形客户端，而不是直接运行内核

普通桌面与移动设备优先使用图形客户端。它会处理配置存储、系统代理、开机启动、日志查看、内核启停与权限申请，出错时也更容易确认当前状态。本站各平台首推 Clash Plus，适合希望用统一界面完成订阅导入、策略切换与基础网络接管的用户。Windows 与 macOS 还可选择 Clash Verge Rev、FlClash；Windows 可选 Clash Nyanpasu，并保留已经停止维护的 Clash for Windows 作为归档选择；macOS 另有已经停止维护的 ClashX Meta。客户端完整排列、平台入口与当前安装包应从下载页查看。

Android 可在 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 之间选择。移动端需要关注系统 VPN 权限、后台运行限制和省电策略，不能只比较界面。iOS 使用 Clash Plus 的 App Store 版本，系统会通过 VPN 配置接管流量。Linux 桌面环境可使用 Clash Verge Rev 或 FlClash；服务器、路由器、容器与没有桌面环境的设备，则更适合直接部署 Mihomo 内核并用配置文件管理。

选择时看三个实际条件

第一是系统架构。Windows 常见为 x64，少量设备为 ARM64；采用 Apple 芯片的 Mac 选择 Apple Silicon 或 ARM 架构包，较早的 Intel Mac 选择 x64 包。Linux 除发行版格式外还要确认 CPU 架构，不能把 AMD64、ARM64、ARMv7 或 MIPS 包混用。系统架构不确定时，应先在系统信息中确认，不要通过文件名猜测。安装包能下载但无法启动，架构不匹配是首要检查项之一。

第二是需要接管的应用范围。只代理浏览器和遵循系统代理的程序，常规系统代理已经够用；游戏、命令行工具、商店应用、虚拟机或不读取系统代理设置的软件，可能需要 TUN。第三是维护方式。桌面用户通常需要可视化订阅更新与策略选择，服务器用户更看重配置文件、服务进程、远程日志和自动重启。选择功能最多的客户端并不一定更稳，能覆盖当前需求、更新路径清楚、日志可读，通常更重要。

避免在多个客户端之间同时接管系统

同一台设备可以安装多个客户端用于比较，但不应同时启用系统代理或 TUN。两个内核可能争用监听端口，两个客户端也可能轮流改写系统代理，造成界面看似开启、实际端口却指向另一进程。切换客户端前，先关闭旧客户端的系统代理与 TUN，确认进程退出，再启动新客户端。若新客户端提示端口占用，应查明占用进程，而不是连续改成随机端口，因为浏览器、环境变量或其他工具可能仍指向旧端口。

归档客户端适合兼容旧配置或临时迁移，不适合作为新安装的默认起点。停止维护并不代表现有安装立即失效，但操作系统升级、协议变化与内核字段更新都可能逐渐产生兼容问题。迁移时先导出本地覆盖规则、记录策略选择和端口设置，再在新客户端中导入订阅；不要直接复制整个程序目录，以免把旧内核、缓存与系统集成状态一并带入。

第三章

安装与初始化：先建立可回退的基础状态

安装前清理冲突状态

安装前先退出正在运行的其他代理客户端，并关闭其系统代理、TUN 或 VPN 配置。Windows 可在系统网络设置中检查手动代理是否仍指向旧端口；macOS 可查看当前网络服务的代理选项；移动端则检查状态栏中的 VPN 是否由其他应用保持。保留旧客户端没有问题，但首次初始化最好只让一个程序控制网络。这样一旦安装后无法访问网络，可以明确判断问题来自新客户端，而不是两个程序叠加。

下载时按照操作系统与架构选择文件。Windows 安装包通常通过安装向导写入用户目录或程序目录；macOS 应把应用放入“应用程序”，首次打开可能需要在系统隐私与安全设置中确认；Linux 的 deb 或 rpm 包应对应发行版，便携包和内核压缩包则需要自行安排路径与执行权限。Android 安装后会请求 VPN 权限，iOS 从 App Store 安装后也会在首次连接时创建 VPN 配置。这些权限用于建立本机流量入口，拒绝后客户端可以打开，但无法真正接管网络。

首次启动只做最小设置

第一次启动不建议立刻修改端口、DNS、TUN 栈和大量覆写项。先保留默认监听地址与端口，确认客户端能够启动内核，并找到日志、配置列表、代理策略和连接记录入口。随后导入一份有效订阅，选择其中一个可用策略，再启用系统代理。此时用浏览器访问普通网页，并观察连接记录是否出现新请求。如果连接列表完全没有变化，说明流量尚未进入客户端，应先检查系统代理，而不是更换节点。

Windows 上若客户端需要安装服务模式或网络组件，应按界面提示完成授权。服务模式通常用于在较高权限下管理 TUN、路由或系统设置，安装后可能需要重启客户端。macOS 的网络扩展或辅助服务同样需要系统确认。Linux 桌面环境中，托盘、系统代理写入和 TUN 权限依赖桌面会话与系统服务；只从终端启动图形客户端时，应留意终端关闭后进程是否随之退出。

用可观察信号验证安装结果

安装成功不能只看窗口是否出现。至少确认四个信号：内核日志没有持续重复的启动错误；本地监听端口已建立；订阅配置可以被加载；启用系统代理后连接记录能够看到浏览器请求。若日志提示地址已被占用，可在 Windows 使用 netstat，在 macOS 或 Linux 使用 lsof 查看端口归属。下面命令只负责定位本机监听状态，不会修改网络配置：

Windows:
netstat -ano | findstr LISTENING

macOS / Linux:
lsof -nP -iTCP -sTCP:LISTEN

如果端口由旧客户端占用，先退出对应进程并恢复旧客户端改写过的系统代理。若端口没有监听但客户端显示运行中，应打开内核日志查找配置解析失败、权限不足或内核文件缺失。不要一开始就关闭防火墙或安全设置；先依据明确日志定位，因为本机回环端口无法创建与远端连接被阻止是两类问题，处理方式不同。

移动端验证还要考虑系统后台限制。Android 在息屏后断开，常见原因是电池优化、后台活动限制或系统清理进程；可以为客户端允许后台运行，并确认 VPN 常驻状态。iOS 切换 Wi-Fi 与蜂窝网络时可能触发网络重建，短暂重连属于系统行为；若长时间不恢复，应回到客户端查看当前配置与策略，而不是反复删除 VPN 配置。

保留这个最小可用状态很重要。后续启用规则覆写、TUN 或 DNS 后，如果网络异常，可以逐项退回到“默认配置加系统代理”的状态。一次修改多个模块虽然省步骤，但出现问题时无法确认是哪一项导致，最终往往只能重装，而重装又不会自动清除系统代理、服务与本地配置。

第四章

订阅与配置：更新来源、加载结果和本地修改

导入订阅后的第一轮检查

订阅导入通常通过 URL、剪贴板或本地文件完成。添加后先手动更新一次，确认客户端显示更新时间，并检查代理策略页是否出现节点与策略组。只看到订阅名称不代表内容已经下载成功；订阅地址过期、网络无法访问、响应格式错误或转换结果不兼容，都可能留下一个空配置条目。更新失败时先查看客户端日志中的 HTTP 状态、解析提示和保存路径，不要连续重复点击更新。

订阅 URL 往往包含访问凭据，应像账户密码一样保存，不要发到公开截图、问题讨论或日志附件中。更换设备时可以在可信渠道重新取得地址，而不是从浏览器历史或聊天记录里长期复制。配置导出也要区分来源：完整导出可能包含订阅地址和节点参数；仅导出本地规则或覆写内容更适合迁移个人设置。

远端配置与本地覆写的边界

直接编辑订阅下载后的 YAML 通常不是长期方案。下一次更新会用远端内容覆盖本地文件，手工添加的规则、DNS 或策略组可能随之消失。支持覆写、合并或扩展脚本的客户端，应把个人规则放在独立覆写层；不支持覆写时，可以复制订阅配置为本地配置，但要接受它不会继续自动同步远端变化。维护前先弄清客户端采用“覆盖更新”“合并更新”还是“生成运行配置”，否则很容易出现界面里改过、重启后又恢复的情况。

标准 YAML 使用缩进表达层级，不能混用制表符。列表项以连字符开头，字符串中含冒号、井号或特殊字符时最好加引号。配置加载失败时，错误常指向后续行，真正原因可能是上一行缩进或引号未闭合。修改后先做小范围测试，每次只改一个模块，并保留上一份可加载文件。下面是一段用于理解结构的最小示例，服务器地址采用文档保留地址，不能用于实际连接：

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

proxies:
  - name: "示例节点"
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: "demo-user"
    password: "your-password"

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - "示例节点"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手动选择
  - MATCH,DIRECT

配置里的名称必须一致。规则指向“手动选择”时，策略组必须存在同名项；策略组引用“示例节点”时，节点名称也必须完全匹配，包括空格与大小写。常见加载错误不是协议参数本身，而是重命名节点后忘记同步策略组，或复制规则时保留了配置中不存在的组名。中文名称可以正常使用，但跨工具转换时，简短且稳定的名称更容易维护。

订阅更新失败的分层处理

先确认设备在不依赖该订阅配置时能否访问订阅地址。部分情况下，旧配置失效后订阅更新也会跟着失败，可以暂时关闭代理直连更新，或切换到另一份可用配置再更新。若返回的是网页、登录页或错误提示而不是配置内容，应回到订阅来源处理授权，不要尝试把网页保存成 YAML。若下载成功但解析失败，检查订阅是否面向其他客户端格式，或者是否包含当前内核不支持的字段。

订阅转换应被视为配置生成过程，而不是节点修复工具。转换可以重组策略组、规则和字段，但不能让失效节点恢复，也不能改变订阅本身的权限。使用转换时记录模板来源、目标格式与更新方式，避免几个月后无法解释某条规则从何而来。涉及访问凭据时，更应确认处理链路与保存位置，尽量在自己可控的环境完成。

配置管理的目标不是保存越多文件越好，而是能说明当前运行的是哪一份、它从哪里更新、哪些内容由本地追加。建议给本地配置写清用途，例如“桌面日常”“仅系统代理测试”“TUN 排障”，并删除长期不用的重复副本。配置过多时，误选旧文件往往比规则本身更难发现。

第五章

代理模式：规则、全局与直连如何选择

规则模式是日常默认选择

规则模式会按照配置中的规则逐条判断请求，决定走某个策略组、直接连接或拒绝。它适合长期使用，因为不同网站和应用可以采用不同出口，本地服务、局域网地址与无需代理的流量也能保持直连。规则模式是否符合预期，取决于规则集内容、顺序、DNS 结果和策略组选择。它不是自动判断所有网络环境的黑盒；当某个地址走错出口时，应查看连接详情中的命中规则，而不是直接把整个客户端改成全局模式长期使用。

连接记录通常会展示目标域名或 IP、匹配规则、策略链与最终节点。排查单个网站时，先清空或过滤连接列表，再重新发起请求，观察新连接。浏览器可能同时请求主域名、静态资源、登录接口和第三方服务，页面异常不一定由主域名造成。只有找到失败连接及其命中规则，才能判断是规则缺失、策略组选择错误还是节点本身不可用。

全局模式用于隔离规则问题

全局模式通常把绝大多数可接管流量送到指定策略或节点，适合短时间验证出口。如果规则模式下某网站无法访问，而全局模式下恢复，说明节点具备连接能力，问题更可能位于规则匹配、DNS 或策略组路径。若全局模式同样失败，则优先检查节点、协议、系统时间和网络环境。全局模式是一种诊断工具，也可用于明确需要统一出口的临时场景，但它会绕开原有分流设计，局域网、本地服务和不需要代理的流量可能受到影响。

切换全局模式后要确认全局策略组选中了什么。部分配置把“GLOBAL”组设为可选列表，仍需手动指定节点；只切模式但没有选择有效出口，结果可能和规则模式一样。测试结束后切回规则模式，并重新打开目标应用。某些程序会复用已经建立的长连接，模式切换不会让旧连接立即改变路径，浏览器可关闭相关标签或等待连接重建。

直连模式用于确认本地网络

直连模式会让被接管的请求不经代理节点直接访问。它适合判断基础网络、DNS 和目标服务在当前网络中是否可达，也适合在暂停代理时保持客户端运行以观察连接。直连模式不等于关闭系统代理：流量仍可能进入内核，只是最终动作是 DIRECT。因此需要彻底退出客户端时，应关闭系统代理或 TUN，并确认系统网络设置已经恢复。

若直连模式也无法访问普通网站，问题可能在本地网络、DNS、系统路由、防火墙或仍然残留的其他 VPN。此时继续更换代理节点没有意义。反过来，直连正常、全局失败，通常指向节点或代理协议；直连正常、全局正常、规则失败，则重点检查规则与策略组。这个三模式对照法可以快速缩小范围，但每次测试应使用同一目标、同一网络和新建连接，避免缓存干扰。

策略组决定最终出口

模式只决定如何进入策略判断，策略组才决定具体使用哪个出口。常见策略组类型包括手动选择、自动测速、故障转移和负载分配。手动选择最容易理解，适合重要场景；自动测速会依据测试地址和间隔选择结果较好的节点，但测试延迟不等于实际访问速度；故障转移在当前节点不可用时切换到备用项，更适合重视连续性的配置。不同客户端对策略组类型的中文名称可能不同，应以配置里的 type 为准。

自动选择不能替代实际验证。测试地址可达，只说明节点能完成该测试请求；目标网站可能使用不同线路、协议或地域策略。遇到节点延迟看似正常但网页很慢时，查看实际连接的建立时间、下载过程与丢包情况，并手动比较少量节点。频繁设置很短的测速间隔会增加后台请求，也可能导致策略在节点间来回切换。日常配置更适合使用合理间隔，并为重要策略保留手动选择能力。

第六章

规则分流：匹配顺序、规则类型与覆盖方法

规则从上到下匹配，首次命中即停止

Clash 规则最重要的行为是顺序。请求从规则列表顶部开始检查，命中第一条后就采用该规则指定的策略，不再继续向下。具体域名规则通常应放在较宽泛的域名后缀、GeoIP 或最终兜底之前。若一条宽泛规则提前命中，后面的精确规则即使写得正确也不会执行。排查“自定义规则不生效”时，先在连接记录中查看实际命中了哪一条，再回到规则列表比较位置。

常见规则包括 DOMAIN 精确域名、DOMAIN-SUFFIX 域名后缀、DOMAIN-KEYWORD 域名关键词、IP-CIDR IPv4 网段、IP-CIDR6 IPv6 网段、GEOIP 地理 IP 分类、PROCESS-NAME 进程名称以及最终的 MATCH。域名规则在域名仍可见时判断最直接，IP 规则依赖解析结果，进程规则则依赖平台与接管方式，不是所有系统和客户端都能提供一致的进程识别能力。

从精确条件写到宽泛兜底

新增规则时先确定目标：是一个具体主机、整个域名后缀、一段 IP，还是某个应用进程。能用精确域名解决时，不要直接使用过宽的关键词，因为关键词可能误伤包含相同片段的其他域名。域名后缀规则会覆盖主域名及其子域，适合结构稳定的服务。IP 网段规则适合没有域名信息或明确按地址分流的服务，但地址可能随 CDN 与网络区域变化，需要后续维护。

rules:
  - DOMAIN,api.example.com,工作策略
  - DOMAIN-SUFFIX,example.net,手动选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,手动选择

no-resolve 用于告诉内核匹配该 IP 规则时不要为了判断而额外解析域名，适合私有网段等明确地址条件。是否添加要看规则类型和实际需求，不应机械地附在所有规则后。MATCH 是最终兜底，通常放在末尾；它前面没有命中的请求都会进入指定策略。若把 MATCH 放到中间，后续规则将永远没有机会执行。

规则集与 Geo 数据需要可追踪

大型配置通常通过 rule-providers 引用规则集，避免在主配置里塞入成千上万条规则。规则集便于独立更新，但也增加了来源、行为和更新时间三个变量。使用前应知道规则集覆盖什么类别、采用何种格式、由哪个策略引用，以及更新失败时是否继续使用缓存。不要同时叠加多个范围高度重合的规则集，否则同一域名命中哪一份会依赖排列顺序，后续很难解释。

GeoIP 与地理站点分类依赖本地数据文件。数据过旧时，新分配的地址或新域名可能分类不准确；数据下载失败时，客户端也可能继续使用旧缓存。进行 Clash GeoIP 更新时，应先查看客户端是否提供数据更新入口，再确认日志中下载与加载是否成功。更新后若分流行为突然变化，比较更新前后的命中规则，不要只凭目标站点的页面内容或公司所在地推测 IP 分类。

本地覆盖要放在正确插入点

客户端提供的“前置规则”“后置规则”“合并规则”含义可能不同。前置规则通常插入远端规则之前，适合需要优先命中的个人规则；后置规则若位于远端 MATCH 之后，则实际上不会生效。使用覆写功能时，先查看最终生成的运行配置或日志中的规则顺序，确认自定义内容真正进入了 MATCH 之前。仅在编辑框里看见规则，不代表内核加载后的排列相同。

规则调试应从一个目标开始。清空连接筛选，访问目标域名，记录域名、解析 IP、命中规则、策略组和最终节点。随后只调整一条规则，重新加载配置并新建连接。浏览器 DNS 缓存、连接复用和服务工作线程都可能保留旧路径，必要时关闭相关页面或重启目标应用。更完整的语法与覆盖案例可继续阅读Clash 自定义规则语法详解。

第七章

TUN 与 DNS：接管更多流量并保持解析一致

系统代理与 TUN 的接管范围不同

系统代理主要影响读取操作系统代理设置的应用，浏览器和部分桌面软件通常支持良好，但游戏、命令行工具、商店应用、虚拟机程序或自行实现网络栈的软件可能绕过。TUN 会创建虚拟网络接口，通过系统路由把更多 IP 流量交给内核，因此覆盖范围更广。它不是“更快的系统代理”，而是另一种入口机制，也会带来路由、DNS、权限、局域网和其他 VPN 兼容问题。

首次启用 TUN 前，应确保系统代理模式已经能正常工作。这样可以证明订阅、节点和基本规则大体有效，TUN 失败时就能把范围缩小到权限、虚拟网卡、路由和 DNS。若一开始同时启用 TUN、自定义 DNS、IPv6 和多套覆写，出现断网后很难知道是哪一层造成。建议先关闭系统代理，仅启用默认 TUN 参数测试；确认请求进入连接记录后，再逐项调整 DNS 与绕过规则。

权限、路由与网络栈参数

TUN 需要创建虚拟接口和修改系统路由，因此桌面系统通常要求管理员权限、辅助服务或网络扩展。Windows 上要关注服务模式、驱动状态和其他 VPN；macOS 要确认网络扩展授权；Linux 需要 TUN 设备与相应 capability 或管理员权限。权限不足时，日志一般会出现创建接口、设置路由或访问设备失败。此时反复更换节点不会改变结果，应先处理系统权限。

常见 TUN 栈名称包括 system、gVisor 或 mixed，具体可用值取决于内核与客户端。system 更依赖操作系统网络栈，gVisor 在用户空间处理更多网络行为，mixed 会按协议组合处理。没有明确问题时保留客户端默认值。遇到特定应用无法连接、UDP 异常或休眠恢复后网络不通，可以在记录原值后切换栈进行对照，但每次只改一项，并重启内核让虚拟接口重新建立。

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

auto-route 负责自动写入路由，auto-detect-interface 用于识别当前默认网络接口。设备同时连接有线、Wi-Fi、虚拟机网卡和其他 VPN 时，自动识别可能选错出口；表现通常是 TUN 启用后所有连接超时。可先退出其他网络工具并重新启用 TUN，观察默认接口变化。strict-route 会加强路由约束，可能减少流量绕行，但也更容易影响局域网、虚拟机或特殊路由，首次配置不宜盲目开启。

DNS 模式决定域名如何进入规则

DNS 不只是把域名转换为 IP，它还影响规则能否看到域名、连接走哪个出口以及是否发生解析路径不一致。Clash DNS 常见增强模式包括 redir-host 与 fake-ip。redir-host 更接近返回真实解析结果；fake-ip 会先返回保留地址映射，再由内核在连接阶段恢复域名，便于把域名信息保留到规则匹配。少量局域网服务、设备发现、游戏或依赖真实 IP 的程序可能需要加入 fake-ip-filter。

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

示例中的公共解析器只是语法展示，实际选择应结合所在网络、配置规则和隐私需求。若配置支持按代理与直连路径拆分 DNS，应保证用于解析代理目标服务器的解析器不会反过来依赖尚未建立的代理，避免启动环路。遇到 Clash DNS 泄漏疑虑时，不要只看单个检测网页结论；先确认系统 DNS 请求是否被 TUN 或 DNS 劫持接管，再查看内核日志、当前监听端口和实际发往哪个解析器。浏览器自带加密 DNS 也可能绕过系统路径，应纳入检查。

TUN 故障按恢复网络优先处理

启用 TUN 后完全断网，先关闭 TUN 并确认路由恢复；若关闭后仍无法联网，退出客户端，检查系统中是否残留虚拟接口、代理设置或其他 VPN。随后重新启动客户端，只用系统代理验证基础连接。基础连接正常后，再检查 TUN 日志中的接口创建、默认路由、DNS 监听和权限错误。局域网设备无法访问时，检查私有网段是否保持 DIRECT、严格路由是否拦截，以及局域网地址是否被 fake-ip 处理。

休眠唤醒、Wi-Fi 切换或从有线切到热点后断网，常见原因是默认接口和路由发生变化。先等待客户端自动重建，未恢复时关闭再开启 TUN；频繁出现则查看客户端是否支持网络变化重载，并检查 auto-detect-interface。若系统同时运行容器、虚拟机或远程接入工具，应记录它们创建的网段，避免 TUN 路由覆盖。TUN 稳定的标准不是开关能点亮，而是切换网络、休眠恢复和访问局域网时都能得到可解释的结果。

第八章

日常维护与故障排查：从配置有效性开始

建立轻量维护节奏

日常维护不需要每天改配置。更可靠的做法是定期更新订阅与规则数据，更新后进行一次最小验证：配置能否加载、常用策略组是否有节点、规则模式下普通网页是否可访问、连接记录是否符合预期。客户端或内核更新前记录当前配置、TUN 状态、端口和本地覆写；更新后先验证基础连接，再恢复复杂选项。若工作环境要求稳定，可以稍后再跟进新功能更新，但遇到系统升级或协议兼容问题时应查看当前维护状态。

备份重点是本地新增内容，而不是缓存。建议保存订阅来源的取得方式、本地覆写规则、DNS 调整、策略组修改和服务配置。节点列表若完全由订阅生成，无需长期复制多个快照；真正需要保留的是那些无法从订阅重新得到的个人设置。备份文件应标注用途和日期，并避免公开其中的订阅地址、节点凭据与局域网信息。

已连接但无法上网的固定顺序

第一步检查配置是否成功加载，策略组是否存在可用选项。第二步切到直连模式验证本地网络，再切全局模式选择一个明确节点，排除规则影响。第三步确认系统代理或 TUN 是否真的接管流量：若连接记录没有新请求，问题在入口；若有请求并快速失败，查看规则、策略链和错误类型。第四步检查 DNS，比较域名访问与直接 IP 连接表现。第五步检查端口冲突、TUN 权限、其他 VPN、防火墙与系统时间。

“已连接”常指节点握手或客户端运行状态，不代表每个目标都可达。若只有一个网站失败，先查看该网站涉及的多个域名和命中规则；若所有网站都失败，再检查出口和系统网络。若浏览器可用但命令行不可用，确认命令行工具是否读取系统代理，或为当前终端设置代理环境变量。临时测试可以使用本机 mixed-port，端口以客户端实际显示为准：

Windows PowerShell:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

macOS / Linux:
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"

环境变量只对当前终端及其启动的进程生效，关闭终端后通常失效。若客户端端口不是 7890，应替换为实际值。测试结束后不要把临时变量误写入全局 shell 配置，尤其是在客户端不常驻的设备上，否则以后关闭客户端时命令行会持续指向不存在的端口。更完整的逐项流程可参考Clash 已连接但无法上网排查清单。

延迟、超时与速度问题要分开看

Clash 节点延迟测试通常发送一个较小的 HTTP 请求，结果受测试地址、DNS、握手方式和当前网络影响。延迟低不代表下载速度高，也不代表目标服务一定可用。超时可能来自节点不可达、测试地址被阻止、协议握手失败或本地网络丢包。比较节点时，应使用同一测试地址与相近时间，并结合实际网页或下载行为，不要只按一次排序结果判断。

速度突然下降时，先确认是否只有单个目标受影响，再比较直连、全局不同节点与规则模式。查看连接是否被送往预期策略，节点是否频繁自动切换，后台是否正在更新订阅或规则。无线网络不稳定、系统省电、移动网络切换和其他下载任务也会影响结果。若只有晚间或特定线路出现，可能属于网络路径变化，频繁重装客户端通常没有帮助。

日志只收集与问题时间相邻的部分

排障时把日志级别临时调到 info 或 debug，复现一次问题后立即记录时间、目标、模式和错误行。debug 日志内容多，不适合长期开启，也不应未经处理直接公开。分享前删除订阅地址、节点服务器、认证信息、本地用户名与文件路径。有效日志应包含问题发生前后的启动、DNS、规则匹配和连接错误，而不是只截取最后一句“timeout”。

HTTPS 证书报错应先检查系统时间、浏览器策略、系统证书链和网络中间设备，再判断是否与代理路径有关。普通 Clash 转发并不要求为所有网站安装解密证书；若某软件启用了流量分析、脚本改写或其他中间处理，则需要单独确认。可按代理后 HTTPS 证书报错处理方法逐层检查，避免通过忽略证书警告来绕过问题。

第九章

进阶路线：从稳定配置走向可维护配置

先把个人需求写成可验证条件

进阶配置不是堆叠更多规则和开关，而是把需求变成可以验证的行为。例如“工作域名始终走固定策略”“局域网与开发环境保持直连”“移动网络切换后 TUN 自动恢复”“规则集更新失败时仍能使用缓存”。每个目标都应对应一组配置、一种观察方式和一个回退方案。若无法说明某个覆写解决什么问题，就先不要加入长期配置。

建议建立基线配置与实验配置。基线只包含稳定订阅、清楚的策略组、必要规则和已经验证的 DNS/TUN 参数；实验配置用于测试新规则集、不同网络栈或策略组行为。实验成功后再把单项变化移入基线。这样即使配置解析失败或路由异常，也能快速切回可用状态，而不需要从大量历史修改中猜测。

使用 proxy-providers 管理动态节点

当节点来源与主配置分开维护时，可以用 proxy-providers 定义远端或本地节点提供器，再让策略组引用。这样策略组和规则可以保持稳定，节点列表按计划更新。提供器需要明确类型、路径、更新间隔与健康检查。缓存路径应避免多个提供器共用同一文件，健康检查地址也应选择长期稳定、响应较小且符合实际网络条件的目标。

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription"
    path: "./providers/primary.yaml"
    interval: 21600
    health-check:
      enable: true
      interval: 900
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: "自动选择"
    type: url-test
    use:
      - primary
    url: "https://www.gstatic.com/generate_204"
    interval: 600

示例地址只用于说明结构。实际订阅地址应由可靠来源提供，并妥善保存。更新间隔不是越短越好：过短会增加远端请求和本地重载，节点频繁变化还可能打断长连接。健康检查同样不代表完整可用性，它只证明节点能访问测试目标。重要业务仍应保留手动策略组，必要时把自动选择作为候选，而不是唯一出口。

用 rule-providers 拆分规则职责

规则数量增长后，可以按用途拆成局域网、工作、媒体、开发、直连与拦截等规则集。主配置只保留引用顺序与最终策略，让每份规则集的职责清楚。拆分时避免按网站逐个建立过细文件，否则维护成本会转移到大量小文件。更实用的边界是“更新来源相同、策略目标相同、维护周期相近”的规则放在一起。

更新远端规则集前应保留缓存，并确认格式与 behavior 类型一致。domain、ipcidr 与 classical 规则集的内容结构不同，类型写错会导致解析失败或匹配异常。规则集加载成功后，仍要通过连接记录验证几个代表性目标。仅看到下载成功，不能证明规则顺序正确，也不能证明目标进入了预期策略。

内核部署需要补齐服务与权限管理

在服务器或路由器上直接运行 Mihomo 时，图形客户端代办的工作需要自行完成，包括配置路径、工作目录、日志、进程守护、启动顺序、更新与权限。先用前台命令加载配置，确认没有语法错误，再交给系统服务管理。不要一开始就让进程后台静默运行，否则启动失败时很难看到原因。配置中引用的相对路径以工作目录为基准，服务管理器使用的目录若与手动测试不同，规则集和数据库文件可能找不到。

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

第一条命令用于检查配置，第二条指定运行目录并加载文件。实际可执行文件名和路径以下载内容为准。服务账户应拥有读取配置、写入缓存和创建必要网络接口的权限，但不应为了省事给整个配置目录开放不必要的写权限。配置变更后先执行检查，再重载服务；若远程设备依赖该代理保持管理连接，更新前还要准备本地控制台或可回退路径。

按阶段扩展，而不是一次完成所有功能

可以把进阶路线分成四段。第一段稳定使用规则模式，能通过连接记录解释一次请求；第二段整理本地覆写与规则集，让订阅更新不会覆盖个人设置；第三段启用并稳定 TUN、DNS 与网络切换；第四段再考虑 provider、服务器部署、自动更新和监控。每一段都至少运行一段时间，确认日常网络、休眠恢复、局域网与常用应用没有异常后再进入下一段。

学习过程中应优先记录现象与结论，而不是收藏大量未经验证的配置片段。同一个字段在不同内核、客户端和操作系统上的默认值可能不同，复制前先确认当前运行配置。遇到 Windows 系统代理、订阅和 UWP 回环问题，可查看Windows 安装 Clash 全流程；需要重新整理首次初始化步骤时，可回到Clash 首次安装设置清单。

后续每次改动都可以沿用同一套流程：写清目标，备份基线，只修改一项，重载后查看日志与连接记录，再用直连、全局和规则模式对照。需要更换客户端或重新安装时，前往客户端下载页确认平台与架构；只需快速恢复首次连接时，按快速上手教程重新建立最小状态。系统手册的作用不是让设置变复杂，而是让每个开关都有明确位置、每次故障都有固定起点。