待機中の電池減り、端末の発熱、バックグラウンドでの頻繁な切断、v2rayNGの電池使用率の異常に悩むユーザー向けです。まず同じ条件で基準値を取り、次にシステムのバックグラウンド制限を見直し、プロキシ対象を絞り込みます。最後にDNS、ノードの再接続、Muxを確認すれば、消費電力の原因が通常のVPN転送、ネットワーク再試行、設定範囲の広さのどれか判断できます。
まずプロキシによる消費か、電池統計の偏りかを確認する
Androidの電池画面に表示される割合は、特定の集計期間における消費の比率であり、アプリが端末全体の電池を同じ割合だけ消費したことを意味しません。端末全体の減少が4%で、そのうちv2rayNGが25%なら、推定への寄与は約1ポイントです。一晩で18%減り、その間v2rayNGがモバイルネットワークを継続して使用していた場合は、詳しい確認が必要です。
テスト前に画面の明るさ、ネットワーク種別、使用ノード、アプリ構成を固定します。Wi-Fiでの待機とモバイルネットワークでの動画再生を直接比較してはいけません。電池残量80%前後から始め、画面オン30分と画面オフ6時間のデータをそれぞれ記録します。テスト中はシステム更新、写真同期、大容量ファイルのダウンロードを停止し、他のバックグラウンド処理が結果に影響しないようにします。
v2rayNGはシステムのVPNインターフェースでトラフィックを受け取り、XrayコアにDNS、ルーティング、アウトバウンド接続の処理を渡します。プロキシを有効にしている間は、他のアプリが発生させた通信もVPNアプリの通信として集計される場合があるため、電池画面のv2rayNG使用率には一部の転送コストが含まれます。本当に注目すべきなのは、継続的なウェイクアップ、接続の繰り返し、過剰なDNSクエリ、不要な全量プロキシです。
| テスト項目 | 記録方法 | 注意すべき現象 |
|---|---|---|
| 画面オフ6時間 | 開始時と終了時の電池残量、ネットワーク種別を記録 | アクティブな処理がないのに8%以上減り、端末が温かい状態を保つ |
| ウェブ閲覧30分 | 明るさを固定し、同じページにアクセス | プロキシ有効時の追加消費が、無効時の2倍を超える |
| バックグラウンド活動 | システムの電池詳細でフォアグラウンドとバックグラウンドの時間を確認 | 画面オフ中のバックグラウンド活動がテスト時間のほぼ全体に及ぶ |
| 接続ログ | 同じエラーが連続して繰り返されていないか確認 | 数秒おきにタイムアウト、名前解決、再接続の記録が出る |
システムの省電力設定とバックグラウンド維持を見直す
省電力設定は、制限を緩めれば緩めるほどよいわけではありません。システムがVPNサービスを頻繁に終了させると、v2rayNGはVPNインターフェースを再作成し、ノードのアドレスを解決して接続を確立し直すため、「終了—再起動—再接続」のループが生じます。安定したバックグラウンド維持は、数分おきのコールドスタートより省電力になりやすく、画面オフ後の通知遅延も減らせます。
Androidメーカーによってメニュー名は多少異なりますが、目的は同じです。v2rayNGのバックグラウンド動作を許可し、このアプリの自動凍結を無効にしつつ、システムVPNの常駐通知は残します。以下は一般的なAndroid 14、Android 15の設定構成とv2rayNG 1.10.xの画面を基準にしています。
電池の最適化を解除
システムの「設定」→「アプリ」→「v2rayNG」→「アプリのバッテリー使用量」を開き、「制限なし」または同等の項目を選択します。メーカーが用意するスリープ凍結リストも同時に有効にしないでください。
バックグラウンド通信を許可
「設定」→「アプリ」→「v2rayNG」→「モバイルデータとWi-Fi」を開き、バックグラウンドデータを有効にします。データセーバー使用中も動作させる場合は、「データ使用量を制限しない」も有効にします。
バックグラウンドの許可リストに追加
端末の「電池」→「バックグラウンドでの使用制限」または「アプリの起動管理」で、自動起動、関連起動、バックグラウンド実行を許可します。メーカーのシステムに一括スイッチしかない場合は、v2rayNGの自動管理を無効にします。
常駐通知を残す
「設定」→「通知」→「v2rayNG」を開き、VPNサービスの通知を残します。通知はフォアグラウンドサービスの状態表示に使われるため、通知を隠す目的でアプリを強制停止しないでください。
接続を一度再構築する
v2rayNGのメイン画面に戻り、現在の接続を停止して5秒待ってから再起動します。画面を10分ロックし、ステータスバーのVPNマークとネットワークアクセスが正常か確認します。
一部のシステムには「最近使ったアプリをロック」もあります。これは一括消去時のプロセス終了を防ぐ機能であり、電池の許可リストの代わりにはなりません。ここまで設定した後、いわゆるバックグラウンド強化ツールを複数追加しないでください。複数の管理機能が同時にプロセス優先度を変更すると、ウェイクアップが重複することがあります。
結論:維持すべきは高頻度の活動ではなく安定性
望ましい状態は、VPNサービスが長時間存在しながら、画面オフ時の接続とDNSリクエストが明らかに減ることです。バックグラウンド時間が長くても連続した通信がなければ、通常のフォアグラウンドサービスである可能性が高いでしょう。数秒おきにログへ再接続が出る場合に、ノード、DNS、ネットワーク切り替えを確認します。
アプリ別プロキシとルーティングルールで処理範囲を絞る
全量VPNでは、システム同期、LAN機器の検出、ソフトウェア更新、メディアのバックアップを含め、端末上のすべてのアプリの通信を受け取ります。最終的に直結と判定される通信でも、VPNインターフェースとルーティングの判定を通る場合があります。本当に必要なアプリだけをプロキシすれば、接続数、DNSクエリ、コアの処理時間を直接減らせます。
v2rayNGのアプリ別プロキシは、使用アプリがある程度固定された端末に適しています。「設定」→「アプリ別プロキシ」を開いて機能を有効にし、プロキシ経由にするアプリを選択します。現在のモードが「選択したアプリのみプロキシ」になっていることを確認し、選択条件を逆に解釈しないよう注意してください。バージョンによっては「選択したアプリをバイパス」と「選択したアプリをプロキシ」という2つの項目で表示されるため、保存前に説明文を確認します。
現在の設定を記録
変更前に、アプリ別プロキシとルーティング設定の現在の状態をスクリーンショットで保存し、使用中のサーバーを記録します。アクセスに違いが出たとき、サブスクリプション全体を再インポートせず、項目ごとに戻せます。
アプリの対象を絞る
「設定」→「アプリ別プロキシ」を開き、まずプロキシが本当に必要な2〜5個のアプリだけを選択します。プロキシの出口が機能しているか確認しやすいよう、ブラウザをテストの入口として残します。
LANを直結にする
「設定」→「ルーティング設定」を開き、プライベートアドレス帯が直結になっていることを確認します。一般的な範囲は
10.0.0.0/8、172.16.0.0/12、192.168.0.0/16です。重複するルールを減らす
同じ作用を持ち、順序が競合するカスタムルールを削除します。ルーティングは上から順に照合されるため、明確なブロック条件と直結条件を、汎用的なプロキシルールより前に置きます。
30分間再テスト
同じノードとネットワークで、普段どおりの操作を30分間行います。接続数、端末温度、1時間あたりの電池減少量を比較し、その後にアプリの対象を広げるか判断します。
| 通信の種類 | 推奨する接続先 | 省電力になる理由 |
|---|---|---|
| 家庭用ルーターとLAN機器 | 直結 | ローカルリクエストが遠隔ノードへ回され、失敗と再試行を起こすのを防ぐ |
| プロキシ不要のシステム更新 | 直結、またはアプリ別プロキシの対象外 | 大容量通信がVPNインターフェースを通る量を減らす |
| 固定したプロキシ出口が必要なアプリ | プロキシ | 必要な機能を保ち、端末全体をプロキシに通さない |
| 広告と既知の追跡ドメイン | ルールに従ってブロック | 無効な接続を減らす。ただしルールを無制限に増やさない |
DNSタイムアウト、ネットワーク切り替え、再接続の繰り返しを確認する
消費電力が増える原因は、暗号化処理そのものより、接続失敗の再試行であることが少なくありません。モバイル電波が弱い、ノードのドメイン解決に失敗する、IPv6経路に到達できない、Wi-Fiとモバイルネットワークが頻繁に切り替わるといった状況では、コアがDNSクエリとTCP接続を繰り返します。ログに同種のエラーが集中しているかどうかは、単発のエラーより診断に役立ちます。
v2rayNGのメイン画面でログを開き、まず関係のないアプリの通信を止めてから2〜3分観察します。context canceled が一度出るのは、ノードの切り替えやサービス停止による正常な記録の場合があります。数秒おきにタイムアウトが繰り返されるなら、バックグラウンド権限を単に緩めるのではなく、ノードへの到達性、DNS設定、現在のネットワークを確認します。
エラー:dial tcp: i/o timeout
原因と対処:制限時間内に対象アドレスへの接続が完了していません。ノードに到達できない、電波が弱い、ポートが制限されている場合によく発生します。同じネットワークで別の利用可能なノードを試し、Wi-Fiとモバイルネットワークを切り替えて比較し、無効なアドレスへの再接続を繰り返さないようにします。
エラー:failed to find an available destination
原因と対処:ドメイン解決、ルーティング先、またはアウトバウンド経路から利用可能なアドレスを取得できていません。サーバーアドレスの綴りとDNS設定を確認し、サブスクリプションを更新してからコアを再起動します。ノードのドメインを同じプロキシのアウトバウンドへ誤って戻していないことも確認してください。
エラー:context canceled
原因と対処:接続のコンテキストが停止しています。手動切断時の記録なら正常です。画面オフ後も続く場合は、システムがVPNサービスを繰り返し終了させていないか確認し、電池の許可リストとバックグラウンド実行権限を設定し直します。
エラー:network is unreachable
原因と対処:現在のネットワークに、対象のアドレスファミリーへ到達する経路がありません。ネットワークを切り替えて比較し、ノードアドレスが到達不能なIPv6レコードだけを返していないか確認します。ネットワークが復旧していない状態で再接続を連打しないでください。
DNS設定は単一で、動作を説明できる状態に保ちます。複数のリモートDNS、FakeDNS、複雑なフォールバック条件を同時に追加してから消費電力を判断しないでください。まず安定したローカルまたはリモートの名前解決を1つ使い、ノードのドメインが解決できることを確認します。その後、振り分けの要件に応じてルールを追加します。DNSのポートは通常53で、暗号化DNSは対応するプロトコルとエンドポイントで決まります。ポートを853に変えるだけでは設定は完了しません。
記録する項目
テストネットワーク:Wi-Fi / モバイルネットワーク
テスト時間:画面オン30分、画面オフ6時間
使用ノード:同じサーバーに固定
タイムアウト回数:ログにおける i/o timeout の出現回数
再接続間隔:連続するエラー間の秒数
1時間あたりの電池減少量:テスト時の電池差 ÷ テスト時間
結論:連続する失敗をなくしてから、パラメータを微調整する
ノードが5〜10秒ごとに再試行している状態では、Muxやアプリ別プロキシを調整しても一部の症状を隠すだけです。まずログから連続タイムアウトをなくし、その後同じテスト条件で省電力設定を比較して初めて、結果に意味が出ます。
Muxは決まった省電力スイッチではない
Muxは複数の論理接続を基盤接続上で多重化します。理論上は頻繁なハンドシェイクを減らせますが、すべてのネットワークやサーバー設定で省電力になるとは限りません。長時間の接続が多く、ネットワークが安定し、サーバーが正しく対応している場合は、接続確立回数を減らせる可能性があります。弱いネットワーク、基地局の頻繁な切り替え、サーバー側の処理不良では、多重化接続の障害が複数リクエストの再構築を引き起こします。
「接続数が少ない」だけで消費電力を判断しないでください。初回データ到着までの遅延、失敗時の再試行、画面オフ後の接続維持を同時に確認します。短時間の接続が多いウェブ閲覧では有効化を試せますが、リアルタイム通信、継続的なダウンロード、ノードが独自の多重化機構を使っている場合は、効果が小さいことがあります。
| 利用シーン | Muxのテスト方針 | 確認する指標 |
|---|---|---|
| 安定したWi-Fi、短時間の接続が多い | 無効と有効をそれぞれテスト | 30分間の接続確立回数、初回データ到着までの遅延 |
| モバイルネットワークを頻繁に切り替える | まず無効にして基準値を取る | 切り替え後の復旧時間、タイムアウトと再接続の回数 |
| 継続的なダウンロードまたは動画ストリーミング | 通常はMuxによる省電力を期待しない | 通信速度の安定性、端末温度、1時間あたりの電池減少量 |
| サーバーが正しく対応していない | 無効のままにする | プロトコルエラー、接続中断、ページ読み込み失敗 |
操作中に現在のサーバーの編集画面を開き、トランスポートまたは詳細パラメータにあるMux設定を確認します。サブスクリプションからインポートしたノードは、更新後に手動変更が上書きされる場合があります。そのため、各テストの前に実際に有効な値を確認してください。完全なカスタム設定を使う場合は、メイン画面の表示名だけでなく、アウトバウンドオブジェクト内の多重化設定を確認します。
結論:2回の比較テストでMuxを決める
ノードとネットワークを固定し、それぞれ30分テストしてタイムアウト回数と電池減少量を記録します。差が2ポイント未満で接続の安定性も近い場合は、デフォルト値のままで問題ありません。有効化後に再接続が明らかに増えるなら無効にし、まずサーバーの対応状況を確認します。
決めた順序で最終テストを行う
確認が終わったら、再現可能な普段使いの設定に戻します。有効な設定には、画面ロック後も切断しない、ログに連続エラーがない、単位時間あたりの電池減少量が安定範囲に戻るという3条件があります。1項目だけを見ると誤判定しやすく、たとえばバックグラウンドを強制終了すれば一時的に消費は下がっても、通知とバックグラウンド通信が損なわれます。
- サブスクリプションを更新し、利用可能であることを確認したノードを1つ選びます。テスト途中でサーバーを自動切り替えしないでください。
- v2rayNGを再起動し、画面を10分オフにしてもVPN状態が維持されていることを確認します。
- アプリを固定して30分テストし、開始時の電池残量、終了時の電池残量、ネットワーク種別、端末温度の変化を記録します。
- 画面オフ6時間のテストを行います。手動のダウンロードと大規模な同期は停止しますが、通常のメッセージ受信は残します。
- ログのタイムアウト、名前解決失敗、再接続回数を確認し、変更前の記録と比較します。
- 2回連続で近い結果になってから、プロキシが必要な他のアプリを少しずつ追加します。
| 再テスト結果 | 判断 | 次の手順 |
|---|---|---|
| 画面オフでも安定し、ログが静かで、電池減少量が低下 | バックグラウンドとルーティングの調整が有効 | 設定を維持し、必要なアプリを段階的に戻す |
| 画面オフで切断し、再び画面をオンにすると復旧 | システムがまだバックグラウンドサービスを制限している | 電池の許可リスト、バックグラウンドデータ、起動管理を再確認 |
| 発熱が続き、タイムアウトが集中して発生 | ノードまたはネットワーク経路に異常がある | 検証済みのノードへ変更し、別のネットワークでも比較 |
| 接続は安定しているが、全量プロキシの消費電力が高い | 処理範囲が広すぎる | アプリ別プロキシを有効にし、直結ルールを追加 |
よくある質問
v2rayNGを有効にすると、電池画面での使用率が高くなるのはなぜですか?
システムがVPNインターフェースを経由した一部の通信をv2rayNGに計上している可能性があります。アプリの使用率だけで判断せず、端末全体の実際の電池減少量、バックグラウンド活動時間、ログの再試行頻度を確認してください。
「制限なし」にすると、必ず電池消費が増えますか?
バックグラウンドで計算処理を続けることと直接同じではありません。主な目的は、システムがVPNサービスを繰り返し終了するのを防ぐことです。安定した待機状態は、頻繁な終了、再解決、再接続より制御しやすい傾向がありますが、アプリ別プロキシと正しいルーティングも必要です。
アプリ別プロキシを有効にした後、一部のアプリが通信できない場合はどうすればよいですか?
まず現在のモードが「選択したアプリをプロキシ」か「選択したアプリをバイパス」か確認し、対象アプリが別のシステムコンポーネントに依存していないか調べます。関連コンポーネントを一時的に追加して比較し、問題を隠すためにすぐ全量プロキシへ戻さないでください。
v2rayNGとv2flyNGの対処方法は同じですか?
システムのバックグラウンド権限、アプリ別プロキシ、ネットワークの基準値を確認する考え方は同じですが、使用するコアと一部のメニューは異なります。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用するため、ログ項目と具体的なパラメータはそれぞれの画面を基準にしてください。
プロトコルを変更すれば、電池消費を直接解決できますか?
プロトコルは要因の1つにすぎません。ノードのパケットロス、DNSタイムアウト、ネットワーク切り替え、全量プロキシを先に確認する価値があります。同じノード条件で比較テストを行って初めて、VMess、VLESS、その他の設定済みプロトコルによる実際の差を判断できます。