Clash Verge Rev 节点连接失败怎么办?按6步排查
简答:先关闭 TUN 和其他代理工具,只保留一个配置、一个节点,开启 System Proxy 后测试;如果仍失败,再按“订阅—内核—节点—代理接管—DNS/规则—本机网络”的顺序排查。不要同时修改多个开关,先在 Connections 和 Logs 中确认请求是否进入客户端。
定义:Clash Verge Rev 节点连接失败,是指配置已导入但节点无法建立连接、请求超时,或客户端运行后网页和应用仍无法通过代理访问。
先做一分钟最小化测试:只保留一个变量
如果你只是想先恢复连接,按下面顺序操作:关闭其他代理客户端、VPN、网络加速器和虚拟网卡工具;暂时关闭 TUN;在 Profiles 中确认已有配置被选中;在 Proxies 中固定一个节点或节点组;开启 System Proxy;把模式临时切换为 Global;打开一个普通网页,再回到 Connections 查看是否出现对应请求。
这样做的目的不是证明 Global 模式一定正确,而是减少变量。如果请求出现在 Connections,说明流量已经进入客户端,下一步重点看规则、DNS或节点响应;如果完全没有请求,优先检查系统代理是否生效、应用是否遵循系统代理,或应用是否使用了自己的网络设置。项目界面中将 System Proxy 与 TUN 分开设置,TUN 用于接管更广泛的系统流量,通常还需要额外权限;不同版本菜单文字可能略有变化,应以当前界面和项目发布页为准。可参考项目设置字段说明与项目常见问题中的代理模式说明。
| 现象 | 先查什么 | 判断标准 | 下一步 |
|---|---|---|---|
| Connections 没有请求 | System Proxy、应用代理设置 | 浏览器或目标应用没有把请求交给本地代理 | 确认系统代理已开启;检查应用是否绕过系统代理 |
| 请求出现但节点 timeout | 节点、订阅状态、出口网络 | 请求进入客户端,但节点连接未完成 | 换一个节点对照,不要立即改DNS或MTU |
| 节点有延迟但网页打不开 | 实际连接、规则、DNS、TLS | 延迟测试通过不等于网页请求成功 | 看 Connections 和 Logs 中的真实错误 |
| 开启 TUN 后断网 | 权限、虚拟网卡、路由和DNS | 关闭 TUN 后普通网络恢复 | 先回滚到 System Proxy,再单独验证 TUN |
第1步:区分订阅更新失败、节点失败和代理未接管
- 订阅更新失败:在 Profiles 中刷新配置时就报错,或配置时间没有更新、节点列表为空。先确认订阅地址完整、账户状态和流量状态正常,检查系统时间是否明显错误,再用浏览器或系统网络工具确认订阅地址是否能建立 HTTPS 连接。不要把订阅地址、token、密码或 UUID 发到公开渠道。
- 单个节点失败:只有某个节点出现 timeout、connection refused 或 TLS handshake failure,而同一配置里的其他节点可以建立连接。此时更像是单节点、线路入口或节点参数问题,应记录节点名称、错误时间和脱敏日志后更换节点对照。
- 全部节点失败:所有节点都超时,或更新后的配置全部无法使用。先确认配置是否激活、内核是否运行、当前选择的代理组是否确实选中了节点,再检查本机网络、系统时间、防火墙和其他代理工具冲突。
- 代理未接管:节点延迟测试有结果,但浏览器、终端或某个应用完全没有请求记录。此时不要反复测速,应检查 System Proxy 是否开启、目标应用是否遵循系统代理,以及是否被应用自身的代理设置覆盖。
节点组的健康检查只是对节点进行测试,健康检查超时字段以毫秒计,且是否测试还取决于节点组是否被选中;因此“有延迟”只能说明某种测试完成,不能直接证明网页访问一定成功。可查看mihomo 官方代理组配置说明。
第2步:确认配置已激活,mihomo 内核正在运行
现象:Profiles 中看到了配置,但 Proxies 没有预期的节点或切换节点后没有变化。先检查当前配置是否处于激活状态,再打开客户端的内核、日志或诊断信息页面,确认核心没有退出、反复重启或配置解析错误。
- 保留原配置文件或订阅地址,不要先删除全部配置。
- 重新选择一次目标配置,等待页面状态完成后再进入 Proxies。
- 确认代理组中显示的节点名称来自当前配置,而不是旧配置残留。
- 如果日志出现 YAML、字段或配置解析错误,先恢复上一份可用备份;不要直接在不熟悉的字段上大范围修改。
- 如果客户端异常,使用设置中的备份、打开配置目录或导出诊断信息功能;这些字段在项目设置中有对应定义。
不同发行版本可能使用不同的界面布局,版本号和菜单位置不要写死;当前版本应以项目 Releases 页面和当前安装界面为准。若升级后才出现问题,先记录当前版本、操作系统和架构,再尝试回到备份配置或上一份已知可用版本,不要在未备份时直接清空配置目录。
第3步:分别测试 System Proxy、Global 和 TUN
这一步要一次只改一个变量。System Proxy 主要依赖应用遵循操作系统代理设置;TUN 在网络层接管更多系统流量,但需要服务或管理员权限。项目设置字段明确区分了这两种模式,并提示 TUN 需要相应的服务模式或管理员模式。
- 先测 System Proxy:关闭 TUN,只开启 System Proxy,固定一个节点和 Global 模式。打开目标网页后查看 Connections。若有请求且能建立连接,说明基础代理链路可能正常。
- 再测规则模式:保持节点不变,把 Global 切回 Rule。比较同一网址在 Connections 中的策略结果。如果请求被标记为 DIRECT,说明问题可能来自规则或策略组,而不一定是节点失效。
- 最后测 TUN:在 System Proxy 测试已有结果后,再关闭或保持系统代理,单独开启 TUN。首次开启可能需要管理员授权、服务模式或虚拟网卡权限;若开启后断网,先关闭 TUN或正常退出客户端,确认普通网络是否恢复。
如果只有 TUN 失败而 System Proxy 正常,优先检查权限、服务、虚拟网卡、路由和DNS,不要先固定修改 MTU。TUN 会改变系统流量路径,配置错误或残留路由可能导致网络中断;mihomo 官方文档也将 TUN 的自动路由、DNS 劫持和 MTU列为独立配置项,适用条件取决于系统和配置。可参考mihomo TUN 文档。
第4步:按报错关键词处理节点和本机网络
| 错误或现象 | 可能范围 | 先做什么 | 不要先做什么 |
|---|---|---|---|
| timeout | 节点入口、出口网络、路由或防火墙 | 固定同一配置换另一个节点;记录是否全部节点都超时 | 不要直接改MTU或反复重装 |
| connection refused | 目标端口未监听、节点参数不匹配或本地端口冲突 | 查看日志中的目标地址和端口;检查本地端口是否被其他程序占用 | 不要把任意端口改成固定值 |
| TLS handshake failure | 时间、证书校验、传输参数或中间网络 | 校准系统时间,确认配置来源和传输字段没有被改坏 | 不要关闭证书校验作为默认解法 |
| 403 | 服务端拒绝、订阅权限或目标站点响应 | 区分订阅地址返回403与节点访问目标返回403 | 不要仅凭403断定订阅失效 |
| DNS解析失败 | DNS配置、TUN劫持、系统解析器或规则 | 先在关闭TUN和开启TUN两种状态下对照;看日志是否出现DNS请求 | 不要未经验证抄用固定DNS地址 |
DNS 是否由客户端处理,取决于配置。mihomo 文档说明,关闭 DNS 功能时会使用系统 DNS;启用后还可能涉及 nameserver、fallback、proxy-server-nameserver 和规则策略。因而“能解析域名”不等于“DNS一定经过节点”,也不等于网页连接已经成功。排查时先记录当前DNS配置并备份,再只调整一个字段,测试后保留能回滚的原值。可查看mihomo 官方 DNS 配置文档。
第5步:检查本地端口、系统代理和安全软件冲突
现象:客户端显示运行,但 System Proxy 无法开启、端口被占用,或关闭客户端后网页仍然走旧代理。先检查操作系统代理设置是否仍指向本地地址,再查看客户端的 Port Config 与日志提示。项目设置字段包含 Mixed、SOCKS、HTTP(S)、Redir 和 TProxy 等监听项,并对“端口已被占用”和“启用监听端口重复”提供了错误提示。
- 关闭其他代理软件、旧客户端、VPN和可能创建虚拟网卡的工具。
- 在系统网络设置中检查是否残留手动代理;确认地址和端口与当前客户端监听配置一致。
- 如果日志提示端口已被占用,先找到占用者并关闭它,或在客户端中选择未被占用且配置允许的监听端口。
- 在 Windows 上,若只有商店应用或UWP应用不通,检查是否需要项目设置中的 UWP 工具;不要把它当作所有应用失败的通用解法。
- 测试完成后恢复原来的系统代理设置,并关闭不再使用的监听端口。
安全软件、防火墙、企业网络策略和虚拟网卡都可能改变连接结果。如果暂时停用安全软件进行对照,必须只做短时间测试并立即恢复;不要为了排查长期关闭系统防护。
第6步:按结果回滚并整理脱敏反馈
如果某一步让网络变差,先回到上一个已知可用状态:关闭 TUN、恢复 System Proxy 原设置、重新选择原配置、恢复备份文件,并正常退出客户端以便清理服务和路由。不要在网络未恢复时连续修改DNS、MTU、路由和内核版本,否则很难判断真正原因。
仍无法连接时,整理以下信息:操作系统及架构、客户端版本、内核版本、配置是否刚更新、全部节点还是单节点失败、错误关键词、是否开启 System Proxy、是否开启 TUN、Connections 中是否有请求、关闭 TUN后网络是否恢复。日志发布前应删除订阅URL、token、密码、UUID、内网地址和个人域名。项目常见问题也提醒不要直接上传包含敏感信息的完整日志;可先使用诊断导出功能,再人工脱敏。
建议使用“现象→先查什么→判断标准→处理→回滚”的格式反馈。例如:Windows 11;System Proxy 开启、TUN关闭;固定节点A;Connections有请求;日志为timeout;节点B可用;关闭客户端后系统网络正常。这比只写“节点连接失败”更容易定位。
常见问题
为什么节点测速有延迟,但网页仍然打不开?
延迟测试与真实网页请求可能使用不同的目标、协议或连接阶段。测速有结果只能说明某项测试完成,网页仍可能在DNS解析、TLS握手、规则选择、目标站点响应或应用未接管等环节失败。请以 Connections 和 Logs 中的实际请求为准,并固定同一节点进行对照。
要不要一遇到连接失败就开启 TUN?
不建议。先用关闭 TUN、开启 System Proxy 的最小化测试确认基础链路,再单独验证 TUN。TUN涉及路由、虚拟网卡、DNS和管理员权限,适合需要接管不遵循系统代理的应用时使用;开启后若断网,应先关闭 TUN或正常退出并确认网络恢复。
所有节点都 timeout,是节点全部失效了吗?
不能直接这样判断。所有节点超时也可能与订阅配置未激活、内核未运行、本机网络、系统时间、防火墙、端口占用或其他代理冲突有关。先关闭其他网络工具,确认普通网络正常,再检查配置激活状态和日志;如果只有当前订阅的节点全部失败,再向配置提供方反馈脱敏信息。
DNS失败时应该直接换成固定DNS吗?
不建议把固定DNS当作通用答案。先区分关闭TUN与开启TUN时的结果,查看客户端是否记录DNS请求,并检查当前配置中的 DNS、nameserver、fallback 和规则策略。更改前备份原配置,验证无效后恢复原值。
什么时候需要重装 Clash Verge Rev?
只有在配置备份、普通网络和权限检查都完成,且问题集中表现为程序文件损坏、安装组件异常或升级后无法启动时,才考虑重新下载安装。应从项目发布页核对来源、版本和校验信息,保留配置备份,不要把重装当作订阅失效、节点超时或规则错误的第一步。
常见问题
Clash Verge Rev 节点连接失败,最快先试什么?
关闭TUN和其他代理工具,只保留一个配置、一个节点,开启System Proxy并切换Global,然后在Connections中确认请求是否进入客户端。
节点有延迟但网页打不开怎么办?
不要只看延迟结果,检查Connections是否有真实请求、规则是否将请求处理为DIRECT、DNS是否失败,以及目标应用是否遵循系统代理。
所有节点都timeout,应该先换DNS吗?
不应先换DNS。先确认普通网络、配置激活、内核运行和系统时间,再固定同一配置更换节点;只有日志指向DNS解析时,才对照检查DNS配置。
TUN模式开启后断网怎么恢复?
先关闭TUN或正常退出客户端,确认普通网络恢复,再检查服务权限、虚拟网卡、自动路由和DNS。恢复前不要继续叠加修改MTU、路由和端口。
相关阅读
参考资料
- Clash Verge Rev 项目 Releases 页面
- Clash Verge Rev 常见问题:系统代理、TUN、Connections与日志(cvergerev.com)
- mihomo 官方 TUN 配置文档
- mihomo 官方 DNS 配置文档
- mihomo 官方代理组与健康检查文档