目次
メモリが増えたら、まず増えているのが Clash Party アプリか Mihomo コアかを分け、ログページを開くと増加するかを比較します。同じ環境で傾向を記録し、撤回されたログの開始・停止の変更を正式な修正とみなせない理由を説明します。一時的な再起動、セキュリティ更新、ログページの再テストは目的が異なり、どれかの結果だけでほかの判断を代用することはできません。
ログページを離れてもメモリが増え続けるのはなぜ？
Clash Partyの起動後は安定していたメモリが、ログページを一度開くと増え続け、ほかのページへ切り替えても止まらない現象は、プロジェクトのissue #1976に寄せられた報告と一致します。Windows、macOS、Linuxのユーザーから同様の報告があり、1.9.6と2.0.0が含まれています。
ログページはリアルタイム接続でデータを受信するため、ページを離れても接続が止まったとは限りません。ページを離れたときに画面のリスナーとメインプロセスのログ用 WebSocket を停止する変更が提案されましたが、後に取り消されました。ログ接続が続くことだけではメモリ増加の原因を特定できないため、アプリとコアの傾向を比較する必要があります。
起動直後からメモリが増える場合や、Mihomoコアだけが増える場合は、コア、接続、設定を別途調べてください。同じ環境での継続的な傾向を判断材料にします。短時間のピークやほかのユーザーのメモリ数値だけでは原因を特定できません。
ログページを開く前後のメモリ傾向を比較する
テスト前に同じ設定、ノード、ネットワーク、プロキシモードへ固定し、ルールを変えながらメモリを観察しないでください。Windows ではタスクマネージャー、macOS ではアクティビティモニタ、Linux ではシステムモニターを使用できます。端末全体の使用済みメモリだけを見るのではなく、Clash Party のアプリプロセス群と Mihomo カーネルを別々に記録することが重要です。
ログの内容を見続ける必要も、大量の接続を発生させる必要もありません。普段安定してアクセスできる Web ページを通常どおり使うだけで、「ログ画面へ一度も入らない」場合と「入ってから離れた」場合の傾向を比較できます。
再現可能な前後比較を一度完了する
完全に終了してから再起動する
トレイメニューから 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 のいずれかで実際の Web リクエストを完了できる
- 使用中はMihomoの転送が正常で、完全終了後はシステムのネットワークが元に戻る
更新後に起動できない、設定の移行に異常がある、またはプロキシが使えない場合は、まずアプリを完全に終了し、現在のデータディレクトリを保存します。システムプロキシとTUNをオフにして直接接続を復旧し、Clash Partyの公式Releaseからv2.0.3以降の安定版を再インストールして、以前に確認した設定バックアップを取り込んでください。
ログ画面の動作を戻すためにv2.0.2以前へダウングレードしないでください。それらのバージョンにrule-providersのコマンドインジェクション修正が含まれるとは証明できません。それでも動作しなければ、クライアントを停止したままエラーを記録し、公式の互換性修正を待ってください。
追加の報告には、OS、Clash PartyとMihomoのバージョン、ログページを開いたかどうか、前後それぞれの観察時間、アプリ側とコア側の開始時・終了時のメモリ数値を含めてください。ピーク時のスクリーンショット一枚を前後比較の代わりにしないでください。
ログや設定は機密情報を除いた抜粋だけを共有してください。サブスクリプションリンク、ノードのパスワード、コントローラーのsecret、個人用ドメインを削除し、ログや設定の全文を公開しないでください。