Clash Verge Rev 无法连接怎么办？按症状逐层排查
简答：先不要急着重装：关闭 TUN、其他 VPN 和浏览器代理扩展，只保留 Clash Verge Rev 的系统代理，确认普通网络正常后测试一个节点。若仍无法连接，再按“订阅是否成功→配置是否激活→节点是否超时→端口是否监听→应用是否接管→TUN 是否冲突”的顺序排查。端口、版本和菜单名称可能随当前版本变化，以下以 2026 年 11 月 2 日检索到的项目资料和当前界面为准。
定义：Clash Verge Rev 是一个运行在 Windows、macOS 和 Linux 上的图形化网络客户端，内置 Mihomo 内核，并提供配置管理、系统代理和 TUN 虚拟网卡模式。
先做这三步：最快判断故障在哪一层
如果 Clash Verge Rev 已打开但网页或应用无法访问，先做最小化测试。不要同时开启 TUN、系统代理、浏览器代理扩展和其他网络工具，否则多个组件可能反复修改系统代理或路由，导致界面显示已开启但实际流量没有经过当前客户端。
- 关闭复杂接管：暂时关闭 TUN、其他 VPN、浏览器代理扩展和旧的代理客户端，只保留 Clash Verge Rev。
- 确认直连网络：关闭系统代理后，确认普通网页、局域网或其他已知可用服务能够正常访问。若直连本身失败，应先检查 Wi-Fi、网线、路由器、DNS 或系统网络。
- 只测一个节点：在 Profiles 中确认配置已成功更新并被激活，在 Proxies 中选择一个节点，先开启 System Proxy，再测试浏览器。
项目源码说明，系统代理会修改操作系统代理设置；TUN 则是虚拟网卡模式，接管范围更大，而且需要服务模式或管理员权限。首次排查时优先使用系统代理，成功后再考虑 TUN。可参考 项目界面配置说明 与 项目仓库说明。
| 现象 | 优先检查 | 第一步动作 |
|---|---|---|
| 订阅更新失败或配置为空 | 地址、权限、HTTP 状态码、解析错误 | 重新核对订阅地址，避免在公开场合粘贴含令牌的链接 |
| 所有节点都是 Timeout | 直连网络、订阅有效期、节点服务端、DNS | 换一个节点并查看 Logs，区分全部失败还是单节点失败 |
| 节点有延迟但网页打不开 | 系统代理、代理端口、规则模式、DNS | 确认当前端口与系统代理设置一致 |
| 浏览器能用，某个应用不能用 | 应用是否读取系统代理、回环限制、应用独立代理 | 先在该应用内检查代理设置，再决定是否测试 TUN |
| 开启 TUN 后断网 | 权限、服务、虚拟网卡、路由、防火墙、DNS | 关闭 TUN，恢复系统代理测试，确认节点可用后再逐项开启 |
按正确顺序检查订阅、配置和节点
第一步是确认订阅更新成功。进入 Profiles 或配置列表，查看最近更新时间、HTTP 状态和是否出现解析错误。401、403 通常意味着访问凭据或权限未通过，但不能仅凭状态码判断具体原因；应回到订阅提供方确认链接是否仍有效、是否要求特定请求头，以及账户权限是否发生变化。
如果页面提示 parse、YAML 或配置格式错误，先保留原配置，不要直接覆盖。可以重新获取一份授权配置，或使用客户端提供的配置校验功能。配置文件中可能包含节点地址、密码、令牌和策略信息，截图 Logs 或分享配置前应遮盖这些内容。
第二步是确认配置已激活。配置下载成功不等于当前内核正在使用它。检查当前选中的 Profile、代理组和节点选择；如果代理组仍为 DIRECT，网页请求可能没有经过节点。可以暂时使用 Global 做单目标测试，再切回 Rule。三种模式的用途不同：
- Direct：用于确认客户端关闭代理后的直连情况，不能用来证明节点可用。
- Rule：按配置规则决定直连或代理，适合日常使用，但某个目标打不开时要结合 Connections 判断实际走向。
- Global：尽量让目标统一经过当前选择的代理，适合短时间排除规则匹配问题。
第三步是区分单节点故障和整体故障。只有一个节点 Timeout，优先怀疑该节点或其协议参数；所有节点同时失败，则应优先检查订阅、直连网络、系统时间、DNS、端口和内核状态。延迟测试有结果也不代表网页请求一定成功，最终应以 Connections 或 Logs 中的实际请求记录为准。
系统代理、端口和内核：网页不走代理时这样查
Clash Verge Rev 需要有正在运行的 Mihomo 内核，系统代理也必须指向当前配置使用的本机代理地址和端口。不要把常见示例端口当成固定值；项目配置或界面显示的当前端口才是有效值。官方项目界面文件明确区分了 System Proxy 和 TUN，并说明系统代理失败时可以手动检查操作系统代理设置。参见 项目设置字段。
- 在 Clash Verge Rev 中确认内核处于运行状态，当前 Profile 已激活。
- 记录当前 HTTP、SOCKS 或 mixed port 的实际数值，不要直接套用网上示例。
- 关闭其他会修改系统代理的程序，再重新启用 System Proxy。
- 在系统代理设置中核对代理主机是否为本机地址，端口是否与客户端当前端口一致。
- 打开 Connections 或 Logs，观察浏览器发起请求后是否出现连接记录。
Windows
可以在 PowerShell 中查看本机端口是否有监听：
Get-NetTCPConnection -State Listen | Where-Object {$_.LocalPort -eq 端口号}
如果没有结果，说明该端口当前没有 TCP 监听，先回到内核、Profile 或端口配置检查；如果提示端口已被占用，可使用：
Get-NetTCPConnection -LocalPort 端口号 | Select-Object LocalAddress,LocalPort,OwningProcess
再根据进程号确认占用者。不要在不清楚进程用途时直接结束系统进程。
macOS
在终端执行：
lsof -nP -iTCP:端口号 -sTCP:LISTEN
若没有输出，说明没有程序监听该端口；若输出的进程不是当前客户端或其内核，应先关闭冲突程序，再重新启用系统代理。
Linux
在终端执行：
ss -ltnp | grep :端口号
若系统没有权限显示进程信息，可在确认命令适用于当前发行版后使用管理员权限重试。排查完成后，恢复原有代理设置，避免把测试端口长期暴露到局域网。
日志关键词怎么判读：不要只看“连接失败”
日志应与实际操作同时观察：先打开 Logs 或 Connections，再访问一个明确目标，最后看是否出现请求、使用的策略和失败原因。以下是通用分流，不代表每个版本都会使用完全相同的文字。
| 关键词或现象 | 常见指向 | 建议动作 |
|---|---|---|
| 401 | 身份验证或订阅权限未通过 | 核对账户、授权状态和订阅地址，不公开分享完整链接 |
| 403 | 请求被服务端拒绝或权限不足 | 确认订阅来源、访问限制和请求要求，以当前服务说明为准 |
| parse / YAML | 配置格式无法解析 | 重新获取配置，保留旧文件，检查是否被截断或混入非配置文本 |
| connection refused / port already in use | 目标端口拒绝连接或本机端口冲突 | 区分远端节点端口与本机代理端口，检查监听进程 |
| TLS handshake failure | 加密握手、时间、协议或链路兼容性异常 | 确认系统时间，换一个节点，查看当前内核支持情况 |
| DNS failed | 域名解析链路异常 | 先关闭 TUN 测试系统代理，再检查 DNS 覆盖和规则 |
| 没有任何 Connections 记录 | 请求没有进入客户端 | 检查浏览器代理、系统代理地址、端口和应用是否绕过代理 |
如果日志显示请求使用 DIRECT，说明规则或模式没有让它经过节点；如果请求进入客户端但节点 Timeout，则更接近节点、协议或远端链路问题。项目隐私说明也提醒，配置更新会访问你提供的远程 Profile 地址，因此订阅地址和日志应按敏感信息处理，参见 项目隐私说明。
TUN 开启后断网：按权限、服务、网卡和 DNS 回退
TUN 会在网络层接管更多流量，不同于只处理系统代理的本机端口，因此更容易受到管理员权限、服务状态、虚拟网卡、防火墙、路由和 DNS 配置影响。项目界面说明中写明，TUN 需要 Service Mode 或 Admin Mode；如果服务不可用，TUN 可能无法启用。相关字段可在 项目设置说明 中核对。
- 先关闭 TUN：确认关闭后系统网络能够恢复。如果仍无法联网，检查系统代理是否残留，或重启网络适配器；不要先删除全部配置。
- 确认节点已可用：先用 System Proxy 成功访问，再测试 TUN。未确认节点可用时直接开 TUN，会把节点问题和路由问题混在一起。
- 确认服务和权限：Windows 检查管理员授权与服务状态；macOS 和 Linux 检查系统是否允许相关网络扩展或服务运行。菜单名称可能随版本变化，以当前界面为准。
- 检查防火墙：Mihomo 官方文档指出，某些 TUN 协议栈在防火墙开启时可能需要放行内核或 TUN 网卡流量。可参考 Mihomo TUN 文档，只放行确认属于当前客户端的程序。
- 检查 DNS 与路由：如果 TUN 一开就出现域名全部无法解析，先回退到系统代理，再逐项检查 DNS Hijack、DNS Mode、Auto Route、Strict Route 和 MTU。除非知道配置含义，不要一次修改多个字段。
如果修改后仍然断网，记录系统、客户端版本、内核状态、TUN 开关前后现象和脱敏日志，然后恢复到“关闭 TUN、仅系统代理”的可回退状态。删除或重置配置可能影响关联设置，必须按客户端提示操作。
什么时候不该继续折腾：停止条件与安全清单
出现以下情况时，建议先停止下载、付款或继续导入，等待来源和账户信息互相印证：
- 下载页面无法与项目发布页或可核验仓库对应。
- 订阅域名、账户状态、套餐条款或客服渠道无法确认。
- 配置文件要求在普通浏览器中公开打开含令牌的链接。
- 来源要求关闭系统安全软件、执行不明脚本或授予与排障无关的高权限。
- 同一配置在多个客户端都失败，但没有明确的服务端状态或错误说明。
排障前建议备份配置文件，但备份文件也应放在受控位置。对外求助时，只提供系统、客户端大致版本、错误关键词和脱敏截图，不要提供订阅 URL、密码、节点凭据、外部控制器密钥或完整配置。
Clash Verge Rev 无法连接的最终验收标准
完成修复后，不要只看客户端开关是否变绿，至少完成以下闭环：
- 普通直连网络在关闭客户端时正常。
- Profile 能成功更新，当前配置已激活，且没有 parse、401 或 403 等未解释错误。
- 至少一个节点能建立连接，Logs 或 Connections 中出现实际请求。
- 系统代理地址和端口与当前客户端显示值一致。
- 浏览器访问测试目标时，模式和代理组没有意外走 DIRECT。
- 如果需要 TUN，再在系统代理成功后单独启用，并确认关闭 TUN 后能够回退。
如果只满足“节点有延迟”而没有实际请求记录，不能算连接恢复；如果只有某个应用失败，则应继续检查该应用是否读取系统代理、是否配置了独立代理，或是否需要网络层接管。
常见问题
Clash Verge Rev 所有节点都 Timeout，应该先换节点还是重装？
先不要重装。先确认关闭客户端时直连网络正常，再检查订阅是否成功更新、Profile 是否激活、内核是否运行。随后换一个节点并查看 Logs；若所有节点同时失败，应优先排查订阅、DNS、系统时间、本机端口和网络链路。
Clash Verge Rev 节点有延迟，但浏览器仍然打不开怎么办？
先确认浏览器请求是否出现在 Connections 中。如果没有记录，检查 System Proxy 是否开启、代理主机和端口是否与客户端当前值一致，以及浏览器扩展是否覆盖了系统代理。如果有记录但显示 DIRECT，检查 Rule、Global 和代理组选择；如果请求进入节点后失败，再看 TLS、DNS 或远端连接错误。
Clash Verge Rev 开启 TUN 后断网，如何恢复？
先关闭 TUN，保留系统代理测试网络是否恢复；然后确认 Profile 和节点可以正常连接，再检查 Service Mode 或管理员权限、虚拟网卡、防火墙、DNS Hijack、Auto Route、Strict Route 和 MTU。一次只改一个设置，并保留回退路径。
端口 7890 一定是 Clash Verge Rev 的默认端口吗？
不能把 7890 当成固定值。不同配置、版本或用户设置可能使用不同端口，应以当前 Port、System Proxy 或配置页面显示值为准。Windows 可用 Get-NetTCPConnection，macOS 可用 lsof，Linux 可用 ss 检查实际监听情况。
订阅更新出现 401、403 或 YAML 错误怎么办？
401、403 通常与权限、授权或服务端拒绝有关，但仅凭状态码无法确定具体原因；应核对账户和订阅状态。YAML 或 parse 错误通常表示配置内容无法解析，建议重新获取配置并保留旧文件。不要把包含令牌的完整订阅地址贴到公开论坛或普通截图中。