Shadowrocketのバッテリー使用割合が高くても、端末全体の電力を同じ割合で消費しているとは限りません。通信処理、バックグラウンド接続、異常な再試行を切り分けてから、接続を維持するかOn Demandを設定するか判断しましょう。この記事では、自分で利用しているサービスとサブスクリプションがあり、iPhoneやiPadの待機中のバッテリー消費を調べたい方を対象に、比較記録の取り方とオンデマンド接続が現在のネットワーク環境に適しているかを確認する手順を説明します。
1. まずバッテリー残量の変化を確認し、アプリの割合を見る
システムの「設定 → バッテリー」で、同じ集計期間を選び、バッテリー残量の推移、画面の使用状況、Shadowrocketのアクティビティを確認します。アプリ一覧の割合は、その集計期間にアプリに割り当てられたバッテリー使用量の比率であり、端末全体のバッテリーをその割合だけ直接消費したという意味ではありません。端末全体の消費量が少ない場合でも、通信処理を継続しているアプリの割合が高く表示されることがあります。
たとえば、バッテリー残量が80%から70%に減り、アプリ一覧でShadowrocketが30%と表示されても、Shadowrocketだけで残量を30ポイント消費したという意味ではありません。バッテリー画面の数値はシステムによる推定値であり、この2つの数値からアプリの正確な消費量を計算することもできません。確認したいのは、条件が近いときに端末全体のバッテリー減少が継続して速くなるか、発熱や接続失敗を伴うかどうかです。
以下の数値は記録方法の例であり、実測値やバッテリー駆動時間の保証ではありません。写真の同期、動画の再生、大容量ファイルのダウンロードをしている時間帯は、まずその活動を別に記録し、通信量がほとんどない待機時間帯と直接比較しないでください。
2. バックグラウンドでの常時接続は何を消費するのか
Shadowrocketの画面が前面に表示されていないときも、接続中のVPNネットワーク拡張機能はシステム上で動作できます。設定に従ってトンネルに入る通信を処理し、他のアプリからのバックグラウンドリクエストも対象になる場合があります。アプリの画面を閉じてもネットワーク拡張機能が停止するとは限らないため、「アプリをスワイプして終了した」ことを接続停止の判断基準にしないでください。
- 通信処理:動画、ファイル転送、バックグラウンド同期があると、パケット処理、暗号化・復号、ネットワーク通信の負荷が増えます。実際の通信量とバッテリー残量の変化をあわせて記録しましょう。
- 接続の維持:接続を維持するためのキープアライブが必要な場合があります。実際の頻度はプロトコル、設定、接続先の要件によって異なるため、すべてのプロトコルのバックグラウンド動作を一律に扱うことはできません。
- 不安定なネットワーク:電波が弱い、Wi-Fiとモバイル通信が切り替わる、接続先に到達できないといった状況では、接続の再確立やアプリによる再試行が発生することがあります。モバイル通信の無線モジュール自体の消費電力も、端末全体の結果に影響します。
- 診断とテスト:接続テストを続ける、速度測定を繰り返す、詳細なログを長時間確認するといった操作は、追加の動作を発生させます。原因を調べ終えたら、手動での連続テストを停止してください。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは通信方式や接続の仕組みが異なりますが、プロトコル名だけでバッテリー消費の優劣を決めることはできません。利用中のサービスが対応する範囲で、実際のネットワーク品質、接続成功率、再試行の状況を比較してください。バッテリーを節約するために、サービス提供者が指定するパラメーターをむやみに削除しないでください。
3. 常時接続とOn Demandの違い
接続を維持する設定では、ネットワーク拡張機能を継続して利用できる状態にします。一方、On Demandでは、オンデマンドルールやネットワークイベントに基づき、システムが接続するかどうかを判断します。「Shadowrocketの画面を開いている間だけ接続する」という意味でも、画面ロック後に自動で切断されるという保証でもありません。他のアプリからのリクエストが、ルールに応じて接続を開始させる場合もあります。
| 設定・状態 | 主な役割 | バッテリー消費の確認ポイント |
|---|---|---|
| 接続を維持 | 現在のVPN接続を継続して利用できる状態にする | 通信の継続、キープアライブ、異常な再接続がないか確認する |
| On Demand | システムのルールとネットワーク状況に応じて接続を開始する | ルールの範囲が広すぎて、頻繁または継続的に接続が開始されていないか確認する |
| Global Routing → Config | 現在のConfigのルールに従って通信のポリシーを選択する | モード名だけでなく、実際に適用されたルールを確認する |
| Global Routing → Proxy | グローバルプロキシの状態で通信を処理する | プロキシ経由で処理される通信の範囲が広がる可能性がある |
| Global Routing → Direct | グローバル直接接続の状態で通信を処理する | VPNネットワーク拡張機能が停止するわけではない |
| Global Routing → Scene | 設定済みのSceneに応じてルーティング動作を選択する | Sceneの条件と実際の適用結果を確認する |
結論:接続の開始条件と通信の振り分けを分けて考える
接続するタイミングを制御したい場合はOn Demandを確認し、リクエストの経路を制御したい場合はGlobal RoutingとConfigを確認してください。ProxyをDirectに変更しても接続の切断にはならず、バックグラウンドのネットワーク拡張機能が停止したことも確認できません。
4. On Demandを順番に比較テストする
テストの前に、現在のConfigが正常に使えることを確認し、元の設定を保存してください。一度に変更する項目は1つだけにします。まず接続方式を比較し、その後にルーティングやプロトコルを検討します。ネットワーク、接続先、ルールを同時に変更すると、バッテリー消費が改善しても、どの変更が効果をもたらしたのか判断できません。
-
基準値を記録する
システムの「設定 → バッテリー」で開始・終了時の残量、時間、画面の使用状況を記録します。ShadowrocketのHomeでは接続状態とGlobal Routingを記録してください。観察時間は60分などに設定し、その間は普段と同じような使い方を保ちます。
-
オンデマンドルールを確認する
ShadowrocketのSettings → On Demandを開き、機能が有効か、現在どの条件が設定されているかを確認します。メニューに表示される具体的なルール項目は現在の画面で確認してください。まず現在の状態を記録し、出所のわからないルールにそのまま置き換えないでください。
-
システムの状態を確認する
システムの「設定 → 一般 → VPNとデバイス管理 → VPN」を開き、Shadowrocketの構成と接続状態を確認します。システムに「オンデマンド接続」のスイッチが表示される場合は、その状態も記録してください。表示場所はシステムのバージョンによって多少異なることがあります。
-
実際に接続が開始される条件を確認する
Homeに戻って接続状態を確認し、普段行うリクエストを1回実行します。画面ロック中、ロック解除後、Wi-Fi切り替え後の結果をそれぞれ記録してください。切断後すぐに再接続する場合は、On Demandの条件とバックグラウンドリクエストを先に確認し、接続スイッチの故障と決めつけないでください。
-
変更する項目を1つに絞って比較する
現在の状態を記録してからOn Demandをオフにし、Homeで接続を切断して、システム上のVPN状態が変わったことを確認します。同じ長さで負荷が近い時間帯を選んで観察してください。テスト後は必要な接続状態に戻し、その後のネットワーク利用に支障が出ないようにします。
短時間のテストで分かるのは、明らかな異常の切り分けまでであり、1日を通したバッテリー駆動時間を示すものではありません。2回のテストで電波強度、画面点灯時間、バックグラウンド同期に大きな差がある場合は、テストをやり直してください。接続を切った結果、一部のリクエストが完了せず通信量が減ったことを、クライアントの効率が向上したと説明しないでください。
5. 頻繁に再接続する場合は、まず失敗の原因を調べる
バッテリー消費の増加に加えてアクセスが遅い場合は、まず接続が安定しているか確認してください。ログに失敗が1件記録されただけで異常とは限りません。同じ接続先への失敗が短時間に繰り返され、リクエストの再試行や状態の頻繁な変化と対応している場合に、原因調査の手がかりになります。以下は表示される可能性のあるエラー文であり、すべての接続で同じ文言が出るとは限りません。
エラー:Operation timed out
原因:接続が制限時間内に完了しませんでした。通信経路のパケットロス、接続先に到達できないこと、接続先からの応答などが原因として考えられます。
対処法:まず安定したネットワークで1回再試行し、利用中のサービス提供者に現在のアドレスとポートを確認してください。原因を確認する代わりに速度測定を繰り返すのは避けましょう。
エラー:Connection refused
原因:接続先のアドレスには到達できても、接続が拒否されています。ポートで待ち受けていない、サービスの状態が変わった、アクセス制限があるなどの可能性があります。
対処法:既存の設定にあるサーバーとポートを確認し、利用中のサービス提供者から案内された有効なパラメーターに修正してください。推測でポートを次々と試さないでください。
利用中のサービス提供者から設定が変更されたと確認できた場合は、Homeで既存のSubscribe項目を更新し、現在選択中のConfigを確認してください。サブスクリプションの更新は最新の設定を取得するためのもので、あらゆる接続エラーを直す万能な方法ではありません。バッテリー消費の調査を理由に、短時間で何度も更新しないでください。
- モバイル通信でのみ異常がある:まず電波状況と通信エリアを比較し、Configは変えずに、安定したWi-Fiでも失敗が繰り返されるか確認してください。
- ネットワーク切り替え後に異常がある:一時的な接続の再確立が起きたか確認してください。長時間回復しない場合は、その時間帯のログを確認します。
- 特定の接続先でのみ異常がある:該当する項目のパラメーターとサービスの状態を確認し、既存のConfigを一度にすべて変更しないでください。
- 調査情報を共有する:エラーの原文、発生時刻、ネットワークの種類を記録してください。共有前にサブスクリプションのURL、認証情報、サーバーアドレス、個人のリクエスト履歴を隠してください。
6. すべてオン・オフにせず、使い方に合わせて選ぶ
仕事中に同じ接続を継続して使う場合は、接続を安定して維持したほうが、何度も手動で切り替えるより原因を調べやすいことがあります。特定のネットワーク条件でのみ接続が必要な場合はOn Demandを検討できますが、条件によって接続の開始範囲が実際に限定されるか確認してください。どのネットワークでも接続するルールにしても、接続時間が短くなるとは限りません。
| 使い方 | 優先して確認する項目 | 判断の目安 |
|---|---|---|
| 長時間連続して使用する | 接続の安定性、Global Routing、実際の通信量 | スイッチを何度も切り替えるより、接続失敗の再試行を減らすほうが効果的です |
| 特定の条件でのみ使用する | Settings → On Demandの条件 | 条件外でも接続が続いていないか、条件内で正しく接続が開始されるか |
| 夜間の待機中にバッテリーが大きく減る | バックグラウンド同期、電波状況、オンデマンド接続の開始条件 | 同じような待機時間で端末全体のバッテリー残量の変化を再現できるか |
| 切断後すぐに再接続する | アプリとシステムのオンデマンド接続状態 | まずオンデマンド接続をオフにしてから、手動で切断した結果を確認する |
Configでは、DOMAIN-SUFFIXはドメインの末尾、IP-CIDRはIPアドレスの範囲、GEOIPはIPアドレスの地理的な位置に基づいて照合します。FINALは、それ以前のルールに一致しなかったリクエストを処理します。ルールの順序と適用先のポリシーによって実際の通信経路が決まるため、ルールが設定されていてもすべてのリクエストが直接接続されるとは限りません。バッテリー使用状況での割合を下げるためだけに、FINALやプロキシが必要なリクエストをすべてDIRECTに変更しないでください。
結論:繰り返し確認できるバッテリー消費の変化を基準にする
必要なアクセスを満たし、接続が安定していて、比較結果にも問題のない設定を維持してください。アプリの割合だけが上昇し、端末全体の待機中のバッテリー消費、温度、アクセス状況に明らかな変化がない場合は、その割合を下げるためだけに設定を何度も変更する必要はありません。