Clash Verge 常见问题

Clash Verge 是桌面代理客户端的项目名称，Clash Verge Rev 是延续这一使用方式的社区项目；两者不是同一条发布线，安装包和维护状态应分别确认。Mihomo 是负责协议连接、规则匹配和 DNS 处理的内核，图形客户端负责订阅管理、系统代理、设置与日志展示。查问题时先在客户端的关于或设置页面记录完整名称，再记录内核信息，不要只写 Clash。桌面客户端也不等于手机应用，Android 与 iOS 需要选择各自平台的客户端，并确认其支持的订阅格式。

客户端本身用于读取配置和转发流量，安装完成不会自动获得可用的代理服务。通常需要从有权使用的服务方取得订阅地址，或自行准备包含代理节点和策略组的配置文件。订阅导入成功仅说明内容已被读取，不代表账户仍有效，也不代表每个节点都可连接。首次使用应先确认订阅状态、选择一个可用策略组，再开启系统代理并测试目标网站。订阅地址可能包含账户标识，应按敏感信息保管；排查时不要把完整地址、二维码或未经处理的配置文件公开发送。

规则模式按配置中的规则顺序，为连接选择直连、拒绝或某个代理策略组；全局模式把进入内核的连接交给全局策略组处理；直连模式则让进入内核的连接直接访问目标。全局模式不等于接管整台设备的所有流量，是否进入内核仍由系统代理、应用代理或 TUN 等入口决定。日常分流通常使用规则模式，临时排查可以切到全局并明确选择可用节点，再恢复原模式。切换后建议重新建立连接，已有的长连接未必随设置立即改变出口；DNS 查询也需要结合 DNS 配置单独判断。

系统代理向操作系统登记本地代理地址，适合遵循该设置的浏览器和应用；部分游戏、命令行工具或自带网络栈的应用不会读取它。TUN 通过虚拟网络接口和路由接管符合配置条件的流量，覆盖范围更广，但涉及权限、路由和 DNS，配置成本也更高。初次配置可先使用系统代理确认订阅与节点正常，再按应用需求启用 TUN。两者可以共存，但不应把同时开启当作故障修复的固定步骤。若设备还运行其他 VPN 或网络接管工具，应先停用其中一套，避免路由相互覆盖。

先区分下载失败与解析失败：请求超时、认证失败或 HTTP 403 通常指向网络、账户或服务端限制；YAML 解析错误则说明取回的内容不是客户端能读取的配置。检查地址是否复制完整、账户是否到期，以及服务方是否更换了订阅入口。若返回的是登录网页或错误页，反复导入不会解决问题；HTTP 403 也不一定表示账户到期，需要结合服务方说明判断。订阅只能经代理访问时，可在已有可用连接下更新，具体取决于客户端的更新设置。不要将私密订阅交给来源不明的在线转换服务。

先查操作系统显示的处理器架构，而不是只看设备品牌。Windows 常见的 Intel 或 AMD 电脑通常使用 x64 包，ARM 设备应先确认客户端是否提供匹配版本及系统的兼容运行能力；macOS 在关于本机中区分 Apple 芯片与 Intel，再选对应安装包。Linux 的 amd64 与 arm64 是架构，deb 与 rpm 是发行版的包格式，两者不能相互替代。遇到无法执行或依赖缺失时，先核对架构、发行版和系统要求，再考虑重新安装。不要用关闭系统安全防护的方式处理来源或兼容性不明的安装包。

先查看日志中失败的是服务启动、虚拟网卡创建还是路由设置，不要只依据开关是否回弹判断。Windows 可检查客户端所需的服务模式是否安装并正在运行，安装或修复服务时通常需要管理员授权；macOS 应完成系统要求的授权流程；Linux 需按客户端说明配置服务或所需网络权限。完成授权后重新启动内核再测试。若日志提示设备被占用或路由冲突，先停止其他 VPN、旧代理服务或重复运行的客户端。权限需求随系统和客户端版本变化，不建议为解决一个错误长期以最高权限运行所有程序。

开机自启只表示登录系统后启动客户端，不等于网络已就绪、订阅已更新或 TUN 服务已启动。先在手动启动时确认当前配置、策略组选择和代理入口都能正常工作，再开启自启；静默启动通常只控制窗口是否显示，不负责修复连接。重启后检查任务栏或菜单栏中的运行状态、服务状态与日志时间，确认不是窗口关闭但进程仍在，或进程根本没有启动。若订阅更新早于网络连接，可以在联网后手动更新并重试。离开客户端前也要确认系统代理的退出恢复行为，避免留下指向未运行端口的设置。

规则通常从上向下匹配，命中后采用对应策略；写在兜底 MATCH 后面的规则一般没有机会执行。先在连接记录中查看目标域名、命中的规则和实际策略，再判断应使用域名规则、IP 规则还是规则集。规则末尾引用的策略组名称必须与配置完全一致，修改后还要确认配置已重新加载。不要只看浏览器地址栏，页面可能连接多个资源域名，且旧连接可能继续使用原策略。需要长期保留的规则应写入客户端支持的覆写或合并机制，并确认插入位置；直接改订阅生成文件的内容，下一次更新可能被替换。

订阅更新会重新获取远程配置，直接写入这份文件的修改可能被新内容覆盖。节点或策略组重命名后，原先保存的选择也可能找不到对应项，于是回到默认选择。先区分需要保留的是自定义规则、DNS 字段还是策略组结构，再使用当前客户端提供的覆写、合并或脚本机制处理，并确认这些机制的执行顺序。修改前保存可恢复的副本，更新后检查最终生效配置，而不只是编辑器中的源文件。恢复时应逐项合并，避免把旧节点信息、过期规则集地址或不再受支持的字段整体覆盖回新配置。

fake-ip 是一种 DNS 应答与连接映射方式，不等于所有 DNS 请求都已被接管。应分别检查系统 DNS、浏览器的安全 DNS、客户端的 DNS 监听与上游解析设置，以及 TUN 的 DNS 接管范围。测试时先记录预期使用的解析服务，再对照日志和实际查询路径；测试网站显示的解析器所在地，不能单独证明发生泄漏。浏览器自带的加密 DNS 可能绕过系统解析，但其连接仍可能经过代理，需按实际路由判断。建议一次只调整一个入口，清理应用 DNS 缓存并重新连接，避免同时修改多处后无法确认原因。

其他设备应填写运行客户端的电脑在当前局域网中的 IP 地址，以及客户端实际监听的代理端口，不能填写 127.0.0.1，因为这个地址在每台设备上都指向自身。先确认允许局域网连接已开启、监听地址允许外部设备访问，两台设备处于可互通的网络，再检查防火墙是否仅对可信网段放行该端口。访客 Wi-Fi 或无线隔离可能阻止设备互访，电脑休眠也会中断连接。建议仅在可信局域网使用，避免把代理端口暴露到公网；不再使用时关闭共享。客户端端口若有改动，其他设备上的设置也需要同步更新。

先在客户端连接记录中观察目标请求是否出现。完全没有记录时，检查内核是否运行、系统登记的地址和端口是否与客户端一致，以及应用是否使用自己的代理设置、浏览器扩展或绕过列表。命令行工具可能需要单独设置代理参数，不能用它是否连通来直接判断系统代理失效。若已经有连接记录，应查看命中规则与策略，问题可能是规则选择了直连，而非代理入口失效。修改后重新建立连接再测试。还要排查其他代理工具是否反复覆盖系统设置；不要同时开多个客户端争用相同端口或控制同一套代理设置。

先关闭代理入口，确认基础网络能访问平时可直连的站点，再检查订阅是否有效、系统时间是否准确。测速超时可能仅表示测试地址不可达，不能单独证明节点已经失效；应结合实际网站访问与内核日志判断。选择一个已知可用的节点，临时用全局模式测试，并观察报错发生在域名解析、连接建立还是协议握手。只有个别节点失败时优先检查节点或服务状态，全部失败时再检查本地端口、DNS、网络限制与其他 VPN 冲突。每次只改一项并保留原值，避免用连续重装掩盖可重复定位的问题。

部分采用 AppContainer 隔离的 Windows 应用不能默认访问本机回环地址，因此浏览器正常并不代表这些应用能连接 127.0.0.1 上的代理。先确认目标应用属于这种情况，再用管理员终端运行 CheckNetIsolation LoopbackExempt -s 查看现有豁免。可通过 Get-AppxPackage 查询目标应用的 PackageFamilyName，然后使用 CheckNetIsolation LoopbackExempt -a -n= 加上该包族名称，仅为需要的应用添加豁免，完成后重新打开应用测试。也可评估使用 TUN 接管其流量，但并非所有联网失败都由回环限制引起。企业设备应先遵循管理策略，不要批量豁免所有应用。

不应把忽略证书警告作为常规解决办法，也不要为继续访问而安装来源不明的根证书。先检查系统日期、时区和时间同步，再比较关闭代理后的同一网站表现。只有代理开启时出错，可检查是否存在 HTTPS 解密工具、安全软件的加密流量扫描、错误的 DNS 结果或需要网页登录的网络门户。普通代理转发通常不需要替换目标网站的证书；若多个网站都显示同一个陌生签发者，应停止敏感操作并检查证书链。若仅单站失败且不同网络都可复现，可能是站点自身证书异常，应等待站点修复，而不是降低浏览器验证要求。