目次
コアの起動や設定の再読み込み時にCPUとメモリ使用量が急増し、画面がなかなか利用可能にならない一方、通常のプロキシ動作中は必ずしもメモリを大量に使い続けるわけではありません。「サブスクリプションが大きい」という情報より、いつ起きるかが判断の手がかりになります。すぐにノードを削除したりDNSを変更したりせず、まず設定の検証中に起きているか確かめます。
設定読み込みの遅さと稼働中のメモリ増加を切り分ける
この記事の対象は、Mihomoの設定で多数のインラインproxiesにdialer-proxyが指定されている場合です。公式の#3315では、実際の利用者が使う大量のノード設定から、検証処理の負荷が原因と突き止められています。v1.19.33には対応する修正が含まれますが、大きなサブスクリプション、メモリ増加、クライアントの動作遅延すべてに共通する原因ではありません。
発生するタイミングに合わせて確認する
| 症状 | まず確認すること |
|---|---|
| 起動、再読み込み、-tでの検証が遅く、多数のproxiesにdialer-proxyがある | 実際に使われている設定、コアのバージョン、同じコピーを検証した結果を照合します。 |
| トレイメニューやログ画面を開くときだけ動作が遅くなる | クライアント画面とログ処理を先に調べます。コアの検証処理の修正を万能な解決策と考えないでください。 |
| 通常動作をしばらく続けるとメモリ使用量が増え続ける | 接続数、DNS、動作ログをそれぞれ記録し、この記事が扱う読み込み時のピークとは区別します。 |
| not foundまたはcircular dialer-proxy dependencyがすぐに表示される | 参照先の欠落や実際の循環を先に修正します。アップグレードしても、無効な参照が有効になるわけではありません。 |
実際の設定でdialer-proxyの参照先を確認する
最初にクライアントのバージョン、実際に動作中のMihomoのバージョン、起動ログを記録します。デスクトップクライアントとコアのバージョンは別です。コマンドラインのmihomo -vがPATH内の別の実行ファイルのバージョンを示している場合もあるため、クライアントが現在使っているコアと一致することを確認します。
サブスクリプションの原文だけでなく、クライアントが最終的にコアへ渡す設定を確認します。proxiesの多数の項目にdialer-proxyが指定され、参照先のアウトバウンドプロキシまたはプロキシグループが存在するか確かめます。関連する項目が少数なら、通常はこの処理負荷の問題には当たりません。proxy-providersは旧来のこの検証の対象外なので、ノードの総数だけで判断しないでください。
proxies:
- {name: relay, type: socks5, server: 127.0.0.1, port: 1080}
- {name: node-a, type: socks5, server: 127.0.0.1, port: 1081, dialer-proxy: relay}
- {name: node-b, type: socks5, server: 127.0.0.1, port: 1082, dialer-proxy: relay}例のrelayは参照先のプロキシ名です。ローカルアドレスとポートは仮の値なので、実際のサブスクリプションの代わりに貼り付けないでください。AがBを参照し、BがAを参照する場合や、項目が自身を参照する場合は、実際の循環です。参照先が改名されたり、上書き設定で削除されたりした場合も、dialer-proxyを消して検証を飛ばすのではなく、正しい参照関係を先に戻します。
設定一式のコピーで、元に戻せる状態を保って検証する
条件をそろえて比較する
まず動作していた設定を保存する
現在の設定、上書き設定、外部リソース、クライアント設定を別のディレクトリにバックアップし、元のコアのバージョンとシステムプロキシ/TUNの状態を記録します。唯一のデータディレクトリで、アップグレード、サブスクリプション変更、DNS調整を同時に行わないでください。
検証に使うプログラムとディレクトリを確かめる
コマンドラインを使う場合は、まず検証対象のファイルが実在し、内容が正しいことを確認してから、仮のパスを設定一式のコピーのパスに置き換えます。-vはバージョンを表示します。-tはデータディレクトリを初期化し、-fで指定したファイルがないと既定の設定を生成する場合があるため、読み取り専用の操作ではありません。-dにはコピー側のデータディレクトリを指定し、元の相対パスとリソースの依存関係も一緒に保ってください。検証が成功したというだけで、目的の設定を検証できたとは判断しないでください。
一度だけ検証し、結果を記録する
中断しても支障のない時間帯に、開始から終了までの時間、プロセスのメモリ使用量のピーク、最初のエラーを確認します。検証はリソースを消費したり外部リソースを読み込んだりする可能性があり、ネットワーク通信が発生しないとは保証できません。アプリが管理するコアに対応したコマンドラインの起動方法がない場合は、プロジェクトが提供する設定の検証機能とログを使い、内部のプログラムを無理に取り出したり上書きしたりしないでください。
mihomo -v
mihomo -t -d "/path/to/complete-copy" -f "/path/to/complete-copy/config.yaml"実際に動いているコアを更新し、循環の検証は残す
v1.19.33の正式リリースノートには、#3315の修正が記載されています。固定タグのソースコードでは探索状態を再利用し、参照を持つ各ノードに対して大きな検証用データを繰り返し割り当てる処理を避けています。参照先が存在しない場合や循環参照のエラーは引き続き検出します。更新が改善するのは検証処理の負荷であり、実際の設定の参照関係を修正するものではありません。
プロジェクトが対応する方法で更新する
まず更新元を確認する
コアを単体で使う場合は、MetaCubeX/mihomoの安定版リリースから、使用するシステムとアーキテクチャに合う版を選びます。クライアントを使う場合は、そのプロジェクトが対応するアプリまたはコアの更新手順に従い、サービスディレクトリ内の実行ファイルを勝手に上書きしないでください。
修正が含まれていることを確かめる
v1.19.33は、この記事で正式な修正版として確認したバージョンです。FlClash v0.9.2の更新履歴にはMihomo v1.19.33の同梱が明記されており、出典のある例として参照できます。他のクライアントではそれぞれの更新履歴を確認してください。アプリの更新が成功しただけで、コアも置き換わったとは判断できません。
動作中のバージョンをもう一度確認する
プロジェクトの指示に従って対象のアプリまたはコアを通常の手順で再起動し、実際のプロセスや起動ログでバージョンを確認します。元の設定とリソースのコピーは残し、最初の検証では、ノードの変更、サブスクリプション更新、DNS変更を同時に行わないでください。
同じ設定での検証後に、実際のプロキシ通信を確認する
検証チェックリスト
- 実際に動作中のコアにv1.19.33の#3315修正が含まれることを確認しました。クライアント画面だけを更新した状態ではありません。
- 同じ設定一式のコピーに対する-tでの検証、またはアプリが管理するコアの対応する検証機能が正常に終了し、対象の設定が実際に読み込まれたことを確認しました。同じ機器で負荷が近い条件をそろえ、所要時間とメモリ使用量のピークを比較します。他の人の秒数やメモリ上限を自分の基準にしないでください。
- 通常の起動と再読み込みの後も、プロキシグループ、ノード選択、dialer-proxyの参照関係が意図した状態を保っています。
- 必要なシステムプロキシ/TUNを元の状態に戻した後、同じ接続先に実際のHTTPSリクエストを送り、接続記録を照合します。設定の検証に通っても、ノードが必ず使えるとは限りません。
- 参照先の欠落や循環のエラーが残る場合は、完全なエラー内容に従って設定を修正します。通信中にだけメモリが増え続ける場合は、他の原因を調べ、読み込みの負荷試験を繰り返さないでください。
当サイトでは、この記事のコマンドを実際のクライアントやルーターで実行していません。また、性能が何倍になるといった保証もしていません。ここでの比較は、自分の設定が確認済みの修正の対象に当てはまるか判断するためのものです。ネットワーク、機器のメモリ、他の設定の問題は、引き続き個別に確認する必要があります。
更新後も不調なら、まず使える状態に戻す
まず現在のエラーと設定のコピーを保存し、再読み込みの繰り返しを止めます。事前の記録に従って、今回新たに有効にしたシステムプロキシ/TUNのスイッチを元に戻し、以前使えていたネットワークの接続方法を復元します。問題を隠すために全ルールを削除したり、セキュリティソフトを無効にしたりしないでください。
アップグレードで互換性の問題が起きた場合は、そのプロジェクトが対応する方法で動作実績のあるバージョンと、それに合う設定・リソースを復元します。新旧のバージョンで唯一のデータディレクトリを共有しないでください。旧版にはこの記事の検証処理の負荷が残っている可能性があるため、バージョンを戻すこと自体は修正ではありません。メモリの少ない機器では、まず以前使えていた設定に戻し、問題のある大規模設定の読み込みは見合わせてください。
プロジェクトに報告するときは、動作中のコアのバージョン、システムとアーキテクチャ、読み込みのどの段階か、関連する項目数の規模、所要時間とメモリの傾向、機密情報を伏せたエラーを添えます。サブスクリプションのトークン、ノードのパスワード、秘密鍵、実際のサーバー情報を削除してください。できるだけ最小限の参照関係だけを残し、完全なサブスクリプションを公開しないでください。