V2Rayのプロトコルとコアの解説

1. 設定を4つの層に分けて考える

クライアントに表示されるサーバー設定には、通常、プロキシプロトコル、下位の伝送方式、セキュリティ層、ローカル接続方式が含まれます。それぞれ役割が異なるため、一覧に表示されたプロトコル名だけで機能全体を判断することはできません。プロキシプロトコルはクライアントとサーバー間の認証、宛先の指定、データ転送を担います。伝送方式はデータを運ぶ接続方法、セキュリティ層は接続の暗号化と認証を担います。ローカル接続方式は、どのアプリの通信をクライアントに送るかを決めます。原因を調べるときは、まず層ごとに切り分けると変更すべき箇所が分かります。

プロトコル名だけでは接続方式は分からない

たとえばVLESSという名称から分かるのはプロキシプロトコルだけです。TLSやREALITYを使うか、どの伝送方式を使うか、サーバーが特定のフロー制御を要求するかは分かりません。同じVLESSでも、必要なコア機能が異なる設定があります。VMessも複数の伝送方式と組み合わせられ、Shadowsocksでは暗号化方式の確認が必要です。サーバー設定を編集するときは、まずプロトコルを確認し、アドレス、ポート、認証情報を照合してから、伝送方式とセキュリティ設定を確認してください。プロトコルの選択欄を適当に変更しても、接続先のプロトコルが切り替わるわけではありません。

サーバーアドレスとサーバー名も別の項目です。サーバーアドレスは接続先を示し、通常はドメイン名またはIPアドレスを指定します。TLSのサーバー名はハンドシェイク時に通知され、証明書の照合にも使われます。両者が同じ場合もあれば、構成に応じて別々に指定する場合もあります。サーバーアドレスをIPアドレスに変更してサーバー名を空欄にすると、正常だった証明書検証に失敗することがあります。ポートは接続先サーバーの待ち受け口です。ローカルの待ち受けポートと混同しないでください。クライアントのローカルポートは端末上のアプリが接続するためのもので、変更してもサーバー側のポートは変わりません。

ローカル接続とサーバー側プロトコルを分けて確認

v2rayNのシステムプロキシは、システムプロキシ設定に従うアプリの通信をローカルのクライアントに渡すための機能です。サーバー側のプロトコルとは別で、すべてのアプリがこの設定に従うとは限りません。TUNモードは別の接続方式で、仮想ネットワークインターフェースや権限、ルーティングの設定が関わります。AndroidクライアントはシステムのVPN許可を得て接続経路を作りますが、VPNアイコンが示すのはローカルサービスが確立したことだけです。サーバー側の認証成功を示すものではありません。ログを確認し、実際のアプリでも接続を検証してください。

ルーティングによる通信の振り分けは、リクエストがクライアントに入った後に行われます。ルールによって、ドメイン、アドレス、ポートごとにプロキシ経由、直接接続、通信の遮断を選べますが、サーバーのパスワード間違いは直せません。DNSによる名前解決は、接続方式や設定に応じてアプリ、システム、ローカルクライアント、接続先のいずれかで行われます。一部のドメインに接続できない場合は、名前解決の失敗、誤った経路への振り分け、サーバーへの接続失敗を切り分けてください。すべてのプロトコルを次々に変更すると、元の状態を再現できなくなります。

確認しやすい形で設定を記録する

設定を確認する際は、プロトコル、アドレス、ポート、伝送方式、セキュリティ層、サーバー名、コアなど、機密情報ではない項目を記録し、システムプロキシなどのローカル接続方式も書き添えておきましょう。UUID、パスワード、サブスクリプションURLは別に保管し、公開するスクリーンショットには載せないでください。まず元の設定を複製し、一度に変更する項目は1つにします。ログにローカルポートのバインド失敗があればポートの競合を解消し、証明書名の不一致があればサーバー名と証明書を確認します。認証拒否の場合は認証情報とプロトコルを調べます。エラーが起きた層に応じて対処するほうが、クライアント名から原因を推測するより確実です。

2. VMess、VLESS、Trojan、SSの違い

プロトコルを選ぶ前に、サーバー側がその接続先を実際に提供していることを確認してください。クライアントが対応していても、あらゆるサーバーが受け付けるとは限りません。ここではプロトコルの役割と設定上の注意点を比較しますが、端末やネットワークの条件を無視した速度ランキングは示しません。プロトコル自体の処理負荷は接続全体の一部にすぎず、回線品質、伝送方式との組み合わせ、サーバーの実装によって使い心地は変わります。安定して使えているサブスクリプションがあるなら、まず正しく追加して接続を確認しましょう。名前が新しいプロトコルにすべて移行するよりも有益です。

VMess：認証と暗号化を組み合わせたプロトコル

VMessはProject Vの初期に設計されたプロトコルで、認証やデータ保護などを担います。現在利用する際は、古い解説にある過去の設定値をそのまま使うのではなく、クライアントとサーバーが現在の認証方式に対応しているかを確認してください。古い設定には追加の識別番号などが含まれることがありますが、その意味は実装や時期によって異なります。インポート後に認証に失敗した場合は、サーバーの案内、UUID、双方の時刻をまず確認してください。古い記事の数値を万能な解決策として扱わないようにしましょう。システム時刻が大きくずれていると、認証やセキュリティハンドシェイクに影響することもあります。

VMessは既存の導入例やサブスクリプションツールが広く使われており、現在も適切に保守されている設定ならそのまま使いやすい点が特長です。プロトコル名を変えるためだけにコアを乗り換える必要はありませんが、伝送方式は双方の対応状況を確認してください。編集時は、プロトコル内部の暗号化設定と外側のTLSを区別しましょう。似た名称でも、同じ設定項目ではありません。配布元が暗号化方式を指定している場合はそのまま照合し、TLSを有効にしたからといって内部の項目を変更しないでください。過去の互換設定が多いほど、インポート時の状態を比較用に残しておくことが重要です。

VLESS：プロキシ層を簡素化し、外側の保護を利用

VLESSはプロキシ層の複雑さを抑えた設計で、基本仕様ではVMessのようなデータ暗号化を担わず、通常はTLSやREALITYなどのセキュリティ層と組み合わせます。軽量な設計だからといって認証を省けるわけではなく、信頼できない経路で暗号化せずに通信してよいという意味でもありません。クライアントの暗号化欄がnoneの場合は、外側のセキュリティ設定と合わせて判断してください。プロトコルの仕様上必要な値であり、接続全体の保護を無効にする指示とは限りません。利用する前に、サーバーが提供する組み合わせを確認しましょう。

VLESSの設定ではflowという項目をよく見かけます。フロー制御は自由に切り替えられる性能設定ではなく、特定の実装や伝送方式との組み合わせに関わるプロトコルの動作です。サーバーが要求していない場合は追加せず、要求されている場合は省略しないでください。サブスクリプションの追加は成功したのに、起動時に特定のフロー制御が未対応と表示される場合は、まず選択中のコアと対応機能を確認します。UUIDを変更するのはその後です。既存のサブスクリプションでは、設定を統一するより、サーバー指定の項目をすべて保持することが重要です。

TrojanとShadowsocks：認証項目の違い

Trojanは一般にパスワード認証を使い、TLSで接続を保護します。パスワードと証明書検証の設定を両方確認してください。パスワードが正しくてもサーバー名が誤っていると、認証前のハンドシェイクで失敗する場合があります。設定項目が少なく見えても、セキュリティ層を省略できるわけではありません。サーバーが追加の伝送方式を使う場合は、クライアント側にも対応する項目が必要です。TrojanのパスワードをUUID欄に貼り付けたり、別プロトコルの共有リンクの先頭だけを書き換えたりしても、正しい設定にはなりません。

ShadowsocksはSSと略され、主な設定項目はサーバーアドレス、ポート、パスワード、暗号化方式です。暗号化方式は互換性があるとは限りません。特に新しい方式を使う場合は、双方の実装が対応しているか確認してください。追加の伝送設定が必要な構成もあり、アドレスとパスワードだけでは足りないことがあります。シンプルな設計ですが、リソース消費は暗号化アルゴリズム、プロセッサの対応状況、転送経路によって変わります。「最も互換性が高い」と古い記事に書かれているからという理由だけで旧方式を優先せず、現在のサーバーとコアが明確に対応している方式を選びましょう。

設定時の要点をまとめると、既存のVMessでは現在の実装との互換性と時刻を確認します。VLESSではセキュリティ層とフロー制御、TrojanではパスワードとTLSの接続先確認、SSでは暗号化方式の正確な名称が重要です。性能を比べるのは、サーバーが比較可能な複数の接続先を提供している場合に限りましょう。同じ地域、同じ接続方式、近い時間帯で比較し、異なるサーバー間の差をプロトコルの違いと取り違えないようにしてください。

3. 伝送方式、TLS、REALITYの設定範囲

プロキシプロトコルだけでなく、伝送方式とセキュリティ層も接続の成否を大きく左右します。伝送方式はデータの構成と運搬方法を、セキュリティ設定は接続相手の認証と通信内容の保護方法を示します。組み合わせて使えますが、自由に組み合わせられるわけではありません。サーバーで設定された伝送方式とセキュリティ方式に、クライアントも合わせる必要があります。クライアントの選択肢が多いのは、その項目を設定できるという意味にすぎません。サブスクリプションの説明を読む際は、プロトコル、伝送方式、セキュリティ層を一組として記録し、個々の名称だけを完全な設定だと考えないようにしましょう。

TCP、WebSocket、gRPC

TCPで直接データを運ぶ場合、接続の構成は比較的分かりやすいですが、新しい接続ではTCP接続、セキュリティハンドシェイク、プロキシ認証が必要になることがあります。WebSocketはHTTPハンドシェイク後に双方向のデータを運び、パスやリクエストヘッダーのホスト情報の確認が必要なことがよくあります。パスの大文字・小文字、先頭のスラッシュ、サーバー側のリバースプロキシ設定は、いずれも照合に影響します。ハンドシェイクが拒否された場合は、プロトコルのパスワードに加え、リクエストが正しい接続先に届いているかも確認してください。通常のWebページが返ってきても、プロキシ認証に成功したとは限りません。

gRPCはHTTP/2をベースにしており、設定にはサービス名などの項目が含まれることがあります。WebSocketのパスをそのままコピーしないでください。前段のサービスが対象の接続方式に正しく対応している必要があり、中継部分のアイドルタイムアウトも長時間接続に影響します。別の回線で安定した伝送方式が、現在の構成にも適しているとは限りません。既存のサーバーでは、明示的に指定された伝送方式を使いましょう。自分でサーバーを管理する場合は、中継プロキシの機能、接続管理、アプリの種類を踏まえて検討します。追加のカプセル化は処理を増やす傾向がありますが、体感できる負荷になるかは実際に確認してください。

TLS：「有効」かどうかより証明書名が重要

TLS設定は単なるオン・オフではありません。クライアントは証明書の信頼チェーン、有効期限、接続先の名前を検証します。設定によってはアプリケーション層プロトコルのネゴシエーション項目も指定します。サーバー名は通常、ハンドシェイク時の名前通知に使われ、証明書の本人確認にも関わります。一方、伝送時のリクエストヘッダーにあるホスト名は、別の層でリクエストを処理するための項目です。たまたま同じ文字列を使う構成でも、常に同じ意味とは限りません。アドレスの変更、ドメインの移行、リバースプロキシの設定変更後は、それぞれを個別に確認し、すべての名前欄を一律に空にしないでください。

証明書エラーが発生したら、まずシステム時刻を確認し、サブスクリプションのサーバー名が保持されているか、サーバー証明書が有効かを調べてください。証明書検証を無効にすると接続の信頼条件が変わるため、通常のトラブル対処として常用しないでください。サーバーが独自の信頼基盤を使う場合は、管理者に正しい設定を確認しましょう。各端末で検証を恒常的に無視するのは適切ではありません。アプリケーション層プロトコルのネゴシエーションも双方の一致が必要です。関連するハンドシェイクエラーが出た場合は、別の設定からよく見かける値をコピーせず、サーバーの要件を確認してください。

REALITY：サーバーが公開するパラメーターに合わせる

REALITYはXrayエコシステムのセキュリティ層方式です。クライアント側の主な設定項目には、サーバー名、サーバーが提供する公開鍵、short ID、クライアントフィンガープリントがあります。クライアントで使うのは公開情報であり、サーバーの秘密鍵をクライアントに配布してはいけません。サーバー名も任意のWebサイト名に置き換えられるものではなく、サーバー側で許可された値を指定します。short IDを空欄にできるか、何を入力するかはサーバーの設定次第です。プロトコルとUUIDだけを残して他の項目を失うと、設定一覧には表示されても接続できないことがあります。

クライアントフィンガープリントは特定のハンドシェイク動作を選ぶもので、ブラウザーやアカウントの身元、通信速度の段階を示すものではありません。選択肢や関連機能への対応状況はコアによって異なるため、設定元が指定し、現在のコアが対応している値を使ってください。フロー制御とREALITYも別の設定です。前者はプロトコルの動作、後者はセキュリティ層に属します。併用されることはよくありますが、個別に確認しましょう。セキュリティ方式に未対応というログが出た場合は、まずコアを確認します。ハンドシェイクまで進んで失敗する場合は、サーバー名、公開鍵、short ID、ネットワークへの到達性を調べてください。

確認の順番は、サーバーアドレスとポート、プロキシプロトコルと認証情報、伝送方式、セキュリティ層のパラメーターとするのがおすすめです。各層を確認するたびに、ログに出た具体的なエラーを記録してください。これにより、接続先に到達できないのか、伝送方式が一致しないのか、認証に失敗したのかを切り分けられます。パス、サーバー名、フロー制御を同時に変更すると、接続が戻っても原因を特定しづらくなり、サブスクリプション更新後に同じ問題が再発するおそれがあります。

4. Project V、V2Fly、Xrayのコアの系統

Project Vはこのツール群のエコシステムを理解する出発点であり、V2Rayはその中で広く利用されているコアプロジェクトです。V2Flyコミュニティは関連する開発と保守を引き継ぎ、Xrayは近いコードや設計の背景から独立して発展したコアの系統です。共通の概念を持ちながら、それぞれ機能を追加し、実装を変更しています。単純な新旧の置き換え関係ではないため、名称だけでどちらがあらゆる設定に適しているかは判断できません。プロトコル、伝送方式、セキュリティ層、拡張項目が実際にサポートされているかを確認して選びましょう。

GUIクライアントとコアの役割

v2rayN、v2rayNG、v2flyNGは、設定の保存、サブスクリプションの追加、ルーティングの管理、コアの起動を行うGUIクライアントです。プロキシ接続の処理は主にコアが担います。画面に項目が表示されても、起動中のコアがその項目を受け付けるとは限りません。リンクを読み込めても、内部で完全な互換性が確認されたことにはなりません。起動エラーを報告するときは、クライアント名、実際のコアの種類、エラーメッセージを記録してください。「インポートできたが使えない」だけでは、原因を判断する材料が足りません。

デスクトップではv2rayNから始め、対応する設定や画面で実際に使われているコアを確認しましょう。Androidのv2rayNGは主にXrayコアをベースとし、v2flyNGはv2flyコアを使う場合の選択肢です。利用できる機能は、インストールパッケージに含まれるコアやクライアントの実装にも左右されます。クライアントを乗り換える前に、問題がプロトコル機能の不足なのか、端末の権限、サブスクリプションの変換、サーバー設定の誤りなのかを確認してください。画面を変えても、誤った認証情報は自動で修正されません。

基本構造が共通でも拡張項目は共通とは限らない

どちらのコアも、インバウンド、アウトバウンド、ルーティング、DNSなどの概念を使い、一部の設定構造は似ています。そのため基本設定には移行できる部分がありますが、拡張プロトコル、セキュリティ層、フロー制御、DNSの動作、項目名などには違いがあります。REALITYや一般的なVisionのフロー制御の組み合わせは、Xrayの明示された対応範囲に沿って確認してください。v2flyコアでもそのまま動くと決めつけないでください。逆に、特定のコア向けに生成された設定も、ファイル名を変えるだけで別のコアに渡せるとは限りません。

設定を移行するときは、共有リンクとネイティブ設定を区別してください。共有リンクが表すのは単一サーバーの接続パラメーターであり、クライアントはそこからローカル接続、ルーティング、DNSを再生成できます。一方、ネイティブのJSON設定にはこれらがすでに含まれていたり、独自のタグやファイルパスに依存していたりすることがあります。以下は2系統のコアでよく見られるルーティングルールの例です。既存の設定に統合し、参照するアウトバウンドタグが定義済みであることを確認してください。単独で起動できる完全な設定ではなく、サーバーの認証情報も変更しません。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": "0-65535",
        "outboundTag": "proxy"
      }
    ]
  }
}

このルールは、まずプライベートアドレスを直接接続し、それ以外のポートをプロキシのアウトバウンドに送ります。アドレスリストを使う場合は、実行環境に対応するデータファイルが必要です。既存の設定にdirectまたはproxyという名前のアウトバウンドがない場合は、存在しない参照を追加せず、実際のタグ名に変更してください。ルールは上から順に適用されるため、広い条件を先に置くと後続の具体的な条件が適用されなくなります。GUIクライアントが設定を自動生成する場合は、独自ルールが再生成時に上書きされないかも確認しましょう。

コアを切り替える前に元に戻せる状態を残す

v2rayNでコア関連の設定を変更する前に、現在の設定をバックアップし、システムプロキシ、ルーティングモード、DNSの状態を記録してください。切り替え後は、まずコアが正常に起動するか確認し、次に同じサーバー設定で接続を試します。ログに未知の項目や未対応のセキュリティ方式が明示された場合は、元の設定に戻して対応範囲を確認してください。起動するまで項目を次々と削除するのは避けましょう。設定を読み込めることは最初の段階にすぎません。認証、名前解決、アプリからのアクセスも個別に検証する必要があります。

クライアントとコアの更新時期は必ずしも一致しません。画面の変更は設定管理だけに影響することがありますが、コアの変更はプロトコル対応や既定の動作を変える場合があります。更新情報を見るときは、バージョン番号だけを追うのではなく、現在の設定に関係する機能を確認してください。このページでは一律に必要となるバージョンを指定しません。ダウンロード時はプラットフォーム別の配布ページで適切なインストーラーを選び、移行前に元の設定を保存し、移行後に実際の機能で互換性を確かめてください。

5. サブスクリプション形式と共有リンクの互換性

サブスクリプションURLは設定一式を取得するための入口であり、プロキシプロトコルではありません。サーバーから返される内容は、共有リンクの一覧、エンコードされたテキスト、構造化設定などさまざまです。クライアントはまず形式を識別し、各レコードを編集・実行可能な形に変換します。そのため、「更新に成功した」「サーバー項目が表示された」「接続できた」は別々の段階です。互換性を確認するときは、それぞれを個別に確認してください。内容をダウンロードできたからといって、すべての項目が正しく読み込まれたとは限りません。

リンクの見た目が似ていても、項目の表し方は異なる

VMessの共有リンクは、エンコードされた構造化データを含む形式がよく使われます。VLESSとTrojanはアドレスに似た書式を使い、ユーザー名に認証情報を入れて、クエリパラメーターで伝送方式やセキュリティ項目を指定することがよくあります。SSの共有リンクでは、暗号化方式とパスワードのエンコード方法も関係します。これらは一般的な書式であり、すべての生成ツールが同じ形式とは限りません。備考欄の日本語、空白、特殊文字は正しくエンコードする必要があり、認証情報の特殊文字を手作業で削って「整える」のも避けてください。

同じ項目でも、形式によって異なる名前で表されることがあります。ある共有形式では短いパラメーターでサーバー名を指定し、ネイティブ設定ではセキュリティ設定のオブジェクト内に別項目として記述する、といった違いです。インポーターが項目を変換しますが、新しい拡張すべてに対応するとは限りません。追加後は備考欄を見るだけでなく、編集画面を開いてプロトコル、伝送方式、サーバー名、フロー制御、REALITY関連の項目を照合してください。同じ名前の項目が複数ある場合は、選択中のものが更新した設定かどうかも確認しましょう。古い項目で新しいサブスクリプションを検証してしまうのを防げます。

サブスクリプション更新でローカルの変更が残るとは限らない

多くのクライアントではサブスクリプション設定と手動追加したサーバーが分かれており、更新時にサブスクリプション内の項目が再生成されることがあります。サブスクリプションの項目でパス、フロー制御、備考を直接変更すると、次回の更新で上書きされる場合があります。一時的に比較する場合は、手動設定として複製し、用途を明記しましょう。問題を確認したらサブスクリプションの提供元で修正し、内容の異なる設定を複数長期間管理しないようにしてください。一度の変更を残すために更新を止め続けると、サーバーアドレスや認証情報の変更後に設定が無効になるおそれがあります。

v2rayNでは「サブスクリプショングループ設定」でURLとグループを確認し、サブスクリプションを更新できます。Androidクライアントでは、サブスクリプション管理と更新の画面で同じ情報を確認してください。画面によってメニュー名は多少異なりますが、確認の要点は共通です。グループが保存されているか、リクエストが成功したか、返された形式を認識できたか、対象の項目が現在のグループに属しているかを確認しましょう。更新後に項目数が大きく減った場合は、すぐにすべての設定を消去せず、更新ログと形式を確認してください。操作前にバックアップしておけば、有効な比較用データを残せます。

サブスクリプション変換では不足する機能を補えない

形式変換では、ある形式の項目を別形式の対応項目に置き換えられますが、REALITYに対応していないコアに機能を追加したり、欠けているパスワードの正しい値を導き出したりはできません。インポート後に項目が欠けている場合は、まず元データにその項目が含まれているか確認し、次にインポーターが認識しているかを調べてください。完全なサブスクリプションURLを、信頼できない変換サイトに送信しないでください。URLにアクセス用の認証情報が含まれている場合、漏えいすると他人に同じ設定一式を取得されるおそれがあります。トラブルの情報を共有する際は、機密情報を隠した項目とエラーメッセージだけにしてください。

複数の端末で同じサブスクリプションを使うとサーバー設定をそろえられますが、システムプロキシ、VPNの許可、アプリの選択、DNS設定などは端末ごとに必要です。バックアップファイルには端末固有のパスやローカルポートが保存されていることもあり、異なるプラットフォームに復元しただけで動くとは限りません。詳しくは複数端末で設定を同期する方法を参照してください。初回インポートの基本手順はクイックスタートガイドが基準です。この節では形式と項目の違いを扱います。

6. 接続速度とリソース消費の比べ方

「速度が速い」には、最初の応答が速い、連続転送が安定している、アイドル後の復帰が速いなど、複数の意味があります。それぞれ影響する要因が異なります。初回アクセスでは名前解決、接続の確立、セキュリティハンドシェイク、プロキシ認証が必要です。連続転送では回線速度、混雑、パケットロス、サーバー負荷、端末の処理能力が大きく影響します。アイドル後の復帰には、接続の破棄やモバイル端末のスリープも関係します。1種類のテスト結果だけでプロトコル全体の性能を判断すると、矛盾した結論になりがちです。

条件をそろえてからプロトコルを比較する

サーバーが複数のプロトコル接続先を提供している場合は、同じ端末、同じ接続方式、近い時間帯で比較しましょう。同じアプリで同じ操作を行い、ルーティングモードとDNS設定も変えないでください。プロトコルごとに接続するサーバーの地域が異なるなら、比較結果に表れるのは主に回線の違いです。テストでは初回接続と、既存の接続を再利用したアクセスも分けて考えましょう。ブラウザーで2回目の表示が速くても、キャッシュや接続の再利用によるもので、プロトコルを変更した効果とは限りません。

プロトコルの処理負荷は、ハンドシェイクの回数、カプセル化の層、認証処理、暗号化計算、接続管理に分けて考えられます。プロキシ層が簡素なら一部の処理を減らせる可能性がありますが、外側の伝送方式が複雑だったり、端末が関連するハードウェア支援に対応していなかったりすると、実際の差は予想と異なることがあります。TLSの接続再開で次回以降の接続コストを抑えられる場合もありますが、効果は実装や接続条件によります。条件を管理したテストを行わずに、特定のプロトコルが必ず速い、特定の暗号化方式が必ず省リソースだと順位付けするのは避けてください。

CPUとメモリの使用量は通信処理全体を反映する

CPU使用率には暗号化だけでなく、データのコピー、名前解決、ルール照合、ログ出力、ローカル接続の処理も含まれます。TUNモードとシステムプロキシモードでは経路が異なるため、それぞれを別のプロトコルでテストすると接続方式の違いも結果に混ざります。メモリ使用量にはルールデータベース、アクティブな接続、DNSキャッシュ、GUIも影響します。タスクマネージャーでクライアント全体のメモリ使用量が多くても、プロトコル自体の負荷が高いとは限りません。アイドル時と同じ負荷をかけた場合の変化を合わせて観察してください。

多重化は、既存の接続で複数の論理ストリームを運び、接続の確立を繰り返す回数を減らせる一方、輻輳や障害の影響範囲も変えます。1本の接続でパケットロスが起きると、複数のリクエストに影響することがあります。伝送方式自体にストリーム管理がある場合、多重化を重ねても効果が高まるとは限りません。特定のフロー制御を必要とする組み合わせでは、コアの説明に従ってください。「最適化」のためにすべての多重化設定を一律に有効にせず、まず既定の動作を保ち、短時間の接続が多い場合や特定のアプリで必要な場合に検証しましょう。

UDP、DNS、接続復帰を分けて測定する

Webページが開けても、アプリが必要とするUDP通信が正しく転送されているとは限りません。リアルタイム音声・映像、一部のインタラクティブなアプリ、特定の通信経路ではUDPが使われることがあります。対応状況はローカル接続、プロキシプロトコル、コア、サーバーのすべてに左右されます。設定を選ぶときは、アプリが実際に必要とする通信の種類を確認し、プロトコル名だけで通信経路全体の対応を判断しないでください。一部のアプリだけに問題がある場合は、その通信がプロキシに入っているか、UDPが適切なアウトバウンドにルーティングされているか、サーバーが必要な転送を許可しているかを確認しましょう。

DNSの使い勝手も、1回の検索結果だけでは判断できません。キャッシュの有無、並列検索、名前解決を行う場所、ルーティング方針が、その後の接続に影響します。ブラウザー独自の名前解決機能が有効な場合、クライアントのDNS設定ですべての検索を制御できるとは限りません。原因を調べるときは、まずリクエストがどこで名前解決されるかを確認し、取得したアドレスと接続経路が一致しているかを調べましょう。プロトコルを変更した直後にキャッシュが消去されていれば、一時的な改善は名前解決状態の変化による可能性もあります。変更前後の条件を記録すると、原因と結果を切り分けられます。

同じ時間帯にすべてのプロトコルが遅い場合は、まずローカルネットワークとサーバー側に共通する要因を確認します。初回アクセスだけ遅い場合は名前解決とハンドシェイク、連続転送が途切れる場合はパケットロス、アイドルタイムアウト、リソース負荷に注目してください。特定のアプリだけに影響があるなら、接続方式とルーティングに戻って確認しましょう。詳しい切り分け方法は接続が遅いときの段階的な診断方法を参照してください。プロトコル選びは原因を特定してから行い、診断の代わりに最初に変更するものではありません。

7. Androidの電池消費とバックグラウンド接続

Androidの電池消費は、VMess、VLESS、特定のコア名だけで決まるものではありません。クライアントがシステムVPNを通じて接続すると、選択したアプリの通信を継続的に処理します。プロセッサの動作、無線通信、DNS検索、再接続、ログ出力はいずれも電池を消費します。同じ設定でもWi-Fiとモバイルデータでは結果が異なり、電波が弱い場合は消費量が大きく増えることもあります。比較する前にネットワーク環境、画面の状態、前面で使うアプリをそろえ、端末全体の使い方の違いをプロキシプロトコルの影響と混同しないようにしましょう。

VpnServiceの許可とバックグラウンド制限

v2rayNGまたはv2flyNGでローカルVPNサービスを初めて開始するときは、Androidのシステム許可が必要です。許可後は、アプリの状態とログを確認してから、対象アプリで通信できるかを検証してください。システムのVPNアイコンは、接続先が利用可能である証明ではありません。同じ接続経路を使う別のアプリがすでに動作している場合、現在の接続を同時に確立できないことがあります。プロトコルを何度も変更するのではなく、システムがどのサービスを有効にしているか確認しましょう。メーカー独自のシステムでは、バックグラウンドサービスに追加制限がかかることもあります。

画面ロック後に切断し、クライアントを再度開くと復旧する場合は、バッテリー最適化、バックグラウンド動作の許可、自動起動の管理を確認しましょう。設定画面の場所はメーカーによって異なるため、システムのアプリ情報から電池やバックグラウンド関連の項目を探し、必要なクライアントだけ調整してください。バックグラウンド制限を緩和すれば接続が保たれやすくなる一方、バックグラウンドでの動作時間が増える可能性があります。一律に電池を節約できる方法ではありません。変更後は同じ時間だけ画面をロックして再テストし、プロセスがシステムに一時停止または終了されていたかを確認してください。

暗号化をむやみに減らさず、不要な再接続を防ぐ

接続に何度も失敗すると、名前解決、ハンドシェイク、認証が繰り返され、モバイルネットワークでは無線モジュールが何度も起動することがあります。同じハンドシェイクエラーがログに繰り返し出る場合は、再試行を続けるのではなく、サーバー名、セキュリティ設定、時刻の問題をまず修正してください。Wi-Fiとモバイルデータを切り替えると既存の接続が失われ、新しい経路を確立する必要がある場合があります。この復帰動作だけで、プロトコルが不安定だとは判断できません。ネットワーク切り替え時だけ起きるのかを記録すると、接続中に継続して発生する切断と区別できます。

電池を節約するためにセキュリティ層を無効にするのは、接続の保護条件を変えることであり、通常の最適化として適切ではありません。まずは、不要なバックグラウンド通信、繰り返しの接続テスト、長時間の詳細ログ、頻繁すぎるサブスクリプション更新を確認しましょう。トラブル対処中は必要なログレベルを使い、情報を集めたら通常の設定に戻してください。通信量が少ないのに端末が発熱する場合は、選択中のプロトコルの暗号化処理を原因と決めつけず、失敗の繰り返しや異常なアプリ動作がないか調べましょう。

アプリ別プロキシでクライアントに入る通信を選ぶ

アプリ別プロキシでは、指定したアプリだけをプロキシに通したり、指定アプリを除外したりできます。具体的な設定名はクライアントの画面で確認してください。2つのモードは意味が逆なので、どのアプリにチェックを入れたかだけでは判断できません。設定後は対象アプリを再度検証しましょう。アプリによってはログイン、ダウンロード、システムサービスを別のコンポーネントが処理するため、メインアプリだけを選択しても必要な通信すべてを含められないことがあります。アプリ別設定の結果、ログイン画面とメイン画面が別の経路を使うと、一部の機能だけ動作する場合があります。

アプリ別プロキシは、ドメインごとのルーティングとは異なります。前者はどのアプリの通信をローカルの接続経路に入れるかを決め、後者はクライアントに入ったリクエストをどのアウトバウンドに送るかを決めます。アプリが接続対象から除外されていれば、クライアント内のドメインルールを変更しても影響しません。逆に、アプリが接続経路に入っていても、ルーティングルールによって直接接続されることがあります。原因を調べるときは、まずアプリの選択を確認し、その後ルーティングを調べてください。両方を同時に変更すると、どの層の変更が影響したのか判断しにくくなります。

電池消費は接続直後の一時的な割合ではなく、通常の使用を一定時間続けて比較しましょう。システムの電池使用記録を見るときは、アプリの動作時間と実際の操作内容も踏まえ、短時間の変化を固定的な結論にしないでください。詳しい設定方法はv2rayNGの許可設定、電池消費対策、アプリ別設定を参照してください。プロトコルを選ぶ際は、まず互換性と接続の安定性を確保してから、不要な処理を減らします。モバイル端末では、プロトコル名を議論するより、繰り返し発生する接続失敗を防ぐほうが実用的です。

8. 用途に応じた選択と互換性の確認

最終的な選択では、次の4点を確認します。使用する端末とクライアント、サーバーが提供するプロトコル・伝送方式・セキュリティ層の組み合わせ、アプリに必要な接続方式と通信の種類、そして問題を再現できるかどうかです。まず互換性を確保し、次に性能を評価し、最後に任意の最適化項目を調整します。サーバーやコアから独立した、あらゆる環境に共通の最適なプロトコルはありません。日常利用には、出所不明でも名前が新しい組み合わせより、安定して保守しやすく、設定が明確な構成が適しています。

デスクトップで普段使うなら、まずv2rayN

Windows、macOS、Linuxのデスクトップでは、まずv2rayNの各OS向けインストーラーを確認し、端末のアーキテクチャとOSに合ったものを選びましょう。Windowsデスクトップ版と従来のWPF版の違いは、主に画面の実装方式と操作感にあります。遠隔サーバーのプロトコル性能を直接示すものではありません。インストールと起動の手順はWindowsのインストールと設定方法を参照してください。macOSでシステムの許可を求められた場合は、インストールと権限の対処方法を確認しましょう。まずクライアントを正常に起動してから設定を追加してください。

ブラウザーやシステムプロキシ設定に従うデスクトップアプリでは、まずシステムプロキシで最小限の接続確認を行いましょう。TUNなどの方式は、必要がある場合に検討してください。初回のインポート時に独自DNS、複雑なルーティング、コアの切り替えを同時に追加しないでください。必要な項目がそろった設定を1つ選び、コアの起動と実際のアクセスを確認してから、必要なルールを少しずつ戻します。使えていた設定がルールの追加後に不具合を起こした場合は、まずルールを元に戻してください。プロトコルまで同時に変更しないようにしましょう。

Android：必要なコアと対象アプリに応じて選ぶ

サーバーがXrayの機能に依存するVLESSとREALITYの組み合わせを提供している場合は、v2rayNGが実際に対応しているか、必要な項目がすべてそろっているかを確認してください。v2flyコア向けの設定がすでにある場合は、v2flyNGも選択肢になります。伝送方式と各項目が対応範囲に含まれているか確認しましょう。2つのクライアント間で移行するときは、まず設定を1件だけ移して検証し、すぐにすべてのデータを上書きしないでください。システムVPNの許可、バックグラウンド権限、アプリの選択は、新しいクライアントでも改めて確認する必要があります。

少数のアプリだけにプロキシが必要なら、接続対象を絞れるアプリ別モードを検討できます。複数のアプリが連携して動作する場合は、ログインに関係するコンポーネントを先に確認し、設定を分けすぎて処理が途切れないようにしてください。リアルタイム通信などUDPを使う場合は、Webページを開くだけでなく接続経路全体を検証しましょう。ネットワークを頻繁に切り替える端末では、画面ロック後の復帰やネットワーク切り替え後の再接続も確認し、接続直後だけでなく日常の利用条件で判断してください。

既存のサブスクリプションと自主管理サーバーでは選び方が異なる

既存のサブスクリプションでは、プロトコルは通常サービス提供者が決めています。利用者ができるのは、適切なクライアントを選び、必要な項目を保持し、適切な接続先を選んでローカル接続を確認することです。クライアントにサーバー側のプロトコルを別のプロトコルへ変換させることはできません。自主管理サーバーの場合は、先にクライアントとアプリの要件を決め、双方が対応するプロトコル、伝送方式、セキュリティ層を選び、証明書や鍵の保守方法も用意します。不要なカプセル化を減らすと原因を調べる範囲を絞れますが、認証を省略してはいけません。

複数のプラットフォームで同じ設定を使う場合は、1台で動いた設定を基準にするのではなく、対象となるすべてのクライアントが実際に対応している範囲の共通部分を選びましょう。用途別の設定を残す場合は、備考と対応端末を明確に区別してください。サーバーのプロトコルやセキュリティ設定を変更した後は、各端末で順に検証します。古い設定、サブスクリプションのキャッシュ、手動で作成した複製にも注意してください。独自のネイティブ設定では、ローカルパス、ルール用データ、アウトバウンドタグも確認し、端末をまたいでそのままコピーできるサーバー項目と混同しないようにしましょう。

最後に一通りの手順で調整結果を確認する

1. クライアントと端末のアーキテクチャが適切で、コアが起動し、ローカルポートが競合していないことを確認します。
2. プロトコル、アドレス、ポート、認証項目に加え、伝送方式とセキュリティ層の必要な設定をすべて照合します。
3. システムプロキシまたはVPN接続が有効になっていることを確認し、状態アイコンだけでなく実際のアプリで接続を検証します。
4. ドメインの名前解決、ルーティングの結果、必要な通信の種類をそれぞれ確認し、再現可能な形でエラーを記録します。
5. 最後に画面ロック、ネットワークの切り替え、長時間の使用を試し、サブスクリプション更新後も設定が想定どおりか確認します。

原因が特定できない場合は、まず動作が確認できている設定に戻し、差分を比べながらこのページの層に沿って切り分けてください。エラーがローカル接続、サーバーへの接続、ハンドシェイク認証、ルーティングや名前解決のどこで起きたかによって、次に確認する箇所が決まります。問題を共有するときは、OS、クライアント、コアの種類、プロトコルの組み合わせ、機密情報を隠したログを記載し、パスワード、UUID、サブスクリプションURLは公開しないでください。操作手順を最初からやり直す場合はクイックスタートガイドへ、別のプラットフォーム向けのインストーラーが必要な場合はクライアントのダウンロードページへ進みましょう。トラブル対処中に、未検証の設定を何種類も追加しないでください。