Clash Verge Rev 连不上？常见报错排查：端口占用/TUN模式/订阅更新

不看日志的排查都是玄学。Clash Verge Rev 连不上，打开 Logs 页面把 Log Level 调到 debug，触发一次网络请求，日志最后几行出现的错误信息就是你该先处理的问题。大多数情况不是软件坏了，是某一个配置值卡住了——端口被占、TUN 路由冲突、订阅过期、DNS 劫持过宽、或是浏览器自己绕过了系统代理。下面按 6 类最常见的报错给排查步骤，每一类都带了终端验证命令。

这篇不处理”软件装不上""打不开客户端”和”怎么获取订阅链接”的问题。如果你连 Clash Verge Rev 都还没装，先去 GitHub Release 下安装包。

错误码速查表

打开 Logs 页面，把日志级别调到 debug，对照下表直接跳到你该看的步骤。

日志里的报错关键词	实际故障	跳到哪一节
address already in use / bind: permission denied	端口 7890 / 9090 被其他程序占用	日志报 address already in use：端口被谁占了？
lookup failed / no such host / i/o timeout（DNS 阶段）	DNS 解析不通或被劫持	日志报 lookup failed：DNS 解析卡在哪一层？
dial tcp ... i/o timeout（TCP 阶段）	节点不可达或端口被封	日志报 dial tcp ... timeout：节点真的不通还是 UDP 误报？
TUN 开关打开后日志无异常但全网断	Strict Route / DNS hijack / MTU	TUN 开了全网断：先关 Strict Route 还是先查 DNS hijack？
Update failed / 404 / 403 / timeout（在更新订阅时）	订阅链接失效或 UA 不匹配	点更新报 Update failed：链接过期、UA 不对还是代理干扰？
unmarshal errors / mapping values are not allowed	订阅返回的 YAML 格式不合法	Proxies 页面什么都没有：忘了激活还是 YAML 解析报错？
日志完全没有新记录	请求没进客户端（系统代理没生效/TUN 网卡未创建）	系统代理开了但浏览器不动

如果你的报错不在表里，把日志里第一次出现 error 或 warn 的那行原文记下来，再往下翻对应的排查节。

排查前先记下当前状态：端口、出口 IP 和 DNS

排查时最忌讳同时改三个参数然后不知道哪一个起了作用。动手之前记下当前的状态：

# 记录当前 Clash Verge Rev 监听的端口
# Windows
netstat -ano | findstr "7890 9090 9091"
# macOS / Linux
lsof -iTCP -sTCP:LISTEN -P | grep -E "7890|9090|9091"

运行这条命令，把输出截屏或复制到记事本。排查到最后你会需要和这里的初始状态做对比。

另外做一次基准测试：浏览器访问 https://api.ipify.org，记录当前出口 IP；终端输入 curl -s https://api.ipify.org 记录命令行 IP。如果是排查 TUN 模式问题，记下这两者是否相同。

日志报 address already in use：端口被谁占了？

日志里看到类似 failed to start mixed http/socks5 server: listen tcp :7890: bind: address already in use，说明 Clash Verge Rev 要用的端口被占。

Clash Verge Rev 默认监听三个端口：

• 7890：mixed（HTTP + SOCKS5 混合端口），系统代理就是指向这里
• 9090：HTTP API（前端面板和内核通信用）
• 9091：SOCKS5（独立 SOCKS 端口）

只要有一个被占，内核就启动失败，Overview 页面的对应指示灯变红或一直转圈。

查出是哪个程序在占端口：

# Windows：最后一列是 PID
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

拿到 PID 后：

# Windows：强制结束进程
taskkill /PID <PID> /F

# macOS / Linux
kill -9 <PID>

<PID> 换成查出来的数字。杀掉之后回 Clash Verge Rev 看 Overview 页面端口指示灯有没有变绿。如果没变绿，退出客户端再重新打开。

常见占用端口的程序：

• 另一个代理客户端（v2rayN、sing-box、Surge、Hiddify、Mihomo Party）——直接退出就行了，最省事
• 某些下载工具（aria2、IDM、迅雷）——它们偶尔会占用 7890/9090 端口做本地代理
• Windows 的 Hotspot 或 Internet Sharing 服务——走 net stop SharedAccess 停掉临时测试

如果每次开机端口都被占，查启动项：Windows 在任务管理器 → 启动里禁用其他代理客户端的自启，macOS 在系统设置 → 通用 → 登录项与扩展里关掉不必要的后台程序。

日志报 lookup failed：DNS 解析卡在哪一层？

日志里出现 lookup failed、no such host、或者在 DNS 阶段 i/o timeout，说明域名没有解析出 IP。

Clash Verge Rev 里 DNS 的行为受 dns 块控制，位置在订阅返回的 YAML 配置内。不同服务商给的配置 DNS 设置不同，常见问题有三类：

第一类：Fake-IP 缓存失效。 Mihomo 的 enhanced-mode: fake-ip 会给每个域名分配一个 198.18.x.x 的虚拟地址。客户端重启或 DNS 缓存过期后，浏览器缓存里的 fake-ip 对不上新的映射，所有标签页一起白屏。解决办法：清浏览器 DNS 缓存——Chrome 打开 chrome://net-internals/#dns 点 Clear host cache，Firefox 打开 about:networking#dns 点 Clear DNS Cache。

第二类：DNS 上游不可达。 很多配置里的 DNS 服务器写的是 https://dns.google/dns-query、tls://8.8.8.8 这类海外 DNS。在代理没建立之前，直连这些 DNS 大概率超时。表现就是 Clash Verge Rev 启动后前几十秒一切正常，过一会 DNS 查询全部超时。检验方法：

# 用系统默认 DNS 查一下能不能解析
nslookup google.com
# 对比 Clash Verge Rev 用的 DNS 上游
nslookup google.com 8.8.8.8

如果 nslookup google.com 8.8.8.8 超时，说明直连海外 DNS 被运营商拦了。改 YAML 配置的 DNS 块，换成国内可直连的 DNS 或通过代理解析：

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://8.8.8.8
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true

nameserver 用国内 DNS 做第一级解析，fallback 用海外 DNS 解析被污染的域名，fallback-filter: geoip: true 只让海外域名走 fallback。

第三类：浏览器 DoH 绕过客户端 DNS。 Chrome/Edge/Firefox 自带的 DNS over HTTPS 直接从浏览器发出 DNS 查询，不经过 Clash Verge Rev 的劫持通道。基于域名的分流规则对这种事毫无办法——浏览器已经自己决定了连接到哪个 IP。关掉它：Chrome → 设置 → 隐私和安全 → 安全 → 使用安全 DNS → 关闭；Firefox → 设置 → 隐私与安全 → 最底部 → 关闭 DNS over HTTPS。

日志报 dial tcp ... timeout：节点真的不通还是 UDP 误报？

DNS 解析成功了，IP 拿到了，但日志里出现 dial tcp ... i/o timeout——卡在 TCP 连接建立这一步。

测一个节点到底通不通最干净的方法是绕开所有规则直接测：

# 拿到节点 IP 和端口（从 Proxies 页面节点详情或配置文件里找）
curl -v --connect-timeout 5 https://<节点IP>:<端口>

connect-timeout 5 是 5 秒超时。如果连不上，三种可能：

节点服务商把你的 IP 拉黑了。 部分服务商在检测到可疑行为（比如短时间内从不同国家频繁切节点）后会临时封账号 IP。等 10-15 分钟再试，或联系服务商确认账号状态。

端口被封。 运营商对非标准端口的封锁比协议识别更常见。SS 节点默认端口通常是 8388/8989，VMess 多变，Trojan 常走 443。如果 curl -v https://<IP>:443 能通但 :8388 不通，就是端口封了——请求服务商提供走 80/443 端口的线路，或切到 Reality / Hysteria2 这类更难被识别的协议。

UDP 不通导致客户端误判。 Clash Verge Rev 的延迟测试用的是 UDP 探测，不同服务商对 UDP 转发支持的完整度不同。延迟显示 timeout 不代表 TCP 不通——测一下 TCP：

# 用 nc（netcat）测 TCP 是否可达
nc -zv -w3 <节点IP> <端口>

TCP 能通但延迟显示 timeout，可以忽略延迟数字直接选节点试试看网页能不能打开。同一策略组内换 2-3 个不同地区的节点，每次只改一个变量，不要同时换节点、改 DNS、切模式。

如果所有节点 TCP 都不通，且同一份订阅在手机端能正常连接，可能是本地网络的 UDP 被运营商 QoS 限速或阻断——切到 Reality 协议做对照，Reality 的流量特征和正常 HTTPS 最接近。

TUN 开了全网断：先关 Strict Route 还是先查 DNS hijack？

TUN 开关打开后，浏览器、命令行、聊天应用——全部断网。这一节的前提是系统代理模式下一切正常，问题只在 TUN 开启后出现。

第一步：关 Strict Route。 Settings → TUN Mode → Strict Route 设为 false。Strict Route 的本意是强制所有流量经过 TUN，不匹配代理规则的流量直接丢弃。后果是局域网打印机、NAS、路由器管理页面、公司内网全部不可达，包括 Clash Verge Rev 用来检测连通性的请求。99% 的 TUN 全网断都是这个开关搞的。

第二步：确认虚拟网卡已创建。

# Windows
ipconfig | findstr Mihomo
# macOS
ifconfig | grep utun
# Linux
ip addr show | grep tun

如果没有任何输出，说明 Service Mode 没装成。回 Settings → System Service → Install 重装。Windows 用户如果 Install 没反应，右键 Clash Verge Rev → 以管理员身份运行后再装。macOS 用户在装完 Service 后要去系统设置 → 隐私与安全性页面底部点”允许”按钮授权系统扩展。

第三步：查 DNS hijack 导致国内全断。 TUN 默认劫持所有 UDP/TCP 53 端口的 DNS 请求。如果 DNS 上游走了代理，国内域名的 A 记录被解析到海外 CDN 节点。百度首页从 20ms 变成 300ms，不是没断——是慢到你以为断了。确认分流规则里有：

rules:
  - GEOIP,CN,DIRECT
  - DOMAIN-KEYWORD,cn,DIRECT
  - DOMAIN-SUFFIX,cn,DIRECT

在 Logs 页面搜 baidu.com，看命中哪条规则。显示 DIRECT 才算 DNS 分流正确。

第四步：MTU。 前两步都做了还是断，把 Settings → TUN Mode → MTU 从 9000 改到 1400。PPPoE 拨号宽带和部分公司网络需要较小 MTU，否则 IP 分片反复失败，TCP 三次握手都完成不了。

第五步：防火墙。 Windows 防火墙可能把 Mihomo 虚拟网卡识别为公用网络并拦截入站连接。控制面板 → Windows Defender 防火墙 → 允许应用或功能通过 → 确认 Clash Verge Rev 两个选项都勾选。部分安全软件（卡巴斯基、ESET、McAfee）的 HTTPS 扫描功能会拦截 TUN 流量——排查时先临时关掉安全软件测一次，能通就是安全软件在拦截。

点更新报 Update failed：链接过期、UA 不对还是代理干扰？

Profiles 页面点更新按钮，弹窗提示 Update failed，日志里可能出现 404 Not Found、403 Forbidden、i/o timeout、connection refused、no such host 或 x509 证书错误。

排查顺序不要乱：

先判断链接本身有没有过期。 把订阅链接贴到浏览器地址栏回车。正常返回是一大段 YAML 文本，开头类似：

mixed-port: 7890
proxies:
  - name: "HK01"
    type: ss

返回 404、空白页、HTML 页面（机场首页）、JSON 报错信息——链接已失效。回服务商后台重新获取订阅链接。

浏览器能打开但客户端报错。 这种情况客户端请求的链路有问题。先确认是不是客户端走代理更新时代理不稳导致的——关掉 Overview 页面的系统代理，用直连网络手动点一次更新。更新成功再开回系统代理。

关代理更新也不行。 进 Profiles 页面点订阅卡片的编辑按钮（铅笔图标），把 User Agent 下拉框的值在 clash-verge、ClashMeta、clash 之间切换。每改一次手动点一次更新按钮——改 UA 不会自动触发重新拉取。不同服务商后台对 User Agent 的处理不同：

服务商后台	常见兼容的 UA	备注
V2Board	clash-verge, ClashMeta	返回标准 Clash YAML
SSPanel	ClashMeta, clash	部分魔改版只认 clash
SubConverter	clash	转换链可能丢掉部分字段

如果三个 UA 都试过还是失败，检查 Settings → Verge → 有没有配置订阅更新的上游代理——部分网络环境下需要给订阅更新单独设代理地址。

证书报错。 x509: certificate signed by unknown authority——两个原因。一是系统时间偏差太大，去系统设置确认日期和时间正确且自动同步开启。二是公司网络环境有中间人证书，需要把公司 CA 证书导入系统根证书库。排查时先用手机热点测一次，正常就是公司网络环境的问题。

如果一个订阅链接在 Mihomo Party、sing-box、Shadowrocket 上都能更新只有 Clash Verge Rev 不行，订阅链接本身没问题——是客户端发出去的请求参数或网络栈有差异。这时候打开 Logs 页面仔细看更新请求发出的 URL 和返回的 HTTP 状态码：URL 有没有被截断、参数有没有丢、User-Agent 请求头是不是和下拉框选的一致。

Proxies 页面什么都没有：忘了激活还是 YAML 解析报错？

Profiles 列表有订阅卡片，切换到 Proxies 页面什么都没有。

第一件事：确认激活。 卡片旁边有没有绿色标记？没有就是没激活——双击卡片。保存 ≠ 激活，这是 Clash Verge Rev 新手最踩的坑。

激活后还是空白，看 Logs 页面有没有 YAML 解析报错：

yaml: unmarshal errors:
  line 42: cannot unmarshal !!int into string

这行报错的意思是：配置文件的第 42 行，服务端给了一个整数类型的值，但 Mihomo 期望的是字符串。unmarshal errors 后面一定会注明行号和具体字段。三种最常见的原因：

1. 端口字段类型不匹配。 port: 443（整数）vs port: "443"（字符串）。Mihomo 对部分字段的类型要求严格，服务端返回的类型不对就解析失败。
2. 缩进问题。 YAML 靠缩进表示层级，多一个空格或少一个空格都会报 mapping values are not allowed here。用 VS Code 打开配置文件，装一个 YAML 语法检查的扩展看一眼。
3. 字段名拼错或缺失。 server 写成了 sever、password 写成了 passwd、或某个必填字段（如 type）在某个节点下缺失了。

不要手动改订阅返回的 YAML。 你的修改会在下次更新时被覆盖。问题出在服务端，联系服务商反馈 YAML 格式问题，或者用 Sub-Store 做订阅转换把输出格式标准化。

如果订阅返回的完全不是 YAML（是一段 base64 字符串或乱码），说明服务端给你的是原始订阅格式，需要经过 SubConverter 做一次转换。Clash Verge Rev 的 Profiles → + → From URL 接受的是转换后的 Clash 格式 YAML 链接，不接受原始 base64 订阅。

排查过程中如果你发现手里的订阅格式有问题、节点频繁超时、或者线路不支持 UDP，末端问题往往不在配置而在线路本身。一份长期维护且格式输出标准的订阅可以省掉反复切客户端查格式兼容的时间，兼容 Clash / Singbox / V2Ray 的订阅可以直接导入 Clash Verge Rev 测试对照。

相关阅读

• Clash Verge Rev 导入订阅完整步骤（Windows / macOS 2026）
• Clash Verge Rev 开启 TUN 模式完整教程（Windows / macOS / Linux 2026）
• 代理客户端显示 connected 但网页打不开：5 步排查法（2026）
• Mihomo Party Fake-IP 与 DNS 配置教程：Windows / macOS 防泄漏完整方案 2026