Clash Verge Rev 代理连接不上怎么解决？分层排查步骤

更新于 2026-11-01 · ghproxy.cyou

简答：Clash Verge Rev 代理连接不上时，不要先重装：先关闭 TUN 和其他代理，只保留当前配置与一个节点测试。若 Connections 没有请求，优先检查系统代理、监听端口和浏览器是否走代理；若有请求但 timeout、DNS 或 TLS 报错，再分别处理节点、解析或握手问题。

定义：Clash Verge Rev 代理连接失败，是指客户端已经启动或打开代理开关，但请求没有进入 Mihomo 内核、无法连接所选节点，或连接后无法正常解析和访问目标地址。

先做一分钟决策树：看请求有没有进入内核

本站是第三方使用指南站，不是 Clash Verge Rev 官方站。下面的判断以当前客户端界面、配置和日志为准；不同版本的菜单名称、默认端口和权限提示可能不同。

现象	优先判断	先做什么	成功标准
Connections 没有任何请求	系统代理未生效、端口不一致，或浏览器没有使用系统代理	关闭其他代理；核对系统代理地址与端口是否等于客户端当前监听值	重新打开网页后，Connections 出现请求记录
有请求，但显示 connection refused	本机端口没有监听，或端口被其他程序占用	在设置页查看当前端口，再检查该端口状态	端口处于监听状态，日志不再出现拒绝连接
有请求，但显示 timeout	节点不可达、节点选择错误，或上游链路超时	在 Proxies 页面手动换一个节点，并保持其他设置不变	同一网址可重复打开，日志显示连接建立
TUN 一打开就断网	权限、虚拟网卡、路由、DNS 或其他 VPN 冲突	先关闭 TUN，恢复系统代理模式，再单独处理 TUN	系统代理模式可用，TUN 开启后 Connections 仍有请求
只有部分应用不能用	应用可能不遵循系统代理，或规则命中 DIRECT	查看 Connections 中的进程、规则和策略组	确认该应用的请求进入客户端并命中预期策略

Clash Verge Rev 是图形界面，实际代理、规则和 DNS 处理由内置或选用的 Mihomo 内核完成；项目仓库将其定位为支持 Windows、macOS 和 Linux 的图形客户端，相关说明可查看项目仓库。

按顺序排查：配置、订阅、节点与模式

先恢复普通网络。关闭 Clash Verge Rev 的系统代理、TUN，以及其他 VPN、代理软件和浏览器代理扩展。确认关闭后普通网络可以访问。若关闭代理后仍无法联网，先处理本地网络、系统 DNS 或网络限制，不要继续修改客户端配置。
确认配置处于启用状态。进入 Profiles 或配置页面，确认目标配置已经成功导入、没有明显的 YAML 解析错误，并且当前使用的是这份配置。导入成功不等于节点可用，仍需继续测试。
检查订阅更新结果。重新更新配置，观察页面提示和 Logs。若出现 HTTP 状态码、解析失败或下载超时，先核对订阅地址是否仍有效、网络是否能访问该地址。订阅链接包含凭据时，不要粘贴到陌生的在线检测工具。
手动选择一个节点。进入 Proxies 页面，不要先依赖自动选择。选择一个节点后，用同一个网址重复测试。若多个节点都 timeout，问题更偏向订阅、上游服务或本地网络；若只有一个节点失败，先保留其他设置，换节点复测。
区分 Rule、Global 和 Direct。先使用当前配置推荐的 Rule 模式观察 Connections 中的命中规则；如果目标请求被判定为 DIRECT，客户端可能正在直连。临时切换 Global 只能用于定位，测试结束后恢复原来的模式，避免把临时结果误认为规则已经修好。

项目隐私说明指出，应用中的代理流量由 Mihomo 内核处理，并按用户配置发送到所配置的代理服务器；因此“客户端能打开”与“上游节点一定可用”是两个不同环节，排查时需要分别验证。

可参考项目隐私说明中关于代理流量、配置文件和订阅更新请求的边界描述。

系统代理与端口：最容易被忽略的一层

不要直接照抄网上常见的端口数字。Mihomo 的配置示例同时列出 port、socks-port 和 mixed-port，实际使用哪一个取决于当前配置；应以 Clash Verge Rev 设置页显示的监听端口为准。字段示例可在Mihomo 配置文档中核对。

打开客户端的设置或配置详情，记录当前 HTTP、SOCKS 或混合端口。
检查系统代理的服务器地址通常是否指向本机地址，并确认端口与客户端当前监听端口一致。若界面提供自动设置系统代理，先关闭后重新打开一次。
暂时关闭其他代理软件、浏览器代理扩展和可能覆盖系统代理的工具。
重新打开一个固定网址，同时观察 Connections。若仍没有请求，问题可能在浏览器绕过系统代理、系统代理未写入，或端口不一致。

检查端口是否被占用

Windows：在 PowerShell 中运行 Get-NetTCPConnection -LocalPort <端口>，将 <端口> 替换为客户端当前端口；也可以使用 netstat -nato | findstr :<端口>。Microsoft 文档说明这些命令可用于查看本地端口和监听状态，参考Windows TCP/IP 排查指南。
macOS 或 Linux：可用系统自带的端口查看工具检查该端口是否处于监听状态；如果不熟悉命令，优先在客户端日志中查找 port、bind、listen 或 address already in use。

如果端口被其他进程占用，不要同时修改系统代理、配置文件和 TUN。先在客户端中改用一个未被占用的端口，再让系统代理重新指向新端口，最后重复 Connections 测试。

TUN、DNS 与权限：代理模式可用后再处理

如果系统代理模式已经可以访问，而 TUN 开启后断网，说明基础配置、节点和系统代理至少已经通过了初步测试。此时先关闭 TUN，重启客户端，再一次只开启 TUN，观察是否出现权限提示、虚拟网卡错误或路由相关日志。

Windows：按当前版本提示尝试以管理员身份运行，或安装客户端提供的服务组件；同时关闭其他虚拟网卡类工具后重试。
macOS/Linux：按客户端核心设置中的授权提示完成权限操作；如果系统拒绝创建或使用虚拟接口，查看系统安全提示和 Logs。
DNS：如果日志出现 DNS、resolve、no such host 或解析超时，先关闭复杂的 DNS 覆写和自定义规则，恢复配置原有设置后测试。不要在没有确认字段和版本的情况下直接复制网上的 TUN YAML。
路由与 DNS 劫持：Mihomo 当前配置文档将 dns-mode、dns-hijack、auto-route、auto-redirect 和 strict-route 分开说明，并标注了平台差异；因此不能仅凭某个字段就推断 Windows、macOS、Linux 都有相同表现，具体以当前内核配置和日志为准。

排查 TUN 时的回滚方法是：关闭 TUN，恢复系统代理或直连模式，确认普通网页可以打开，再逐项恢复设置。若恢复后仍断网，优先检查旧 VPN 网卡、系统代理残留和 DNS 设置，而不是继续增加配置项。

日志关键词对照：看到什么就查什么

日志关键词	通常说明	下一步
`connection refused`、`bind`、`address already in use`	本地监听端口未启动或被占用	核对端口并检查监听状态，必要时更换端口
`timeout`、`i/o timeout`	连接上游节点超时，或节点、网络链路不可达	固定网址并更换节点复测，不要同时改 DNS 和规则
`DNS`、`resolve`、`no such host`	域名解析阶段失败	暂时恢复默认 DNS 配置，检查 TUN 与 DNS 设置
`TLS handshake`、`certificate`	加密握手或证书校验阶段异常	确认系统时间、节点协议和配置是否匹配，不要直接关闭安全校验
`401`、`403`	订阅或上游服务返回权限类状态	核对订阅授权、地址和有效性，必要时联系服务提供方
有请求但策略为 `DIRECT`	规则将目标判为直连	查看规则顺序和策略组，不要只看客户端是否显示已连接

请在 Logs 和 Connections 中同时观察：Connections 说明请求是否进入内核，Logs 更适合定位端口、DNS、TLS 和上游连接错误。分享截图或日志前，应删除订阅地址、访问令牌、私钥、内网地址和个人路径。

三个高频场景的最短处理路径

场景一：代理开关已打开，但浏览器仍直连

先确认系统代理开关已启用，再核对系统代理端口与客户端当前端口；关闭浏览器代理扩展和其他代理程序后重启浏览器。打开网页时观察 Connections：没有记录就继续查系统代理或浏览器代理行为，有记录但命中 DIRECT 则查规则。

场景二：浏览器能用，但命令行或某个应用不能用

这通常不能直接证明客户端故障。先确认该应用是否支持系统代理；若不支持，单独配置应用支持的代理入口，或在基础系统代理可用后再考虑 TUN。每次只改变一个模式，并用 Connections 验证该应用的请求是否真的进入内核。

场景三：TUN 一开就断网

立即关闭 TUN，恢复系统代理模式并确认网络恢复。然后检查权限、服务组件、虚拟网卡、其他 VPN、DNS 与路由日志；不要把多个 TUN 字段一次性复制进配置。若系统代理模式始终正常而 TUN 始终失败，应保留日志和当前版本信息，按项目发布页核对变更后再决定是否升级或回滚。

排查完成后的验证清单

关闭其他代理和 VPN 后，普通网络可以正常访问。
当前配置成功导入并处于启用状态。
Proxies 页面已手动选择可测试的节点。
系统代理地址和端口与当前客户端监听值一致。
固定同一个网址重复测试，Connections 能看到请求。
Logs 中没有持续出现端口拒绝、DNS 失败或 TLS 握手错误。
分别验证浏览器和实际出问题的应用，不把客户端显示“已启动”当作最终成功标准。
如果启用了 TUN，关闭后能回滚到可用的系统代理模式。

只有“请求进入内核、命中预期规则、节点建立连接、目标应用实际成功访问”同时满足，才能认为这次排查完成。

常见问题

Clash Verge Rev 代理开关打开了，为什么网页还是打不开？

先看 Connections 是否出现请求。没有请求时，优先核对系统代理开关、地址和端口，并关闭其他代理或浏览器代理扩展；有请求但打不开，再查看命中的规则、节点和日志。

Clash Verge Rev 的代理端口应该填多少？

不要固定照抄某个数字。进入当前配置或设置页面查看实际监听端口，再让系统代理使用相同端口。Mihomo 同时存在 HTTP、SOCKS 和 mixed-port 等字段，具体以当前配置为准。

TUN 模式一开启就断网怎么办？

先关闭 TUN，确认系统代理模式可以联网，再检查权限、服务组件、虚拟网卡、其他 VPN、DNS 和路由日志。不要同时修改多个 TUN 字段；每次只恢复一个设置并观察 Connections。

节点显示可用，但访问网页仍然失败怎么办？

节点延迟或可用标记不能代替实际访问测试。固定一个网址，手动选择节点，观察 Connections 和 Logs；如果命中 DIRECT，查规则；如果 timeout，换节点并检查上游连接。

需要马上重装 Clash Verge Rev 吗？

通常不应把重装作为第一步。重装无法直接修复失效订阅、错误规则、DNS、端口占用或上游节点问题，还可能让原有日志和配置更难保留。先导出或备份配置，再按端口、请求、节点、TUN 的顺序排查。