本文目录
内存上涨时，先分清增长的是 Clash Party 应用还是 Mihomo 内核，再比较是否由打开日志页触发。下文按同一环境记录趋势，并说明已回滚的日志启停方案为什么不能当作正式修复。临时重启、安全更新和日志页复测各有目的，不能用其中一个结果代替其他判断。
离开日志页后，内存为什么还在涨？
Clash Party 启动后原本稳定，打开一次日志页后内存持续增加，切到其他页面也不停，这与项目 issue #1976 中的反馈一致。Windows、macOS 和 Linux 用户均报告过相似现象，涉及 1.9.6 和 2.0.0。
日志页通过实时连接接收数据，离开页面不一定意味着连接已停止。项目曾提出在离开页面时停止界面监听和主进程日志 WebSocket 的方案，但随后回滚；持续日志连接本身不能证明内存上涨原因，仍需比较应用与内核的趋势。
如果内存从启动时就上涨，或只有 Mihomo 内核上涨，应另查内核、连接和配置。判断依据是同一环境中的持续趋势；短时峰值和其他用户的内存数值，都不能单独确定原因。
比较打开日志页前后的内存趋势
测试前固定同一份配置、节点、网络和代理模式，不要一边换规则一边观察内存。Windows 可用任务管理器，macOS 可用活动监视器，Linux 可用系统监视器；重点是分别记录 Clash Party 应用进程组和 Mihomo 内核，而不是只看整机已用内存。
不需要一直盯着日志内容，也不需要制造大量连接。用一个平时能稳定访问的网页维持普通使用，就足以比较“从未进入日志页”和“进入后再离开”两段趋势。
完成一次可重复的前后对照
完整退出后重新启动
从托盘菜单退出 Clash Party，确认应用及其子进程已经结束，再重新打开；先不要进入日志页。
记录打开日志页前五分钟的内存
在相同网络活动下，每分钟记录一次应用进程组和 Mihomo 内核的内存，避免用单个瞬时数值下结论。
打开日志页一次
停留约一分钟，让页面收到实时日志；随后切到首页或代理页，不要清空日志、换配置或重启内核。
再观察五分钟
继续记录同一组进程。若离开日志页后应用侧仍连续上涨，而内核趋势没有同步变化，证据更接近已知问题。
按内存变化选择排查方向
| 观察到的现象 | 更可能的范围 | 下一步 |
|---|---|---|
| 两段趋势相近，而且都没有持续上涨 | 当前没有复现日志页问题 | 当前没有复现，不需要为这个 issue 更换版本或改配置。 |
| 打开日志页后持续上涨，离开页面也不停 | 与官方 issue 的触发方式一致 | 完整退出后复测，并暂时避开日志页 |
| 从启动开始就上涨，是否打开日志页都一样 | 可能另有连接、缓存、规则或内核问题 | 分别观察桌面应用与 Mihomo 进程，不直接归因于日志页 |
| 只有 Mihomo 内核进程上涨，界面进程稳定 | 问题可能在流量、规则或内核 | 记录内核版本、运行配置、规则模式与连接数量，转向内核侧排查 |
| 打开日志页时短暂增加，离开后很快稳定 | 可能是页面正常加载 | 延长观察，但不要把短时峰值当成泄漏 |
Issue 中既有数百 MB 增至数 GB 的反馈，也有缓慢上涨的反馈。机器、运行时长与日志量不同，不能用一个固定数值判断。
- Mihomo 内核持续产生运行日志
- 主进程日志连接通过 WebSocket 接收实时日志
- 界面监听器把日志事件发送给渲染页面
- 日志页显示、筛选并保留当前日志
图示说明曾提出的日志启停方案：离开日志页时停止界面监听和主进程日志连接。该方案随后被回滚，不能据此认定当前正式版已解决内存上涨。
暂时无法升级时，怎样规避日志页问题
暂时无法升级时，可以完整退出 Clash Party，再重新启动并避开日志页。Issue 中有用户反馈，重启应用能让已经增长的内存回到正常起点；这只结束当前应用会话，不能据此认定内存上涨的原因，也不是永久修复。
恢复原配置并避开日志页
记下当前配置
记录当前 Profile、代理模式、系统代理和 TUN 状态，不删除订阅或覆写。
从托盘完整退出
关闭主窗口可能只是收进托盘。使用托盘退出菜单，确认 Clash Party 及相关界面进程结束；若仍有进程停留，等待正常退出，不随机结束其他系统进程。
重新启动并恢复代理
若系统代理或 TUN 没有自动恢复，按原设置关闭它们并确认直连正常，再启动客户端。使用原配置访问同一测试网页，确认节点、规则和连接仍正常。
保持日志页关闭
在首页、代理页和连接页完成日常操作，再观察十分钟，确认内存不再沿原趋势增加。
日志启停改动已回滚，更新时该看哪些依据？
v2.0.0 发布说明包含其他内存相关调整，但项目维护者在 2026 年 8 月 7 日明确说明：v2.0.0 尚未包含日志页的这项修复。看到“内存修复”字样时，要继续核对具体提交和发布版本。
截至 2026 年 8 月 10 日，稳定版仍为 v2.0.0。v2.0.1 于 2026 年 8 月 11 日发布，但 6cbd24e 已回滚 5532a851。v2.0.1、v2.0.2 和 v2.0.3 标签均未保留按日志页启停的实现，不能仅看历史提交判断修复。
v2.0.1 的发布说明没有单独点名日志页内存问题。实际更新前保留配置备份；更新后仍按第二节的方法复测，不能只以新版本能启动判断恢复。
不同版本选择的边界
| 选择 | 能解决什么 | 需要接受的限制 |
|---|---|---|
| 升级到 v2.0.3 或后续稳定版 | 获得 rule-providers 安全修复及正式说明中的资源泄漏修正；日志页相关现象仍需单独复测。 | 仍需用同一配置和负载完成前后对照 |
| 暂时无法升级 | 完整退出后重新观察；只有对照显示与日志页有关，才把避开该页作为临时规避。 | 这不能替代 v2.0.3 的安全更新；升级前避免导入不可信配置 |
| 旧版 1.9.6 或 v2.0.2 | 不能作为推荐的回退方案，也不能据此认定日志页问题已修复 | 也不包含 v2.0.3 的 rule-providers 安全修复 |
更新后的复测、异常处理与反馈
更新后沿用相同配置、节点、网络和代理模式，按第二节的方法比较日志页打开前后的内存趋势。
升级后的验收结果
- 离开日志页后，Clash Party 应用侧内存不再持续上涨
- 订阅、策略组、系统代理或 TUN 仍能完成真实网页请求
- 使用时 Mihomo 转发正常，完整退出后系统网络能够恢复
如果升级后打不开、配置迁移异常或代理不可用，先完整退出并保留现有数据目录；关闭系统代理与 TUN 恢复直连，再从 Clash Party 官方 Release 重新安装 v2.0.3 或后续稳定版，导入此前核验过的配置备份。
不要为了恢复日志页行为降级到 v2.0.2 或更早版本：这些版本不能证明包含 rule-providers 命令注入修复。若仍无法运行，保持客户端停用并记录错误，等待官方兼容修复。
继续反馈时，提供操作系统、Clash Party 与 Mihomo 版本、是否打开过日志页、两段观察时长，以及应用侧和内核侧的起止内存。不要用一张峰值截图代替前后对照。
日志和配置只分享脱敏片段，移除订阅链接、节点密码、控制器 secret 与私人域名，不公开完整日志或配置。