接続中の待機で電池が急に減る、画面ロック後に通信が切れる、または電池使用量でv2rayNGの割合が高いAndroidユーザー向けです。まず実際の消費電力とアプリへの電池使用量の割り当てを切り分け、同じ時間・条件で比較しながら、バックグラウンド制限やノードの再接続、プロキシの対象範囲を確認します。そのうえで常時接続が必要か判断しましょう。設定は元に戻せるようにし、一度にすべてのバックグラウンド権限を許可するのは避けてください。
まず端末全体の電池残量を確認し、次にアプリの使用割合を見る
v2rayNGはXrayコアでプロキシ接続を処理し、通常はAndroidのVPNサービスを通じて選択したアプリの通信を受け取ります。電池使用量の画面でネットワーク処理の一部がVPNアプリに計上されても、消費のすべてがクライアント自体によるとは限りません。VPN経由の動画再生、写真の同期、アプリの更新によって、電池使用量の一覧でv2rayNGの割合が高くなる場合もあります。
システムに「電池使用量 30%」と表示されても、電池残量が30ポイント減ったという意味とは限りません。集計期間中に消費した電力のうち、アプリに割り当てられた割合を示している場合があり、算出方法はシステムによって異なります。より参考になるのは、同じ時間で端末全体の電池がどれだけ減ったか、画面点灯時間、ネットワーク環境が同じか、画面ロック後に接続が繰り返し切れていないかです。
| 確認項目 | 記録する内容 | 判断の目安 |
|---|---|---|
| 端末全体の電池残量 | 開始時と終了時の残量、測定間隔は60分 | 接続の前後で実際に消費量が増えたか |
| 画面の状態 | 画面点灯時間、動画再生の有無 | 画面表示やメディア処理の違いを除外する |
| ネットワーク環境 | 同じWi-Fi、または同じ場所でのモバイル通信 | 電波が弱いことによる消費をプロキシの影響と混同しない |
| 接続状態 | ノード、接続が途切れた時刻、ログのエラー | 再接続やリクエスト失敗の繰り返しを見つける |
たとえば、あるテストで80%から77%になった場合は3ポイント減、別のテストで80%から74%になった場合は6ポイント減です。これは記録方法の例であり、この記事での実測値でも合格基準でもありません。電池残量の表示には丸め誤差があるため、各条件で2回は繰り返し、5分間の一度きりの急減だけで判断しないでください。
バックグラウンド動作と電池の最適化：まず通信切断を防ぎ、許可は必要な範囲にとどめる
画面ロック後に通信できなくなり、画面を点灯するとすぐ復旧するなら、システムによるバックグラウンド制限が考えられます。画面点灯中もタイムアウトが続く場合は、まずノードとネットワークを確認してください。すべての最適化を無効にしても、必ず電池持ちがよくなるわけではありません。システムがサービスを停止していると確認できた場合に限り、v2rayNGのバックグラウンド制限を緩和しましょう。
-
現在の設定を記録する
ホーム画面のv2rayNGアイコンを長押しして「アプリ情報」を開き、電池と通知の権限を記録します。再テストで条件をそろえられるよう、アプリのバージョン、Androidのバージョン、現在のノード名も控えておきましょう。
-
電池関連の設定を確認する
システムの「設定」→「アプリ」→「v2rayNG」→「電池」または「アプリの電池使用量」を開きます。システムによって「制限なし」「最適化」「制限付き」と表示されたり、「バックグラウンドでの使用を許可」のスイッチが用意されていたりします。端末に表示される項目に従って操作してください。
-
画面ロック後の状態を確認する
まず現在の設定を維持し、接続可能なノードに接続してから30分間画面をロックします。ロック解除後、接続状態とログをすぐ確認してください。サービスの終了が何度も確認できた場合は、v2rayNGだけ電池の制限を緩和し、同じ時間で再テストします。
-
バックグラウンド動作の設定を確認する
メーカー独自のシステムに「自動起動」や「バックグラウンド動作」の設定がある場合は、システムの説明を確認しながら必要な項目だけ許可します。最近使ったアプリの画面で固定する操作は、すべての端末で必要とは限らず、電池の権限の代わりにもなりません。テストごとに変更するスイッチは一つだけにしてください。
-
効果のあった設定だけ残す
どの変更で通信切断が解消したかを確認し、それ以外は元に戻します。バックグラウンドの定期消去、アプリの定期起動、ノードの頻繁な切り替えを同時に設定しないでください。互いに干渉し、原因の特定が難しくなります。
VPNモード・アプリごとのプロキシ・ルーティングの使い分け
いわゆる「省電力プロトコル」を探すより、通信がどこを通るかを把握するほうが効果的です。VPNモードでは、仮想ネットワークインターフェースに入った通信が転送処理とルール判定を受けます。プロキシ経由のアウトバウンドに一致した通信だけがリモートノードを通ります。直接接続に一致しても、その通信が端末内のVPN処理を完全に迂回するわけではありません。
アプリごとのプロキシはAndroid側で対象アプリを選ぶ機能で、ルーティングはコアに入った通信をドメインやアドレスなどの条件で振り分ける機能です。両者は同じ設定ではありません。ブラウザーだけにプロキシが必要なら、すべてのアプリをいったんVPNに通してから個別に直接接続させるより、対象アプリを絞るほうがバックグラウンド通信を管理しやすい場合があります。ただし、電池消費への効果は条件をそろえた比較で確認してください。
- 選択したアプリだけをプロキシ経由にする：v2rayNGの「設定」→「アプリごとのプロキシ」で機能を有効にし、画面の説明に従ってプロキシを使うブラウザーなどを選びます。「選択したアプリがプロキシを使用する」設定になっていることを確認し、リストの意味を取り違えないようにしてください。
- 選択したアプリを除外する：「バイパスモード」が有効な場合、リストにあるアプリは通常VPNを経由しません。保存後、接続をいったん停止して再起動し、対象アプリの変更を反映させてください。
- すべてのアプリを接続する：全アプリの通信を一括管理する必要がある場合に適しています。この設定では、クライアントの項目だけでなく、クラウド同期、自動ダウンロード、ショート動画アプリのバックグラウンド再生も確認しましょう。
- プロキシモードのみ：使用中のバージョンにこのモードがある場合、ローカルプロキシを明示的に設定したアプリだけが利用できます。多くのAndroidアプリは、このプロキシを自動では使用しません。従来の全アプリを対象にする設定をそのまま置き換えることはできません。
メニュー名はバージョンによって変わるため、選択前に画面の説明を読んでリストの意味を確認してください。プロキシの対象を絞った後は、ログイン、ウェブページの表示、必要なメッセージの受信に問題がないか確認します。電池使用量の順位を下げるために、プロキシが必要なアプリを対象外にし、何度も再試行して使い続けることのないようにしてください。
ノードのタイムアウト・DNSエラー・接続の繰り返しをログで調べる
電池消費が増えても、接続数が多いとは限りません。リクエストが成功せず、アプリが何度も再試行している可能性もあります。余分な名前解決や接続確立、モバイル通信が発生することがあります。v2rayNGのメイン画面からサイドメニューの「ログ」を開き、異常が起きた時刻の記録を確認しましょう。ノードの遅延テストを一度実行した結果だけで判断しないでください。
エラー：i/o timeout
原因：ネットワークの読み書きが制限時間内に完了していません。ノードに到達できない、通信経路でパケットが失われる、上流からの応答が遅いなどの可能性があり、特定のプロトコルだけが原因とは限りません。
対処法：同じネットワークで、利用できることが確認済みの別ノードに切り替え、ほかの設定は変えずに試します。すべてのノードで発生する場合は、Wi-Fiとモバイル通信を比較し、接続先のネットワークによってエラーが変わるか確認してください。
エラー：no such host
原因：ドメイン名の名前解決に失敗しています。ログに記録されたドメインを確認し、ノードのアドレスか、アプリがアクセスしようとした接続先かを切り分けてください。
対処法：ノードのアドレスの入力ミスやサブスクリプションの内容を確認します。また、Androidの「設定」→「ネットワークとインターネット」→「プライベートDNS」で設定したホスト名が利用可能か確認してください。メーカーによってメニュー名は異なる場合があります。
エラー：bind: address already in use
原因：ローカルのリッスンアドレスまたはポートがすでに使用されており、コアが現在の設定で待ち受けを開始できません。
対処法：まず接続を停止し、重複して起動しているプロセスを終了してから再起動します。リッスンポートを手動で変更した場合は、関連する設定が競合していないか確認してください。外部の自動処理から、起動に失敗するサービスを繰り返し起動しないようにします。
上記はログに現れる可能性のあるエラーの一部です。通常は前後にアドレス、時刻、接続情報も記録されます。一度タイムアウトが起きただけでは、電池消費の原因とは断定できません。同じ接続先への失敗が画面ロック中に続き、ノード変更後にエラーと電池消費の両方が減った場合は、有用な手がかりになります。ログを共有する前に、サブスクリプションURL、アクセストークンなどの認証情報を削除してください。
3つの条件で比較し、設定変更の効果を確かめる
比較では画面の状態、場所、利用内容をそろえましょう。一方は電波の強いWi-Fiで画面をロックし、もう一方は地下鉄の弱い電波で動画を再生する、といった比較は避けてください。できれば充電中はテストせず、多数のアプリをインストールした直後、システム更新中、写真の一括同期中も測定しないでください。端末が明らかに熱くなったら高負荷の処理を止め、温度が下がってから比較します。
| テスト条件 | そろえる条件 | 比較するポイント |
|---|---|---|
| A：接続を停止 | 同じWi-Fi、画面ロック60分、バックグラウンドアプリは同じ | 端末の待機時の基準値。ネットワークに接続できないことで、自動的に再試行するアプリがある点に注意 |
| B：現在の設定 | 元のノードと対象アプリの設定を使い、画面を60分ロック | Aとの電池消費の差、サービスが停止していないか |
| C：一項目だけ変更 | ノードだけを変更、バックグラウンド設定だけを変更、または対象アプリだけを減らす | Bと比較し、変更した項目の効果を確認 |
Aではプロキシを停止することでアプリがネットワークに接続できるかどうかも変わるため、完全に公平な性能基準にはなりません。主に端末の基本的な状態を把握するためのものです。設定変更の効果を判断するには、同じ条件で行うBとCの比較を重視してください。差が1ポイント程度なら、まずテストを繰り返し、特定のスイッチが原因だと決めつけないようにしましょう。
- ノード変更後にタイムアウトが減り、端末の温度も下がった：まず安定して使える接続先を維持し、1日ほど様子を見ます。プロトコルの設定を同時に変える必要はありません。
- バックグラウンド制限を緩和した後、通信切断はなくなったが待機時の電池消費が増えた：大量のアプリ同期が再開していないか確認し、すぐにサービスを再制限するのではなく、プロキシの対象アプリを絞ることを検討してください。
- 接続を停止しても電池が大きく減る：システムの電池使用量画面で、画面、モバイル通信、位置情報、ほかのバックグラウンドアプリを確認してください。
- モバイル通信時だけ電池消費が目立つ：場所を固定して再テストし、電波状況とネットワーク切り替えの影響を切り分けます。異なる場所での測定結果をそのまま比較しないでください。
よくある質問：常時接続と省電力設定の選び方
画面ロック後に通信できない場合、電池の最適化をすべて無効にする必要がありますか？
まずv2rayNGだけ設定を変更します。「アプリ情報」→「電池」を開き、バックグラウンド制限を確認してください。このアプリだけ制限を緩和し、30分間テストします。サービスが動作しているのにログで接続タイムアウトが続く場合は、ネットワークとノードを調べましょう。端末全体のバックグラウンド制限を解除しても、通信経路の問題は通常解決しません。
Muxを無効にすれば、必ず電池が長持ちしますか？
一概には言えません。Muxは接続を多重化する仕組みで、効果はプロトコル、サーバーの対応状況、実際のリクエストによって異なります。一般的な省電力スイッチではありません。現在の設定でMuxが有効なら、設定をバックアップしてから、この項目だけ無効にし、同じ通信内容でエラー率と電池消費を比較してください。並列処理数やノードは同時に変更しないでください。
一日中接続するのと、使い終わったら切断するのでは、どちらがよいですか？
決まった時間だけプロキシを使うなら、使い終わった後に手動で切断するほうが、不要なバックグラウンド通信を抑えやすくなります。対象アプリの通知を一日中受け取る必要がある場合は、接続の安定性を優先し、プロキシを使うアプリを絞りましょう。接続がアイドル状態でもどれだけ通信が発生するかは、アプリのハートビート、バックグラウンド処理、ネットワークの変化によって異なります。稼働時間だけから電池消費を単純に計算することはできません。
v2flyNGに変えれば解決しますか？
v2rayNGはXrayコア、v2flyNGはv2flyコアを使用しています。同じクライアントの省電力設定違いではありません。切り替える前に、ノードのプロトコルと機能が対応しているか確認してください。クライアントの切り替えと設定変更が混ざらないよう、まずノード、バックグラウンド設定、対象アプリを比較テストしましょう。
最終的に残すのは、結果を説明できる設定です。どのアプリにプロキシが必要か、システムでどのようなバックグラウンド動作を許可するか、ノードは安定しているか、問題が起きたときにどう戻すかを整理しましょう。接続が安定し、端末全体の待機時の電池消費に問題がなければ、電池使用量の順位を気にして何度も設定を変える必要はありません。異常が続く場合は、バージョン、ネットワーク環境、テスト時間、個人情報を除いたログをそろえて調べるほうが、電池使用量のスクリーンショットだけを提示するより有効です。