Clash 常见问题与故障排查

Clash 是代理内核及相关配置生态的常用称呼；mihomo 是这一生态中持续发展的内核，早期也常被称为 Clash Meta；Clash Verge Rev 则是提供配置管理、代理切换和系统设置入口的桌面客户端。客户端界面与实际内核不是同一层，某个 YAML 字段能否使用，要看客户端搭载的内核及其版本。排查时先到关于页面记录客户端名称，再从内核信息或启动日志确认内核，避免拿另一款客户端的菜单位置直接套用。

客户端负责读取配置和转发流量，不会因为完成安装就自动获得可用的代理服务。订阅链接通常由服务方提供，用于获取节点、策略组和规则等配置内容。打开服务方的订阅页面，选择与 Clash 或 mihomo 兼容的配置链接，再到客户端配置页添加远程配置。不要把账户登录页面的网址当成订阅地址，也不要把订阅链接发到公开讨论区；链接中的访问凭据可能允许他人读取配置。只有本地配置文件时，也可以使用文件导入方式。

日常先选规则模式，让已加载配置中的规则决定流量去向。全局模式通常把已进入内核的连接交给全局策略处理，但并不等于所有应用都已被接管；仍要检查系统代理或 TUN 是否生效。直连模式让内核接收到的流量直接连接目标，适合临时比较连接表现。测试时一次只更换模式，不同时修改 DNS 或节点。若只有某个网站在全局模式能打开，优先检查规则匹配和策略组选择，而不是长期用全局模式掩盖配置问题。

系统代理把代理地址写入操作系统设置，主要影响遵循这项设置的应用；TUN 通过虚拟网络接口和路由接管符合条件的流量，通常需要额外权限。两者不必为了连接成功而全部开启。先只用系统代理验证浏览器，再根据游戏、命令行或其他应用的需求测试 TUN。部分客户端允许二者并用，但接管范围还受路由和排除设置影响。开启 TUN 后出现异常时，先关闭 TUN 做对照，确认问题属于路由接管还是代理服务本身。

先回到配置页，确认刚导入的配置已设为当前配置，而不只是保存在列表里。随后查看更新记录和内核日志，判断下载是否成功、YAML 是否被正常解析。有些配置使用 proxy-providers 单独拉取节点，主配置加载成功并不代表节点提供器也已更新，需要在提供器页面再检查一次。若服务方返回的是登录网页、错误提示或客户端不支持的订阅格式，应重新获取兼容链接。不要通过反复新建同名配置解决问题，先保留一份便于对照的配置即可。

先到服务方账户页面检查订阅是否到期、流量是否用尽，以及链接是否被重置。401 通常与身份验证有关，403 表示访问被拒绝，但具体原因仍应以服务方说明为准。重新复制完整订阅地址，去掉误带的空格和换行，再在原配置中替换链接并手动更新。若链接在其他网络可用，检查当前网络是否拦截请求。提交反馈时只保留错误码和脱敏日志，不附完整订阅地址；频繁点击更新一般不能解除服务端的访问限制。

先确认普通系统代理可以连接，再处理 TUN 的权限问题。桌面客户端通常需要安装或启动服务模式；Windows 可在客户端设置里检查服务状态，按提示授权，macOS 则需完成对应的系统授权。Linux 应依照客户端文档配置服务或所需能力，不要随意给整个目录开放写入权限。授权后重新启动客户端，查看日志是否仍有创建设备、设置路由或访问接口失败的记录。若是受管理的工作设备，应联系管理员确认权限政策，不要反复绕过系统限制。

部分采用 AppContainer 隔离的 Windows 应用，默认不能访问本机回环地址，因此浏览器可用、商店应用却失败时，可以检查回环限制。若客户端带有 UWP 回环工具，使用管理员权限打开，只勾选确实需要访问本地代理的应用，保存后完全退出并重新启动该应用。不同客户端的入口名称可能不同，没有工具时应查阅 Windows 的回环豁免说明。仅为需要的应用授权，不要直接全选；回环豁免也不能解决订阅失效、远端节点故障或应用自身的网络限制。

先遵循服务方建议的更新间隔；没有特殊要求时，可以从每日一次开始，避免过于频繁地请求订阅。远程配置更新后，直接改在远程 YAML 内的内容可能被替换，因此自定义规则、DNS 或策略调整应优先放进客户端支持的覆写或合并配置中。设置完成后手动更新一次，再查看最终生效配置，确认修改仍然存在。不同客户端的合并顺序和数组处理方式并不相同，迁移客户端时要重新检查，不能只复制覆写文件就假定结果一致。

给每份配置使用可区分的名称，例如按用途或服务来源命名，不要全部保留默认名称。需要切换时，在配置页将目标配置设为当前配置，再到代理页确认策略组和可选节点已随之变化。切换后旧连接可能暂时沿用原来的连接路径，测试前可以关闭目标应用再重新打开，或使用客户端的连接管理功能结束相关连接。确认新配置可用后再删除旧配置；删除前保存必要的本地规则，尤其注意远程订阅与本地覆写是否分别存储。

在客户端打开连接页面，然后重新访问目标网站，按域名或目标地址查找新建立的连接，查看匹配规则、策略组以及最终出站。已有连接可能不会重新匹配，所以应关闭旧页面或结束对应连接后再测试。若界面只显示 IP，结合日志确认是否发生了 DNS 解析，以及规则是否依赖域名信息。发现流量命中兜底规则时，检查目标规则是否放在兜底规则前面、规则集是否加载成功。不要仅凭代理页选中了某个节点，就认定所有网站都使用该节点。

提供操作系统、客户端名称、客户端和内核版本，以及问题发生时使用的模式、系统代理和 TUN 状态。描述一个可以重复执行的操作，例如打开哪个类型的应用后出现什么错误，并说明同一网络下其他应用是否正常。日志从一次失败操作前后截取即可，保留错误码和必要上下文。发布前隐藏订阅完整链接、访问凭据、节点密码、个人账户和不必要的公网地址。配置文件不要整份公开上传，先提取相关字段并替换敏感值，方便他人判断又减少信息暴露。

先关闭代理确认基础网络可以连接，再检查设备日期和时间是否正确，随后确认订阅状态和配置更新结果。挑选一个已知可用的节点单独测试，观察日志属于域名解析失败、连接被拒绝还是握手失败。测试地址不可达也会导致测速超时，因此要结合实际访问结果判断。若所有节点同时失败，优先检查 DNS、网络限制和本地配置；若只有一个节点失败，切换其他节点并联系服务方。保持每次只改一项设置，记录改动，避免同时切换端口、DNS 和路由后无法定位原因。

先检查客户端内核是否正在运行，再核对系统代理里的主机与端口是否对应客户端当前监听地址和混合端口，不能只看到开关开启就认为设置正确。关闭其他代理客户端和可能接管代理设置的浏览器扩展，然后重新启动浏览器测试。Firefox 等应用可能使用自己的网络设置，需要选择系统代理或填写正确的本地代理。若连接页面始终没有新记录，问题多半发生在应用到客户端之间；若已有连接记录，则继续查规则命中、策略选择和节点状态。

先关闭 TUN 做一次对照，确认基础网络和系统代理是否正常，再查看日志中的 DNS 超时、解析失败或路由错误。检查配置里的 DNS 服务是否启用、上游地址能否通过预期路径访问，以及 TUN 的 DNS 劫持设置是否与当前内核兼容。fake-ip 返回合成地址本身是正常机制，不等于配置损坏。修改解析模式或过滤规则后，清理客户端与系统 DNS 缓存，并重新建立连接。若只影响少数应用，先考虑针对相关域名设置 fake-ip 过滤，不要直接复制整套来源不明的 DNS 配置。

端口占用时先退出其他代理客户端，确认是否有旧内核进程仍在后台运行；使用系统的网络连接或进程工具识别占用者，不要直接结束不认识的系统进程。需要改混合端口时，同时更新手动填写该端口的应用设置。退出客户端后断网，先到系统网络设置确认是否残留指向本机的手动代理，关闭该项后再测试。若仍异常，检查 TUN 服务和路由是否已恢复，必要时按正常流程重启设备。下次退出前先关闭接管功能，可减少强制结束进程留下的网络设置。