V2Ray プロトコルとカーネル技術リファレンス

v2rayNG や v2rayN でノードを開く前に、まず 3 つの層を切り分けておくと、その後の選択がずっと分かりやすくなります。層はクライアント、カーネル、プロトコルと転送の 3 つで、それぞれ変更できる範囲が違います。

3 つの層の役割

クライアントは目に見える層です。デスクトップでは v2rayN、Android では v2rayNG と v2flyNG が該当します。クライアントは画面、サブスク管理、ルーティングの切り替え、アプリごとのプロキシといった操作を担当し、ノード情報をカーネルが読める設定に変換します。

カーネルは実際に接続を確立するプログラムです。JSON 設定を読み、inbounds で本機のトラフィックを受け取り、outbounds で送り出し、その間を routing のルールでどのアウトバウンドを通すか決めます。v2rayNG が呼び出すのは Xray カーネル、v2flyNG は V2Fly カーネル、デスクトップ版 v2rayN も Xray カーネルが中心です。使えるプロトコルはカーネルで決まります。たとえば REALITY は Xray 側にしか存在せず、REALITY ノードを v2flyNG にインポートしても解析できません。

プロトコルと転送は実際の挙動を決める層です。プロトコルは VMess、VLESS、Trojan、Shadowsocks、REALITY といった認証とカプセル化の方式を指し、転送は TCP、WebSocket、gRPC といった搬送方式を指します。さらに TLS を使うかどうかが重なります。この層は通常サブスクと一緒に配信されるため、日常的に手で書くことはほとんどありません。

日常的に変えられるのは実は数項目だけ

クライアントの設定画面を開くと、一般ユーザーが実際に触る項目は数か所に集中しています。どのノードを選ぶか、ルーティングモードをどれにするか、どのアプリをプロキシ経由にするか、自動起動を有効にするかどうかです。プロトコルと転送はノードに付いてくるもので、その場で編集するものではありません。つまり「プロトコルを正しく選ぶ」のは、サブスクを選んだり自前の設定を整理したりする段階の話で、接続のたびに考えることではありません。プロトコルの違いを理解する価値は 2 つあります。1 つのサブスクに複数プロトコルのノードが混在しているとき、どれを先に試すべきか分かること。そして、あるノードがつながらないとき、原因がプロトコルのパラメータにあるのか回線そのものにあるのかを判断できることです。

本ページとはじめかたページの役割分担

はじめかたは、1 回の接続を通すための最短ルートを扱います。サブスクのインポート、モードの選択、接続、確認という流れで、各手順は必要な操作だけを説明します。本ページはその本線を繰り返すのではなく、各段階の背後にある選択を掘り下げます。プロトコル同士はどこが違うのか、2 つのカーネルをどう使い分けるのか、サブスクのフィールドはどう対応するのか、どの場面でどの組み合わせを使うのか。今すぐつながればよいという場合は、まずはじめかたをご覧ください。サブスクを選ぶ、自前の設定を整理する、あるいはトラブルを切り分けるという場合は、このページに留まってください。

目的別に章を探す

• 5 種類のプロトコルの設計差を知りたい → プロトコルファミリー
• ハンドシェイクのコストとリソース消費を比べたい → 速度とオーバーヘッドの比較
• v2rayNG と v2flyNG のカーネルの違いを知りたい → カーネルファミリー
• サブスクのインポートに失敗する、フィールドが合わない → サブスク形式と互換性
• 転送方式とルーティングモードの影響を知りたい → 転送とルーティング
• Android 端末の電池消費が気になる → モバイルの電池消費
• おすすめの組み合わせをすぐ見たい → 用途別の選定
• フィールドの早見表やトラブルシューティングの一覧が必要 → パラメータ早見表とトラブルシューティング

用語の取り決め

本ページでいうノードとは、サーバーアドレス、ポート、認証フィールド、転送パラメータを含む 1 件分の完全なアウトバウンド設定を指します。サブスクは複数のノード情報を含むリンクまたはファイル、カーネルは v2ray-core 系の処理プログラム、インバウンドとアウトバウンドはそれぞれ本機トラフィックの入口と出口に対応します。フロー制御は、プロトコル層がデータ転送方式を制御するパラメータを指します。REALITY は本ページではプロトコル層の方式として扱い、選定と互換性の判断にとどめ、サーバー側の構築手順には踏み込みません。

プロトコル同士の違いは、たいてい「どちらが速いか」の一言で答えられる問題ではありません。各方式が設計時に何を優先して解決し、何をあえて手放したかという話です。5 つのプロトコルをそれぞれの出発点に戻して見ると、選定時の迷いはかなり減ります。

VMess:プロトコル自体が認証と暗号化を担う

VMess は V2Ray プロジェクトが初期に持っていた独自プロトコルで、品質が安定しない回線上でも本人確認とデータのカプセル化を完了させることを狙っています。UUID の認証フィールドとタイムスタンプ検証を備え、初期は alterId の仕組みで複数のサブ ID を生成していましたが、後に AEAD 認証暗号へ移行し、alterId を 0 にするのが主流になりました。設計上の特徴は、認証も暗号化もプロトコルの内部で完結するため、外側に TLS がなくても動作することです。代償として、パケットごとに 1 層余分なカプセル化がかかり、ハンドシェイク時にクライアントとサーバーが 1 往復の要求と応答を交わすため、モバイル端末ではプロセッサの起床回数が増えます。

VLESS:暗号化は外側に任せる

VLESS は VMess の引き算版と考えると分かりやすいでしょう。プロトコル自前の暗号化層を外し、軽量な識別子と任意のフロー制御パラメータだけを残しました。暗号化は完全に外側のチャネル、通常は TLS に任せます。トレードオフは明確で、「素の状態でも暗号化される」能力を手放す代わりに、より短いハンドシェイク経路とより少ないカプセル化バイトを手に入れています。そのため VLESS は TLS か同等の信頼できる暗号化チャネルと組み合わせて使う必要があり、単体で裸のまま使っても機密性は得られません。Xray カーネルでは、VLESS に flow パラメータを組み合わせて XTLS Vision フロー制御を有効にし、暗号化・復号の層をさらに減らせます。

Trojan:トラフィックを標準的な HTTPS の見た目に保つ

Trojan は新しいトラフィック形態を発明せず、プロキシのトラフィックを標準的な HTTPS アクセスそのものの見た目に保ちます。サーバーは 443 番ポートで待ち受け、本物の証明書を保持します。パスワードが正しければトラフィックを転送し、誤っていればリクエストを実在のサイトへフォールバックします。外部から見れば、ただの普通の Web サーバーです。トレードオフは、ドメインと有効な証明書が必須で、証明書やポートの設定を誤るとまったく使えなくなること。利点は設定の概念が少なく理解コストが低く、トラフィックの形が通常の HTTPS と非常に近いことです。

Shadowsocks:軽量な対称暗号

Shadowsocks は軽量な対称暗号の路線を取ります。クライアントとサーバーが 1 つのパスワードを共有し、そこから暗号鍵を導出します。追加の認証ハンドシェイク用フィールドはありません。一般的な暗号方式は chacha20-ietf-poly1305 や aes-256-gcm といった AEAD アルゴリズムです。カプセル化のオーバーヘッドはこの中で最小で、実装も最も単純なため、計算資源の限られた機器でもよく使われます。代償は、プロトコル自体に偽装層がなくトラフィックの特徴が比較的固定されるため、外側のカプセル化やプラグインで補う必要があることです。

REALITY:実在サイトのハンドシェイク手順を借りる

REALITY は Xray 側が提唱した方式で、証明書の維持コストという具体的な問題に狙いを定めています。通常の TLS 方式では自分のドメインと証明書が必要ですが、REALITY はハンドシェイク段階で実在するサイトの証明書チェーンを借ります。クライアントは対象サイトの公開鍵を事前に知っており、ハンドシェイクで検証するのはその対象サイトで、サーバーは自分の証明書を持つ必要がありません。利用者から見ると、REALITY ノードは通常いくつかのパラメータを埋めるだけで済みます。公開鍵、shortId、対象ドメインです。現在は主に VLESS と組み合わせ、XTLS Vision フロー制御と併用します。

5 つの方式のトレードオフ対照

表からはっきりした進化の筋道が読み取れます。初期の方式は能力をプロトコルの内部に作り込む傾向があり、後の方式は能力を外側に任せ、プロトコル自体をできるだけ薄くする傾向があります。この筋道は、新しいプロトコルがしばしば TLS との併用を前提とする理由も説明します。安全の境界を外へ移したからです。

「どのプロトコルが速いか」は、まず分解して考える必要があります。1 回の接続にかかる時間は 3 つの部分からなります。物理回線の往復、ハンドシェイクの往復回数、暗号化・復号とカプセル化の処理時間です。前の 2 つはサーバーの位置と回線品質で決まり、プロトコルとは関係ありません。プロトコルが影響できるのは 3 つ目と、ハンドシェイクに何往復必要かだけです。したがって同じサーバーでプロトコルを変えて速度を測っても差はふつうごく小さく、サーバーを変えれば差ははるかに大きくなり得ます。

ハンドシェイク経路:何往復必要か

VMess のハンドシェイクは要求と応答の 2 段階で、クライアントは認証情報を送った後、サーバーの確認を待ちます。VLESS は軽量な識別子を 1 つ持つだけで、追加の確認往復を待ちません。Trojan は標準の TLS ハンドシェイクを行い、パスワード検証はハンドシェイク後のアプリケーション層データで行われます。Shadowsocks には認証の往復がなく、鍵は共有パスワードから直接導出されます。REALITY のハンドシェイクは実在サイトへのアクセスと同じ流れで、クライアントが検証するのは対象サイトの証明書チェーンです。往復回数が少ないほど、遅延の大きい回線での初回パケット時間が短くなります。

カプセル化の層数:暗号化・復号を何回行うか

カプセル化の層数がプロセッサの負荷を決めます。VMess は自前の暗号化を持ち、外側にさらに TLS を重ねるとデータは 2 回暗号化・復号されます。VLESS と Trojan は自身では暗号化せず、TLS の 1 層だけです。REALITY は XTLS Vision と組み合わせるとプロキシのデータを直通させられ、重複する暗号化・復号を減らせます。デスクトップのプロセッサではこの数層の差はほとんど体感できませんが、低消費電力の Android 端末では電池消費と発熱に表れます。この点はモバイルの電池消費の章で詳しく扱います。

3 つのオーバーヘッド対照

差が体感できるのはどんなときか

3 つの状況ではプロトコルの差がはっきりしてきます。回線自体の遅延が大きいときは、ハンドシェイクの往復回数の影響が増幅されます。端末の計算能力が限られるときは、暗号化・復号の層数がそのまま電池消費と速度低下に表れます。同時接続数が多いときは、接続ごとのオーバーヘッドが積み上がります。逆に、遅延の小さい固定ブロードバンドと中位以上の端末という条件では、VMess と VLESS の体感差は安定して再現できないほど小さいのが普通です。

意味のある自己計測のやり方

v2rayNG のノード一覧では、メニューから遅延テストを実行できます。よく使うのは TCP テストと実接続テストの 2 種類です。TCP テストはアドレスとポートに到達できるかだけを確認するもので、速い代わりに得られる情報は少なめです。実接続テストは実際にプロキシ接続を 1 回確立するため、結果は実使用に近くなります。プロトコルを比較するときは、次の順序で進めます。

1. サーバーを 1 台に固定し、同じ設定をプロトコル別に 1 つずつアウトバウンドとして書く。
2. 実接続テストを各 3 回行い、単発の数値ではなく変動幅を記録する。
3. すべてのテストを同じ時間帯に完了させ、時間帯をまたいだ比較を避ける。
4. さらに実際のアクセス確認を 1 回行い、テスト結果と体感が一致するか確かめる。

3 回の結果が重なり合うなら、その回線ではこれらのプロトコルに判別できる差はなく、選定は別の要素に移すべきです。偽装が必要か、証明書の維持コスト、端末の電池消費などです。同じ考え方でノードを絞り込む一連の流れは初回接続チェックをご覧ください。

サブスクはノード情報がサービス提供者からクライアントへ届く主要な経路です。形式を理解しておくと、インポートに失敗したときに原因を素早く特定でき、クライアント間で設定を移すときにフィールドを落とすのも防げます。

サブスクリンクと共有リンクの違い

共有リンクは 1 つのノードを表し、vless:// や vmess:// のような形式です。1 本コピーすればノードを 1 つインポートできます。サブスクリンクはノードの集合を表し、それ自体が HTTP または HTTPS のアドレスです。クライアントがアクセスするとテキストが返り、その 1 行 1 行が共有リンクになっています。サブスクの価値は更新にあります。ノードの追加や削除があったとき、提供者が 1 か所を直せば、クライアントは次回の更新で同期でき、1 件ずつコピーし直す必要はありません。

テキストはどう符号化されているか

サブスクが返す内容には 2 つの一般的な形があります。平文の複数行の共有リンクと、テキスト全体を 1 回 Base64 エンコードした単一の文字列です。クライアントはインポート時にまず平文として解析し、失敗すると Base64 としてデコードしてから解析します。そのためサブスクの中身を手で確認するとき、改行のない長い文字列が見えたら、まず Base64 デコードしてから読んでください。デコード後の各行はプロトコル名で始まっているはずです。

4 種類の共有リンクのフィールド形態

見て分かるように、VMess と Shadowsocks はフィールドを Base64 の塊に詰め込み、VLESS と Trojan はフィールドを URL クエリパラメータに展開します。REALITY ノードは通常 vless:// の形で現れ、公開鍵と shortId の 2 つのパラメータを追加で持ちます。どちらか一方でも欠けるとハンドシェイクを完了できません。

インポートが失敗するよくある原因

• Base64 の塊がコピーの途中で切れ、末尾の数文字が欠けてデコード結果が不完全になっている。
• 共有リンクのサーバーアドレスがドメイン名で、現在の環境では名前解決できず、インポートは成功するのに接続に失敗する。
• REALITY ノードの公開鍵または shortId が欠けており、インポート後もノードは存在するがハンドシェイクが完了しない。
• サブスク内のノードが現在のクライアントのカーネルで対応していない機能を使っており、インポート時にスキップされる。
• サブスクのアドレスに追加のリクエストヘッダーや認証パラメータが必要で、ブラウザに貼れば開けるのにクライアントからは取得に失敗する。

インポート後、クライアントの内部はどうなっているか

インポートが完了すると、ノードはカーネルが読める JSON に変換されます。以下は VLESS アウトバウンドの最小構成で、フィールド名は実際の設定と同じ、アドレスと認証情報は置き換えています。

{
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "publicKey": "example-public-key",
          "shortId": "0123456789abcdef"
        }
      }
    }
  ]
}

この骨格と見比べればインポートの流れが理解できます。共有リンクの各クエリパラメータは、最終的に settings か streamSettings のいずれかのキーに落ち着きます。フィールドが合わないときは、問題はたいていリンク側にあり、クライアント側ではありません。

複数のクライアントを併用するときの同期

同じサブスクを v2rayN と v2rayNG でインポートした場合、ノード一覧は理論上一致するはずです。デスクトップにはあるノードが Android にない場合は、まずそのノードのプロトコルと転送を確認してください。REALITY や flow 付きの VLESS ノードは、基本プロトコルしか対応しないカーネルではスキップされます。サブスクを更新すると、クライアントは通常サブスクのグループ単位で丸ごと置き換えるため、ローカルでの個別ノードの名前変更や並べ替えは保持されないことがあります。重要なノードは主要フィールドを別途控えておくことをおすすめします。複数端末間で設定を移すいくつかの方法は複数端末での V2Ray 設定同期で解説しています。

同じプロトコルのパラメータでも、転送方式を変えると挙動がまったく変わることがあります。転送はデータをどう運ぶかを決め、ルーティングはどのトラフィックをプロキシに入れるかを決めます。両者が接続成功率と使用感に影響します。

よく使われる転送方式

転送を選ぶときの実用的な判断は、TCP が使えるなら TCP を使い、前置サービスや特定ポートと組み合わせる必要があるときに WebSocket や gRPC を検討する、というものです。WebSocket は設定項目が最も多く、パスと Host ヘッダーの書き間違いは接続失敗の最も一般的な原因の 1 つです。gRPC は回線品質が揺らぐときに多重化で有利ですが、設定にサービス名のパラメータが 1 つ増えるため、ここを誤ってもつながりません。

TLS と SNI は選定でどう位置づけるか

TLS はトラフィックを暗号化するかどうかを決め、SNI はハンドシェイク時にどのドメインへアクセスするかを相手に告げる役割を持ちます。VLESS と Trojan にとって TLS は任意ではなく前提です。VMess にとって TLS は追加できる 1 層です。REALITY は SNI を実在サイトに向け、ハンドシェイク時に検証するのはそのサイトの証明書チェーンなので、設定内の serverName は対象サイトと一致していなければならず、誤るとハンドシェイクに失敗します。転送を選ぶときは、まずサブスクに含まれる SNI フィールドを確認し、そのうえで追加設定が必要かを判断してください。

ルーティングモードの 3 択

v2rayNG と v2rayN のルーティングモードは通常 3 種類あります。

• プロキシのみ:内蔵ルールで振り分け、一致したトラフィックはプロキシ経由、それ以外は直接接続します。日常利用で最もよく使います。
• LAN をバイパス:LAN のアドレスは直接接続し、それ以外のトラフィックはプロキシ経由にします。ルーターの管理画面や LAN 上のストレージなど、ローカル機器へアクセスしたい場面に向いています。
• グローバル:すべてのトラフィックがプロキシに入ります。問題の切り分けでよく使い、日常利用では不要な通信量が増えます。

3 つのモードはカーネル設定の routing セクションの異なるルールセットに対応します。モードを切り替えてもノード自体は変わらず、どのトラフィックがアウトバウンドへ送られるかだけが変わります。

アプリごとのプロキシと自動起動

Android のアプリごとのプロキシは、アプリのパッケージ名でプロキシ経由にするかを決めます。ごく一部のアプリだけをプロキシ経由にしたい使い方に向いています。有効にするとアプリを 1 つずつチェックする必要があり、チェックしていないアプリは直接接続として扱われます。デスクトップにはこの設定はなく、代わりにプロセス単位やアドレス帯単位のルールがあります。自動起動は常時接続の機器に向いています。モバイル端末で有効にするとバックグラウンド接続を 1 つ占有し続けるため、使うかどうかは利用頻度次第です。

domainStrategy と DNS の関係

ルーティングルール内の domainStrategy は、ドメイン名がいつ IP に解決されるかを決めます。よく使われる値は 3 つです。

この項目は DNS 設定と結び付いています。DNS クエリがプロキシ経由でない場合、解決結果から実際の出口が漏れることがあります。関連する症状と確認方法はV2Ray の DNS リーク検出と防止設定にまとめています。すべてのトラフィックを仮想ネットワークインターフェースに引き込む方法はTUN モードの仕組みと有効化をご覧ください。

ここまでの章の結論を 1 つの判断手順にまとめます。まずカーネルの対応を確認し、次に回線と維持コストを見て、最後に端末の種類で微調整します。以下、よくあるシーン別に推奨の組み合わせを示します。

3 ステップの判断手順

1. カーネルを見る:ノードに REALITY や flow パラメータがあるかどうか。あれば Xray カーネルのクライアントを使い、なければどちらのカーネルでも対応できます。
2. 回線と維持コストを見る:ドメインと証明書を維持するかどうか。維持するなら Trojan や VLESS + TLS はいずれも成熟した選択です。維持しないなら VLESS + REALITY で証明書の工程を省けます。
3. 端末を見る:低消費電力の機器ではカプセル化の層数が少ない方式を優先し、デスクトップは利便性で選んで構いません。

シーン別対照

おすすめしない組み合わせ

• VLESS を TLS なしでそのまま使う:プロトコル自体が機密性を提供せず、データは回線上で暗号化されません。
• V2Fly カーネルで REALITY ノードを使う:カーネルがこの方式に対応しておらず、設定は機能しません。
• Shadowsocks だけですべてのシーンをまかなう:プロトコル層の偽装がなく設定項目も少ないため、パスのカスタマイズが必要な回線で打つ手がなくなります。
• モバイル端末でグローバルモードを常用する:すべてのトラフィックがプロキシに入り、接続数も起床回数も増えます。

実行に移せる手順

1. クライアントにサブスクをインポートし、ノード数が想定どおりか確認する。
2. プロトコル別にグループ分けし、カプセル化の層数が少ないノードから試す。
3. 実接続テストでつながらないノードをふるい落とす。手順は初回接続チェックを参照。
4. 常用するノードを 2〜3 個選び、残りは予備として残す。
5. 端末の種類に応じてルーティングモードとアプリごとのプロキシを調整する。

プロトコル同士の横断比較はVMess・VLESS・Trojan・SS の横断比較も参考になります。こちらはハンドシェイクのオーバーヘッド、遅延、シーン別選定の 3 つの観点で展開しており、本ページの対照表と補い合う内容です。クライアントの選び方とシステム要件はダウンロードセンターに、3 つのクライアントの違いは選定ガイドにまとめています。

この章はここまでの内容を索引としてまとめる締めくくりです。よく使うフィールドの意味、典型的な症状に対応する確認項目、そしてサイト内の関連ページへの入口を扱います。

よく使うフィールド早見表

症状と確認項目

関連ページ

• はじめかた:サブスクのインポート、モードの選択、接続、確認までの一連の流れ。
• ダウンロードセンター:3 つのクライアントのプラットフォーム別入口とシステム要件。
• 選定ガイド:v2rayN、v2rayNG、v2flyNG の 3 つのクライアントの横断比較。
• よくある質問:基礎知識、インストールと設定、使い方のコツ、トラブルシューティングの分類で整理。
• 初回接続チェック:ノードの選別、実接続での速度測定、プロキシ有効化の確認。
• DNS リーク検出:症状、確認の入口、設定項目。
• 複数端末の設定同期:3 つの移行方法のトレードオフ。
• 4 つのプロトコルの横断比較:ハンドシェイクのオーバーヘッド、遅延、シーン別選定。
• TUN モード:仕組みと有効化の順序。

最後にひとこと

本ページの結論はすべてプロトコルとカーネルの公開された設計に基づくもので、特定のサーバー側の構築パラメータには触れていません。プロトコルの選択に唯一の正解はありません。同じサブスクでも回線が違えば挙動が異なることがあり、同じサーバーでも端末が違えば電池消費の傾向も変わります。本ページを判断の材料とし、実際のテストを最終的な結論として、両者を組み合わせてこそ自分に合った組み合わせを選べます。本ページで扱いきれない疑問があれば、よくある質問で分類から探すか、はじめかたに戻って本線の流れをもう一度たどってください。