目次
まず、メモリ増加がログ画面によって発生するか確認する
この記事で扱うのは、境界が明確な問題です。Clash Party は起動後には安定していますが、「ログ」画面を一度開いて別の画面へ移動しても、アプリのメモリ使用量が増え続けます。公式 issue #1976 には Windows、macOS、Linux の利用者から同様の報告があり、1.9.6 と 2.0.0 が対象です。
Clash Party の使用量が多いというだけで、この記事をそのまま当てはめることはできません。サブスクリプションの更新、接続数、ルールセット、TUN、Mihomo カーネルもメモリへ影響します。「ログ画面を開かない間は比較的安定し、開いた後に増加傾向が明確に変わる」という前後比較がある場合に限り、現在の既知問題に近いと判断できます。
まず四種類の現象を分ける
| 観察された現象 | 可能性が高い範囲 | 次の手順 |
|---|---|---|
| 起動後にログ画面を開かず、メモリ使用量がほぼ安定している | ログ画面の問題はまだ発生していない | 基準値を記録し、制御された比較を一度行う |
| ログ画面を開いた後に増え続け、画面を離れても止まらない | 公式 issue の発生条件と一致する | 完全に終了してから再テストし、ログ画面を一時的に避ける |
| 起動直後から増え続け、ログ画面を開いたかどうかに左右されない | 接続、キャッシュ、ルール、カーネルの別経路に問題がある可能性 | デスクトップアプリと Mihomo のプロセスを個別に観察し、ログ画面だけを直接の原因としない |
| Mihomo カーネルのプロセスだけが増加し、画面側のプロセスは安定している | 通信、ルール、カーネルのいずれかに問題がある可能性 | カーネルのバージョンと実行設定を残し、カーネル側の調査へ移る |
十分間の比較で、画面と Mihomo カーネルを区別する
テスト前に同じ設定、ノード、ネットワーク、プロキシモードへ固定し、ルールを変えながらメモリを観察しないでください。Windows ではタスクマネージャー、macOS ではアクティビティモニタ、Linux ではシステムモニターを使用できます。端末全体の使用済みメモリだけを見るのではなく、Clash Party のアプリプロセス群と Mihomo カーネルを別々に記録することが重要です。
ログの内容を見続ける必要も、大量の接続を発生させる必要もありません。普段安定してアクセスできる Web ページを通常どおり使うだけで、「ログ画面へ一度も入らない」場合と「入ってから離れた」場合の傾向を比較できます。
再現可能な前後比較を一度完了する
完全に終了してから再起動する
トレイメニューから Clash Party を終了し、アプリと子プロセスが終了したことを確認してから、もう一度開きます。最初はログ画面を開かないでください。
五分間の基準値を記録する
同じネットワーク活動の下で、アプリのプロセス群と Mihomo カーネルのメモリ使用量を一分ごとに記録し、一つの瞬間値だけで結論を出さないようにします。
ログ画面を一度開く
約一分間とどまり、画面でリアルタイムログを受信させます。その後ホーム画面またはプロキシ画面へ移り、ログの消去、設定の変更、カーネルの再起動は行いません。
さらに五分間観察する
同じプロセス群の記録を続けます。ログ画面を離れた後もアプリ側だけが増え続け、カーネル側の傾向は同期して変わらない場合、既知問題により近い証拠になります。
二つの期間の傾向が近く、どちらも増え続けない
現在は再現していないため、この issue のためにバージョンや設定を変更する必要はありません。
ログ画面を開いた後にアプリ側の増加率が明確に変わり、離れた後も増え続ける
次の節へ進み、完全な再起動で一時的に影響を止めます。
Mihomo カーネルだけが増加する
カーネルのバージョン、ルールモード、接続数を記録し、デスクトップのログ画面へ原因を求めるのを止めます。
ログ画面を開いた際に一時的に増えるが、離れるとすぐ安定する
画面の通常の読み込みである可能性があります。観察時間を延ばしますが、短時間のピークを漏えいとして扱わないでください。
すでに発生している場合は、完全に終了してログ画面を一時的に避ける
安定版に修正が収録されるまでは、Clash Party を完全に終了し、再起動後にログ画面を一時的に開かない方法が最も影響の少ない回避策です。公式 issue では、アプリの再起動によって増加済みのメモリが通常の開始値へ戻ったという報告があります。これは現在のセッションに残ったログストリームを解除するだけで、コード上の問題が修正されたことを意味しません。
メインウィンドウを閉じるだけでは、アプリがトレイへ入るだけの場合があります。トレイメニューの終了操作を使い、システム監視ツールで Clash Party と関連する画面プロセスが終了したことを確認してください。システムプロキシまたは TUN が自動的に復元されない場合は、元の設定どおりに無効にし、直接接続が正常になってからクライアントを起動します。
まず長時間利用できる状態へ戻す
現在の設定を記録する
現在の Profile、プロキシモード、システムプロキシ、TUN の状態を記録し、サブスクリプションやオーバーライドは削除しません。
トレイから完全に終了する
アプリのプロセスが終了するまで待ちます。画面側のプロセスが残っている場合も、まず正常終了を待ち、Mihomo 以外のシステムプロセスを無作為に終了しないでください。
再起動してプロキシを復元する
元の設定で同じテストページへアクセスし、ノード、ルール、接続が引き続き正常であることを確認します。
ログ画面を閉じたままにする
ホーム画面、プロキシ画面、接続画面で日常の操作を行い、さらに十分間観察して、メモリ使用量が元の傾向どおりに増え続けないことを確認します。
ログ画面を離れてもデータストリームが残る場合がある理由
Clash Party のログ画面はテキストを一度だけ読み取るのではなく、メインプロセスからリアルタイムのログ接続を確立し、イベントを画面へ送ります。公式の修正コミット 5532a851 の目的は明確で、画面のアンマウント時にリスナーを解除し、同時にメインプロセスのログ WebSocket を停止します。
この仕組みは、別の画面へ切り替えるだけでは増加がすぐに止まらない理由も説明します。以前の動作では画面が消えても、リアルタイムのログ経路がデータを受信し続ける場合がありました。この結論が説明するのは、ログ画面をきっかけとする条件に一致する場合だけです。Mihomo カーネル、接続キャッシュ、ほかの画面に対する個別の診断を代替するものではありません。
- Mihomo コア実行ログを継続して生成する
- メインプロセスのログ接続WebSocket でリアルタイムログを受信する
- 画面のリスナーログイベントをレンダリング画面へ送る
- ログ画面現在のログを表示、絞り込み、保持する
ソースコードへ取り込まれた修正では、ログ画面を離れる際に画面のリスナーとメインプロセスのログ接続を同時に停止し、画面のアンマウント後もデータストリームが残ることを防ぎます。
v2.0.1 にはログストリームの修正が収録されていますが、更新後も再テストが必要です
2026年8月10日時点の最新安定版は v2.0.0 であり、ログストリームを停止するコミットは含まれていませんでした。その後 Clash Party は 2026年8月11日に v2.0.1 を公開し、公式タグにはコミット 5532a851 が含まれています。この修正を得るためにソースコードからビルドする必要はなくなりました。
v2.0.1 のリリースノートはログ画面のメモリ問題を個別に挙げていないため、更新後もこの記事の十分間の前後比較を繰り返してください。ログ画面を離れた後にアプリ側のメモリ使用量が安定へ戻り、Mihomo の転送が正常で、終了時にシステムネットワークも復元されて初めて、手元の環境で検証が完了したと判断できます。
バージョンごとの選択範囲
| 選択肢 | 解決できること | 受け入れる必要がある制限 |
|---|---|---|
| v2.0.1 またはそれ以降の安定版へ更新する | 残存するログストリームを停止するコミットを利用できる | 現在の安定版は v2.0.2 です。同じ設定と負荷で前後比較を行う必要があります |
| v2.0.0 を維持し、ログ画面を避ける | 既知問題が発生する可能性を下げる | 接続画面または短時間の再起動で、ログを長時間見る操作を代替する必要があります |
| 1.9.6 へダウングレードする | この問題を確実に回避できません | 旧版でも再現し、2.0.0 のほかの改善も失われます |
ロールバックをテストし、メモリの増加傾向が実際に止まったことを確認する
更新後に起動できない、設定の移行に異常がある、プロキシを利用できない場合は、まず完全に終了して現在のデータディレクトリを残します。Clash Party の公式 Release から現行安定版 v2.0.2 を再インストールし、以前の設定バックアップをインポートしてください。旧版へ戻す必要がある場合は、バージョンとデータディレクトリの互換性も記録し、新しいディレクトリで唯一のバックアップを直接上書きしないでください。
v2.0.1 にはログストリーム修正のコミットが含まれますが、同じ十分間の比較を繰り返す必要があります。実際の受け入れ条件は「新しいバージョンが起動する」ことではありません。ログ画面へ入り、離れた後にアプリ側のメモリ使用量が安定した傾向へ戻り、同時に Mihomo の転送と終了時の復元が正常であることです。
調査完了の確認リスト
- Clash Party のアプリプロセス群と Mihomo カーネルのメモリ傾向を個別に記録している
- ログ画面を一度も開かなかった基準値と、開いてから離れた後の傾向を繰り返し比較できる
- 完全な再起動後にログ画面を避けると、メモリ使用量が元の傾向どおりに増え続けない
- サブスクリプション、ポリシーグループ、システムプロキシ、TUN のいずれかで実際の Web リクエストを完了できる
- v2.0.0 にコミット 5532a851 が含まれる修正版だとは記載していない
- 公式 Release から v2.0.1 またはそれ以降の安定版（現在は v2.0.2）をインストールし、更新前に設定をバックアップしている
- issue の提出時に、サブスクリプションリンク、ノードのパスワード、コントローラーの secret、個人用ドメインを削除している