Clash 常见问题与故障排查

Clash 通常指一套代理配置语法与规则分流体系。Mihomo 是延续该配置生态的内核，负责连接代理、匹配规则、处理 DNS 和建立 TUN 接口；Clash Verge Rev、Clash Plus 等图形客户端负责订阅导入、节点选择、系统代理开关和日志查看。排障时应先区分问题位于客户端界面、内核进程、配置文件还是上游节点。

规则模式按配置文件中的 rules 从上到下匹配连接，并把流量交给指定策略组；全局模式通常把所有被 Clash 接管的连接交给同一个代理策略；直连模式则让接管到的连接直接访问目标。日常使用优先选择规则模式。只有在判断规则是否误分流时，才建议短暂切换全局模式进行对照测试。

全局模式只影响已经进入 Clash 的流量，并不等于强制接管设备上的全部连接。未遵循系统代理的程序、使用独立网络栈的游戏、部分命令行工具和局域网通信可能绕过系统代理。先确认系统代理是否开启，再检查程序自身的代理设置；需要接管更多 TCP、UDP 流量时，可在确认权限和路由配置后使用 TUN 模式。

Clash for Windows 已停止维护，现有安装仍可能运行，但不会持续获得兼容性修复和内核更新。旧配置迁移前应保留订阅地址、覆写规则和策略选择记录，再改用仍在维护的客户端。不要直接复制整个旧程序目录覆盖新客户端；不同客户端的配置存储位置、内核字段和覆写机制可能不同。

先打开订阅更新记录，确认服务器返回的是 Clash 配置而不是登录页、提示页或空内容。随后查看解析错误所在行，重点检查 proxies、proxy-groups 和 rules 的缩进与字段类型。如果订阅能正常下载但节点列表为空，可删除该订阅的本地缓存后重新导入，并确认客户端选择了刚更新的配置文件。

先在浏览器中访问订阅地址，确认返回状态正常且内容不是过期提示。地址包含临时令牌时，应从订阅提供方重新取得完整链接。若响应内容存在但客户端报解析失败，可新建一个独立配置导入，避免旧覆写继续生效；再依据日志定位具体字段。更新前能使用、更新后立即失败时，还应检查远端配置是否出现缩进错误、重复键或客户端暂不支持的字段。

先确认 Clash 内核处于运行状态，并检查系统代理地址是否指向当前监听端口。浏览器若安装了代理扩展，扩展配置可能覆盖操作系统设置，应暂时停用后复测。Windows 还要检查代理设置中是否残留旧地址；macOS 可在当前网络服务的代理页核对 HTTP 与 HTTPS 项。最后使用客户端日志确认浏览器请求是否进入内核，日志完全没有记录通常表示流量尚未被接管。

部分采用 UWP 网络隔离机制的应用不能直接访问本机回环代理，因此浏览器可用而商店应用可能连接失败。可在客户端提供的 UWP 回环工具中勾选目标应用并保存，然后重新启动该应用。只选择确实需要经过本机代理的程序；如果客户端没有回环工具，可使用 Windows 系统提供的 CheckNetIsolation 能力进行配置，并在变更后重新测试。

延迟测试只表示从当前网络到测试目标的响应情况，不能单独代表下载速度、晚高峰稳定性或目标网站可用性。应在同一测试地址、同一网络环境下比较节点，并连续测试数次观察是否频繁超时。选择节点后再进行实际网页访问和持续下载测试；若测速正常但特定网站失败，应转向规则、DNS 或目标站限制排查，而不是反复测速。

节点切换通常只影响新建连接，已经建立的长连接可能继续使用原节点。关闭并重新打开目标应用，或在客户端连接列表中终止对应连接后再测试。还要确认当前规则命中的策略组就是刚才修改的策略组；如果规则指向另一个组，修改无关分组不会产生效果。策略组使用自动选择或故障转移时，最终节点还可能由组内检测结果决定。

Clash 规则通常从上到下匹配，连接命中第一条适用规则后便不再继续检查。范围过大的 DOMAIN-SUFFIX、IP-CIDR 或规则集放得过早，可能遮蔽后面的精确规则；MATCH 是兜底规则，应位于列表末尾。修改后可在连接详情中查看实际命中的规则与策略，先用单个域名验证，再逐步扩大规则范围，避免一次调整多个条件后无法定位原因。

远端订阅更新通常会覆盖该配置的主体内容，因此不应直接在下载后的配置文件中长期维护本地修改。优先使用客户端提供的覆写、合并或脚本功能，把本地 DNS、规则和策略组变更放在独立层。策略选择能否保留取决于客户端是否按策略组名称保存状态；更改组名后往往需要重新选择。操作前应导出本地覆写，并先用副本验证合并结果。

先关闭代理验证本地网络能否直接访问常用网站，再更新订阅并确认节点信息没有过期。随后用两个以上节点交叉测试，区分单节点故障与整条网络入口故障。若所有节点都超时，检查系统时间、防火墙、其他代理软件和内核日志；若只有特定协议失败，再核对该协议所需字段。最后切换手机热点复测，可快速判断问题是否来自当前宽带或局域网。

TUN 需要创建虚拟网络接口并修改路由，因此权限要求高于普通系统代理。Windows 可重新以管理员权限启动客户端，并检查服务模式是否正确安装；macOS 需要允许客户端安装或启用网络辅助组件；Linux 应确认进程具备创建 TUN 设备和管理路由所需的权限。权限修复后先关闭其他 VPN 与虚拟网卡工具，再重新启用 TUN，避免路由和 DNS 被多个程序同时改写。

这种现象通常指向 DNS 链路。先查看日志中是否出现查询超时，再确认配置里的 nameserver、fallback 或 proxy-server-nameserver 可以从当前网络访问。使用 Fake-IP 时，还要检查增强模式、排除列表与 TUN DNS 劫持是否配套。可暂时切换到普通 DNS 配置进行对照，但不要同时改动节点和规则；若关闭 Clash 后仍无法解析，应先恢复系统网卡的 DNS 设置。

常见原因是系统代理已经恢复，但 Clash 内核尚未启动完成，系统流量因此指向暂时没有监听的本地端口。先关闭系统代理恢复直连，再检查客户端是否重复启动、配置是否能正常加载，以及内核端口是否被其他程序占用。可取消开机时自动启用系统代理，待内核启动成功后再手动开启；若客户端支持启动延迟或服务模式，也可据此调整启动顺序。