On this page
When memory rises, distinguish the Clash Party app from the Mihomo core and compare whether opening the logs page triggers the growth. The following sections track trends in the same environment and explain why the reverted logging change is not evidence of a released fix. A temporary restart, security updates and logs-page retesting serve different purposes; one result cannot substitute for the others.
Why does memory keep growing after you leave the logs page?
Memory is initially stable after Clash Party starts, but keeps growing after you open the logs page once, even when you switch to another page. This matches the reports in project issue #1976. Users on Windows, macOS, and Linux reported similar behavior involving 1.9.6 and 2.0.0.
The logs page receives data over a live connection, which may continue after you leave the page. The project proposed stopping the UI listener and the main process’s logging WebSocket when leaving the page, but that change was later reverted. A continuing log connection alone does not establish the cause of rising memory use; compare the app and core trends.
If memory grows from startup, or only the Mihomo core's memory grows, investigate the core, connections, and configuration separately. Judge the sustained trend in the same environment; a brief peak or another user's memory figures cannot establish the cause on their own.
Compare memory trends before and after opening the logs page
Before testing, keep the configuration, node, network, and proxy mode unchanged; do not change rules while observing memory. Use Task Manager on Windows, Activity Monitor on macOS, or System Monitor on Linux. Record the Clash Party application process group and Mihomo core separately, rather than looking only at total system memory.
You do not need to watch log content continuously or generate heavy connection volume. Ordinary use of one consistently reachable webpage is enough to compare the trend before ever visiting the log page with the trend after visiting and leaving it.
Complete one reproducible before-and-after comparison
Restart after quitting completely
Quit Clash Party from the tray menu, confirm that the app and its child processes have ended, then reopen it. Do not visit the log page yet.
Record memory use for five minutes before opening the logs page
Under the same network activity, record memory for the application process group and Mihomo core once per minute. Do not draw conclusions from a single instantaneous value.
Open the log page once
Stay for about one minute so the page receives live logs, then switch to the home or proxies page. Do not clear the logs, change configurations, or restart the core.
Observe for another five minutes
Continue recording the same processes. If application memory keeps rising after leaving the log page while the core's trend does not change with it, the evidence more closely matches the known issue.
Choose what to investigate based on memory changes
| Observed pattern | More likely scope | Next step |
|---|---|---|
| The two trends are similar, and neither keeps rising | The logs page issue has not been reproduced | The issue is not reproduced; there is no need to change releases or configuration for this issue. |
| Memory keeps rising after opening the log page and does not stop after leaving it | Matches the trigger in the official issue | Retest after a complete exit and avoid the log page temporarily |
| Memory rises from launch whether or not the log page is opened | There may be another connection, cache, rule, or core problem | Observe the desktop app and Mihomo process separately; do not attribute it directly to the log page |
| Only the Mihomo core process grows while the UI process remains stable | The issue may be in traffic, rules, or the core | Record the core version, runtime configuration, rule mode, and connection count, then investigate the core |
| A brief increase occurs while the log page is open, then stabilizes quickly after leaving | This may be normal page loading | Observe for longer, but do not treat a brief peak as a leak |
Reports in the Issue include growth from hundreds of MB to several GB, as well as gradual increases. Hardware, running time, and log volume vary, so a fixed number is not enough to judge the problem.
- Mihomo CoreContinuously generates runtime logs
- Main-process log connectionReceives live logs over WebSocket
- UI listenerSends log events to the rendered page
- Log pageDisplays, filters, and retains current logs
The diagram illustrates the proposed logging change: stop the UI listener and main-process log connection when leaving the logs page. That change was later reverted, so it does not establish that current stable releases have resolved rising memory use.
How to avoid the logs page issue when you cannot update yet
If you cannot update yet, fully quit Clash Party, restart it, and avoid the logs page. Users in the Issue reported that restarting the app returned its increased memory use to the normal starting level. This ends the current app session; it neither identifies the cause of the memory growth nor provides a permanent fix.
Restore the original configuration and avoid the logs page
Record the current configuration
Record the current Profile, proxy mode, system proxy, and TUN state. Do not delete subscriptions or overrides.
Quit completely from the tray
Closing the main window may only minimize the app to the tray. Use the tray's quit command and confirm that Clash Party and its related UI processes have ended. If processes remain, wait for them to exit normally rather than terminating other system processes at random.
Restart and restore the proxy
If the system proxy or TUN does not reset automatically, disable it using the original settings and confirm that direct access works before starting the client again. Use the original configuration to open the same test page and check that nodes, rules, and connections still work.
Keep the log page closed
Perform everyday actions on the home, proxies, and connections pages, then observe for ten minutes and confirm that memory no longer follows the previous upward trend.
The logging change was reverted. What should guide an update?
The v2.0.0 release notes include other memory-related adjustments, but on 8/7/2026 the project maintainer explicitly said that v2.0.0 did not yet contain this log-page fix. When you see “memory fix,” verify the specific commit and release.
As of 8/10/2026, the stable release was still v2.0.0. v2.0.1 was released on 8/11/2026, but 6cbd24e had already reverted 5532a851. The v2.0.1, v2.0.2, and v2.0.3 tags do not retain page-controlled logging, so commit history alone cannot prove that the fix is effective.
The v2.0.1 release notes do not specifically name the logs page memory issue. Keep a configuration backup before updating, then repeat the test in section two. Being able to start the new version does not prove that the problem is resolved.
Boundaries between release choices
| Option | What it can solve | Limit you must accept |
|---|---|---|
| Update to v2.0.3 or a later stable release | Includes the rule-providers security fix and the resource-leak fixes listed in the official notes; retest the logs-page symptoms separately. | Still requires a before-and-after comparison using the same configuration and workload |
| You cannot update yet | Observe again after fully quitting the app. Avoid the logs page as a temporary workaround only if the comparison shows a connection to it. | That does not replace the v2.0.3 security update; avoid importing untrusted configuration until you have upgraded |
| Older versions 1.9.6 or v2.0.2 | These are not recommended rollback options and do not establish that the logs-page issue is fixed | Also lacks the rule-providers security fix in v2.0.3 |
Retesting, troubleshooting, and feedback after updating
After updating, keep the same configuration, node, network, and proxy mode. Follow section two to compare memory trends before and after opening the logs page.
Results to check after updating
- Clash Party's app memory no longer keeps growing after you leave the logs page
- The subscription, policy group, system proxy, or TUN can still complete a real webpage request
- Mihomo forwards traffic normally during use, and the system network returns to normal after you fully quit the app
If the app will not open after updating, configuration migration fails, or the proxy stops working, exit completely and preserve the current data directory. Disable the system proxy and TUN to restore a direct connection, then reinstall v2.0.3 or a later stable release from the official Clash Party Release and import the previously verified configuration backup.
Do not downgrade to v2.0.2 or earlier just to restore logs-view behavior: those versions cannot be shown to contain the rule-providers command-injection fix. If it still cannot run, leave the client disabled, record the error, and wait for an official compatibility fix.
For further feedback, include the operating system, Clash Party and Mihomo versions, whether you opened the logs page, both observation durations, and the starting and ending memory figures for the app and core. Do not substitute a single peak screenshot for the before-and-after comparison.
Share only redacted excerpts of logs and configuration. Remove subscription links, node passwords, the controller secret, and private domains; do not publish complete logs or configuration.