Clash 使用手册：订阅、分流与 TUN 配置

核心概念：先分清内核、客户端与配置文件

Clash 不是单一安装包

日常说到“Clash”，可能指代理内核、图形客户端，也可能泛指采用 Clash 配置格式的一整套工具。内核负责读取配置、建立代理连接、匹配规则和转发流量；图形客户端负责把配置、日志、策略组、系统代理和更新操作整理成可点击的界面。mihomo 是当前 Clash 生态中常见的延续内核，许多新客户端使用它提供协议、规则类型、TUN 与 DNS 能力。理解这层关系很重要：同一份订阅在不同客户端中的按钮位置可以不同，但内核实际处理的代理节点、策略组和规则逻辑往往相近。

配置文件通常采用 YAML。它可以包含端口、代理节点、策略组、规则、DNS 和 TUN 设置。订阅则是一种远程配置来源：客户端保存订阅链接，按需下载服务提供方生成的配置，再交给内核加载。订阅链接本身不是“连接按钮”，节点名称也不等同于最终出口；请求先经过规则匹配，再由规则指定的策略组选择具体节点或直连。因此排错时必须区分三个环节：远程订阅能否下载、配置能否被内核解析、流量能否按规则送到可用策略。

一次请求如何经过 Clash

以浏览器访问网页为例，浏览器先把请求交给系统网络栈。如果系统代理已经开启，支持系统代理的应用会把 HTTP 或 SOCKS 请求送往客户端监听端口；如果启用了 TUN，更多 IP 流量会先进入虚拟网络接口。内核取得目标域名或目标地址后，从规则列表顶部开始匹配，命中后把请求交给指定策略。策略可以是某个具体节点，也可以是手动选择、自动测速、故障转移、直连或拒绝。最后，节点按对应协议与远端服务器建立连接，返回的数据再沿原路交给应用。

这条链路解释了常见现象：浏览器正常而某个游戏不通，通常说明该应用没有使用系统代理，可能需要 TUN；所有网站都打不开但订阅更新成功，通常说明配置已下载，问题发生在节点、策略或本地接管环节；只有特定域名异常，则更可能是规则、DNS 或目标服务自身限制。排查不应反复删除客户端，而应先确定故障位于“订阅获取、配置解析、流量接管、规则匹配、节点连接、DNS 解析”中的哪一层。

选择客户端：按平台、内核与使用场景判断

优先选择仍在维护的图形客户端

选择客户端时，先看操作系统，再看维护状态、内核类型和所需功能。本站下载清单首推 Clash Plus，覆盖 Windows、macOS、Android 与 iOS，适合希望在多个平台使用相近操作逻辑的读者。Windows 与 macOS 还可选择 Clash Verge Rev、FlClash；Windows 另有 Clash Nyanpasu。Android 可选择 Clash Meta for Android、FlClash 或 Surfboard。Linux 桌面环境可使用 Clash Verge Rev 或 FlClash。Clash for Windows 与 ClashX Meta 已停止维护，只适合处理旧配置迁移，不应作为新安装时的默认选择。

“界面看起来熟悉”不是唯一标准。需要 TUN、进程规则、规则集或较新的配置字段时，应确认客户端采用的内核能够识别这些功能。采用 mihomo 内核的客户端通常更适合当前配置生态，但同为 mihomo 客户端，权限申请、配置存储位置、托盘菜单和系统代理实现仍可能不同。订阅服务生成的配置如果依赖特定字段，也应优先遵循服务说明；遇到字段不识别时，先确认内核兼容性，不要直接删改整个配置。

桌面、移动端与服务器不是同一种使用方式

桌面客户端通常同时提供系统代理和 TUN。系统代理配置简单，适合浏览器、即时通信和遵循系统代理设置的软件；TUN 覆盖面更广，适合不读取系统代理的应用。Android 客户端通常通过系统 VPN 接口接管流量，启用时会显示 VPN 状态标识；若系统同时运行其他 VPN 类应用，二者一般不能同时占用接口。iOS 版本同样依赖系统的网络扩展能力，配置入口和后台行为受系统规则影响。移动端应额外关注电池优化、后台限制和按应用代理。

服务器、软路由和容器环境更适合直接运行 mihomo 内核。这类环境没有必要为了图形界面增加桌面依赖，通常通过配置文件、命令行参数和外部控制接口管理。但内核包不等于开箱即用的桌面客户端：使用者要自行准备配置路径、运行用户、服务管理、日志轮转和防火墙规则。仅在个人电脑上浏览网页时，应优先选图形客户端；只有明确需要网关转发、旁路由或自动化部署时，再进入纯内核方案。

确认系统架构与安装包类型

Windows 常见桌面设备使用 x64；搭载 ARM 处理器的设备才需要 ARM64。macOS 可在“关于本机”中查看芯片类型：Apple 芯片对应 arm64，Intel 处理器对应 x64。Android 安装包可能分为 arm64、arm 或通用包，近年的主流手机多使用 arm64，但旧设备和特殊模拟器需要按实际架构选择。Linux 除架构外还要区分 deb、rpm 与压缩包：Debian、Ubuntu 常用 deb，Fedora 系列常用 rpm，纯内核压缩包则需要手动部署。

完整客户端清单、平台入口和维护状态集中在下载页。如果旧客户端仍保存重要配置，迁移前先导出配置或记录订阅地址、策略选择与自定义规则，再安装新客户端。不同客户端的数据库和设置目录通常不能直接互相覆盖，稳妥做法是重新导入订阅，再逐项恢复自定义内容。

安装与初始设置：建立可恢复的基础环境

安装前先清理冲突状态

安装客户端前，先退出仍在运行的代理、VPN 和旧版 Clash 客户端，并确认系统代理没有残留。Windows 可在系统网络设置中查看手动代理是否仍然开启；macOS 可在当前网络服务的代理设置中检查 HTTP、HTTPS 与 SOCKS 项。残留代理常导致一种误判：新客户端尚未启动，浏览器却仍把请求发送到已经不存在的本地端口，于是所有网页都无法打开。此时问题不在安装包，而在旧程序退出后没有恢复系统代理。

桌面安装完成后，先启动客户端但不要立即打开所有高级功能。确认界面能够正常显示、内核可以启动、日志中没有持续重复的错误，再导入订阅。首次启动 TUN 时，Windows 可能申请管理员权限或安装虚拟网络组件；macOS 可能要求允许网络扩展或输入系统凭据。权限只需要在功能确实启用时授予。若拒绝了权限，系统代理通常仍可使用，但 TUN 无法建立虚拟接口。

先确定配置目录与自启动策略

图形客户端一般会把设置、订阅索引、内核文件和日志保存在用户目录。不要把程序目录和配置目录混为一谈：卸载应用未必会删除用户配置，覆盖安装也未必会重置设置。遇到异常时应先使用客户端提供的重置、切换配置或清理缓存功能；只有确认配置数据库损坏，才考虑备份后删除配置目录。随意清理用户目录会同时丢失订阅地址、脚本、自定义规则和策略选择。

“开机启动”和“启动时开启系统代理”是两个不同选项。前者只负责运行客户端，后者会修改操作系统的代理设置。移动办公设备可以开启客户端自启动，但建议先观察几次重启行为，再决定是否自动接管网络。若设备经常进入需要网页认证的公共网络，自动开启代理可能让认证页无法弹出；这时先暂停系统代理完成网络认证，再恢复连接。TUN 的自动启动也应在基础配置稳定后开启，避免开机阶段因权限或 DNS 设置异常影响全部网络。

端口设置要保持职责清楚

Clash 配置常见端口包括 HTTP 端口、SOCKS 端口和混合端口。混合端口可以在同一监听端口接收 HTTP 与 SOCKS 请求，适合多数个人设备。端口号只要未被其他程序占用即可，不需要为了“速度”频繁修改。允许局域网连接会让同一网络中的其他设备有机会访问监听端口，因此只在确有共享需求时开启，并配合监听地址、访问控制和系统防火墙限制来源。

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

external-controller: 127.0.0.1:9090

上面的基础片段表示启用混合端口、仅允许本机访问、使用规则模式并把控制接口限制在本机。不同客户端可能由界面生成这些字段，手动编辑前应确认客户端是否会在保存时覆盖文件。控制接口用于图形界面与内核通信，不应直接暴露到不受信任的网络。日志级别日常使用选择 info 即可；debug 会产生更多诊断信息，适合短时间排错，长期启用会增加日志体积并干扰关键信息判断。

用最小闭环验证安装

基础验证按固定顺序进行：先确认内核状态为运行中；再导入一份可用配置；选择策略组中的节点；开启系统代理；最后使用浏览器访问普通网页。如果失败，先观察客户端连接记录与日志：完全没有连接记录，说明流量没有进入客户端；有记录但显示直连，说明规则命中了 DIRECT；有代理记录但握手失败，说明节点连接或网络环境存在问题。这个最小闭环完成后，再启用 TUN、DNS 劫持、脚本或复杂规则，可以显著降低排错难度。

订阅导入与更新：管理远程配置的完整周期

订阅链接、配置文件与节点链接的区别

订阅链接通常返回一份由服务端生成的配置，内容可能包括多个节点、策略组、规则和 DNS 设置。单个节点链接只描述一个代理节点，不能自动提供完整分流结构；本地 YAML 文件则是某一时刻保存的静态配置，不会自行跟随远端变化。导入前先确认手中内容的类型：如果客户端要求填写 URL，应提供以 HTTPS 开头的订阅地址；如果使用文件导入，应选择完整 YAML；如果只有单个节点链接，则需要客户端支持从剪贴板解析或自行加入现有配置。

订阅地址相当于配置访问凭据，不适合发布到截图、论坛或公共仓库。客户端通常会把地址保存在本机配置数据库中。跨设备同步时，优先在每台设备中分别导入订阅，或使用服务方提供的集中管理方式；不要把包含订阅地址的配置文件放进公开同步目录。示例地址应使用测试域名，例如：

https://example.invalid/api/profile/clash?token=xxxx

一次正确的导入流程

在客户端中打开“订阅”“配置”或“Profiles”页面，选择从 URL 新建配置，粘贴链接后为配置填写容易识别的名称。更新间隔可按配置变化频率设置，日常使用通常不需要每隔几分钟刷新。保存后手动执行一次更新，确认客户端显示配置名称、更新时间或策略组，而不是只看到“已添加”状态。然后切换到这份配置，让内核重新加载。某些客户端把“下载订阅”和“启用配置”分成两个动作，只更新而不切换时，当前运行的仍可能是旧配置。

导入完成后不要立刻删除旧配置。先检查关键策略组是否存在、规则模式能否选择、常用节点是否显示，再完成连接测试。确认新配置稳定后，可以保留一份旧配置作为短期回退。多份配置并存时应使用明确名称，例如“日常订阅”“本地规则测试”，避免都叫 config 或 default。配置切换会改变策略组和规则，客户端可能无法把旧策略选择映射到新配置，因此切换后需要重新确认出口组。

更新失败时按层排查

订阅更新失败首先看错误类型。超时通常表示客户端无法访问订阅服务器；证书或系统时间错误会影响 HTTPS 建立；返回未授权通常表示地址失效或访问条件变化；下载成功但解析失败，则说明返回内容不是有效配置，可能是网页错误信息、编码异常或包含当前内核不识别的字段。先复制订阅地址到允许访问的浏览器环境中确认是否能取得内容，但不要把返回内容公开。若浏览器可访问而客户端失败，检查客户端是否设置了订阅更新使用代理、直连或当前代理。

“通过代理更新订阅”有一个常见循环：当前配置的节点全部失效，订阅更新又必须经过当前代理，于是客户端无法取得新配置。此时可临时切换为直连更新，或使用仍可用的备用配置完成更新。相反，在当前网络无法直连订阅服务器时，则需要通过可用代理更新。不同客户端对更新通道的命名不同，应在订阅设置、全局设置或网络设置中查找，而不是反复重新添加同一个地址。

自动更新需要保留回退空间

启动时自动更新适合配置较稳定、设备网络可靠的场景，但不应把它当作唯一维护方式。远端配置如果临时生成失败，自动更新可能把可用配置替换成异常内容。较稳妥的做法是保留最近可用配置、开启合理更新间隔，并在重要出行或网络切换前手动更新和测试。对于自行维护的本地覆盖规则，应确认订阅更新不会直接覆盖修改；客户端若支持覆写、合并或脚本功能，应把自定义内容放在独立层，而不是直接编辑每次都会被替换的订阅文件。

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

规则模式是日常使用的默认选择

规则模式会逐条检查请求目标，根据域名、IP、进程或规则集把流量交给不同策略。常见配置会让本地网络和无需代理的目标直连，把特定目标交给代理组，再用最后一条兜底规则处理未命中的请求。它的优势不是“自动选择最快节点”，而是让不同类型流量采用不同路径。最终使用哪个节点，仍由命中的策略组决定。多数日常场景应保持规则模式，因为它兼顾访问范围、局域网服务和不同应用的连接需求。

规则模式出现“部分网站正常、部分网站异常”时，不要立即改成全局。先在连接记录中找到目标请求，查看命中的规则和策略。若目标被错误判为直连，可以加入更精确的域名规则；若被送往错误策略组，应调整规则目标或策略组选择；若根本看不到域名，只显示 IP，则需要检查 DNS 模式、嗅探或应用是否直接连接地址。全局模式可以作为诊断工具：切到全局后恢复，说明节点本身大概率可用，问题集中在规则或 DNS；全局也失败，则优先检查节点和流量接管。

全局模式不是“性能加强模式”

全局模式通常把所有已进入内核的流量交给同一个全局策略组，不再按普通分流规则决定路径。它适合短时间验证节点、临时访问规则尚未覆盖的目标，或在明确知道全部流量都应使用同一路径时启用。全局模式不会让不遵循系统代理的应用自动进入 Clash，也不会绕过操作系统权限；某个程序在规则模式下完全没有连接记录，切换全局模式通常仍然无效，此时需要处理系统代理、应用代理设置或 TUN。

长期使用全局模式可能使本地服务、打印机、局域网设备和原本应直连的业务也经过代理。部分配置会为局域网地址保留特殊处理，但不能假设所有客户端行为完全相同。需要访问路由器管理页、局域网存储或开发环境时，如果发现连接绕远，应恢复规则模式并为本地网段保留 DIRECT。全局模式下的出口取决于“GLOBAL”策略组当前选择，不等于自动使用列表中的第一个节点。

直连模式用于恢复与定位问题

直连模式会让进入内核的流量不经过代理节点，常用于网络认证、订阅直连更新、验证目标在本地网络是否可达，以及临时恢复普通网络。它与“退出客户端”并不完全相同：客户端仍可能保持系统代理或 TUN 接管，只是转发动作改为 DIRECT。排查系统代理残留时，应同时测试直连模式和完全关闭接管；如果直连模式可用但退出客户端后不可用，可能是系统 DNS、代理设置或网络接口状态尚未恢复。

模式切换后的验证方法

切换模式后，应重新发起一次请求，不能只看之前已经建立的连接。浏览器可能复用现有连接，应用也可能保留 DNS 缓存，因此测试时可以打开新的无痕窗口、重新加载目标或短暂重启应用。随后在连接列表中确认新请求命中的模式和策略。若客户端支持清理连接，可在切换后关闭旧连接，但不需要频繁重启内核。记录“模式、命中规则、策略组、具体节点、错误信息”五项，通常比只记录“能开或打不开”更容易找到差异。

选择模式时还要区分“代理模式”和“流量接管方式”。规则、全局、直连决定进入内核后的处理逻辑；系统代理与 TUN 决定哪些流量能够进入内核。两个维度互相独立。规则模式配合 TUN 可以处理更多应用，全局模式配合系统代理仍然只能覆盖遵循系统代理的软件。理解这一点后，许多看似矛盾的现象会变得清楚。

规则分流：从匹配顺序到策略组设计

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

Clash 规则列表具有明确顺序。请求从第一条开始检查，命中后直接使用该规则指定的策略，不再继续向下匹配。因此，范围越精确的规则通常越靠前，范围较大的规则集和最终兜底规则放在后面。如果把广泛的域名后缀或 IP 段放得过早，后面的精确规则就永远没有机会生效。排查规则时，不能只确认“配置里有这条规则”，还要确认它位于哪一条更宽规则之前或之后。

常见规则类型包括精确域名、域名后缀、域名关键字、IP 网段、源地址、目标端口、进程名称和规则集引用。域名规则依赖内核能够取得目标域名；如果请求只表现为 IP，域名规则可能无法匹配。IP 规则则要考虑解析结果与 IPv4、IPv6 差异。进程规则在桌面平台较有价值，但受系统权限和客户端实现影响，不应把所有核心分流都建立在进程识别之上。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - DOMAIN-KEYWORD,media,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DST-PORT,22,Direct-or-Proxy
  - MATCH,Final

示例中，精确域名首先直连，example.org 及其子域进入 Proxy，名称包含 media 的域名进入 Media，本地网段直连，目标端口为 22 的请求交给单独策略，剩余请求由 Final 处理。策略名称必须与 proxy-groups 中的名称完全一致，包括大小写和空格。no-resolve用于避免某些 IP 规则为了匹配而额外触发域名解析，但是否适用要结合规则类型和配置目标判断。

策略组把规则与具体节点解耦

规则最好指向语义清楚的策略组，而不是直接写某个节点名称。例如规则指向“Media”“Work”或“Final”，策略组内部再选择具体节点。这样订阅更新导致节点增删时，规则层不需要全部重写。手动选择组适合由使用者明确决定出口；自动测试组会定期访问测试地址，根据响应选择节点；故障转移组按顺序尝试可用节点；负载均衡组则按配置算法分配连接。不同组解决的问题不同，不能仅凭名称推断行为。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

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

url-test测量的是到指定测试地址的一次请求表现，不代表视频带宽、长连接稳定性或所有目标的实际体验。测试地址应长期可访问、响应体小，并与真实使用网络路径具有一定代表性。间隔过短会产生额外请求，间隔过长则可能无法及时发现节点变化。tolerance用于减少延迟接近时的频繁切换，避免策略在多个节点之间来回变化。自动组适合一般访问，重要会话或需要固定出口的业务更适合手动选择组。

规则集与远程提供者

规则数量较多时，可使用 rule-providers 把不同类别拆成独立文件，由主配置引用。这样可以单独更新规则集，也便于复用。但远程规则同样存在下载失败、格式不兼容和更新改变行为的风险。应为规则提供者设置合理更新间隔和本地缓存路径，首次启用后检查日志是否下载成功。规则集类型、行为类型和文件格式需要匹配；domain、ipcidr 与 classical 的内容结构不同，混用会导致解析错误或规则无法按预期工作。

修改规则时采用“最小覆盖”思路：先为明确异常的域名增加一条精确规则，验证命中后再决定是否扩大到域名后缀或规则集。不要因为一个子域异常就把整个顶级域名全部送往同一策略，也不要把最终 MATCH 提到前面。客户端若支持覆写或合并规则，应把本地规则放进持久化覆盖层，避免订阅更新后丢失。关于 DNS 与规则如何相互影响，可继续阅读Clash DNS 配置详解。

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

TUN 解决的是流量入口问题

系统代理依赖应用主动读取操作系统代理设置。浏览器和多数桌面应用通常支持，但游戏、命令行工具、部分商店应用和使用自定义网络栈的软件可能完全忽略系统代理。TUN 会建立虚拟网络接口，通过路由把更多 IP 流量送入内核，因此能覆盖更广的应用范围。它不是一种新的代理模式：流量进入 TUN 后，仍然要按规则、全局或直连模式处理，也仍然由策略组决定出口。

首次启用 TUN 时，客户端可能需要管理员权限、网络扩展权限或 VPN 权限。Windows 上还要关注其他虚拟网卡、企业安全软件和已有 VPN；macOS 上要确认网络扩展已获系统允许；Android 与 iOS 通常会把 TUN 表现为系统 VPN，会与其他占用同一接口的应用冲突。若启用后所有网络立即中断，应先关闭 TUN 恢复基础连接，再查看日志中的接口创建、路由写入和 DNS 监听错误，而不是继续切换节点。

常见 TUN 参数的作用

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

auto-route让内核自动写入必要路由，auto-detect-interface用于识别当前出站网络接口，适合会在有线、无线和移动热点之间切换的设备。stack决定 TUN 使用的网络栈实现，mixed 是常见选择；若某个平台出现兼容问题，可以根据客户端文档在 system、gvisor 或 mixed 之间测试，但一次只改一个参数。dns-hijack用于把符合条件的 DNS 请求交给内核，减少应用绕过 Clash DNS 的情况。

示例中的地址仅用于说明字段结构。实际 DNS 服务器要结合当前网络可达性、隐私要求和配置来源选择。不要简单叠加大量 nameserver 与 fallback；服务器越多并不必然越稳定，反而会让查询路径和排错结果变复杂。若订阅已经提供 DNS 段，先理解现有逻辑再修改。客户端使用图形开关生成 TUN 配置时，也应避免同时在订阅文件和全局设置中写两套互相冲突的 DNS 参数。

fake-ip 与 redir-host 的差异

fake-ip 模式会为域名返回保留地址段中的映射地址，内核通过映射关系保留原始域名，从而更早进行域名规则匹配。它通常具有较好的分流能力，但某些局域网服务、特殊应用或依赖真实解析结果的程序可能需要加入 fake-ip-filter。redir-host 更接近传统解析流程，返回实际 IP，再结合解析结果进行转发，兼容思路较直观，但域名信息保留和匹配路径有所不同。选择时应依据客户端默认值和实际兼容性，不需要为了追求某个名称而频繁切换。

出现“网页能打开但某个局域网设备找不到”“应用登录失败但浏览器正常”时，可以检查 DNS 日志、fake-ip 过滤项和局域网域名。过滤应尽量精确，例如针对特定本地域名后缀，而不是把所有域名都排除。修改后清理应用自身 DNS 缓存或重新建立连接，否则旧解析结果可能继续生效。若系统启用了其他加密 DNS、浏览器安全 DNS或企业 DNS 客户端，还要确认它们是否绕过了 Clash 的解析路径。

TUN 常见冲突的定位

TUN 开启后完全断网，优先检查虚拟接口是否创建成功、默认路由是否写入、当前物理接口是否识别正确。只有部分应用异常，则查看该应用请求是否进入连接列表，以及是否被排除在 TUN 路由之外。访问局域网异常时检查私有网段规则和路由排除项。休眠唤醒后失效，可能是网络接口发生变化而路由未及时刷新，可先关闭再开启 TUN，确认是否恢复，再考虑自动检测接口和客户端更新。

同时运行容器、虚拟机、游戏平台加速工具或企业 VPN 时，路由表会更复杂。排错时先暂时退出其他会修改路由的程序，验证单独运行 Clash TUN 是否正常；随后逐个恢复，观察冲突出现在哪一步。若工作环境强制使用企业 VPN，不应擅自覆盖其路由，应优先使用系统代理或遵循网络管理要求。TUN 的目标是扩大接管范围，不是强行改变所有受管理网络策略。

日常维护与故障排查：建立稳定的检查顺序

维护重点是配置、内核与系统状态

Clash 客户端稳定运行后，不需要频繁清空配置或更换节点。日常维护可以固定为四项：按需更新订阅、关注客户端与内核维护状态、定期检查日志体积、保留可恢复的配置来源。订阅更新后简单验证常用策略组即可；客户端更新前记录当前配置位置和关键开关，更新后先确认内核启动、系统代理和 TUN 状态。直接覆盖安装通常不会改变订阅，但仍应为自定义规则和本地配置保留独立备份。

日志用于定位问题，不适合长期保持 debug 级别。正常运行时使用 info，可以看到配置加载、监听端口、订阅更新和连接错误。出现问题后复现一次，再从复现时间点附近读取日志。搜索第一条明确错误通常比盯着最后一行有效，因为后续错误可能只是前面失败的连锁结果。分享日志前应删去订阅地址、节点认证信息和个人路径，只保留错误类型、相关字段与必要上下文。

按“范围”判断故障位置

所有应用都无法联网时，先切换直连模式并关闭 TUN，检查普通网络是否可用；随后确认内核状态和端口占用。只有遵循系统代理的应用正常，其他应用异常，说明需要检查 TUN 或应用自身代理。只有一个网站异常，查看命中规则、DNS 结果和目标服务状态。只有某个节点异常，换同策略组中的其他节点对照。订阅无法更新但现有连接可用，则把问题限定在订阅地址与更新通道，不要重置整个客户端。

延迟测试只能反映测试地址上的短请求表现。一个节点显示较低延迟，却可能受带宽、丢包、拥塞或目标线路影响，在视频和大文件场景下表现不佳。反过来，延迟略高的节点也可能更加稳定。判断实际体验时，应结合连接成功率、持续传输、目标服务响应和一段时间内的稳定性。延迟数字的原理与误区可参考Clash 延迟测试数字怎么看。

端口、时间与缓存是容易忽略的基础项

端口占用会让内核无法监听，日志通常会出现 address already in use 一类信息。先退出旧客户端和重复内核进程，再确认端口是否释放。系统时间明显不准会导致 HTTPS 证书验证和部分协议握手失败，应开启可靠的时间同步。DNS 和连接缓存则会让修改不能立即表现：规则切换后旧连接仍可能继续使用原策略，DNS 修改后应用可能保留旧结果。测试时重新建立连接，必要时重启目标应用，而不是每次都重启整台设备。

系统代理关闭失败时，可在操作系统网络设置中手动恢复。Windows 还应检查自动配置脚本和手动代理是否同时残留；macOS 需要按当前网络服务检查代理项目。客户端异常退出后，TUN 路由通常会被清理，但少数情况下虚拟接口或路由状态可能暂时保留，重启客户端并正常关闭一次往往比直接删除驱动更稳妥。移动端则可在系统 VPN 设置中断开连接，再重新授权客户端。

建立可复现的排错记录

有效的排错记录至少包括操作系统、客户端名称、使用的接管方式、代理模式、问题发生时间、目标应用、命中策略和关键日志。描述“不能用”无法区分订阅、规则、DNS 与节点问题；描述“规则模式下浏览器请求命中 DIRECT，全局模式命中 Proxy 后恢复”就能直接指向规则层。每次测试只改变一个变量，并记录改变前后的结果。复杂问题可以复制当前配置建立测试副本，避免在日常配置上连续叠加临时修改。

如果更新客户端后出现新问题，先确认配置是否仍被选中、内核是否切换、TUN 权限是否保留，再考虑回退。旧客户端停止维护时不宜长期停留，迁移到新客户端后应重新验证系统代理、策略组和自定义覆盖。关于原版、Meta 与 mihomo 的关系，可阅读Clash 内核版本区别与选择，避免把客户端版本变化与内核差异混为一谈。

进阶路线：从图形设置走向可维护配置

先学会阅读配置，再开始重写配置

进阶配置的第一步不是从空白文件开始，而是读懂一份已经可以运行的配置。先识别基础监听、DNS、代理提供者、策略组、规则提供者和最终规则，再追踪一个真实请求会经过哪些字段。对订阅生成的配置建立副本，在副本中做最小修改并通过客户端的配置检查功能验证。YAML 对缩进敏感，列表项、对象层级和字符串中的特殊字符都可能导致解析失败；编辑器应使用空格缩进，并避免自动把普通字符替换成排版符号。

配置拆分应围绕维护边界：订阅负责远程节点，本地覆写负责个人规则，规则提供者负责可复用分类，全局设置负责设备级端口、TUN 和界面行为。不要把所有内容堆进一个每次订阅更新都会替换的文件。客户端支持 merge、override 或脚本时，应先确认合并顺序：同名字段是覆盖、追加还是深度合并，会直接影响最终配置。修改后查看客户端实际生成并交给内核的配置，而不是只看输入片段。

代理提供者适合管理动态节点

proxy-providers:
  main-provider:
    type: http
    url: https://example.invalid/provider.yaml
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: Main
    type: select
    use:
      - main-provider
    proxies:
      - DIRECT

proxy-providers 可以把节点来源与主配置分开，主配置通过 use 引用提供者。远程文件应采用内核支持的 provider 格式，路径用于本地缓存，更新间隔控制重新获取频率。健康检查用于判断节点对指定测试地址的可达性，但结果仍不代表全部目标体验。多个提供者并存时，可以按用途分别建立策略组，不必把所有节点塞入一个巨大列表。提供者更新失败时，本地缓存通常仍有机会继续使用，因此缓存路径应放在客户端可写且会被保留的位置。

外部控制接口与局域网开放要分别管理

external-controller 允许图形界面或管理面板读取内核状态并执行切换操作。个人电脑上优先监听回环地址，只有需要从其他设备管理时才考虑局域网监听，并同时配置访问凭据、系统防火墙和可信网段。allow-lan 控制代理端口是否允许局域网设备连接，与控制接口不是同一个开关。开放代理端口不代表应开放控制接口，反之亦然。任何面向局域网的监听都应明确用途和访问范围。

在软路由或服务器中运行时，还要决定内核以哪个用户启动、配置和缓存目录由谁写入、服务失败后如何重启。使用系统服务管理器比在终端中长期挂起进程更可靠。更新内核前应保留当前可执行文件和配置，先执行配置检查，再重启服务并观察日志。容器部署则需要明确端口映射、网络模式、TUN 设备权限和配置卷，不应把宿主机全部目录直接映射给容器。

DNS、嗅探与规则要作为一套系统设计

高级配置经常同时启用 fake-ip、DNS 劫持、域名嗅探和规则集。它们的共同目标是尽可能保留域名信息并正确分类流量，但重复或互相冲突的设置会增加误判。嗅探可以从部分 HTTP、TLS 或 QUIC 流量中恢复域名，对直接连接 IP 的应用有帮助；它并不能解密业务内容，也不是所有协议都能得到域名。应从客户端默认范围开始，只为明确问题调整端口或排除项。

设计 DNS 路径时画出三个问题：系统请求交给谁、内核向哪些上游查询、解析结果如何参与规则。若使用 nameserver-policy，可为特定域名指定解析服务器，但规则范围要精确，防止大量查询被意外送往不适合的上游。fallback-filter 用于判断哪些结果进入备用解析逻辑，应结合地理数据、网段和域名条件理解。相关字段的完整关系可查阅nameserver、fallback 与劫持参数说明。

形成自己的变更流程

可维护配置需要一套固定流程：复制当前可用配置，写明本次只解决一个问题；修改后执行语法检查；在直连可恢复的环境中加载测试；观察连接记录、规则命中和日志；确认稳定后再合并到日常配置。对于规则集和代理提供者，记录来源、用途和更新方式。删除不再使用的字段，避免同一功能在图形设置、覆写文件和订阅中重复定义。

学习顺序可以沿三条线推进。第一条是规则线：掌握 DOMAIN、IP-CIDR、PROCESS-NAME、RULE-SET 与 MATCH 的匹配边界。第二条是网络线：理解系统代理、TUN、路由、DNS 和 IPv6。第三条是运维线：掌握配置拆分、日志、服务管理和回退。完成这三条线后，再研究 mihomo 扩展协议与特殊规则类型。可先阅读mihomo 内核功能差异，确认哪些字段属于当前内核，再决定是否加入配置。