Clash モバイル版の異常なバッテリー消耗の調査とバックグラウンド動作の最適化
モバイル版 Clash のバッテリー消耗が大きい原因は、バックグラウンド常駐・グローバルルーティング・ログレベルにあることが多い。プラットフォーム別の省電力設定と調査手順を解説する。
まず前提:バッテリー統計の数値は過大評価されている
キーワード:バッテリー消耗の帰属。Android と iOS のバッテリー統計には共通の特徴がある。VPN トンネルを経由したトラフィックが発生させるネットワーク消費は、すべて VPN アプリの名目で計上されるのだ。Clash はモバイル端末では VPN として動作し、Android では VpnService インターフェース、iOS では Network Extension を経由する。WeChat の動画、ショート動画、地図ナビが流したすべてのバイトが Clash のトンネルを通るため、ベースバンドの起動や無線送信の消費電力もすべて Clash のものとして計上される。プロセス自体の CPU 消費は、統計上の数値のごく一部に過ぎないことが多い。
本当に異常かどうかは 2 つの指標で判断する。Android では「設定 → バッテリー → アプリのバッテリー使用量」に進み、Clash の項目を開いて CPU のフォアグラウンドとバックグラウンドの活動時間を確認する。iOS では「設定 → バッテリー」で Clash の行の下に表示されるバックグラウンド活動時間を見る。ルールモードで一日中常駐させた場合、Clash 自身の CPU 時間は通常数分程度で、割合が 5% 前後で推移するのは正常な範囲だ。割合が数日連続で 15% を超え、CPU 時間が時間単位に達する場合にのみ、次の調査に進む必要がある。
思い込みも排除する必要がある。プロキシを常駐させるようになると利用習慣も変わり、海外コンテンツを見る時間が増えれば、当然バッテリー持ちは短くなる。厳密には半日の対照テストを行う。Clash をオフにし、同程度の使用強度を保ち、画面オン時間と待機時の消耗を比較する。差が実在することを確認してから、設定をいじるかどうか判断しよう。
数値の見方
バッテリー使用量ランキングのパーセンテージは「帰属の割合」であり「プロセスの消費電力」ではない。Clash が異常かどうかは CPU 活動時間を基準に判断し、パーセンテージの順位だけを見てはいけない。
バックグラウンド常駐:省電力と切断防止のバランス
キーワード:バッテリー最適化のホワイトリスト。モバイル端末で最も一般的なジレンマは、システムが省電力のためにバックグラウンドプロセスを終了させ、トンネルが落ちればプロキシが切れることだ。クライアント側が切断を防ぐために常駐を強化すれば、その常駐手段自体が電力を消費する。正しい解決策は Clash により積極的な常駐をさせることではなく、システムの省電力対象リストから外し、システムに干渉させないことだ。
Android での標準的な手順は、Clash をバッテリー最適化のホワイトリストに追加することだ。手順:設定 → アプリ → 特別なアプリアクセス → バッテリー最適化 で Clash を見つけ、「最適化しない」に変更する。ホワイトリストに追加すれば、システムはバックグラウンドのネットワークやウェイクを制限しなくなり、フォアグラウンドサービスだけでトンネルを安定維持できる。追加の手段は不要だ。
中国メーカーの ROM にはさらに第二の制限がある。Xiaomi の MIUI では別途「自動起動」を有効にし、最近のタスク画面で Clash のカードを下に引いてロックする。Huawei の EMUI では「アプリ起動管理」で自動管理をオフにし、手動に切り替えてバックグラウンド活動を許可する。OPPO や vivo では設定項目の名前は異なるが、ロジックは同じだ。バックグラウンド実行を許可し、バックグラウンドでの高消費電力を許可する。この手順を欠くと、ホワイトリストに入れても ROM 独自のクリーンアップポリシーは防げない。
常駐通知はオフにしないこと。Clash の VPN 通知はフォアグラウンドサービス通知であり、Android 準拠の常駐メカニズムだ。通知が邪魔だからと通知権限を丸ごとオフにすると、フォアグラウンドサービスが格下げされ、プロセスが終了されるたびに再起動を繰り返す。再起動のたびにトンネルの再構築と再ハンドシェイクが発生し、かえって電力を消費する。
iOS 側に手動での常駐という概念はない。Network Extension はシステムが管理し、トンネルの起動と停止はシステムのスケジューリングに任される。Clash Plus のオンデマンド接続(On Demand)を有効にしておけば、システムがネットワーク需要に応じてトンネルを起動し、アイドル時にサスペンドする。手動で頻繁にオンオフするよりはるかに省電力だ。
省電力系ツールと VPN の競合
「バッテリー節約」「バックグラウンドクリーナー」系のツールは、VPN トンネルをクリーンアップ対象とみなす。トンネルを落とせばクライアントの再接続がトリガーされ、切断と再接続のループで電力を消耗する。こうしたツールを入れている場合は、まず Clash を除外リストに追加するか、ツール自体をアンインストールしよう。OS 標準のバッテリー管理で十分だ。
ルーティングモードとルールセット:マッチングコストの大半
キーワード:ルールモード。ルーティングモードは、どれだけのトラフィックが暗号化転送を通るかを決める、消費電力の差が最も大きい設定項目だ。グローバルルーティング(Global)では全トラフィックがプロキシに入り、すべてのバイトが暗号化と転送を通るため消費電力が最大になる。接続性の一時的な調査にのみ向く。ルールモード(Rule)では中国本土のサイトが直接接続になり、ルールに合致したトラフィックだけがプロキシを通る。普段はルールモードを常駐させるべきだ。ダイレクト(Direct)モードはプロキシを切るのと同じで、ここでの議論の対象外だ。
ルールセットは多ければよいというものではない。新しい接続のたびにルールを一つずつ照合するため、数万件の GEOSITE ルールはマッチングのたびに CPU コストが発生することを意味する。サブスクリプション設定に付属するルールセットで通常は十分であり、サードパーティの大規模リストを重ねる必要はない。ルール数が倍になればマッチングコストも倍になるのに、得られる恩恵は体感できないことが多い。
DNS には fake-ip を使う。redir-host モードでは、プロキシ対象のドメインをまず実際に DNS 解決してからルールマッチングに入る。解決のたびにネットワーク往復とベースバンドの起動が発生する。fake-ip モードは予約済みセグメントの偽アドレスを直接返し、ドメインをそのままリモート側の解決に渡す。ローカル解決の待ち時間と起動を省けるため、モバイル端末では有効化を推奨する。
DNS アップストリームは欲張らないこと。nameserver に 7〜8 個のアップストリームを並べると、並行クエリのたびに各アップストリームへパケットを送信し、無線モジュールが繰り返し起動される。低遅延のアップストリームを 2〜3 個残せばよい。たとえばキャリア DNS にパブリック DNS を一組加える形だ。
mode: rule
log-level: warning
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29このスニペットはサブスクリプション設定のオーバーライドセクションに組み込むか、クライアントの設定画面で各項目に対応させて入力する。変更後は設定を再読み込みして有効化する。
ログと画面更新:見落とされがちな 2 項目
キーワード:ログレベル。log-level を debug や info にしていると、接続の確立・マッチング・切断のたびにログが書き込まれる。頻繁なファイル書き込みとウェイクは、モバイル端末では紛れもない電力消費だ。普段は warning か error に固定し、問題を調査するときだけ一時的に info に戻し、終わったら元に戻す。
画面の常駐も同様に電力を消費する。接続パネルやログパネルはリアルタイムで更新され、画面を開いたまま接続のスクロールを眺めていると、CPU と画面の両方が起き続ける。確認が終わったら閉じ、クライアントを長時間フォアグラウンドに置かないこと。
ノードの自動速度テストは控えめに。一部のクライアントはデフォルトで全ノードに周期的な遅延テストを行う。間隔が短すぎると、定期的にノードリスト全体をなめることになり、数十から上百のノードそれぞれにプローブを送信する。自動テストをオフにするか、間隔を 30 分以上に伸ばそう。普段のノード選びには手動テストで十分だ。
プラットフォーム別 省電力設定チェックリスト
まず表で結論を示し、その後プラットフォーム別に展開する。
| 設定項目 | 省電力の方向性 | 説明 |
|---|---|---|
| ルーティングモード | ルール(Rule) | グローバルモードは全量を暗号化転送し、消費電力が最大 |
| DNS モード | fake-ip | ローカルでの実解決によるネットワーク往復を省略 |
| DNS アップストリーム | 2〜3 個 | 並行クエリ時に各アップストリームへパケット送信 |
| ログレベル | warning / error | debug と info は接続ごとにログを書き込む |
| 自動速度テスト | オフまたは 30 分以上 | 周期プローブがノードリスト全体をなめる |
| バッテリー最適化 | ホワイトリストに追加 | システムによるバックグラウンド強制終了と再接続の繰り返しを防止 |
Android(Clash for Android / FlClash)
- ルーティングモードはルールに固定し、障害調査時のみ一時的にグローバルへ切り替える。
- ログレベルは warning に設定し、障害調査時のみ一時的に info にする。
- 自動速度テストをオフにするか、間隔を 30 分以上に伸ばす。
- バッテリー最適化のホワイトリストと ROM のバックグラウンド権限は前節の通りに設定し、常駐はフォアグラウンドサービス通知に任せる。
- プロキシを使わないときはクライアント内で接続を切断する。カードをスワイプしてプロセスを終了させてはいけない。終了後の再起動による再構築コストは、常駐させるより高くつく。
iOS(Clash Plus)
- オンデマンド接続を有効のままにし、トンネルの起動と停止はシステムのスケジューリングに任せる。
- ルールモードと fake-ip の組み合わせは、Android 側と同じ理屈だ。
- ログレベルは warning か error にする。
- 低電力モードでシステムがバックグラウンドのネットワーク活動を圧縮するのは正常な動作だ。これを理由にトンネルを手動で繰り返し再起動してはいけない。
標準的な調査手順
バッテリー消耗の問題に遭遇したら、決まった順序で進める。各ステップで変数は一つだけ変え、変更後は半日から一日観察する。
- バッテリー統計の CPU とバックグラウンド活動時間を確認し、本当の異常か帰属による水増しかを見極める。
- ルーティングモードを確認し、グローバルならルールに戻す。
- ログレベルを warning に下げ、自動速度テストをオフにする。
- DNS アップストリームとルールセットを絞り、fake-ip が有効か確認する。
- バッテリー最適化のホワイトリストと ROM のバックグラウンド権限を再確認し、常駐通知は有効のままにする。
- 半日の対照テストを行う。それでも異常なら、ログを一時的に info にして一定時間分を採取し、機種と OS バージョンとともにクライアントのプロジェクトへ報告する。
大半のケースは 3 ステップ目までで正常水準に戻る。クライアントの欠陥が原因の消費電力は少数派だ。順序立てて調査すれば、行ったり来たりの試行錯誤を避けられる。