Clash 常见问题

Clash 最初是负责连接、规则匹配与 DNS 处理的代理内核；Clash Meta 是在其基础上扩展功能的分支，后来以 mihomo 名称继续发展。Clash Verge Rev 等桌面客户端在内核之外提供图形界面、配置管理和系统集成。同一份订阅能否使用，主要看内核支持的协议与配置字段，而不是界面是否相似。遇到未知字段或不支持协议的错误，先查看客户端的内核信息，再对照配置要求；只更换界面主题不会改变协议兼容性。

客户端负责读取配置并执行转发，不会因安装完成就自动获得可用的代理服务。通常还需要服务提供方给出的订阅地址，或包含服务器信息、认证参数与规则的配置文件。先确认配置适用于当前内核，导入并选为活动配置，再选择策略组和流量接管方式。软件许可与代理服务费用是两回事，具体取决于所选项目和服务提供方。订阅地址常带访问凭据，应像密码一样保管；排查问题时遮盖地址、用户名和认证内容，不要把完整配置发到公开讨论区。

系统代理把代理地址写入操作系统设置，主要影响主动读取该设置的应用；部分游戏、命令行程序或自行管理网络的应用可能不采用它。TUN 模式通过虚拟网络接口和路由接管流量，通常能覆盖更多应用，也更依赖系统权限、路由及 DNS 设置。日常浏览可以先用系统代理，确认连接正常后再按应用需求测试 TUN。TUN 并不代表所有连接必然经过代理，最终去向仍受规则、排除路由和客户端实现影响。两种方式可以由客户端协调使用，但不宜叠加多套代理软件接管网络。

先按操作系统与处理器架构筛选，再比较配置兼容性和系统集成功能。本站在 Windows、macOS、Android 与 iOS 优先列出 Clash Plus；Linux 可从 Clash Verge Rev 或 FlClash 开始比较。需要沿用现有 mihomo 配置时，重点确认目标客户端的内核及导入格式，不要只按名称判断。iOS 的 Clash Plus 可通过 App Store 获取，官网为 clashplus.io。迁移前保留原配置和规则，先在新客户端验证订阅、DNS 与常用应用，再停用旧客户端，避免两个客户端同时写入系统代理。

Windows 可在设置的系统信息中查看系统类型；macOS 在关于本机中查看芯片或处理器；Android 可通过设备信息或厂商规格确认架构。x64、AMD64 通常指同一类架构，ARM64 安装包则面向对应设备；macOS 的 Apple Silicon 与 Intel 包也应区分。不要仅凭文件大小选择安装包。安装失败时先记录完整提示，检查系统最低要求、剩余空间以及是否仍有旧进程运行。系统安全提示应结合下载来源和项目说明判断，不要为运行安装包而长期关闭系统防护或随意修改安全策略。

先核对订阅地址是否完整，清除复制时带入的空格、换行和末尾标点，再查看更新日志中的具体错误。401 或 403 通常涉及认证、权限或访问限制，404 可能表示地址已变更；返回网页而非配置内容时，需要向提供方确认专用订阅入口。连接超时则先检查基础网络和更新请求的出站方式。若日志提示配置解析失败，应确认订阅格式适配当前客户端与内核。不要反复导入同一条失效地址，也不要把私人订阅提交给不明转换网站；凭据泄露时应在服务端重置订阅地址。

先关闭 TUN，确认普通代理连接可用，再查看日志中关于服务、虚拟网卡或路由创建的报错。Windows 桌面客户端常需要安装或修复服务模式，具体按该客户端说明操作；macOS 应完成系统请求的网络扩展或 VPN 授权；Linux 需具备创建 TUN 接口和修改路由所需的权限。Android 通常会弹出 VPN 连接授权，应确认请求来自正在使用的客户端。已有 VPN、旧虚拟网卡或安全软件也可能冲突。每次只调整一项并重试，避免直接用长期管理员运行代替权限问题的定位。

部分采用应用容器隔离的 Windows 应用不能直接访问本机回环代理，因此可能出现浏览器正常、某个商店应用失败的情况；并非所有商店应用都属于这一情形。先确认该应用是否使用系统代理，并查看客户端是否记录到它的连接。若确属回环限制，可使用客户端提供的 UWP 回环豁免工具，仅为需要的应用授权；相关操作通常要求管理员权限。修改后重启目标应用再测试。若仍失败，应继续检查应用自身网络设置、DNS 和规则，也可在兼容条件下测试 TUN，不要给全部应用一概放开权限。

日常使用通常从规则模式开始，让连接按配置中的规则分流。全局模式把连接交给全局策略处理，实际出口取决于该策略当前选择；适合短时比较问题是否与分流有关，不等于必然选择某个代理服务器。直连模式一般让连接直接访问目标，不经过代理出口。切换模式后，新连接会按新策略处理，但现有长连接未必立即重建，测试时应重开目标应用或在确认影响范围后关闭相关连接。模式名称相同也不保证不同客户端的界面位置相同，排查时同时核对模式和策略组的实际选项。

优先使用客户端提供的覆写、合并或持久化规则功能，避免直接修改订阅生成文件后被下一次更新覆盖。规则通常从上往下匹配，较具体的域名规则应放在可能提前命中的宽泛规则之前，兜底 MATCH 一般位于末尾。添加后检查 YAML 缩进、规则类型、策略组名称及大小写，并确认重载的是当前活动配置。域名规则还依赖客户端能否识别连接域名；只看到目标 IP 时，匹配结果可能不同。用连接记录核对命中规则与实际出口，比反复刷新网页更容易判断规则究竟有没有被读取。

把启动客户端、启动代理内核和开启系统代理看作三个独立环节，逐一确认客户端支持哪些选项。先在手动启动时保存可用配置，再开启登录启动，并检查是否有重复的系统启动项。若登录后网络暂时不可用，可能是系统代理已写入而内核尚未就绪，或网络尚未建立就触发了订阅更新。可按客户端能力使用启动延迟，减少多个网络工具同时启动，并查看启动日志。不要把私人订阅地址写进公开脚本。取消自启或卸载前，先正常退出客户端并关闭系统代理，避免留下指向本机失效端口的设置。

延迟测试通常只反映到某个测试地址的一次请求耗时，并不等于持续下载带宽，也不代表所有网站的访问体验。目标站位置、服务器负载、线路拥塞、丢包以及策略组选择都会影响实际速度。先确认网页连接确实使用了被测试的出口，再用同一目标、同一网络和相近时间比较，避免同时运行多个测速任务。若只有特定网站慢，检查该域名命中的规则、DNS 结果和目标服务状态；若所有连接都慢，再换出口或换基础网络对照。不要仅凭单次延迟结果调整大量 DNS 与 TUN 参数。

先关闭代理确认基础网络能访问正常服务，再查看订阅是否成功更新、认证是否仍有效，以及系统时间是否准确。随后用实际网页请求配合连接日志测试；如果网页可用而延迟测试超时，可能只是测试地址不可达或不适配当前线路，不应立即判定全部节点失效。若实际请求也失败，记录超时、认证错误或 TLS 错误等具体信息，再尝试另一个出口和另一种基础网络。全部出口同时失败时，应优先排查订阅状态、本机防火墙和网络环境。每次只改变一个条件，保留错误信息，方便向服务提供方说明问题。

先在客户端确认内核正在运行，并核对系统代理中的地址与端口是否对应实际监听值；不要把其他教程里的端口直接当作本机设置。接着查看连接列表，判断目标应用的请求是否进入客户端。浏览器扩展、独立代理设置和某些命令行工具的环境变量都可能覆盖系统代理，部分应用则根本不读取系统设置。可先用支持显式代理的工具进行单次测试，再决定为应用单独配置代理还是启用 TUN。若退出客户端后网络仍异常，检查系统中是否残留本机代理地址，并清理过时的代理环境变量后重新启动终端。

先明确希望哪些域名通过哪条路径解析，再检查客户端 DNS、系统 DNS、浏览器安全 DNS 和其他 VPN 是否各自接管了解析。测试网站显示的解析器位置只能作为线索，不能单独证明泄漏；还需结合配置、日志与必要的网络抓包判断查询实际去向。Fake-IP 通过返回映射地址帮助内核关联域名与连接，不是加密 DNS 的同义词，也不是每个场景都必须开启。遇到局域网设备发现或特定应用兼容问题，可按文档设置例外。修改解析模式后清理相关缓存并重启应用，再用相同请求复测，避免把旧缓存当成新结果。

先在客户端关闭 TUN 和系统代理，正常退出后检查基础网络是否恢复；如果客户端异常退出，应检查系统残留的代理设置和仍在运行的服务进程。确认只保留一个 VPN 或流量接管工具，再检查 DNS、路由和虚拟网卡是否存在冲突。重新打开客户端时先测试系统代理，正常后再单独启用 TUN，并观察创建接口、设置路由和 DNS 的日志。若基础网络仍不可用，可重连网络或重启设备后复测。不要一开始就删除全部网卡、清空路由或执行来源不明的网络重置命令，这些操作可能影响远程连接和其他工作网络。