プロトコル · 通信方式 · セキュリティ · コア

V2Rayのプロトコルとコアクライアント選びの技術ガイド

ノード設定に合わせてプロトコルを選び、コアの対応状況、サブスクリプション形式、ルーティング動作を確認します。

このページでは、設定項目の背景にある互換性を体系的に解説します。初回のインストールや接続については、まず入門ガイドをご覧ください。プロトコル、セキュリティ、コアの選択に迷ったら、該当する章を確認してください。デスクトップでは、まず v2rayN をご利用ください。インストール方法はクライアントのダウンロードをご覧ください。

VMess
VLESS
Trojan
Shadowsocks
REALITY

確認の順序：まず設定のレイヤーを把握し、次にプロトコルと動作条件を比較します。

利用できるノードがある場合は、提供元の設定をそのまま使うのが基本です。プロトコル名は速度のランクではなく、コアを切り替えても設定が変換されるわけではありません。

設定のレイヤーと VMess：プロトコル、通信方式、暗号化を区別する

ノード名や設定を読むときは、まず各要素を別のレイヤーに分けて考えましょう。プロキシプロトコルは、認証情報や接続先をどのように伝えるかを定めます。通信方式は、それらのデータをどのような経路で運ぶかを定めます。セキュリティ層は、その接続の認証と暗号化を担います。クライアントは画面上の設定項目をコアの設定に変換します。同じプロトコルでも通信方式は異なることがあるため、「どちらも VMess」だからといって、すべての設定を相互に流用できるわけではありません。接続先、ポート、ユーザーID、通信方式、セキュリティ設定がそろって初めて接続できます。項目が一つでも欠けると、接続のどこかで失敗することがあります。

VMessの設計背景と現在の使われ方

VMessは、Project Vのエコシステムで初期に開発されたプロキシプロトコルです。ユーザー認証とプロキシデータの転送を組み合わせ、後の発展では認証付き暗号化方式を採用しました。クライアントとサーバーが合意したユーザーをどう識別するか、プロトコルデータをどう保護するか、プロキシリクエストをどう表現するかを扱うものであり、外側の通信方式すべてを直接定めるものではありません。現在のサブスクリプションにも VMess ノードが含まれている場合があります。選ぶ際は、ノード設定がそろっていることと、サーバー側でその接続方式が引き続き提供されていることを確認してください。プロトコル名が古いという理由だけで、利用可能な設定を別の方式に変える必要はありません。

v2rayN で VMess ノードを編集するときは、サーバーアドレス、ポート、ユーザーIDを確認してから、暗号化方式、通信方式、TLS設定を確認します。ユーザーIDは通常 UUID 形式ですが、同じ長さの文字列なら何でも代用できるわけではありません。画面の「自動」は、一般にコアが対応するルールに従って暗号化方式を決める設定です。サーバー側の誤った設定を自動修正する機能ではありません。共有リンクから読み込んだ後も編集画面を開き、特に古い形式から変換されたノードでは、重要な項目を確認してください。

プロトコルの暗号化と外側の TLS を区別する

VMess自体の認証付き暗号化と、外側の TLS は別の仕組みです。前者はプロキシプロトコルの処理に含まれ、後者は外側の接続を保護し、証明書やサーバー名の確認を伴う場合があります。一方を有効にしたからといって、もう一方を無効または有効にすべきとは限りません。WebSocket と TLS を使うノードでは、接続先アドレス、リクエストの Host、パス、サーバー名も区別してください。これらは同じ値の場合もあれば、接続先の特定、リクエストの転送、認証にそれぞれ使われる場合もあります。画面上の見た目をそろえるために、すべて同じ値を入力するのは避けましょう。

古い資料には、追加ID、旧式の認証方式、過去の設定項目が記載されていることがあります。そのような設定を使う場合は、古い画面の項目を一つずつ写すのではなく、現在有効な共有リンクやサブスクリプションを提供元に確認してください。旧方式に対応する範囲は、現在の実装によって異なります。クライアントに入力欄が表示されていても、コアが過去の値をすべて受け付けるとは限りません。端末の時刻が大きくずれていると、時刻に依存する認証や TLS 証明書の有効期間判定にも影響します。認証に失敗したら、まずシステム時刻を合わせ、ユーザーIDと元のノード設定を照合してください。

設定レイヤー	主な項目	確認すること
プロキシプロトコル	種類、ユーザーID、パスワード	サーバー側の認証設定と一致していること
通信方式	ネットワーク、パス、Host	接続先の通信方式と一致していること
セキュリティ	TLS、サーバー名	サーバー側のセキュリティ設定に合っていること
実行環境	コア、ログ、設定生成	上の3つのレイヤーを正しく表現できること

エラーの発生レイヤーを特定する

接続がタイムアウトする場合は、まずアドレス、ポート、通信方式の接続先を確認します。証明書エラーでは、セキュリティ設定と端末の時刻を確認してください。接続直後に切断される場合は、認証情報、パス、サーバーログを確認します。この順序はエラーの種類を一対一で特定する表ではなく、複数の設定を同時に変更しないための手順です。元のノードが接続できる場合は複製を作り、根拠のある項目を一つずつ変更してテストしてください。操作手順の詳細はサブスクリプションの読み込みガイドをご覧ください。元のグループを試行錯誤用の設定場所にしないでください。

VLESS と REALITY：プロトコルとセキュリティを分けて確認

VLESSは、プロキシプロトコル自体の処理を簡潔にし、データの保護を選択した外部の仕組みに任せる設計です。認証は必要ですが、「名前が短い VMess」と考えるべきではありません。VMessをVLESSに変更し、ほかの設定をそのまま使うこともできません。リクエストの表現や処理方法が異なるため、サーバー側にも対応する接続設定が必要です。VLESSは TLS や REALITY などのセキュリティ設定と組み合わせて使われることがよくあります。通信方式やフロー制御の設定は、ノードで指定された内容に従ってください。

VLESSのユーザーID、暗号化、フロー制御

クライアントで VLESS ノードを編集するときは、アドレス、ポート、ユーザーIDを入力し、通信方式、セキュリティの種類、フロー制御の項目を確認します。暗号化の値は none が一般的ですが、これは VLESS のレイヤーを示すもので、通信全体が暗号化されていないという意味ではありません。ノードで TLS または REALITY を指定している場合は、該当するセキュリティ設定を漏れなく行う必要があります。この値を見て、合意のない暗号化設定を追加したり、外側の保護を無効にしたりしないでください。レイヤーをむやみに追加しても、サーバーと自動的に互換になるわけではありません。

フロー制御は特定の組み合わせで使う機能であり、自由に有効化できる高速化スイッチではありません。たとえばノードで Vision に対応するフロー制御値が指定されている場合、クライアント、コア、サーバーがその組み合わせに対応し、通信条件も一致している必要があります。フロー制御の指定がないノードに、別のノードの画面を参考に同じ項目を追加することはできません。設定生成エラーやハンドシェイク後の切断が発生したら、サブスクリプション変換ツールでフロー制御が欠落していないか、対応しない通信方式に誤って適用されていないかを確認してから、提供元に設定を問い合わせてください。

REALITYは単独のプロキシプロトコルではない

REALITYはXrayエコシステムのセキュリティ機能です。通常、プロキシプロトコルとして VLESS と並べて指定するのではなく、クライアントのセキュリティの種類として選択します。一般的なノードでは、プロトコルが VLESS、セキュリティ層が REALITY です。一般的な独自ドメインの証明書を使う構成とは異なる検証方式を採用しており、クライアントではサーバーに対応する公開鍵など、合意されたパラメーターが必要です。TLS のノードを REALITY に変更したり、公開鍵を削除して TLS を選び直したりしても、有効な接続が自動的に作られるわけではありません。サーバー側も該当する設定である必要があります。

REALITYでよく使うクライアント設定項目は、サーバー名、公開鍵、Short ID、フィンガープリントです。サーバー名は提供元が許可した値から選びます。公開鍵はサーバーの鍵と対応している必要があります。Short ID は提供元の値をそのまま使い、ゼロを足したり、別の値を連結したりしないでください。構成によっては Short ID を空にできますが、許可されるかどうかはサーバー側の設定で決まります。フィンガープリントはクライアントのハンドシェイク特性に影響するため、コアの対応状況も確認してください。読み込み画面に公開鍵が残っていても、サーバー名や Short ID が欠落していれば接続に失敗することがあります。「リンクを認識できた」だけでは、設定が完全とは限りません。

クライアントが設定の組み合わせに対応しているか確認する

デスクトップでは v2rayN を使い、ノードに実際に割り当てられたコアを確認してください。インストール先に Xray があるかを見るだけでは不十分です。Android で REALITY ノードを使う場合は、v2rayNG に含まれる Xray の機能がノードの要件を満たしているか確認してください。V2Fly をコアとする v2flyNG に同じ設定を渡しても、同等に動作するとは限りません。クライアント画面の選択肢、リンクの解析機能、コアの実行能力は別々の要素です。どこか一つでも項目に対応していないと、読み込みは成功しても接続できないことがあります。

選ぶ際は、必要な導入条件を満たしているか確認してください。VLESS と REALITY の設定がすべてそろい、現在のクライアントが各項目に対応している場合は、提供元の設定どおりに利用できます。通常の TLS 設定しかない場合は、通常の TLS ノードとして扱ってください。REALITYはあらゆる接続の標準的なアップグレードではなく、低遅延を保証するものでもありません。実際の性能を比較する際は、サーバーの場所、接続経路、テスト先、ネットワーク環境をそろえましょう。関連技術の違いはXray と V2Fly のコアの違いをご覧ください。まず互換性の範囲を把握してから、性能差を比較しましょう。

Trojan と Shadowsocks：TLSへの依存と暗号化方式を比較

TrojanとShadowsocksは、それぞれ異なる設計方針を持ちます。従来型の Trojan は TLS 接続内で認証とプロキシリクエストを扱うため、正しいセキュリティハンドシェイクと証明書検証が必要です。一方、Shadowsocks は軽量な暗号化プロキシ通信を中心に設計され、事前共有の認証情報と指定された暗号化方式を使って通信します。どちらもサーバーアドレスだけでは設定全体を復元できません。選ぶ際は、まずサーバーがどちらの接続方式を提供しているかを確認し、指定された暗号化方式や拡張機能にクライアントが対応しているかを確かめてください。パスワードの形式が似ていても、プロトコルに互換性があるとは限りません。

Trojan：TLSの検証が成立するか確認する

Trojan ノードを編集するときは、アドレス、ポート、パスワード、サーバー名の順に確認してください。接続先アドレスは入口への接続に使い、サーバー名は通常、TLSハンドシェイクや証明書の本人確認に使います。両者が同じとは限りません。提供元がサーバー名として特定のドメインを指定している場合、アドレス欄にIPアドレスを入力していても、そのサーバー名を維持してください。パスワードはプロキシ層の認証情報であり、Webサイトのログインパスワードではありません。コピー時は前後の空白、改行、入力方式による記号の置き換えに注意してください。画面に表示される文字数が正しくても、元の値と一致しているとは限りません。

証明書エラーが発生したら、まず端末の時刻、サーバー名、サーバー側の証明書設定を確認してください。「安全でない接続を許可」は一般的な解決策ではありません。証明書検証を省略すると、接続先の本人確認が弱まります。信頼できる証明書で動作していたノードでは、サーバー名や証明書の問題を修正してください。独自の信頼設定を使う構成の場合は、明確な説明に従って条件を設定します。検証設定の変更は、管理されたテストで問題箇所を特定する場合に限って一時的に行い、テスト後に元へ戻して、失敗の原因を記録してください。

Shadowsocks：暗号化方式を正確に一致させる

Shadowsocksノードでは、アドレス、ポート、暗号化方式、認証情報の組み合わせが重要です。現在よく使われる設定では認証付き暗号化方式が使われますが、方式ごとに鍵、実装、データの形式に固有の要件があります。方式名を「自動暗号化」のように省略したり、端末の性能に合わせて別の方式に変更したりしないでください。比較的新しい Shadowsocks 2022 の方式は、従来の方式と鍵の表記や処理方法が異なります。クライアントとコアの両方が該当形式に対応している必要があります。読み込み後に変換ツールがパスワードを一般的な文字列として再エンコードすると、元の意味が損なわれることがあります。

共有リンクの ss:// 形式は一種類ではありません。方式名と認証情報をエンコードするものや、異なる URI 構成を使うものがあり、拡張パラメーターを含む場合もあります。解析機能は、リンクの外側の形式と内部の項目の両方を理解する必要があります。ノードが追加の拡張機能に依存している場合、このページで使うクライアントが基本的な Shadowsocks を認識できても、すべての拡張機能が動作するとは限りません。まず提供元に拡張機能の要否と具体的な条件を確認し、利用中のコアが対応しているか調べてください。説明にないコンポーネントをインストールして試すのは避けましょう。

項目	Trojan	Shadowsocks
認証情報	パスワード	暗号化方式と対応する認証情報または鍵
セキュリティで確認すること	TLSのサーバー名と証明書検証	暗号化方式と鍵の形式
主な互換性の境界	通信拡張と TLS の設定	方式の世代と拡張機能への対応
UDPの動作	実装とサーバーの対応状況による	方式、実装、導入環境による

「軽量」だからといって、すべての環境で高速とは限らない

Shadowsocksの軽量な設計は、すべてのスマートフォンや回線で電池消費が少ないことを意味しません。TrojanがTLSを使うからといって、リクエストごとに毎回フルハンドシェイクを行うわけでもありません。接続の再利用、セッション再開、プロセッサーの高速化、サーバー負荷、アプリのリクエストパターンによって結果は変わります。短時間の接続を大量に行う場合は接続確立のコスト、長時間の通信ではスループット、パケットロス、継続的な暗号化処理が重要です。同じ端末とネットワークで比較し、プロトコル名だけで性能を判断しないでください。

通常の Trojan 設定があり、証明書検証も正常なら、まずその設定を維持してください。最新の Shadowsocks 方式に対応したクライアントがあれば、軽量なプロキシ接続として利用できます。音声通話、ゲームなど UDP に依存するアプリを使う場合は、サーバー、中継経路、クライアントの通信取り込み方法も確認してください。ノードが TCP に対応しているだけでは、あらゆるアプリが使えるとは限りません。Webページは開けても特定のアプリが動かない場合は、まず通信がプロキシ経由かどうか、プロトコルが対象データを運べるかを切り分けてから、ノードの種類を変えるか検討しましょう。

Xray と V2Fly：クライアントの画面と実際のコアを区別する

Project Vは、関連するプロキシツールや設定思想の重要な源流です。V2FlyはV2Rayエコシステムを引き継いでコミュニティで保守され、Xrayはその技術を基盤に独自に発展したコアの系統です。共通の歴史を持ちますが、プロトコル拡張、通信機能、設定にはそれぞれ違いがあります。同じプログラムの名称だけを変えたものと考えることはできません。また、ある時点の機能一覧から、その後のすべての実装を推測することもできません。互換性を判断するには、現在動作しているコアが特定の項目を認識するか、その組み合わせに対応するか、生成された設定の検証に通るかを確認してください。

3種類のクライアントの役割

v2rayNは、ノード管理、サブスクリプションの更新、ルーティング設定、コアの呼び出しを担うデスクトップ用のGUIクライアントです。Windows版の Desktop と WPF の違いは、主に画面の実装技術や操作方法に関するもので、プロキシプロトコルの規格が異なるわけではありません。macOS と Linux のユーザーも、別のクライアント名を探すのではなく、対応する v2rayN のインストール方法からアーキテクチャとパッケージ形式を選んでください。画面で設定した内容は実行時の設定に反映されますが、実際にネットワーク接続を処理するのは呼び出されたコアです。トラブルの切り分けでは、両方を確認する必要があります。

Android版の v2rayNG は主に Xray コアを使い、v2flyNG は V2Fly コアを使う選択肢を提供します。画面上の操作が似ていても、すべての共有リンク、フロー制御値、セキュリティ機能が同じ範囲で使えるとは限りません。特に REALITY や Xray 固有の機能を使う場合は、まず必要な項目を設定できるクライアントを選んでください。両方が対応する基本機能だけを使うノードであれば、実際の互換性を確認して選べます。クライアント名に似た文字が含まれていることだけで判断しないでください。

設定の互換性は、項目をそのままコピーできるとは限らない

設定構造やプロトコル名の共通性は、移行の助けになります。しかし、項目の意味、初期値、対応する組み合わせは異なる場合があります。古い項目の削除、実験機能の変更、DNSやルーティング構造の調整によって、同じに見える JSON が別のコアで起動しないこともあります。GUIクライアントは独自の実行設定を生成することが多く、手動で追加したカスタム設定が同じように変換されるとは限りません。切り替える前に、通常のノードモードと完全なカスタム設定のどちらを使っているか確認してください。設定元や上書きの順序が異なるため、両者を混同しないようにしましょう。

v2rayN では、まずノードのプロトコルとコアの割り当て設定を確認し、実行ログで実際に起動したプログラムを確かめてください。画面の種類によってメニュー名は多少異なることがあります。コア設定、プロトコルごとのコア、ノード編集画面の該当項目を探しましょう。全ノードが一つのプルダウン設定だけで切り替わるとは限りません。ログに未対応の項目やセキュリティ方式が表示されたら、まずコアの選択と項目の出所を確認します。設定の検証に通って接続できない場合は、サーバー側の設定を確認してください。異なる種類のエラーをすべてネットワークの問題として扱わないようにしましょう。

更新や切り戻しでは、比較用の設定を残す

更新前に、現在利用できるノード、ルーティングモード、DNS設定、コアの割り当てを記録してください。サブスクリプションと通信の取り込み方法を同時に変更するのは避けましょう。更新後は同じノードと同じ接続先で確認してから、新機能を試してください。クライアントの更新にはコアの変更が含まれる場合もあれば、画面や設定生成だけの変更の場合もあります。システム内に別のコアファイルを置いても、クライアントがそれを呼び出すとは限りません。切り戻すときは、入手元と互換性が明確な方法を使い、対応する設定も元に戻してください。複数のディレクトリにあるファイルを混在させると、実行状態を追跡しにくくなります。

オープンソースであることは、実装や保守の過程を調べられるという意味です。第三者が作成したすべての設定が検証済みであることや、特定のコアがあらゆる環境で省リソースであることを保証するものではありません。当サイトでは3種類のクライアントのダウンロード先と設定資料を提供しており、独自のコア配布ページは設けていません。インストール方法はクライアントのダウンロードをご覧ください。クライアントがメイン画面を開く前に終了する場合は、ノードのプロトコルを繰り返し変更するのではなく、まず起動時のクラッシュ対処法に沿って動作環境を確認してください。

サブスクリプション形式と読み込み：URL、内容、設定項目の欠落を確認

サブスクリプションは複数のノード設定を取得するための入口であり、特定のプロキシプロトコルではありません。サブスクリプションURLから複数の共有リンクが返されることもあれば、エンコードされたテキストや特定のクライアント専用形式が返されることもあります。クライアントはまず内容を取得し、外側の形式を解析してから、各ノードを内部形式に変換します。そのため、ブラウザーでURLを開けたとしても、確認できるのは取得処理が正常な可能性があることだけです。読み込み、全項目の保持、実際の動作はそれぞれ別に確認してください。各段階を切り分ければ、根拠なくプロトコルを変更せずに済みます。

サブスクリプションURLと単一の共有リンクの違い

単一の共有リンクは、通常プロトコル固有の URI プレフィックスから始まり、一つのノードの接続先、認証情報、追加設定を含みます。一方、サブスクリプションURLは通常、アクセス情報を含むWebアドレスで、クライアントがアクセスするとノードの一覧を取得できます。それぞれ適切な入力欄に設定してください。単一のリンクをサブスクリプショングループのURL欄に入力すると、更新に失敗することがあります。サブスクリプションURLを通常のサーバーアドレスとして使っても、プロキシ接続は確立できません。初回はリンクの形式を確認し、「クリップボードから共有リンクを読み込む」か、サブスクリプショングループの設定を選びましょう。

v2rayN でサブスクリプショングループの設定を開き、グループを追加して名前を入力します。完全なURLを「任意のアドレス (URL)」に貼り付け、必要に応じて更新を有効にしてからグループを更新してください。例のURLは https://example.com/sub?token=xxxx です。入力欄の場所を示すだけで、ノードは提供しません。自分のURLをコピーするときはクエリパラメーターを保持し、疑問符以降を削除しないでください。チャットアプリが追加した改行や末尾の句読点も含めないようにします。サブスクリプションURLにはアクセス権情報が含まれるため、公開画面やログ、許可を確認していない変換サービスに記載しないでください。

デコードに成功しても、設定がすべて保持されたとは限らない

一般的な VMess 共有形式ではエンコードされたデータが使われることがあります。一方、VLESS、Trojan、Shadowsocks のリンクは、それぞれの設定を URI に含めることがよくあります。共有形式によって、パス、サーバー名、フィンガープリント、フロー制御の項目名は統一されていません。特に拡張項目は変換時に欠落しやすいため、読み込み後にノードを一つ選び、編集画面で元の設定と照合してください。プロトコル、通信方式、セキュリティの種類、認証情報を確認します。名前、アドレス、ポートが表示されていても、REALITY の公開鍵や WebSocket のパスが空なら、読み込みは不完全です。

サブスクリプションの応答が、別の設定システム向けの形式で、異なるノード項目やルール構造を使っている場合があります。ファイルの拡張子を変えただけで現在のクライアントの標準形式になるわけではなく、すべてのクライアントが自動変換できるとも限りません。まず提供元に、v2rayN または利用するAndroidクライアントに適した形式を問い合わせてください。変換が必要な場合は、変換ツールがどの項目を扱い、どの形式を出力するか、認証情報が端末外に送信されるかを確認しましょう。変換後のノードは項目ごとに再確認してください。特にセキュリティと通信方式の拡張は、ノード数が一致するだけでは不十分です。

更新後のノードと手動変更の管理

サブスクリプションの更新でノード一覧が再生成されることがあります。ノード名、パス、コアとの関連付けといった手動変更が保持されるかどうかは、クライアントの管理方法によって異なります。一時的な比較にはノードを別のグループに複製し、変更内容をメモしてください。サブスクリプショングループを長期的な手動設定の保管場所にしないでください。更新後は、選択中のノードが残っているか、フィルター条件で対象ノードが除外されていないかを確認します。リストが空でも、サーバーにノードがないとは限りません。応答形式、権限、フィルター、解析に問題がある可能性もあります。

自動更新の間隔は、提供元の制限と実際の利用頻度に合わせて設定します。頻繁に取得してもノードの遅延は改善されません。バックグラウンドでの起動、リクエスト失敗、アクセス負荷が増える場合があります。更新に失敗したら、まずログを読み、接続、権限、形式のどの問題かを確認してください。ログを公開する前に、完全なURL、ユーザーID、パスワードを隠してください。サブスクリプションとノードの基本は初心者向けFAQ：よくある10の質問をご覧ください。実際の操作手順は入門ガイドの読み込み手順で確認できます。

性能とスマートフォンの電池消費：接続の流れに沿って比較

プロトコルの性能に、環境を問わず通用する固定の順位はありません。アクセスでは、DNSによる名前解決、プロキシ接続先への接続、外側のセキュリティハンドシェイク、プロキシ認証、接続先への転送を経てから、継続的な通信が始まります。テストごとに測定対象は異なります。TCPポートのテストで分かるのは接続先が接続を受け付けるかどうかで、認証情報や接続先へのアクセスが正常かは確認できません。実際の接続テストは実利用に近いものの、結果はテスト先にも左右されます。まず何を測定したのかを明確にしてから、プロトコルの速度を比較しましょう。

最初のリクエスト、継続的な転送速度、リソース使用量

最初のリクエストは、DNS、接続の往復時間、セキュリティハンドシェイクの影響を受けやすくなります。継続的なダウンロードでは、回線速度、パケットロス、輻輳制御、サーバー負荷、暗号化処理能力がより重要です。短時間の測定でノードの遅延が低くても、大容量ファイルのダウンロードが速いとは限りません。プロセッサーにハードウェアアクセラレーションがあれば、一部の暗号化処理の負荷を抑えられる場合があります。一方、端末の負荷が高いときや省電力状態では、同じ設定でも結果が変わります。暗号化方式はサーバーとの合意に従い、理論上の転送速度だけを理由に変更しないでください。

接続の再利用は、接続を繰り返し確立するコストを減らせる一方、複数のリクエストが共有経路に入るため、障害の影響や輻輳の現れ方は実装によって異なります。接続の再利用、通信プロトコル、アプリの接続プールが重なる場合もあります。画面上の再利用設定を、あらゆる場面で有効な高速化機能と考えないでください。接続が安定している場合は初期設定または提供元の推奨を維持し、特定のアプリで問題が起きたときに個別にテストします。一度に変更するのは一項目だけにし、短いリクエスト、長時間の接続、並行リクエストを観察してください。遅延テストを繰り返すだけでは不十分です。

スマートフォンの電池消費はバックグラウンド動作にも左右される

Androidの電池消費は暗号化処理だけで決まりません。VPNサービスの継続動作、無線ネットワークの起動、ハートビート、DNSリクエスト、バックグラウンド同期、頻繁な再接続も電池に影響します。電波が弱い場合や Wi-Fi とモバイル通信を頻繁に切り替える場合は、無線モジュールの消費がプロトコルの違いより大きくなることがあります。ノードが何度も切断と再接続を繰り返すなら、1回の暗号化処理が軽くても、全体の電池消費が少ないとは限りません。v2rayNG と v2flyNG を比較するときは、両方が完全に対応する同等の設定を使ってください。そうでなければ、互換性の問題を測定することになります。

まず、バックグラウンドの電池制限で VPN サービスが頻繁に停止されていないか確認し、クライアントログで再接続の頻度を調べます。接続を維持する必要があるアプリでは、システム設定でバックグラウンド動作を許可できますが、端末全体の電池消費が変わるため、必要性と照らし合わせてください。VPN機能を使うアプリを複数同時に起動し、互いの通信取り込みの競合をプロトコルの電池消費と誤認しないようにしましょう。画面ロック後だけ接続が切れる場合は、セキュリティ方式をすぐに変更するのではなく、システムのバックグラウンド制限、ネットワーク切り替え、接続維持の動作を確認してください。

測定項目	主に分かること	直接には判断できないこと
ポートへの接続時間	接続先への到達条件	プロキシ経路全体が使えること
実接続の遅延	指定した接続先への1回のプロキシリクエスト	すべてのアプリで同じ速度が出ること
継続的な転送速度	指定した時間帯の通信性能	最初のリクエストが必ず速いこと
バックグラウンド時の電池消費	実行環境全体での電力使用量	プロトコル名だけで消費量が決まること

再現できる比較方法を作る

同じ端末、同じネットワーク、近い時間帯で同じテスト先を選び、ノード、コア、通信の取り込み方法、ルーティングモードを記録してください。テストのリクエストが実際に対象ノードを経由していることを確認し、初回アクセス、再アクセス、継続的な転送をそれぞれ観察します。スマートフォンの電池消費を比較するには、画面点灯時間、電波状況、バックグラウンドタスクも近づける必要があります。短時間の電池残量の変化だけでは差を判断できません。一律の性能向上率を作ったり、地域の異なるサーバーの結果をプロトコル設計の違いに直接結び付けたりしないでください。

日常利用で安定性を重視するなら、必要な設定に完全対応し、再接続が少なく、アプリが正常に動作する構成を優先し、その後で体感速度を比較してください。クライアントにある測定機能の違いはノード遅延テストの解説をご覧ください。テスト結果は利用可能な設定を比較するためのもので、認証を省略したり、証明書の問題を無視したり、設定項目の欠落を見過ごしたりするためのものではありません。性能を比べる前に、そうした問題を解決してください。

ルーティングと DNS：選択したノードを通信が経由しているか確認する

正しいプロトコルで解決できるのは、プロキシ接続の確立方法です。ルーティングは、どのリクエストをその接続に渡すかを決めます。システムプロキシは、システム設定に従うアプリにプロキシを提供しますが、すべてのアプリに強制適用するわけではありません。TUNは仮想ネットワークインターフェースでより広範囲の通信を取り込みますが、適切な権限、ルーティング、DNS設定が必要です。ノードの実接続テストが成功しても特定のアプリが直接接続する場合、通信の取り込み範囲やルールに問題がある可能性があり、プロトコル自体が使えないとは限りません。トラブルを調べる前に、現在の通信取り込み方式と、対象アプリがその方式に対応するかを確認してください。

ルールの順序と照合に使う情報

ルーティングルールは通常、決められた順序で照合されます。先に一致したルールが後続の判定に影響します。ドメインのルールには利用可能なドメイン情報が必要です。IPルールは宛先アドレスまたは名前解決の結果に基づきます。geosite と geoip はよく使われる分類データの参照名であり、プロキシプロトコルではありません。クライアントの組み込みテンプレートは、異なるデータファイルやデフォルトのアウトバウンドと組み合わせて使われる場合があります。ルールをコピーするときは、参照データが存在するか、タグが有効かを確認してください。テンプレート名が同じでも、異なるコアやクライアントが生成するすべてのルールが同一とは限りません。

ルールをカスタマイズする場合は、まず現在のルーティング設定を複製し、必要最小限のルールを追加してください。対象が単一のドメイン、ネットワーク範囲、特定のアプリのどれかを明確にし、広範囲のルールで既存設定を覆わないようにします。ルールに一致しない場合は、アプリがプロキシに渡す情報がドメインかIPアドレスかを確認してから、ルールの順序とアウトバウンドタグを調べてください。条件によってはスニッフィング機能で接続先情報を補えますが、すべてのプロトコルやリクエストからドメインを復元できるわけではありません。適切なDNSや通信の取り込み設定の代わりにもなりません。変更後はログで実際の経路を確認してください。

DNS設定と名前解決の場所

DNSはホスト名をIPアドレスに変換しますが、名前解決はアプリの端末内で行う場合も、プロキシ側に任せる場合もあります。システムプロキシ、TUN、アプリ独自のDNSによって経路は変わります。システムDNSだけを変更しても、クライアント内部の名前解決には反映されないことがあります。クライアントのDNSだけを変更しても、アプリ独自の暗号化DNS通信を取り込めるとは限りません。サーバーアドレスの名前解決と、接続先サイトの名前解決を区別してください。前者に失敗するとプロキシの接続先に到達できず、後者に失敗するとノードには接続できても一部のドメインを開けないことがあります。

名前とIPアドレスがどのレイヤーで必要かを確認してから、名前解決方法を選んでください。ドメイン名をそのまま遠隔側で処理すれば、ローカルの名前解決による差を避けられることがあります。ただし、ローカルIP分類ルールでは同じ判定ができない場合があります。ローカルで名前解決するとIPアドレスに基づくルールを利用できますが、ローカルの解決結果と遠隔側のアクセス場所が一致しない可能性があります。あらゆる環境に適した唯一の方法はありません。まずクライアントの既存設定を一通り利用し、ログを見ながら項目ごとに調整してください。複数のガイドから設定を半分ずつ取り出し、新しいDNSの手順を作らないようにしましょう。

以下は、プライベートアドレスを直接接続する設定項目の関係を示す、Xray形式のルーティング例です。完全な設定ではありません。既存設定の routing に組み込み、既存アウトバウンドのタグが実際に direct であること、分類データが利用できることを確認してください。GUIクライアントは実行設定を再生成することがあります。一般のユーザーは、ルーティング設定画面から同じ目的を設定してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

確認できる通信経路に沿って切り分ける

まずノードへの接続をテストし、次にシステムプロキシまたは TUN の状態を確認します。その後、対象アプリを検証し、最後にルールと名前解決を確認してください。LAN内の機器に接続できない場合は、プライベートアドレスのルール、仮想インターフェースのルート、ローカルの名前解決を確認します。特定のドメインだけに失敗する場合は、名前解決の結果とルールの一致状況を比較してください。すべてのルールを繰り返し消去しても、プロトコルの優劣は判断できません。公開するログでは、内部のアドレス設計と認証情報を隠し、原因の特定に必要なエラーの種類と項目名だけを残してください。

デスクトップとAndroidでは通信を取り込む方法が異なり、一方のシステムプロキシ設定を、もう一方のVPN権限と同じものとして扱うことはできません。ルーターやバイパスルーターを使った集中管理では、ゲートウェイ、戻り経路、DNS転送も関係するため、個別の設計が必要です。デスクトップ向けの設定をそのまま流用しないでください。背景はルーターとバイパスルーターの構成概要をご覧ください。初回接続は、まず入門ガイドのモード選択手順に沿って設定し、その後この章に戻ってルールを調整してください。

用途に応じた選び方と動作確認：設定をそろえて再現性のある接続を実現

クライアント選びは、プロトコルの順位付けではなく、利用中の有効なノードと端末の条件から始めましょう。利用可能なサブスクリプションがある場合は、設定をすべて解析して実行できるクライアントを選びます。自前で構築する場合や導入方法を調整する場合は、保守のしやすさ、セキュリティ機能、アプリの要件を比較してください。デスクトップでは v2rayN でノードを管理し、Androidではコアの対応状況に応じて v2rayNG と v2flyNG を選びます。ダウンロードパッケージのCPUアーキテクチャはインストールと実行の可否に関わり、プロトコルの種類は接続動作に関わります。この2つは別の条件です。

デスクトップとモバイルの日常利用で考慮すること

デスクトップで日常的に使う場合は、設定の入手元が明確であること、ルーティングが分かりやすいこと、ログを確認できることを優先します。VMess、Trojan、Shadowsocks のノードが正常に動作しているなら、名称を変えるためだけに再設定する必要はありません。VLESS と REALITY の組み合わせを使う場合は、Xrayの対応状況とすべてのセキュリティ項目を確認してからテストしてください。同じサブスクリプションを複数の端末で使う場合は、各端末で読み込み結果を個別に確認します。デスクトップで成功したからといって、Androidでもすべての拡張項目が保持されるとは限りません。システム時刻、権限、通信の取り込み範囲も端末ごとに確認してください。

モバイル端末でネットワークを頻繁に切り替える場合は、再接続からの復帰とバックグラウンドサービスの安定性を優先して確認し、継続的な通信では転送速度と発熱も観察してください。音声通話など UDP を使うアプリでは、クライアントによる通信の取り込み、プロトコルの転送、サーバー側の中継、接続先へのアクセスまで一連の経路を確認する必要があります。Webページが開けるだけでは、これらの条件を満たすとは限りません。2つのノードが異なる地域や回線にある場合、結果には導入環境全体の違いが反映されます。体感の差を VLESS、Trojan、Shadowsocks のいずれか一つの名称に直接結び付けないでください。

パラメーターをまとめて変更せず、段階ごとにエラーを確認する

第1段階は起動です。クライアントの画面が開かない場合は、システムの動作条件、権限、インストールパッケージのアーキテクチャを確認してください。コアが起動しない場合は、設定の解析エラーや未対応機能を調べます。第2段階は接続先への接続です。アドレス、ポート、名前解決、通信方式の入口を確認してください。第3段階はセキュリティハンドシェイクと認証です。端末の時刻、サーバー名、証明書、ユーザーID、パスワード、REALITYの設定を照合します。第4段階で接続先へのアクセスとルーティングを確認します。段階を分けることで、別のレイヤーの問題に誤った対処をするのを防げます。

たとえば「接続がタイムアウトしました」という表示から分かるのは、どこかの処理が制限時間内に完了しなかったことだけで、パスワードの誤りとは限りません。「未対応の項目」は、設定またはコアの互換性に関係する可能性が高く、まず DNS を変更する必要はありません。「証明書名が一致しない」場合は、暗号化方式ではなくサーバー名と証明書の設定を確認してください。ログの内容は実装によって異なります。エラーの前後を読み、サブスクリプションの取得、コアの起動、プロキシリクエストのどこで発生したかを特定しましょう。異なる段階で表示された同じ「失敗」を、同一の障害として扱わないでください。

再現可能な接続テストを行う

サブスクリプションの更新が完了し、設定項目が欠けていないことを確認してから、選択したノードを起動します。コアのログに設定エラーがないことを確認し、次に特定の接続先への通信と、想定したアウトバウンドを経由していることを検証してください。ノードを変えずに対象アプリと画面ロック後の復帰をテストします。比較するときは設定を複製し、根拠のある項目だけを一つ変更してください。テスト中にサブスクリプションを更新し、コアを切り替え、TUNを有効にし、DNSも変更すると、結果が改善してもどの変更が効いたか分からず、別の端末で再現するのも難しくなります。

長期的な運用では、原因を追跡できない設定差を減らすことが重要です。グループごとに用途を明記し、サブスクリプションから生成されたノードと手動テスト用ノードを分けます。更新後はセキュリティ設定と実際のコアを確認してください。サポートを求める際は、クライアント名、OS、失敗した段階、必要な情報だけに整理したログを伝え、サブスクリプションURLや認証情報を公開しないでください。提供元がサーバーのプロトコルやセキュリティ設定を変更した場合は、新しい設定一式を入手し、古いノードに新しい項目を推測で追加しないでください。設定を増やすより、一つひとつの変更理由を説明できることが、安定した利用につながります。

最終的な選択は3つの条件で判断できます。サーバーがそのプロトコルの組み合わせを実際に提供していること、クライアントとコアが必要な項目すべてに対応していること、対象アプリが実際のネットワークで動作確認できていることです。条件を満たしたら、応答時間、継続的な転送速度、バックグラウンド時の電池消費を比較してください。インストール方法とパッケージ形式はクライアントのダウンロードへ、基本的な操作手順は入門ガイドへ戻り、個別の技術項目はこのページの目次から各章をご覧ください。プロトコルは設定条件の一つであり、測定やトラブルシューティングに代わる結論ではありません。