Clash Verge Rev 流量与连接日志怎么用：实时监控看板与排查入口分步说明

1. 本文范围：你已装好 Verge Rev 之后要看什么

Clash Verge Rev 在图形界面上把 mihomo 的能力拆成几块：配置与订阅、代理与策略组、以及运行时观测（流量、连接、日志）。很多教程停在「导入订阅、点一下系统代理」，接下来用户最常卡住的是两类问题：第一类是「我感觉没走代理」，第二类是「走了，但去的地方不对」。这两类都不需要先改 YAML，而是先在实时监控看板里看有没有速率，再在连接列表里看这一条会话到底命中了哪条规则、从哪个节点出去，最后用内核日志补齐 DNS、握手、规则集更新等细节。

不同发行的小版本会把入口放在侧边栏或顶部标签上，命名可能是「首页」「仪表盘」「流量」「连接」「日志」的组合；不必死记每一个译名，你只要建立习惯：先看流量有没有动起来，再看连接表，最后才翻日志。如果你连主界面都打不开，或订阅始终更新失败，请先回到安装与订阅专文，不要在本文里找「安装包从哪下」类答案。

另一点边界是 外部控制器：启用 external-controller 后，可以用浏览器打开 Yacd-meta 等面板看连接与流量，那是同一内核数据的另一种视图，但涉及监听地址、Secret、是否对局域网暴露等安全决策，与「客户端自带 Tab」不是同一件事。只想在单机上看数值，用内置页面通常更简单。

2. 实时流量与统计看板：先确认「有没有活流量」

实时流量最常见的展示形式，是当前上传与下载的瞬时速率，有时会附带简易曲线或会话峰值。它的用途非常单纯：当你打开浏览器访问一个明显需要跨境的站点时，图表应在短时间内出现非零读写；若长期贴近零，优先怀疑的是「应用根本没把流量交给 Clash」，而不是节点质量。此时应回头检查：系统代理是否写入 Windows 设置里的代理页、TUN 是否已正确安装虚拟网卡并开启、目标应用是否不读系统代理（许多游戏与命令行工具属于此类）——这类模式问题在 Windows 11 Verge Rev 首配里已有分层说明。

部分界面还会展示累计统计，例如自本次内核启动以来的总字节数，或按进程粗略分组。累计值的工程意义在于：当你怀疑「后台某个程序在狂跑流量」时，可以结合连接表里的进程名或目标域名一起判断，而不是凭任务管理器猜。要注意的是，不同版本对「进程级统计」的粒度可能不一致，应以当前客户端实际展示的列为准。

还有一种常见误判：用户只盯着速率曲线，却忘了自己选的策略组当前指向 DIRECT。此时流量依然会显示，但出境 IP 并不会变成节点侧。要回答「到底有没有出国」，应结合下文连接表里的出站或第三方检测站的 IP，而不是单看速率非零。

3. 连接列表：字段怎么读，如何对照分流

连接列表（有时叫 Connections）是排查「走错出口」的第一现场。它展示的是当前活跃的会话，通常包含目标地址或域名、协议、源进程或应用、命中规则、所属策略组、实际出站节点，以及上传下载量。你不需要一次性背下所有列，只要抓住四个问题：这条连接访问的是谁；被判到哪条规则；应该从哪个策略组出；最后从哪个节点或直连出去。

下表概括常见列的含义，便于你对照本地界面（具体列名可能因主题或版本略有不同）：

实操上建议开一个会触发外网访问的应用，让连接表刷新，再按域名或 IP 排序，锁定那条会话。若你发现明明应该走代理的域名却显示 DIRECT，不要先换节点，而是去看规则顺序里是否前面有一条更宽泛的直连；若显示走了代理但网站仍判定地区不对，才需要换节点或检查 DNS 模式（例如 Fake-IP 与站点测 IP 的差异）。更系统的 DNS 模式对比可参考 fake-ip 与 redir-host 说明。

连接表是实时视图：短连接可能在几秒钟内消失，排查时要动作快一些，或重复触发请求。对于长连接（即时通讯、语音、部分 HTTP/2 会话），你会看到持续占用与字节累加，这属于正常现象。

4. 日志查看：内核日志、应用日志与日志级别

「日志查看」在 Verge Rev 里通常拆成两层：内核日志来自 mihomo，记录规则匹配、DNS 查询、出站握手、规则集与 GEOIP 更新等；应用日志或「客户端日志」则记录 GUI 拉起内核、下载内核、权限错误、路径问题等。订阅拉取失败时，两类日志都可能出现线索：HTTP 状态码、TLS 错误往往在内核侧更完整；若提示无法写入配置目录，则多看应用侧。

日志级别控制噪音量：error 只看失败，warning 增补风险，info 适合日常观察，debug 会吐出大量 DNS 与规则细节。经验做法是：平常用 info；遇到「间歇性打不开」又看不清原因时，切到 debug 复现几分钟，保存或截屏关键片段后再切回，避免长期 debug 拖慢界面与占满磁盘。若你在日志里看到大量 TLS 或证书字样，可与订阅专文中的对照流程衔接，而不是在 Verge 里盲目切换节点池。

与连接表的关系可以这样记：连接表管「现在这条流怎么走」，日志管「为什么这么走、中途哪里报错」。两者一起用在 HTTPS 站「看似走错」的场景特别有效：连接表给出 SNI 或解析结果的外在表现，日志里可能有 Sniffer 或 DNS 解析的补充信息。更深度的 SNI 与 Sniffer 话题见 Sniffer 与 SNI 日志排查。

5. 简单排错流程：从现象回到界面里的三条线

把排错想成三条线，交叉点越少越好。第一条线是模式与订阅：内核有没有加载成功、当前配置是否更新、是否存在「没有可用出站」的策略组空状态。第二条线是连接表里的规则链：目标域名从哪条规则被送进哪个策略组。第三条线是节点与链路质量：握手是否超时、延迟是否飘、是否只有特定协议失败。

若实时流量长期为零，先不要在规则里大改，先确认系统代理或 TUN 是否真的生效，并用浏览器或命令行制造一条明确的出站访问；必要时对不读系统代理的程序改用 TUN。若有流量但网站仍判定地区错误，先在连接表里确认该会话的出站节点，再谈换节点或改 DNS。若只有订阅或规则更新报错，日志优先级高于连接表，可直接对照 Windows 订阅 TLS、DNS 日志专文 的关键词分类法。

排错时一次只改一个变量：不要同时换节点、改 DNS、关 TUN、手改覆写；否则连接表与日志都会对不上号。把「最小复现步骤」写进备忘录，往往比在社交群里发一张模糊截图更有效。

6. Windows 与 macOS 的小差异

在 Windows 上，看不到流量时要额外想到：系统代理是否写入「设置 → 网络和 Internet → 代理」、是否与其他全局 VPN 争抢默认路由、TUN 需要的 UAC 授权是否曾被拒绝。连接表能显示会话，但进程列有时会受权限影响而不完整，这属于系统设计差异，而不是 Clash 单独的问题。

在 macOS 上，首次 TUN 往往涉及系统扩展与隐私授权；若你仅用系统代理，连接表里仍可能对一些沙盒应用显示不完整信息。界面语言若设为英文，「Connections / Logs」等标签与本文用词一一对应，可按英文菜单对照阅读。

无论平台，只要内核版本与配置兼容，流量、连接、日志三者的语义保持一致；跨机排查时可以把「这三张图」的截图作为共同语言。

7. 常见问题

以下为正文速查版；结构化问答已写入页面 JSON-LD。

8. 使用前自检清单