まずはバッテリー消費とバックグラウンド切断を切り分ける

まずは、システムのバッテリー使用状況を確認し、画面ロック後の接続状態を記録しましょう。発熱が続く、バックグラウンド通信量が増える、ロック後にプロキシ接続が切れる、といった症状はそれぞれ原因が異なります。前の2つは実際のネットワーク通信を減らす必要があり、最後の症状ではバックグラウンド制限を確認します。省電力制限をすべて解除すると接続が復旧する場合もありますが、頻繁なヘルスチェックによる電池消費が続く可能性もあります。

Androidのモバイルクライアントは通常、システムのVPNインターフェースを使って通信を処理し、mihomoなどのコアが設定の解析、ルール判定、接続処理を担います。iOSクライアントは一般にNetwork Extensionのトンネル拡張機能を使います。VPNアイコンはトンネルが接続中であることを示すもので、端末が常に高負荷で動作しているという意味ではなく、アイコンだけで電池消費の原因を判断することもできません。

あとから確認できる基準値を記録する

  1. 端末の機種、OSバージョン、クライアントのバージョン、コアのバージョンを記録します。コアの情報は通常、クライアントの「アプリ情報」や実行ログで確認できます。メニュー名はアプリによって異なります。
  2. 同じWi-Fi、同じノード、同じルールモードを使い、システムアップデート、写真のバックアップ、大容量ファイルのダウンロードは一時停止します。
  3. 画面をロックして60分間様子を見て、開始時と終了時の電池残量、切断の有無、クライアントのバックグラウンド通信量、ログに記録された再接続回数を記録します。
  4. 一度に変更する設定は1種類に絞り、再度同じ条件で確認します。少なくとも2回は試し、バッテリー残量の整数表示が変わっただけで結論を出さないようにしましょう。

たとえば、ある回は80%から77%に、別の回は80%から78%に減った場合、それぞれ3ポイント、2ポイント減ったことを示します。これは記録方法の例であり、本サイトでの実測値ではありません。短時間の差は電波状況、温度、バッテリー残量の推定にも左右されます。

Androidのバックグラウンド動作：必要なクライアントだけを許可する

まずは標準のバッテリー設定のまま使いましょう。画面ロック後も接続が維持されるなら、バックグラウンド動作を無制限に許可する必要はありません。ロック後にサービスが終了する、VPNアイコンが消える、ログにプロセスの再起動が記録される場合に限り、クライアントのバッテリー最適化設定を確認してください。

Androidの設定でバッテリー項目を確認する

  • Pixel／標準に近いAndroid 14：クライアントのアイコンを長押し →「アプリ情報」→「アプリのバッテリー使用量」→「バックグラウンドでの使用を許可」を確認します。システムによっては「制限なし」「最適化」「制限」の3つの選択肢が表示されます。
  • Samsung One UI 6：「設定」→「アプリ」→ クライアントを選択 →「バッテリー」→「制限なし」の順に開きます。さらに「設定」→「バッテリー」→「バックグラウンドでの使用を制限」を確認し、クライアントが「ディープスリープ中のアプリ」に登録されていないかチェックしてください。
  • その他のAndroid：アプリ情報で「バッテリー管理」「バックグラウンドでの実行」「自動起動」などの項目を探します。メーカーやシステムアップデートによってメニュー名は変わるため、手元の画面を確認し、ほかの機種の手順をそのまま当てはめないでください。

自動起動は、端末の起動時やプロセス終了後にアプリを起動する機能です。バッテリー最適化はバックグラウンド動作を制限し、最近使ったアプリのロックは一部メーカーのタスク終了動作に影響します。これらは別々の設定です。項目ごとに変更して結果を記録し、ネットワークを使うアプリをすべて許可リストに追加するのは避けましょう。

VPNの常時接続は省電力設定ではない

Androidの「VPNを常時接続」は、主にVPN接続を維持するための設定です。「VPN未接続時の接続をブロック」は、トンネルが使えない場合にほかのネットワーク通信を制限します。どちらもバッテリー最適化の設定ではなく、ノード自体の不安定さを解消するものでもありません。通信を常にVPN経由にする必要がある場合に限って有効にし、再起動、ネットワーク切り替え、画面ロック後に接続が復旧するか事前に確認してください。

iOSのAppのバックグラウンド更新：VPNトンネルとは別に設定する

iOS 17またはiOS 18では、「設定」→「一般」→「Appのバックグラウンド更新」からアプリの設定を確認できます。この設定は主に通常のアプリがバックグラウンドで更新できるかどうかを制御するもので、VPNトンネル全体のオン・オフではありません。通信を処理するトンネル拡張機能とクライアントのメイン画面は、動作の仕組みが異なります。バックグラウンド更新をオフにしてもVPNが必ず切断されるわけではなく、オンにしてもトンネルが停止しないとは限りません。

  • 設定を手動で読み込み、サブスクリプションも手動で更新する場合は、クライアントのメインアプリのバックグラウンド更新をオフにして、トンネルが正常に動作するか試せます。
  • サブスクリプションの自動更新を利用する場合は、クライアントがその機能に対応しているか、バックグラウンド更新が必要か、実際にどのような条件でシステムが実行を許可するかを確認してください。
  • 「設定」→「バッテリー」でアクティビティの記録を確認します。低電力モードをオンにした場合は、更新タスクや接続の復旧に影響がないか確認してください。

Androidの「バックグラウンドでロック」の使い方をiOSに当てはめないでください。省電力のテストとして、アプリスイッチャーからクライアントを何度も終了するのも避けましょう。メインアプリを強制終了すると、その後のバックグラウンドタスクに影響する場合があります。トンネルの動作はクライアントの実装によって異なります。まずはクライアント内の接続ボタンを使って、明確にオン・オフを切り替えて比較してください。

オンデマンド接続で不要な接続時間を減らす

クライアントにオンデマンド接続、信頼済みWi-Fi、ネットワーク変更時の接続といった機能がある場合は、まずどのネットワークでプロキシが必要かを整理してから条件を設定します。オンデマンド接続で管理するのはトンネルを確立するタイミングであり、ノードのヘルスチェック頻度ではありません。条件を増やしすぎたり、互いに矛盾する条件を設定したりすると、ネットワーク切り替え時に接続を繰り返すことがあります。まず条件を1つだけ設定し、Wi-Fiとモバイル通信を切り替えて動作を確認してから追加しましょう。

ヘルスチェック間隔：一斉探測と重複タスクを減らす

自動選択グループとプロキシプロバイダーのヘルスチェックを優先して確認しましょう。40個のノードを60秒ごとにチェックし、全ノードが毎回対象になると仮定した場合、1時間あたり約2,400回です。600秒間隔なら約240回になります。これは予定されるリクエスト数の概算です。遅延チェック、失敗時の再試行、実装の違いによって実際の回数は変わるため、一定の電池消費量に直接換算することはできません。

url-testのモバイル向け設定例

以下はmihomoのプロキシグループ設定例です。時間の単位は秒です。ノード名は現在の設定にある名前と一致させてください。この断片をサブスクリプション全体にそのまま上書きしないでください。次回のサブスクリプション更新で設定が元に戻らないよう、クライアントが対応しているオーバーライド機能や設定のマージ機能を使って変更しましょう。

proxy-groups:
  - name: モバイル自動選択
    type: url-test
    proxies:
      - 日常用ノード
      - 予備ノード
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true
  • interval: 600：定期ヘルスチェックの間隔を10分に設定します。省電力の比較を始める設定例であり、すべての構成に最適な値ではありません。
  • tolerance: 100：切り替えの許容幅をミリ秒単位で設定し、小さな遅延変動による切り替えを抑えます。接続タイムアウトの時間ではありません。
  • lazy: true：グループが使われていない間、定期チェックを減らします。具体的な動作は利用中のmihomoのバージョンによって異なります。
  • url：ここで指定するのはチェック先のURLであり、サブスクリプションのURLではありません。現在のネットワークから安定してアクセスできることを確認し、チェック先の障害をすべてのノードの障害と誤認しないようにしましょう。

安定したノードを1つだけ使う場合は、まず手動選択グループと比較してみましょう。自動ヘルスチェックの間隔を短くしながら、クライアントの全ノード定期チェックも有効にするのは避けてください。また、proxy-providersのhealth-checkも確認します。プロキシグループと別々にチェックを実行している可能性があります。重複タスクを減らしたうえで、切断時の復旧に必要な頻度に調整しましょう。間隔を長くすると、障害の検出が遅くなる場合があります。

サブスクリプションとルールセット：内容の変化に応じて更新頻度を調整

サブスクリプションの更新、プロキシプロバイダーの更新、ルールセットの更新、ノードのヘルスチェックは、それぞれ別のタスクです。サブスクリプションには設定全体が含まれる場合があり、プロキシプロバイダーは主にノードを提供します。ルールプロバイダーはルールを読み込み、ヘルスチェックはノードの使用可否を確認します。すべてを1分ごとに実行しても、日常的なメリットが同じように増えるわけではありません。

タスク比較の開始設定確認ポイント
サブスクリプション全体の更新24時間ごと、または手動更新後に設定が自動で切り替わるか、コアが再起動するか
ノードのヘルスチェック600秒全ノードのチェックも同時に実行されていないか
リモートルールセットの更新86400秒ファイルサイズ、失敗時の再試行、ルール数
リアルタイムログとダッシュボードトラブルの確認時のみ有効接続一覧や通信量グラフが常に更新されていないか

これらの値は比較の基準として使うもので、すべてのサービスに共通する推奨値ではありません。ノードが頻繁に変わるサブスクリプションは更新間隔を短くし、変更の少ないルールセットは1日1回の更新にできます。mihomoのHTTPタイプのrule-providersでは、interval: 86400は24時間を意味します。クライアント全体のサブスクリプション自動更新は分単位や時間単位の場合があるため、設定前に画面上の単位を必ず確認してください。

ログは原因を特定できる範囲で残す

通常はlog-level: warningを使用し、切断原因を調べるときだけ一時的にinfoへ切り替え、再現後に元へ戻しましょう。debugを常時有効にするとログの生成・処理負荷が増えます。リアルタイムの接続パネルを長時間表示したままにすることも、画面の更新処理を増やします。ログを減らす前に重要なエラーを保存してください。保存しないと、認証エラー、DNSタイムアウト、トンネルの再起動のどれが原因か判断できなくなります。

TUN、DNS、電波の弱さ：実際の通信元を確認する

モバイル端末のVPNによる通信処理は、デスクトップのシステムプロキシ設定と単純に同じものではありません。アプリごとにVPNを迂回できるか、TUNの設定が表示されるかは、クライアントとプラットフォームの機能によって異なります。Androidの一部クライアントはアプリ単位の振り分けに対応しており、プロキシが不要なアプリを迂回させられます。一方、iOSの一般的な個人向けVPNでは、Androidのアプリ除外リストと同じ設定をそのまま使うことはできません。

まず通信量の多いアプリを特定し、ルールの適用状況を確認します。動画の自動再生、クラウドストレージの同期、システムのダウンロードは無線通信を継続的に使うため、クライアント自身がヘルスチェックをしていなくても電池を消費します。対象の通信をDIRECTにすれば、不要なリモートプロキシ経由の通信を減らせます。ただし、VPNによる通信処理を完全に迂回するわけでも、通信そのものを止めるわけでもありません。

DNSモードだけで省電力になると考えない

  • まず、名前解決の繰り返し失敗、DNSタイムアウト、接続の再試行がないか確認してから、DNS設定を変更しましょう。Fake-IPが正常に動作しているなら、バッテリー消費ランキングで上位という理由だけで無効にする必要はありません。
  • 名前解決の経路を明確に保ちましょう。コアのDNS、システムの暗号化DNS、ほかのVPN系ツールを併用する場合は、到達できないDNSサーバーが指定されていないか、転送ループが発生していないか確認してください。
  • ネットワーク切り替え後に接続が一度再確立されるのは正常な場合があります。同じネットワーク上で再試行が続く場合は、ノードへの到達性、名前解決結果、ログの時刻を確認しましょう。

モバイル通信の電波が弱いと、無線通信の負荷が増えます。同じ場所でまずWi-Fiとモバイル通信を比較し、次に2つのノードを比べて、電波の問題をプロキシプロトコルのせいにしないようにしましょう。最も遅延の小さいノードが、必ずしも最も省電力とは限りません。1回の測定値より、通信が安定して再試行や切り替えが少ないことのほうが参考になります。

3回の比較でバックグラウンド接続と省電力のバランスを取る

  1. 1回目：バックグラウンドタスクを減らす：ノードを固定し、ヘルスチェックを600秒間隔、ルールセットを1日1回の更新に設定します。デバッグログを常時記録しないようにし、システムのバッテリー設定は変更しません。
  2. 2回目：バックグラウンド制限を確認する：画面ロック後に切断される場合に限り、Androidクライアントのバッテリー制限を緩和します。iOSではメインアプリのバックグラウンド更新設定とトンネルの接続状態を個別に確認します。
  3. 3回目：実際の使い方で確認する：普段使うアプリに戻し、動画視聴、同期、モバイル通信の使用量を記録し、こうした操作に応じて電池消費が増えるか確認します。

画面ロック中の接続、ネットワーク切り替え後の復旧、日常的な通信に必要なバックグラウンドタスクだけを残しましょう。発熱が続く、短時間に大量の通信が発生する、毎分再起動を繰り返すといった場合は、接続を一時停止して個人情報を伏せたログを保存し、トラブル対処で原因を確認してください。ログを共有する前に、サブスクリプションURL、トークン、ノードのパスワード、個人を特定できる情報を削除してください。

クライアントを変更する場合は、まずOSとコアの互換性を確認しましょう。クライアント、ノード、すべてのルールを同時に変更するのは避けてください。設定し直す必要がある場合は、入門ガイドを参考に項目ごとに復元し、動作確認済みの設定を比較用に保存しておきましょう。