Clash Verge Rev 内存占用过高优化方法
任务管理器里 verge-mihomo 占了六七百 MB，挂了一两天之后数字还在往上爬，最后重启才能降回去——这是 Clash Verge Rev 内存占用过高最典型的描述。先给一个基准：代理内核维护着活跃连接、规则匹配缓存和 DNS 缓存，150–300 MB 属于正常范围，长期稳定超过 500 MB 才值得动手。更关键的是分清内存是“用出来的”还是“漏出来的”：短时尖峰集中在订阅更新和批量测速，而单调上涨、闲置也不回落，才指向会话回收或加载方式的问题。下面按收益从高到低，把界面层到内核层的可调项拆开。
01. 日志级别：收益最大的一项
Mihomo 在 debug 级别下会把大量连接细节和匹配过程写入内存缓冲区，日积月累，单这一项就可能占掉三位数的 MB。很多人是在排查某个问题后忘了把级别切回去，之后内存就一直没有降下来。遇到 Clash Verge Rev 内存占用过高，先看这一项，往往比调其他参数都立竿见影。
操作路径：设置 → 内核设置（或 Core）→ 日志级别，把 debug 改回 info。如果日常不需要看到每条连接的状态，warning 甚至 error 能进一步收窄缓冲占用。排障时临时切到 debug，问题定位完就切回，不要让它长期停在调试档。
Clash Verge Rev 的日志查看器本身对内存也有上限控制，界面侧最多保留 1000 条日志，超出后滚动丢弃，但内核侧的日志缓冲区由 log-level 决定，界面设置只影响展示，不影响内核已经分配的内存。所以改 log-level 必须落到内核配置里，光关掉日志页面不够。
02. 连接数与失败会话：内核侧的主要堆积点
每条活跃连接在内核里都维护着状态。BT 下载、P2P 应用动辄开出上千条并发，如果这些流量全部进入内核，内存会随连接数线性增长。更隐蔽的是失败连接的会话回收：节点连不上时客户端会反复重试，部分失败会话如果没有被及时释放，会在长时间运行中逐渐堆积，这也是社区反馈里内存持续上涨的主要方向之一，上游 Mihomo 有过相关的修复提交。
把下载流量挡在内核之外是最直接的减法。在 Merge 或覆写规则中给下载器加一条进程直连规则：
rules:
- PROCESS-NAME,qbittorrent.exe,DIRECT
- PROCESS-NAME,transmission-daemon,DIRECT然后到“连接”页面观察当前连接总数。如果长期停在几千条，先找出发起进程，再决定是加直连规则还是收窄分流范围，不要直接归因于内核本身。节点稳定性同样影响这一项：反复超时的节点会带来大量重试会话，挑连通性稳定的节点使用，比频繁切换更能减少失败连接的堆积。
03. 订阅瘦身与代理组精简
订阅里塞了五六百个节点、几十个分组，所有配置对象都会驻留内存，测速时还会成倍放大。如果大部分节点从来不用，用 Script 在加载阶段过滤掉是收益明确的一步：
function main(config) {
config.proxies = config.proxies.filter(p =>
/HK|JP|SG|香港|日本|新加坡/i.test(p.name)
);
return config;
}只保留实际在用的区域，节点数量降下来，规则匹配的缓存压力和测速开销都会同步下降。
代理组类型也影响内存占用。select 组只做手动选择，没有后台健康检查，占用最低；url-test 需要周期性发起测速请求，占用中等；fallback 要维护连接池检测状态，占用相对更高。不常用的自动测速组可以改成 select，或者保留 url-test 但把间隔放宽到 300 秒以上：
proxy-groups:
- name: Auto
type: url-test
interval: 600
tolerance: 50tolerance: 50 让新旧节点延迟差在 50ms 以内时不切换，既减少不必要的连接重建，也避免测速带来的周期性内存波动。
04. 自动更新频率与多配置残留
订阅数量多、更新间隔又短，意味着配置被反复重载，每次重载都会带来解析和对象创建的开销。把不用的订阅删掉，只保留常用的一到两条；自动更新间隔从很短的分钟级调到 1440（24 小时），能明显减少配置层的累积开销。
如果你习惯在多个 profile 之间来回切换，切换后确认旧的核心进程已经退出。从托盘退出后任务管理器里如果还有 verge-mihomo.exe 残留，新配置加载时可能同时存在两个内核实例，内存读数会叠加，端口和命名管道也可能发生争抢。以管理员身份运行 PowerShell 清理残留：
Get-Process | Where-Object { $_.ProcessName -like "*mihomo*" } | Stop-Process -Force05. 规则集加载方式：geodata-mode 与 MRS 格式
规则集是内存占用里容易被低估的一块。Mihomo 默认可能把 GeoIP/GeoSite 数据库一次性读入内存，大体积的 geosite.dat 或 geoip.dat 全量加载时，常驻内存可以到几百 MB。切换加载模式能显著改变这一点：
geodata-mode: true
geodata-loader: memconservativegeodata-mode: true 让 Mihomo 使用 mmdb 格式的 GeoIP 数据库，geodata-loader: memconservative 则改为内存映射的分页加载方式，而不是把整个数据库读入堆内存；对大体积规则库，优化后常驻内存可以压到几十 MB 的量级。默认的 standard 模式加载更快，但内存占用更高，二者按机器配置取舍。
规则集格式同样有影响。Mihomo 支持的 mrs 二进制格式比传统 YAML 或 text 规则集文件小一半以上，加载时的解析开销和内存占用也更低。如果订阅或自定义的 rule-providers 仍然在使用 classical 或大体积文本格式，在条件允许时换成 mrs，启动和常驻内存都会改善。rule-providers 本身的设计初衷就是按需加载和缓存，避免每次重启都重新解析全部规则原文，所以确认 provider 正常加载、没有反复回退到空状态，也是间接控制内存的一环。
06. TUN 与系统代理的内存代价
TUN 模式通过虚拟网卡接管全部流量，包括 UDP 和 ICMP，需要维护完整的网络栈，内存占用通常比系统代理多出 50–80 MB。这不是说 TUN 不好，而是如果机器本身内存紧张、使用场景又以浏览器 HTTP/HTTPS 为主，关掉 TUN 改用系统代理是合法且有效的减法。需要 UDP 转发、游戏加速或全流量接管的场景，再保留 TUN。
如果决定保留 TUN，先确认路由和 DNS 配置没有造成额外的无效流量。部分“内存涨得快”的案例，根源是规则过宽把轮询或心跳流量卷进了代理，连接数被动膨胀，而不是 TUN 本身的固定开销。结合“连接”页面观察 TUN 开启后的连接构成，比单纯比较开关前后的瞬时内存更有意义。
如果以上调整都做完，Clash Verge Rev 内存占用过高的问题仍然单调上涨、重启才降，先升级到最新稳定版 v2.5.2；历史版本中有过会话回收和内存泄漏相关的修复，旧内核的问题靠改配置绕不过去。进一步的内核参数可以在 Merge 与 Script 指南 中找到覆写位置，TUN 与路由的联动细节参考 TUN 模式完全指南。