On this page
First confirm whether the log page triggers the memory growth
This article covers a clearly bounded issue: Clash Party is stable after launch, but after opening the Logs page once and navigating elsewhere, its memory continues to grow. Official issue #1976 received similar reports from Windows, macOS, and Linux users on 1.9.6 and 2.0.0.
High Clash Party memory usage alone does not establish this issue. Subscription updates, connection count, rule sets, TUN, and the Mihomo core can all affect memory. Only a before-and-after comparison showing relative stability without opening the log page and a clear trend change after opening it closely matches the known problem.
Separate the four patterns first
| Observed pattern | More likely scope | Next step |
|---|---|---|
| Memory remains generally stable after launch without opening the log page | The log-page issue has not been triggered | Record a baseline, then run one controlled comparison |
| 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 | Another path involving connections, cache, rules, or the core may be responsible | 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 and runtime configuration, then troubleshoot the core instead |
Use a ten-minute comparison to distinguish the UI from the Mihomo core
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 a five-minute baseline
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.
The two trends are similar, and neither keeps rising
The issue is not reproduced; there is no need to change releases or configuration for this issue.
The application-side slope changes sharply after opening the log page and keeps rising after leaving
Proceed to the next section and use a complete restart for temporary containment.
Only the Mihomo core grows
Record the core version, rule mode, and connection count; stop attributing the issue to the desktop log page.
A brief increase occurs while the log page is open, then stabilizes quickly after leaving
This may simply be normal page loading. Observe longer, but do not call a short-lived peak a leak.
If already triggered, quit completely and avoid the log page temporarily
Before a stable release includes the fix, the least disruptive workaround is to quit Clash Party completely, relaunch it, and avoid opening the log page temporarily. Users in the official issue reported that restarting the app returned the increased memory to a normal baseline. This only stops the leftover log stream in the current session; it does not mean the code defect is fixed.
Closing the main window may only minimize the app to the tray. Use Quit from the tray menu and confirm in the system monitor that Clash Party and related UI processes have ended. If the system proxy or TUN is not restored automatically, disable it according to the original settings and confirm direct connectivity before starting the client again.
Restore a state suitable for continued use
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
Wait for the application process to end. If a UI process remains, allow it to exit normally; do not terminate random system processes other than Mihomo.
Restart and restore the proxy
Use the original configuration to open the same test webpage and confirm that the node, rules, and connection 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.
Why the data stream may continue after leaving the log page
The Clash Party log page does not read text just once. It establishes a live log connection from the main process and sends events to the UI. Official fix commit 5532a851 has a specific goal: remove the UI listener when the page unmounts and stop the main process's log WebSocket.
This explains why simply navigating elsewhere may not stop growth immediately: under the old behavior, the live log path could keep receiving data after the page disappeared. This conclusion applies only when the log-page trigger matches; it does not replace separate diagnosis of the Mihomo core, connection cache, or other pages.
- 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 merged fix stops both the UI listener and main-process log connection when the user leaves the log page, preventing the data stream from surviving after the page unmounts.
v2.0.1 includes the log-stream fix, but you must retest after upgrading
As of 8/10/2026, the latest stable release was still v2.0.0 and did not include the commit that stops the log stream. Clash Party then released v2.0.1 on 8/11/2026. The official tag includes commit 5532a851, so a source build is no longer required to obtain this fix.
The v2.0.1 release notes do not call out the log-page memory issue separately, so repeat the same ten-minute before-and-after comparison after upgrading. Validation is complete in your environment only if application memory stabilizes after leaving the log page, Mihomo forwarding remains healthy, and quitting restores normal system networking.
Boundaries between release choices
| Option | What it can solve | Limit you must accept |
|---|---|---|
| Upgrade to v2.0.1 or a newer stable release | Obtain the commit that stops the leftover log stream | The current stable release is v2.0.2; you still need a before-and-after comparison using the same configuration and load |
| Keep v2.0.0 and avoid the log page | Reduce the chance of triggering the known issue | Use the Connections page or brief restarts instead of watching logs for long periods |
| Downgrade to 1.9.6 | Cannot reliably avoid this issue | The older release reproduces it too and also loses other improvements from 2.0.0 |
Test a rollback and verify that the memory trend actually stops
If the app will not open after upgrading, configuration migration behaves incorrectly, or the proxy stops working, quit completely and preserve the current data directory. Reinstall the current stable v2.0.2 from the official Clash Party Release, then import the previous configuration backup. If an older release is required, record both the version and data-directory compatibility; do not overwrite your only backup with a new directory.
v2.0.1 includes the log-stream fix commit, but you must still repeat the same ten-minute comparison. Acceptance is not merely that the new release starts: after entering and leaving the log page, application memory must return to a stable trend while Mihomo forwarding and network restoration on exit both work.
Troubleshooting completion checklist
- Memory trends have been recorded separately for the Clash Party application process group and the Mihomo core
- The baseline before ever opening the log page can be repeatedly compared with the trend after opening and leaving it
- After a complete restart and avoiding the log page, memory no longer continues along the original upward trend
- The subscription, policy group, system proxy, or TUN can still complete a real webpage request
- v2.0.0 has not been presented as a fixed release containing commit 5532a851
- v2.0.1 or a newer stable release (currently v2.0.2) was installed from the official Release after backing up the configuration
- The subscription link, node passwords, controller secret, and private domains were removed before filing an issue