排查 Clash，先确定问题发生在哪一层：配置有没有成功加载、节点能不能连接、应用流量有没有进入客户端。按这个顺序检查，比同时切换模式、改端口和重装更容易找到原因。

01 / Clash、客户端和 mihomo 是什么关系？

客户端负责操作界面，内核负责处理连接。导入订阅、点击节点和开启系统代理，通常在客户端中完成；真正读取规则、连接服务器的是内核。Clash Meta 项目后来更名为 mihomo，网上的旧教程可能仍使用原来的名称。

遇到「不支持的代理类型」或「未知字段」时，不要只比较应用图标。在客户端的「关于」或内核信息页面记录名称与版本，再确认订阅是否适配该内核。旧版 Clash 能读取的配置范围，与当前 mihomo 并不完全相同。

02 / 安装完成后，为什么没有节点可选？

安装客户端不等于已经获得代理配置。节点是远端服务器的连接信息，通常由服务提供方通过订阅交付。订阅链接则是获取和更新配置的地址，不是一个打开后就能直接使用的普通网页。

  1. 从可信来源取得适用于当前客户端或内核的订阅链接，不要把账户管理页地址当作订阅。
  2. 打开客户端的「配置」页面，选择新建远程配置或从 URL 导入，粘贴完整链接。
  3. 导入成功后，选中这份配置，使它成为当前生效配置。
  4. 进入「代理」页面，展开被规则引用的策略组，再选择其中一个节点。策略组就是一组可供规则调用的连接选项。

配置列表里出现名称，不代表内核已经切换过去。如果代理页依然只有直连选项，先看当前配置的选中状态，再检查日志是否提示配置加载失败。

03 / 订阅导入失败，先检查链接还是网络？

先读错误，再决定检查方向。超时、权限错误和解析错误属于不同问题。反复点击更新通常只会重复同一条错误。

报错或现象优先检查下一步
连接超时、域名解析失败获取订阅时使用的网络路径确认普通网页能打开，再检查更新功能是否依赖一个已失效的代理
HTTP 401 或 403订阅凭据、账户状态、访问限制在服务提供方页面重新获取链接，不要反复公开测试旧链接
HTTP 404地址是否完整、接口是否变更重新复制订阅，检查是否缺少路径或查询参数
YAML 解析失败返回内容是否真的是配置检查是否返回登录页、错误页，或不受支持的订阅格式

按三步缩小范围

  1. 重新复制链接，去掉首尾空格，确认没有混入中文标点或换行。
  2. 核对服务方提供的格式选项，选择与当前内核匹配的 Clash 或 mihomo 配置。
  3. 如果现有代理已经失效，而订阅更新设置为经由代理获取，可临时改为直连更新；反之，直连无法访问订阅地址时，需要一条已可用且允许使用的获取路径。

04 / 导入成功却提示配置错误，应该改哪里？

获取成功与加载成功是两回事。客户端可能已经下载文件，但内核无法解析其中的内容。先打开「日志」，找本次加载时最早出现的配置错误，而不是只看最后一条启动失败提示。

下面两行只演示规则怎样引用组名，并不是一份完整配置：

rules:
  - DOMAIN-SUFFIX,example.com,网页代理
  - MATCH,DIRECT

这里的「网页代理」必须在配置的 proxy-groups 中存在；MATCH 表示匹配剩余流量。修改前先备份原文件。对于远程订阅，直接编辑下载后的副本可能被下次更新覆盖，长期调整应使用客户端支持的覆写或合并功能，并确认实际生效结果。

05 / 节点测速全部超时，是否说明节点都坏了？

测速超时只说明测试请求没有按时完成。它可能是节点不可达，也可能是测试网址、DNS 或配置选择出了问题。测速数字通常反映到指定测试地址的响应情况，不等于下载带宽。

  1. 先确认设备本身能访问正常的直连网站，排除断网和 Wi-Fi 登录页。
  2. 确认当前配置加载成功，并且订阅没有到期、流量没有耗尽。
  3. 手动选一个节点，访问一个获准使用的目标页面，同时查看连接和日志。
  4. 若实际访问正常但测速超时，检查测试 URL、超时时间和测试方式；若实际访问也失败，再换另一个节点比较。

用对照测试，不凭延迟大小下结论

例如，一个节点显示 80 ms，另一个显示 180 ms，只能说明它们在这次测试中的响应耗时不同，不能据此断言前者下载一定更快。若多个节点在家中网络失败、换手机热点后恢复，应优先检查本地网络路径，而不是立即重装客户端。

日志出现 connection refused 通常表示连接被拒绝；timeout 表示等待超过限制；no such host 常指向域名解析问题。记录具体目标和时间，才能区分是本地入口、远端节点还是目标网站出错。

06 / 系统代理已经打开，浏览器为什么还没变化？

系统代理只是告诉愿意遵循该设置的应用，把请求发到本机代理端口。它不会自动接管所有程序。第一步是核对系统填写的地址，与内核实际监听的地址是否一致。

  1. 在客户端设置或运行配置中查找 HTTP 端口或混合端口。混合端口可以同时接收 HTTP 与 SOCKS 代理请求。
  2. 以本机混合端口确实为 7890 为例，系统代理应指向 127.0.0.1:7890。不要把本例端口直接当成所有客户端的默认值。
  3. Windows 11 可打开「设置」→「网络和 Internet」→「代理」，检查手动代理设置；macOS 可打开「系统设置」→「网络」→ 当前连接 →「详细信息」→「代理」。
  4. 检查浏览器的代理扩展、独立代理设置，以及其他正在运行的网络工具，避免它们覆盖系统设置。

Windows PowerShell 中可以用下面的命令，直接测试本机 HTTP 代理入口。先把端口改成实际值：

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

这个命令显式指定代理，不依赖浏览器是否遵循系统代理。它只证明到该测试站点的一次请求结果：若无法连接 127.0.0.1，先查内核是否运行、端口是否正确；若已经进入客户端却访问失败，再查规则和节点。

07 / 规则、全局、直连模式应该选哪个？

日常先用规则模式，排查时再短暂切换。三种模式决定进入内核的请求如何选择出口，不决定应用流量有没有进入客户端。

规则一般从上到下匹配，命中后就采用相应策略。因此，同一个网站在规则模式下直连、在全局模式下走节点，可能是规则结果不同，不一定是客户端故障。打开「连接」查看目标域名、命中规则和实际策略链，比只看页面能否打开更有用。

08 / 什么时候需要 TUN 模式？开启后断网怎么办？

需要接入不遵循系统代理的流量时，再考虑 TUN。TUN 是虚拟网络接口，通过系统路由把符合条件的流量交给内核。它可能需要管理员权限或客户端服务模式，具体能力取决于系统、内核和配置。

开启前先验证基础链路

  1. 先用显式代理请求或浏览器确认至少一个节点能正常访问目标。
  2. 记录当前系统代理、DNS 和其他 VPN 的状态，避免同时改变多个变量。
  3. 按客户端要求安装服务或授予网络权限，再开启 TUN，观察是否创建接口、是否出现路由或权限错误。

如果开启后直连网站也打不开，先关闭 TUN，检查原网络是否恢复，再查看权限、路由冲突和 DNS 设置。DNS 是把域名换成 IP 地址的解析过程；DNS 配置异常时，可能出现连接仍在、但域名无法解析的现象。

不要把其他教程中的 fake-ip、DNS 劫持或路由字段整段粘贴进现有配置。fake-ip 是使用虚拟地址辅助域名映射的机制，是否适用要结合当前 DNS 与路由方案判断。企业网络、其他 VPN 和虚拟机网络也可能与 TUN 产生冲突。

09 / 浏览器能用，游戏或商店应用为什么不能用？

先看失败应用的连接有没有出现在客户端里。浏览器成功，只能说明浏览器这条路径可用，不能代表其他应用采用相同的代理方式。

回环豁免只处理特定应用访问本机接口的限制，不能修复过期订阅，也不能让不支持的协议突然可用。先确定应用身份和失败路径，再使用可信客户端提供的对应工具；不要为了测试而批量放开所有应用。

10 / 更新订阅或退出客户端后异常，怎样安全恢复？

先恢复上一条可用路径，再做长期修复。订阅更新可能改变节点名、策略组成员和规则；客户端退出后，系统也可能还保留指向本机端口的代理设置。这两类问题应分开处理。

订阅更新后失效

  1. 检查当前激活的是哪份配置，以及最近一次更新是否真正成功。
  2. 重新检查策略组选择。原来手动选中的节点被改名或移除后，组内结果可能变化。
  3. 查看配置加载日志；有已知可用的本地备份时，可临时切回验证，注意其中节点和凭据也可能过期。
  4. 恢复后再逐项迁移自定义规则，避免把旧规则直接覆盖到结构已经变化的新配置上。

退出后无法上网

先检查系统代理是否仍指向 127.0.0.1。客户端已经停止监听时，继续使用这个代理就会失败。关闭残留代理设置；若使用过 TUN，再确认接口和路由已经恢复。不要删除整个配置目录来代替这一步检查。

继续查阅：按问题选择入口

首次安装与导入可以接着看使用文档；需要确认字段层级、策略组引用和规则顺序时，查阅YAML 手册；常见操作问题可在FAQ 中继续查找。排查时一次只改一项，并保留修改前后的结果。