任务管理器里 Clash 相关进程 CPU 很高、内存一直涨,先分清是界面卡还是核心在烧。界面卡多半是连接页/日志刷太猛;核心烧 CPU 则看连接数、测速、Tun、订阅是否在死循环更新。
短时尖峰(刚更新订阅、刚测速)可以忽略。长时间双位数 CPU、内存只涨不回,再按下面减法处理。别一上来重装——重装清不掉「测速把自己打满」这类配置问题。
立刻做的减法
连接页若堆着几千条短连接,查是谁在重试:浏览器扩展、失败的更新任务、或规则把轮询流量卷进来了。规则过宽也会堆连接,见规则分流。
订阅、自启、多配置
订阅特别大或更新失败后疯狂重试,会表现为周期性 CPU 尖峰。改更新间隔,失败先排订阅更新失败,别让它空转。开机自启叠上早高峰自动更新,容易「一开机就吵」——错开时间。
多 profile 来回切时,确认旧核心进程退干净;关软件后进程还在,先结束进程再开,避免双开抢端口(端口)。
对照实验:像泄漏还是配置过重
记下当前内存 → 只用浏览半小时 → 再看是否回落。只用测速/频繁切节点半小时再对比。若闲置也只涨不回,再怀疑泄漏或旧内核问题,并记录客户端版本(可升到当前稳定版,见下载中心、v2.5.6)。老硬件内存本身紧,别和泄漏画等号。
分不清是界面(WebView)还是核心(mihomo)在吃资源时,按进程名各看一次占用:
# Windows(PowerShell)
Get-Process | Where-Object {$_.ProcessName -match 'clash|verge|mihomo'} | Select-Object ProcessName,CPU,WorkingSet
# macOS / Linux
top -o cpu -n 15 | grep -iE 'mihomo|clash|verge'
WebView 那一行高,多半是连接页/日志刷太猛;mihomo 高,才回到测速、连接数、Tun 那几条去减。
Windows 休眠唤醒后占用异常:退出客户端再开一次,或重启服务模式。macOS/Linux 用活动监视器/top 看是 WebView 还是 mihomo 进程在涨。
和「网速慢」分开查
CPU 高但网速正常:优先减测速/连接刷新。网速慢但 CPU 不高:走慢速优化,别混在一篇里乱改。
重置前与验收
重置前备份订阅 URL 与 Merge(备份、配置目录)。处理好后:闲置 CPU 回落;内存不再单调上涨;测速按需手动而不是狂暴自动。给社区提问时带上:版本、是否 Tun、订阅大概体积、复现步骤。