Clash 从零到精通使用手册

先理解 Clash 的核心概念

开始操作前，先把客户端、内核、配置文件、订阅、节点、代理组和规则这几个概念分开。很多看似复杂的故障，本质上只是把其中两个环节混在了一起。例如，客户端成功启动并不代表已有可用配置；订阅导入成功也不代表配置已经选中；选中了配置仍要确定代理组使用哪个节点；系统代理打开后，也只有遵循系统代理设置的程序会自动交给 Clash。沿着这条链路逐层确认，比反复重装更容易找到问题。

客户端、内核与配置分别负责什么

客户端是能看到的图形界面，负责导入订阅、修改设置、展示连接记录以及控制系统代理。内核是实际解析配置并处理连接的程序，Mihomo 是当前常见的兼容内核之一。配置文件通常是 YAML 文本，其中包含端口、代理节点、代理组、规则和 DNS 等内容。图形客户端启动内核时，会把当前选中的配置交给内核读取；只要配置语法有效，内核便按照其中定义的顺序处理流量。

这三层的故障表现不同。客户端打不开，多半要检查安装、权限或系统兼容性；客户端能打开但提示配置解析失败，应查看 YAML 格式或订阅内容；内核已运行但网页不通，则继续检查系统代理、代理组选择、规则命中和节点可用性。排查时先判断问题位于哪一层，避免把所有异常都归到“节点失效”。

订阅、节点和代理组的关系

订阅链接是配置提供方给出的远程地址。客户端请求这个地址后得到配置内容，并把它保存为本地配置。节点是配置中的单个代理出口，通常记录服务器地址、端口和协议参数。代理组则把多个节点组织在一起，可以手动选择，也可以按延迟测试或故障转移策略选取。规则一般不会直接指向某个节点，而是先指向“节点选择”“自动选择”之类的代理组，再由代理组决定最终出口。

因此，看到节点列表不等于当前连接已经使用某个节点。需要先选中订阅配置，再进入代理页面查看主要代理组，把它切换到合适节点。若代理组停在 DIRECT，相关连接会直接访问；若停在 REJECT，连接会被拒绝；若使用自动选择，则结果取决于该组的测试地址、测试间隔和候选节点。节点来源不属于客户端本身，Clash 也不会在安装后自动生成可用线路。

系统代理与 TUN 的接管范围

系统代理是操作系统提供的一组代理地址设置。浏览器和许多桌面应用会读取这组设置，把 HTTP 或 SOCKS 连接发送到 Clash 的本地监听端口。它配置简单、影响范围清晰，适合作为第一次使用时的首选。部分游戏、命令行程序、商店应用和自行实现网络栈的软件不会读取系统代理，因此即使开关处于开启状态，也可能继续直连。

TUN 模式通过虚拟网卡接收更多系统流量，覆盖范围通常比系统代理更完整，但同时涉及管理员权限、路由表、DNS 接管和网络安全软件兼容。正确顺序是先用系统代理验证订阅与节点可用，再根据实际需求开启 TUN。若一开始同时修改订阅、DNS、规则和 TUN，出现问题后很难判断由哪个环节引起。

按系统与使用方式选择客户端

Clash 生态包含多个图形客户端和可独立运行的内核。选择时应先看操作系统，再看是否需要 TUN、规则编辑、订阅管理和桌面托盘等功能，不必单纯比较界面外观。本站下载页按 Windows、macOS、Android、iOS、Linux 和 Mihomo 内核分组展示，客户端清单与这里的建议保持一致。首次使用优先选择维护状态清晰、操作入口完整的图形客户端，服务器和路由器场景才考虑直接运行内核。

各平台的首选思路

Clash Plus 覆盖 Windows、macOS、Android 与 iOS，是本手册的全平台首推方案。它适合希望在不同设备上使用相近操作逻辑的人，也提供常用的订阅与代理设置入口。Windows 用户还可以选择 Clash Verge Rev、FlClash 或 Clash Nyanpasu；Clash for Windows 已停止维护，只适合处理已有环境或旧配置迁移，不建议作为新安装的起点。

macOS 除 Clash Plus 外，可以选择 Clash Verge Rev 与 FlClash。ClashX Meta 已停止维护，已有用户可先导出或记录订阅信息，再迁移到仍在维护的客户端。Android 可使用 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard。移动端系统对后台运行和电池优化限制较多，安装之后还要检查 VPN 权限、后台活动和省电策略。iOS 使用 Clash Plus 的 App Store 版本，相关入口可在iOS 下载分区查看。

Linux 桌面环境可选 Clash Verge Rev 或 FlClash。没有桌面环境的服务器、软路由和容器场景，可以使用 Mihomo 内核，但需要自行准备配置文件、服务管理和日志查看方式。直接运行内核不会自动提供图形界面，也不会替系统设置桌面代理，因此更适合已经理解端口、路由和配置结构的用户。

图形客户端与独立内核怎样取舍

图形客户端适合日常桌面和移动设备。订阅更新、代理组切换、连接查看、系统代理与 TUN 开关都集中在界面里，出现问题时也更容易确认当前状态。独立内核适合希望使用 systemd、Docker 或脚本管理的环境，优点是部署方式灵活，代价是需要自己维护配置路径、启动参数、日志轮转和重启策略。

如果只是想让浏览器与常用应用按规则访问网络，不必为了“功能更多”直接选择内核。先用图形客户端熟悉规则模式、代理组和连接记录，之后再迁移到服务端环境，理解成本会低很多。反过来，若目标设备没有桌面、需要长期运行且配置由自动化系统下发，图形界面反而没有必要。

迁移旧客户端时保留哪些信息

从 Clash for Windows 或 ClashX Meta 迁移时，最重要的是保存原始订阅地址以及自行编写的覆写规则。不要只复制客户端缓存目录，因为不同客户端对配置目录、数据库和界面设置的组织方式不同。若订阅仍可访问，在新客户端重新通过 URL 导入通常更稳妥；若配置中包含本地规则集或脚本，应单独备份相关文件并检查新内核是否支持对应语法。

迁移完成后先关闭旧客户端，避免两个程序同时修改系统代理或占用相同端口。确认任务栏、菜单栏或后台进程中只保留一个内核，再启动新客户端。随后依次导入订阅、选择配置、选择代理组和开启系统代理。旧客户端可以暂时保留用于对照，但不要同时运行。

完成安装、权限授予与首次启动

安装阶段的目标不是立刻修改所有高级设置，而是让客户端、内核和系统权限处于可验证状态。完成安装后先启动一次，确认主界面可以打开、内核状态正常且没有端口占用提示，再继续导入订阅。若首次启动就出现错误，应先处理安装与权限问题，不要用反复导入配置来掩盖底层故障。

Windows 安装与端口检查

Windows 用户从下载页选择与系统架构匹配的安装包，按安装向导完成部署。若系统询问是否允许应用通过防火墙，可根据当前网络类型授权；局域网共享代理并非首次使用的必要条件，不需要提前打开局域网连接。安装后从开始菜单启动客户端，观察内核是否成功运行。准备使用 TUN 时，后续还可能需要安装服务或以管理员权限完成虚拟网卡初始化。

端口被占用是 Windows 上常见的首次启动问题。Clash 配置常使用本地 HTTP、SOCKS 或 mixed 监听端口，如果旧代理工具仍在后台运行，新内核可能无法绑定同一端口。先退出其他代理客户端，再重启 Clash。需要进一步确认时，可以在 PowerShell 中查看某个端口的监听进程：

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,7892 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess>

不同配置可能使用不同端口，界面中显示的实际监听值才是判断依据。不要因为习惯值是 7890 就直接修改系统代理；图形客户端通常会自动把正确地址写入系统设置。

macOS 的安全提示与网络权限

macOS 安装完成后，将应用放入“应用程序”目录并从中启动。系统可能要求确认应用来源、添加网络配置或输入管理员密码。系统代理只需修改网络代理设置，而 TUN 或增强接管通常还要安装辅助服务。每一次授权都应对应当前正在执行的操作；如果取消授权，客户端界面可能仍能打开，但相关开关会无法生效。

菜单栏客户端容易与旧代理程序同时存在。检查菜单栏图标和“活动监视器”，确认旧内核已经退出。若系统代理开关开启后立即自动关闭，先查看客户端日志是否提示权限不足，再检查网络设置是否被其他网络管理工具覆盖。切换 Wi-Fi、网线或热点后，系统使用的网络服务可能变化，必要时重新切换一次系统代理开关。

Android 与 iOS 的 VPN 授权

移动端通常通过系统 VPN 接口接管流量。首次启动连接时，系统会弹出 VPN 配置或连接请求，只有同意后客户端才能工作。Android 状态栏出现 VPN 标识，通常表示系统接口已经建立，但仍需确认配置与代理组正确。若应用退到后台后连接很快停止，进入系统电池设置，允许后台活动并将客户端从过度严格的省电限制中移出。

同一时间通常只能有一个应用占用系统 VPN 接口。若设备上已有企业 VPN、其他代理客户端或隐私保护工具，启动 Clash 时可能主动断开其中一个。先明确需要保留哪个连接，不要同时开启多个相互竞争的 VPN。iOS 上添加 VPN 配置后，可以在系统设置中看到对应条目；删除客户端前如需彻底移除连接配置，可同时检查系统 VPN 列表。

Linux 桌面与内核运行方式

Linux 图形客户端按发行版选择对应安装包。安装后若应用可以启动但无法设置系统代理，需要检查桌面环境是否支持自动写入代理设置。GNOME、KDE 和轻量桌面对代理配置的存储方式不同，必要时可以在桌面网络设置中手动核对地址与端口。使用 Wayland 或沙盒环境时，还要关注托盘图标与权限限制，但这些界面问题不一定影响内核运行。

直接运行 Mihomo 内核时，应先准备独立工作目录，将配置保存为可读文件，再以前台方式启动以观察日志。下面是常见的启动形式，路径需要替换为本机实际目录：

mkdir -p "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

确认配置加载成功后，再考虑交给 systemd 等服务管理器。首次测试不建议直接放到后台，否则配置解析错误和端口冲突只会留在服务日志中，不易察觉。服务器还应限制控制接口和代理端口的监听范围，默认仅供本机使用时绑定环回地址即可。

导入订阅并建立可恢复的配置流程

订阅导入是把远程配置交给客户端管理的过程。开始前准备完整的订阅 URL，并确认复制时没有多出空格、换行或说明文字。订阅属于配置来源，不应粘贴到节点名称、代理端口或控制器地址输入框。不同客户端可能把入口称为“配置”“订阅”“Profiles”或“配置文件”，但核心操作都是通过 URL 下载配置、保存到本地并把它设为当前配置。

URL 导入的标准步骤

进入配置或订阅页面，选择从 URL 新建配置，将完整链接粘贴到地址栏。名称可以填写便于识别的短文本，例如按用途或设备区分，不建议把完整 URL 当作名称显示。提交后等待客户端下载；成功时通常会出现新的配置条目，并显示更新时间或更新按钮。接下来点击该条目使其成为当前配置，有些客户端导入完成后不会自动选中，这是“能看到订阅但没有节点”的常见原因。

配置启用后进入代理页面，查看主要代理组是否已经出现，并选择一个节点。然后开启系统代理，用浏览器进行基础访问测试。整个过程应分成“下载配置”“选中配置”“选择节点”“开启接管”四步，不要仅凭订阅条目存在就认为设置已经完成。完整图文式主线可参考Clash 订阅链接导入方法。

判断链接格式是否被客户端接受

常见订阅内容包括 Clash YAML 配置、节点列表以及需要转换后才能被 Clash 识别的格式。客户端通过 URL 请求到内容后，会交给配置解析器。如果返回的是登录网页、错误页面、空文本或不兼容格式，界面可能提示解析失败，而不是简单显示网络错误。此时先在订阅提供方页面重新复制专用于 Clash 或 Mihomo 的链接，不要随意把网页地址当作订阅地址。

一个基础 YAML 配置通常包含端口、代理、代理组和规则等字段。下面示例展示结构关系，不包含实际节点信息：

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

proxies: []

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,节点选择

YAML 对缩进敏感，通常使用空格，不要混入制表符。订阅由远程服务生成时不必手工改动原文件；需要添加自定义规则时，优先使用客户端提供的覆写或合并功能，避免每次更新订阅后本地修改被覆盖。

更新失败时按响应类型处理

订阅更新超时，说明客户端在限定时间内没有完成请求，可能是当前网络无法访问订阅地址、DNS 解析异常或更新请求需要经过已有代理。可以先用原网络直接打开订阅提供方的管理页面，确认服务可达；如果客户端有“通过代理更新”选项，可在已有可用配置时尝试开启。首次导入尚无可用配置时，则应先保证订阅地址可以通过当前直连网络访问。

返回 404 或类似的资源不存在提示，通常意味着链接路径失效、令牌已经更换或复制不完整。此时重试不会修复地址，需要回到订阅来源重新生成链接。若返回未授权或拒绝访问，应检查账户状态、链接权限和服务端限制。更多按错误类型拆分的处理方式见订阅更新失败排查。

自动更新间隔与本地备份

自动更新无需设置得过于频繁。节点和规则只有在服务端内容发生变化时才会改变，短时间连续请求会增加失败概率，也不利于判断当前使用的是哪一次更新结果。日常设备可以按客户端提供的小时级间隔设置；需要立即同步时再手动更新。更新后若节点列表明显异常，先查看配置更新时间，并尝试切回上一个仍可用的本地配置。

订阅 URL 应作为敏感配置信息保管，因为它可能允许获取账户对应的配置内容。分享截图时遮住完整地址，排查问题时优先提供错误类型和日志片段，而不是公开链接。备份时可保存订阅地址、自定义覆写和客户端设置说明；远程订阅生成的节点列表通常可以重新下载，不必在多台设备间复制整个缓存目录。

理解规则、全局与直连三种代理模式

代理模式决定连接在进入 Clash 后如何选择出口。它不决定流量能否进入客户端；系统代理或 TUN 才负责接管。模式选择也不会改变节点本身是否可用。理解这两个边界后，排查会清楚很多：连接记录里完全没有请求，应检查接管；有请求但出口不符合预期，应检查模式、规则与代理组；请求选择了代理却连接失败，再检查节点和目标网络。

规则模式适合日常使用

规则模式会从上到下检查配置中的规则，第一条匹配成功的规则决定连接交给哪个策略组、直连还是拒绝。常见规则依据包括域名、域名后缀、IP 地址、地理数据库、进程名和规则集。它可以让局域网、本地服务和常用直连站点保持直连，同时把需要代理的连接交给指定代理组，兼顾访问路径与本地服务兼容性。

规则模式并不等同于“自动判断一切”。判断依据来自配置文件，规则的覆盖范围和顺序都可能影响结果。某个新域名尚未进入规则集时，最终会落到末尾的 MATCH 规则。遇到单个网站出口不对，应先在连接记录中找到目标域名，查看它命中了哪条规则以及最终策略，再决定是否增加自定义规则，而不是立刻切到全局模式长期使用。

全局模式用于对照测试

全局模式通常把已接管的连接统一交给全局代理组。它适合短时间判断“问题是否由规则导致”：若规则模式下访问失败，切换全局后恢复，说明节点和接管链路大致正常，接下来应检查规则命中或 DNS 结果。如果全局模式仍失败，则优先检查节点、端口、权限和网络环境。

全局模式不代表操作系统的全部流量一定被接管。仅开启系统代理时，不读取系统代理的应用仍可能直连；要扩大范围需要 TUN。全局模式也可能让局域网设备、打印机、开发服务或仅允许本地网络访问的资源走向代理，因此更适合作为测试工具或明确需求下的临时选择，而不是解决所有故障的固定开关。

直连模式用于恢复与基线检查

直连模式会让进入 Clash 的连接绕过代理出口。它可用于确认系统原始网络是否正常，也适合在保留客户端运行的同时临时停止代理。若切到直连后普通网站仍无法访问，问题可能位于本机 DNS、系统网络、残留代理设置或 TUN 路由，而不是远程节点。

退出客户端前建议先关闭系统代理和 TUN，再结束程序。若程序被强制终止，系统代理地址可能仍指向已经不存在的本地端口，表现为所有遵循系统代理的应用突然无法联网。此时重新启动客户端并正常关闭开关，或进入系统网络设置清理代理地址。直连模式与关闭接管并不完全相同：前者仍让连接经过内核后直连，后者则不再把相应流量送入内核。

代理组的手动、自动与故障转移

select 类型代理组由用户手动选择节点或其他子组，结果稳定、容易理解，适合主要出口。url-test 类型会定期请求测试地址，从候选节点中选择响应表现较合适的一个；测试结果只反映该测试目标，不等于所有网站的实际体验。fallback 类型按顺序检查可用性，当前项失效后切换到后续候选，适合强调连续性的场景。

自动组频繁切换时，已有连接不会一定平滑迁移，登录会话和下载任务也可能受到影响。测试间隔不宜过短，候选节点也不必无限增加。对于需要固定出口的账户或服务，选择稳定的手动组更容易保持一致。代理组中还可能嵌套其他代理组，排查时要逐层查看，避免只看到外层名称便误判最终节点。

掌握规则顺序、分流写法与 DNS 配合

规则分流是 Clash 的核心能力，也是配置出现“部分网站正常、部分网站异常”时最值得检查的部分。规则按照配置中的排列顺序逐条匹配，命中后停止继续检查。因此，范围较大的规则如果放得太靠前，可能遮住后面的精确规则。设计规则时通常先处理局域网和明确例外，再放具体域名或规则集，随后处理 IP 类规则，最后使用 MATCH 接住剩余连接。

常见规则类型怎样使用

DOMAIN 用于完整域名，适合处理单一主机；DOMAIN-SUFFIX 匹配某个域名及其子域；DOMAIN-KEYWORD 范围更宽，容易误匹配，只有在域名结构不稳定且关键词足够明确时才使用。IP-CIDR 按 IPv4 网段匹配，IP-CIDR6 对应 IPv6。GEOIP 依据 IP 地理数据库处理，RULE-SET 则引用外部或内置规则集合。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,节点选择

示例中的 no-resolve 表示匹配该 IP 规则时不为域名额外触发解析，适合明确的本地网段。实际配置应保留订阅原有规则框架，只把确有需求的例外放在合适位置。若客户端支持覆写规则，可以在订阅更新后自动合并；直接修改下载得到的配置，下一次更新很可能覆盖改动。

从连接记录反推规则问题

排查某个网站时，先清空或暂停无关应用，重新访问目标页面，再在连接记录中按域名筛选。记录通常会显示目标主机、使用的规则、策略组和链路。若命中了意外的直连规则，检查是否存在范围过大的域名后缀或地理规则；若落到 MATCH，说明前面的规则没有覆盖它；若已经命中预期代理组但最终选到 DIRECT，则继续查看该代理组当前选择。

现代网页会同时访问多个域名，主页面域名正常不代表静态资源、登录接口和图片域名都使用相同策略。只添加一个主域名规则后页面仍不完整，应从失败请求中找出关联域名，而不是盲目添加宽泛关键词。浏览器开发者工具与 Clash 连接记录可以互相对照：前者确认哪个请求失败，后者确认该请求走了什么出口。

DNS 为什么会影响规则结果

DNS 负责把域名转换为 IP 地址。若应用在流量进入 Clash 前已经自行解析并只发送 IP，基于域名的规则可能无法直接获得原始主机信息；如果解析结果受到网络环境影响，即使节点可用，也可能连接到错误地址。Clash 的 DNS 模块可以按配置处理查询，并配合 fake-ip 或 redir-host 等模式保留域名映射关系。

fake-ip 模式会向应用返回保留地址段中的临时地址，内核再根据映射找到真实域名并执行规则。它通常具有较好的域名规则识别能力，但少数局域网设备、旧应用或依赖真实 IP 的程序需要加入过滤列表。redir-host 更接近返回真实解析结果，兼容思路直观，但域名映射和连接识别方式有所不同。不要仅因为名称看起来陌生就切换模式；若当前订阅的 DNS 配置稳定，应先保持原设置。

dns:
  enable: true
  listen: 0.0.0.0:1053
  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"

这段示例展示字段关系，并不意味着所有网络环境都应使用同一上游地址。订阅配置可能采用 DoH、DoT、系统 DNS 或按域名分流的 nameserver-policy。修改前先记录原值；若改动后所有域名都无法解析，先恢复订阅默认配置，再检查 1053 等监听端口是否冲突、系统防火墙是否拦截，以及 TUN 的 DNS 劫持是否指向正确端口。

IPv6、局域网与自定义规则边界

设备拥有 IPv6 连接时，应用可能优先请求 AAAA 记录。如果配置只处理 IPv4，而系统又通过 IPv6 直连，可能出现出口不一致。是否关闭 IPv6 取决于节点、内核和本地网络是否完整支持，不应把关闭作为固定答案。更稳妥的做法是先在连接记录中确认异常请求是否使用 IPv6，再决定补充规则、调整 DNS 返回或暂时禁用相关路径。

访问路由器、NAS、打印机和开发服务器时，应确保私有地址段与本地域名直连。TUN 环境下还要保留局域网路由，避免把本地连接送往远程代理。允许局域网设备连接 Clash 本地代理属于另一项功能，它会改变监听范围；只在确有共享需求时开启，并配合防火墙限制可信网络，不要把“访问局域网”和“向局域网开放代理”混为一谈。

按需开启 TUN 接管全局流量

TUN 模式会创建虚拟网络接口，并通过路由把更多连接交给 Clash。它适合不读取系统代理的游戏、命令行工具、商店应用以及需要统一处理 TCP、UDP 流量的场景。TUN 能扩大接管范围，但不会修复失效节点、错误订阅或不合理规则。因此开启前必须先在系统代理模式下验证配置可用，并记住原有 DNS 与代理设置，便于出现异常时快速退回。

开启前的四项检查

第一，确认当前配置在规则模式下可以通过系统代理正常访问。第二，关闭其他 VPN、虚拟网卡代理和可能修改路由的网络工具，避免多个接管层互相覆盖。第三，确认客户端具备管理员权限或已安装所需服务。第四，保存正在使用的配置，并了解关闭 TUN、关闭系统代理和退出客户端的准确位置。完成这些准备后，再开启 TUN 并等待虚拟网卡初始化。

Windows 客户端常通过服务模式获得修改路由所需的权限。如果开关点击后立即复位，查看是否提示安装服务、权限不足或驱动初始化失败。macOS 可能要求安装网络扩展或辅助服务。Android 与 iOS 本身已使用系统 VPN 接口，界面中的接管实现与桌面端不同，通常不需要寻找完全相同的 TUN 开关名称。

常见 TUN 参数的意义

auto-route 用于自动添加必要路由，适合大多数桌面客户端；关闭后需要自行管理流量怎样进入虚拟网卡。auto-detect-interface 尝试识别当前实际联网接口，设备在 Wi-Fi、网线和热点间切换时较有帮助。dns-hijack 把指定的 DNS 请求交给内核 DNS 模块处理，用于减少系统 DNS 绕过。strict-route 会更严格地约束路由行为，可能改善泄漏问题，也可能影响多网卡、虚拟机和局域网访问。

stack 参数决定 TUN 网络栈实现。不同系统和客户端提供的选项可能包括 system、gVisor 或 mixed。system 通常更贴近系统网络栈，性能与兼容性取决于平台；gVisor 使用用户态网络栈，在部分环境中隔离和兼容表现不同；mixed 会按协议组合处理。没有明确故障时优先使用客户端推荐值，不必为了追求某个理论差异频繁切换。

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

该示例只展示通用结构。配置文件中的具体字段支持情况由当前内核与客户端决定，图形界面生成的配置可能还包含设备名、MTU、路由包含项和排除项。使用订阅覆写时，应确认合并结果没有重复定义 tun 区块，否则后出现的字段可能覆盖前面的设置。

开启后的验证顺序

开启 TUN 后先保持系统代理关闭，以便明确当前流量由哪条路径接管。访问一个普通网页，观察连接记录是否出现域名请求；再测试此前不遵循系统代理的应用。随后检查局域网设备、DNS 解析和常用登录服务。如果网页可用但局域网失效，重点检查私有网段路由和 strict-route；如果所有域名都无法解析但直接访问 IP 有响应，重点检查 DNS 劫持、监听端口和上游解析。

命令行可以辅助检查系统路由，但不要在不了解作用时手动删除整套路由。Windows 可使用 route print 或 PowerShell 查看接口，macOS 与 Linux 可使用 netstat -rn、route -n get 或 ip route。比较开启前后的默认路由和虚拟接口，确认流量确实进入 TUN。更完整的原理和操作路径见Clash TUN 模式开启方法。

异常时如何安全退出

若开启后网络完全中断，先关闭 TUN，等待路由恢复，再关闭系统代理并退出客户端。仍无法恢复时，重新连接 Wi-Fi 或网线，让系统重新获取地址和 DNS；随后检查系统代理是否残留、虚拟网卡是否仍启用。不要在网络断开时连续重装多个客户端，因为旧服务、旧网卡和新设置叠加后会增加判断难度。

休眠唤醒、切换网络或从公司网络回到家庭网络后，自动识别接口可能暂时保留旧路由。先切换一次 TUN 开关，让客户端重建接口。如果问题固定发生在某类网络，记录当时的物理接口、DNS、路由和日志，再决定是否使用接口排除、路由排除或不同 stack。企业 VPN 与 TUN 同时使用时尤其容易发生路由优先级冲突，通常应明确哪个工具负责哪些目标网段。

建立日常维护、排错与进阶路线

完成配置后，稳定使用依赖的是可重复的维护习惯，而不是持续调整参数。建议保留一套已经验证可用的基础状态：一个正常订阅、一组明确的代理组选择、规则模式、可工作的系统代理，以及按需启用的 TUN。每次更新客户端、订阅或自定义规则后，只检查这条基础链路是否仍成立。若多个环节同时变化，出现异常时很难回到确定状态。

日常更新分成三个层次

客户端更新、内核更新与订阅更新是三件不同的事。客户端更新改变界面、系统集成和内核管理方式；内核更新可能带来配置语法、协议与网络处理变化；订阅更新只刷新远程配置、节点和规则。遇到问题时应记录最近改变了哪一层。例如，仅更新订阅后代理组消失，应先查看新配置内容；更新客户端后 TUN 服务无法启动，则应检查权限和服务状态。

日常可以按较长的固定间隔更新订阅，并在更新后确认当前配置仍被选中。客户端升级前记下订阅地址、自定义覆写和关键设置。升级后不要立刻删除旧配置，先完成一次浏览器访问、连接记录、局域网和 TUN 测试。对于长期运行的设备，维护窗口内主动重启一次客户端，可以尽早发现服务自启动、权限或配置加载问题。

用日志和连接记录缩小范围

连接记录回答“某次请求经过了哪里”，日志则回答“内核在处理过程中发生了什么”。网站出口不对时优先看连接记录；订阅解析、端口绑定、DNS 查询、TUN 初始化和网络错误则更适合看日志。排查时先把日志级别保持在 info，通常已经包含足够信息；debug 会产生大量记录，只在需要复现短时问题时临时开启，完成后恢复。

提取日志时保留错误前后的少量上下文，并去除订阅地址、认证字段、设备标识和不必要的访问记录。常见关键词包括 timeout、connection refused、network unreachable、address already in use、parse error 和 permission denied。它们分别指向超时、目标拒绝、无路由、端口占用、配置解析和权限问题。先按错误类别处理，再考虑更换客户端。

一套稳定的故障定位树

1. 确认原始网络。关闭系统代理与 TUN，检查普通网络是否可以访问本地和常用站点。原始网络异常时先处理 Wi-Fi、网线、认证页面或系统 DNS。
2. 确认内核状态。启动客户端，检查是否有配置解析、端口占用或权限错误。内核未运行时，后续模式与节点设置都不会生效。
3. 确认配置链路。查看订阅更新时间、当前选中的配置、主要代理组和最终节点。必要时手动更新订阅，但不要连续重复请求。
4. 确认流量接管。开启系统代理并发起新请求，观察连接记录。没有记录说明应用未走系统代理或本地端口设置异常。
5. 确认规则与出口。比较规则、全局模式的结果，查看目标域名命中规则。全局可用而规则失败时，集中处理分流。
6. 最后检查 TUN。基础链路正常后再开启 TUN，分别测试 DNS、局域网、UDP 和休眠恢复，不把多个变量一次加入。

如果需要按具体症状继续排查，可进入疑难解答查找系统代理、订阅、TUN 与连接问题。描述故障时最好包含平台、客户端名称、接管方式、代理模式、是否能在连接记录看到请求以及错误类型，这些信息比一句“无法上网”更容易得到准确结论。

备份哪些内容才真正有用

值得备份的内容包括订阅地址清单、自定义规则覆写、自定义 DNS 片段、内核服务配置以及对关键设置的简短说明。若客户端支持导出设置，可以作为辅助，但不要把单一导出文件当成唯一恢复方式。不同客户端之间迁移时，最通用的仍是订阅 URL 与标准 YAML 片段。

自定义配置应附上修改原因。例如，某条域名规则用于解决哪个服务，某个局域网段为什么要排除，某项 TUN 参数针对什么网络环境。数月后重新查看时，这些说明能帮助判断规则是否仍有必要。没有原因记录的配置容易越积越多，最终出现重复、冲突和顺序难以理解的问题。

从日常使用走向进阶配置

进阶学习可以沿着连接处理顺序展开：先熟悉代理组的 select、url-test 与 fallback，再学习规则集和规则提供器，随后理解 DNS 的 fake-ip、分流解析与 IPv6，最后研究 TUN 路由、进程规则和独立内核部署。每一阶段都应有明确场景，不必一次启用所有功能。能够通过连接记录解释一条请求为何选择某个出口，比记住大量参数更重要。

需要多设备使用时，可以把稳定的自定义规则维护为单独覆写文件，减少对远程订阅主体的直接修改。服务器环境则应进一步学习最小监听范围、服务用户权限、配置目录权限、日志管理和启动失败回退。图形客户端用户也可以了解 YAML 基础，以便看懂合并结果和解析错误，但日常修改仍优先使用客户端提供的结构化入口。