Clash Verge Rev 内存占用高怎么办？按进程定位与 7 步排查

更新于 2026-11-13 · xianzhey.shop

简答：先不要只看任务管理器里“Clash Verge Rev”这一组的总数：分别确认是 clash-verge 图形界面、verge-mihomo 内核，还是 WebView 子进程在增长。短时升高可先关闭日志面板和连接；如果工作集或 RSS 持续上涨，或已经达到数 GB，应先停止 TUN/代理、保存版本与日志，再重启相关进程并用最小配置复测。

定义：Clash Verge Rev 内存占用高，是指其图形界面、Mihomo 内核或关联 WebView 进程的工作集、RSS 或提交大小持续高于平时，不能仅凭一个进程名判断原因。

先看哪个进程在占内存：Windows、macOS、Linux 对照表

本文是第三方使用指南，不是 Clash Verge Rev 官方页面。不同系统的进程名、内存指标和菜单位置可能不同，以下名称均应以本机实际显示为准。

项目仓库的设置文本包含日志级别、打开日志目录、打开核心目录、导出诊断信息和轻量模式等入口，但具体菜单名称会随版本和语言变化，操作时以当前设置页显示为准。查看项目仓库中的设置字段。

第 1 步：Windows 先确认工作集与提交大小

Windows 任务管理器中的“内存”更接近工作集，不等于虚拟地址空间。排查时建议同时记录工作集和 Private Bytes；不要把 VirtualMemorySize64 写进名为“CommitMB”的列，因为它代表虚拟地址空间，不是提交大小。

打开 PowerShell，先列出名称中可能相关的进程：

Get-Process | Where-Object { $_.ProcessName -match 'clash|verge|mihomo|webview|webkit' } | Select-Object Id, ProcessName, CPU, @{Name='WorkingSetMB';Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}}, @{Name='PrivateMB';Expression={[math]::Round($_.PrivateMemorySize64 / 1MB, 1)}} | Sort-Object PrivateMB -Descending

如果想持续采样，可使用下面的脚本。它把 WorkingSet64 记录为工作集，把 PrivateMemorySize64 记录为 PrivateMB；进程退出后会自动跳过，不会因变量不存在而报错。

$names = 'clash-verge','verge-mihomo','mihomo','msedgewebview2'
$out = Join-Path $env:TEMP 'clash-verge-memory.csv'
while ($true) {
  $rows = foreach ($name in $names) {
    Get-Process -Name $name -ErrorAction SilentlyContinue | ForEach-Object {
      [pscustomobject]@{
        Time = Get-Date
        PID = $_.Id
        Process = $_.ProcessName
        WorkingSetMB = [math]::Round($_.WorkingSet64 / 1MB, 1)
        PrivateMB = [math]::Round($_.PrivateMemorySize64 / 1MB, 1)
      }
    }
  }
  if ($rows) { $rows | Export-Csv -Path $out -Append -NoTypeInformation }
  Start-Sleep -Seconds 60
}

判断方法：短时间打开设置页、切换代理组或刷新订阅后上升，随后回落，通常先检查操作触发的日志和连接；每隔 1 分钟都上涨且关闭窗口、停止连接后仍不回落，才更接近持续增长型问题。

注意：msedgewebview2.exe 也可能属于 Edge、Teams、Widgets 等其他程序。不要仅凭进程名归因，应在任务管理器“进程”页展开 Clash Verge 分组，或通过 PID、父进程和命令行核对归属。

第 2 步：macOS 与 Linux 分别确认主进程、内核和子进程

macOS 打开“活动监视器”，搜索 clash、verge、mihomo 和 WebKit，切换到“内存”列并记录进程名、内存和父子关系。WebKit Web Content 可能属于其他应用或窗口，不能只按名称判断；应结合活动监视器中的层级、客户端是否打开以及重启客户端后是否同步回落。

Linux 可以先用下面的命令查看 RSS 和父进程：

ps -eo pid,ppid,comm,%mem,rss,etime,args --sort=-rss | grep -Ei 'clash|verge|mihomo|webkit|webview' | grep -v grep

其中 rss 是常用的常驻内存指标，单位为 KB；它和虚拟内存、提交大小不是同一个概念。若需要观察某个 PID 的变化，把示例中的 12345 换成本机 PID：

while true; do
  date
  ps -p 12345 -o pid,ppid,comm,%mem,rss,vsz,etime
  sleep 60
done

macOS 的 ps 不一定能完整筛出所有 WebKit 子进程。若表格写的是 WKWebView 或网页内容进程，优先在“活动监视器”中按父进程确认，不要因为命令行没有匹配到就认定不存在。

项目问题报告中曾分别出现 Windows 内核进程、Linux 图形界面进程和 macOS 主进程长期增长的报告，说明“内存占用高”不能直接归结为同一个组件；这些是用户提交的个案，不代表每台设备都会复现。Windows verge-mihomo 内存增长报告、Linux 图形界面进程长期运行报告。

第 3 步：按现象区分短时尖峰、稳定高占用和持续增长

一个 GitHub 报告记录了 Windows 上 verge-mihomo.exe 虚拟内存达到约 116 GB 并伴随系统冻结，但该数值是报告者的虚拟内存记录，不等于物理内存或 Private Bytes；应使用本机任务管理器和 PowerShell 同时核对。查看该问题报告。

第 4 步：降低日志、连接和配置带来的额外开销

1. 日志级别：进入设置中与 Clash、内核或日志相关的页面，把长期运行的 debug 调整为 info、warn 或更低的必要级别。仓库设置文本列出的选项包括 debug、info、warning、error 和 silent；实际可选项以当前版本为准。核对日志级别字段。
2. 连接数：暂时关闭下载器、P2P、同步软件和会反复重连的程序，观察内核 Private Bytes 或 RSS 是否停止增长。不要把“连接数多”直接当成泄漏，先用关闭相关程序前后的采样结果对照。
3. TUN 模式：如果开启了 TUN，先按当前版本的入口关闭，再重复相同的网页、订阅和节点操作。TUN 会改变流量接管范围；关闭前后必须保持测试步骤一致，避免把网络变化误判为内存变化。
4. 规则与节点：备份当前配置后，暂时只保留少量节点和必要规则集。若最小配置不再增长，再逐项恢复规则集、订阅和自定义脚本，找出触发项。
5. 订阅更新：检查订阅是否返回错误、反复重试或生成异常大的配置。订阅地址属于敏感信息，不要把完整 URL、令牌和节点密码上传到公开 Issue；提交日志前应打码。

第 5 步：用最小配置做对照测试

这一步的目的不是长期替换配置，而是把“客户端本身”和“当前配置”分开。先备份配置文件，退出客户端，再创建一个只包含占位节点和必要监听项的测试配置。不同版本的配置目录和字段可能变化，应优先通过设置中的“打开配置目录”或“打开诊断信息”入口确认位置。

mixed-port: 7890
mode: rule
log-level: warning
proxies:
  - name: test-node
    type: socks5
    server: 127.0.0.1
    port: 1080
proxy-groups:
  - name: auto
    type: select
    proxies:
      - test-node
rules:
  - MATCH,auto

上面的节点只是占位示例，不能直接代表可用节点。使用时要替换为自己已核验的配置，并注意不要把订阅链接、密码或真实节点信息发布到日志和文章中。

• 最小配置稳定，恢复完整配置后上涨：优先检查规则集、节点数量、订阅内容、脚本和连接来源。
• 最小配置也持续上涨：分别关闭 TUN、关闭界面窗口、停止订阅更新，再记录哪个动作改变曲线。
• 只在某个系统或某个版本出现：记录客户端版本、Mihomo 内核版本、操作系统版本、TUN 状态和复现步骤，去项目 Releases 与 Issues 页面核对是否已有报告。

第 6 步：临时缓解与版本核对

临时重启客户端或内核可以释放当前已占用的资源，但不能证明问题已经根治。若图形界面占用高，可先关闭主窗口并观察后台进程；若内核占用持续上涨，可先停止代理、关闭 TUN，再结束对应内核进程。执行前先保存配置和诊断信息，避免丢失复现线索。

版本号、修复状态和可下载资产应以项目 Releases 页面为准，不要仅凭搜索摘要或第三方页面判断“最新版”。截至本次查阅，项目 Releases 页面列出了不同系统的安装包和 SHA256 字段，但页面内容会更新，具体版本仍需在下载前重新核对。查看 Clash Verge Rev Releases 页面。

如果出现系统冻结、分页文件不足、应用批量崩溃或内存持续达到数 GB，优先停止相关进程并重启系统；恢复后再用最小配置采样，不要在高风险状态下继续长时间等待。

第 7 步：提交问题前准备哪些信息

• 客户端版本、Mihomo 内核版本和操作系统版本；版本号从客户端“关于”或诊断信息中复制，不要凭记忆填写。
• 发生问题的具体进程名、PID、工作集或 RSS、Private Bytes，以及采样间隔。
• TUN、系统代理、轻量模式、日志级别、规则集数量和订阅自动更新状态。
• 最小配置与完整配置的对照结果，以及关闭窗口、停止连接或重启后的变化。
• 可复现步骤、开始增长的时间点和是否伴随连接失败、订阅更新失败或界面卡顿。

不要上传完整订阅地址、访问令牌、节点密码、个人 IP 或未打码的配置。项目问题页中的报告包含具体系统、版本和内存指标，提交前应先确认这些信息是否仍能复现，并在标题中注明平台和组件。查看长期运行内存问题报告示例。

常见问题

Clash Verge Rev 内存占用高就是内存泄漏吗？

不一定。刷新订阅、解析大量规则、打开日志或连接数暂时增加，都可能造成短时升高。只有在相同操作条件下，工作集、RSS 或 Private Bytes 持续上涨，并且关闭窗口、停止连接或使用最小配置后仍能复现，才值得按持续增长型问题继续定位。

Windows 任务管理器显示的虚拟内存很大，是否等于实际内存不够？

不等于。虚拟内存、工作集和 Private Bytes 是不同指标。排查时应同时记录任务管理器内存、PowerShell 的 WorkingSet64 和 PrivateMemorySize64，不要把 VirtualMemorySize64 当作提交大小。

为什么看到 msedgewebview2.exe 不能直接认定是 Clash Verge Rev？

因为 Edge、Teams、Widgets 等其他程序也可能使用 WebView2。应在任务管理器展开 Clash Verge 分组，或通过 PID、父进程和命令行核对；只看进程名不足以确认归属。

重启 Clash Verge Rev 后内存下降，是否说明问题已经解决？

不一定。重启通常会释放当前进程资源，只能作为临时缓解。应继续用相同配置记录一段时间，并对比关闭日志、TUN、异常连接和订阅更新后的曲线。

提交 GitHub Issue 时可以直接上传订阅链接和完整配置吗？

不建议。订阅链接、令牌、节点密码、个人 IP 和部分日志可能包含敏感信息。提交前应打码，并保留版本、系统、进程指标、复现步骤和最小配置对照结果。

相关阅读

• Clash Verge Rev TUN 模式排查
• Clash Verge Rev 系统代理不生效排查
• Clash Verge Rev 订阅导入后没有节点
• Clash Verge Rev 速度慢排查
• 连接问题排查指南

参考资料

1. Releases · clash-verge-rev/clash-verge-rev
2. clash-verge-rev 设置字段与日志选项
3. verge-mihomo.exe memory leak: 116GB virtual memory consumed, causing system freeze
4. GUI process severe memory leak over long uptime
5. v2.5.2 长期后台运行存在内存泄露