XrayコアとV2Flyコアの違い｜VLESS・XTLS・REALITY対応比較

この記事の要点

コア選びではクライアント名より、まずノードのパラメーターを確認しましょう。REALITYやxtls-rprx-visionを含むノードには、該当機能に対応したXrayが必要です。VMess、WebSocket、一般的なTLSの場合も、通信方式の項目や設定形式を確認してください。この記事では、v2rayN、v2rayNG、v2flyNG間で設定を移行する方向けに、プロトコル、通信方式、セキュリティ層、クライアントのインポート対応を整理し、起動ログからローカルポートまでの確認手順を紹介します。

1. XrayとV2Fly：コアの系譜とクライアントは別のもの

V2Rayはプロキシツールとその設定エコシステムの名称です。V2FlyコミュニティはV2Rayコアの保守を続けています。一方、XrayはV2Rayのコードから派生し、独自のプロトコル拡張や通信方式、設定仕様の進化を重ねています。共通の出自があっても、新しい設定項目が常に相互利用できるとは限りません。JSONファイル全体を汎用形式とみなすのも避けてください。

クライアントはサブスクリプション管理、ノード編集、システムプロキシの設定、コアの起動を担当します。コアは実行設定を解析し、インバウンドとアウトバウンドを確立してルーティングを処理します。クライアントにノードが表示されても、搭載コアで実行できるとは限りません。サブスクリプションのインポート成功とプロトコルのハンドシェイク成功は、別々に確認する必要があります。

v2rayN：デスクトップ向けクライアントです。プログラムのアイコンやサブスクリプションのグループ名ではなく、実際の起動ログに記録されたコア名とバージョンを確認してください。
v2rayNG：Android向けクライアントで、Xrayコアを使用します。REALITYなどのパラメーターには、クライアントの編集画面、サブスクリプション解析機能、コアのすべてが対応している必要があります。
v2flyNG：Android向けクライアントで、V2Flyコアを使用します。実際のコアとインポート形式に合ったノードを選び、v2rayNGと同名の代替品として扱わないでください。

2. VLESS・XTLS・REALITYの対応範囲を比較

VMessとVLESSはプロキシプロトコル、TCPとWebSocketは通信方式です。TLSとREALITYは接続のセキュリティ層に関わる設定で、XTLS Visionは特定のフロー制御によって接続処理に関わります。これらは同じ階層の項目ではないため、自由に置き換えられる「プロトコルの選択肢」として並べることはできません。

項目	Xrayコア	V2Flyコア	移行時の確認事項
VMess	対応	対応	UUID、暗号化設定、通信方式、TLSパラメーターを確認
VLESS	対応。VisionやREALITYと組み合わせて使われることが多い	旧バージョンに実装あり。使用するバージョンと設定形式を確認	VLESS対応だけでは、Xray拡張への対応は判断できない
WebSocket + TLS	対応	対応	path、Host、serverName、証明書の検証を確認
XTLS Vision	該当するVLESSフロー制御設定に対応	XrayのVision方式には非対応	flowがxtls-rprx-visionか確認
REALITY	対応	XrayのREALITY方式には非対応	セキュリティ層、公鍵、serverName、shortIdなどのパラメーターを確認
実行用JSON	Xrayの設定仕様に従って解析	該当するV2Fly設定バージョンに従って解析	設定構造が似ていても、そのまま相互利用できるとは限らない

VLESS自体には、TLSと同等の通信暗号化機能はありません。VLESSノードを確認する際は、プロトコル名だけで接続の保護方式を判断せず、セキュリティ層も確認してください。過去のVLESS実装が存在したからといって、V2FlyがREALITYやVisionを含むサブスクリプションノードを利用できるとは限りません。

古い解説にあるsecurity: "xtls"と、現在よく使われるflow: "xtls-rprx-vision"は別の記述です。古い設定の文字列をTLSに書き換えて「修正」しないでください。サーバーの待ち受け方式、フロー制御、クライアントの対応状況をそろえる必要があります。

3. 速度の表示ではなく、ノードのパラメーターでコアを選ぶ

コア選びで最初に確認するのは、設定を実行できるかどうかです。接続品質はその後に確認します。遅延は回線、サーバー負荷、DNS、ルーティング、ネットワーク環境などの影響を受けるため、特定のコアに速度向上を期待できるとは限りません。以下の推奨は、REALITYまたはVisionのパラメーターを明示的に含むノードを対象としています。

Xrayコア

推奨

ノードにREALITY、xtls-rprx-vision、またはXrayを明示的に要求する設定が含まれる場合は、それらの項目に対応したXrayのバージョンを選び、クライアントがパラメーターをすべて保持できることを確認してください。

適した用途：VLESS + REALITY、Vision、およびサーバー側でXrayが明示的に指定されているノード。

V2Flyコア

V2Flyの設定仕様で構築したVMessなどのノードをすでに利用している場合は、対応するコアと設定手順を継続できます。移行前に通信方式、DNS、ルーティングの構成を個別に確認してください。

適した用途：既存のV2Fly設定の保守、VMessノード、Xray拡張に依存しない環境。

一般的なVLESS + TCP + REALITYノードを例にすると、アドレス、ポート、UUID、フロー制御、セキュリティ層、サーバー名、公鍵、shortIdを一つずつ確認します。フィンガープリントのパラメーターも、提供元の指示に従って設定してください。shortIdに設定できる値はサーバー側で決まるため、別のノードからコピーしたり、必ず特定の長さにする必要があると考えたりしないでください。

ノードの編集画面で、プロトコルがVLESSになっていることと、通信方式がサーバー側の設定と一致していることを確認します。
セキュリティ層がREALITYになっていることを確認します。xtls-rprx-visionを設定するのは、サーバー側でVisionが必要な場合に限ります。
公鍵とサーバー名を確認してください。接続先アドレス、WebSocketのHost、serverNameをすべて同じ値にするとは限りません。
起動後はログを確認し、まず設定が受け付けられたことを確認してから、ハンドシェイクとアプリからのアクセスが成功するかを判断します。

4. 設定の互換性：共有リンクと実行用JSONを区別する

共有リンクにはノード情報が記述され、クライアントが実行設定に変換します。一方、JSON全体にはローカルの待ち受け設定、DNS、ルーティング、複数のアウトバウンドが含まれることがあります。共有リンクのインポート成功は、解析機能がそのリンクを受け付けたことを示すだけです。JSONをコピーできても、別のコアがすべての項目を認識できるとは限りません。

以下はXrayのセキュリティ層を確認するための設定例であり、単体で実行できる設定ではありません。サーバーアドレス、ユーザー情報、REALITY接続パラメーターを含んでいないため、完全な設定として保存して起動しないでください。

{
  "streamSettings": {
    "network": "tcp",
    "security": "reality"
  }
}

プロトコル層：protocolと対応するsettingsを確認します。プロトコル名だけを置き換え、ユーザー情報の構造をそのまま残すことはできません。
フロー制御層：Xrayで一般的なVLESSアウトバウンド設定では、flowはユーザー項目に記述します。streamSettingsに任意で追加する項目ではありません。
通信層：streamSettings.networkと対応する通信方式の設定を確認します。新旧の通信方式名の互換性は、実際に使うコアのバージョンで確認してください。
セキュリティ層：securityと関連する設定オブジェクトを確認します。realitySettingsに対応していないコアに、そのまま渡さないでください。
ルーティング層：outboundTagが存在するか確認してください。ノードのハンドシェイクが成功しても、ルールの参照先が誤ったアウトバウンドなら、アプリからアクセスできないことがあります。

5. ローカルポートとハンドシェイクログの確認手順

テストではまずローカルの接続口を固定し、その後にリモート接続を確認します。以下の3つのポート番号はトラブルシューティング用の例です。10808と10809は実際のローカル待ち受け設定に合わせてください。443はリモートのTLS接続でよく使われるポートですが、すべてのノードで必須ではなく、サービスのプロトコルを示すものでもありません。

10808

ローカルSOCKSの待ち受けポート例

10809

ローカルHTTPの待ち受けポート例

443

リモートのセキュア接続ポート例

起動を確認：ログに未知のプロトコル、未知の通信方式、設定の解析エラーが表示された場合は、接続速度を測る前に設定を修正するか、対応するコアを選んでください。
待ち受けを確認：ローカルアドレスとポートを確認してください。address already in useが表示された場合は、使用中のプロセスを特定するか、ローカルポートを変更してテストコマンドにも反映します。
ハンドシェイクを確認：コアは起動しているのに接続できない場合は、リモートポート、UUID、flow、serverName、公鍵、shortId、システム時刻を確認してください。
ルーティングを確認：コマンドラインからプロキシ経由でアクセスできるのにブラウザーではできない場合は、システムプロキシ、ブラウザーのプロキシ設定、分割ルーティングの結果を確認します。まずコアを切り替える必要はありません。

curlをインストール済みのデスクトップ環境で、SOCKSの接続先が127.0.0.1:10808の場合は、以下のコマンドで明示的なプロキシリクエストをテストできます。--socks5-hostnameを指定すると、接続先のドメイン名はSOCKSプロキシ側で名前解決されます。システム全体のDNSや、すべてのアプリのプロキシ状態を確認できるわけではありません。

curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2ray88.com/

HTTPレスポンスが返れば、そのリクエストでは接続処理が完了しています。ただし、すべてのサイトやルールが正常とは限りません。サイト独自のアクセス制限によるレスポンスは、プロキシのハンドシェイク失敗と区別してください。エラーを記録する際は時刻とエラーの種類を残し、ログを共有する前にサブスクリプションリンク、UUID、その他の接続情報を削除してください。

6. デスクトップとAndroidでの設定の使い分け

同じサブスクリプションから複数のプロトコルが提供されることがあります。両方の端末に同じリンクをインポートしても、解析機能、フィルター、更新時刻の違いにより、ノード一覧が異なる場合があります。まず両方の端末で確実に認識されるノードを1つ選んでテストし、一覧の件数が同じであることを互換性の判断基準にしないでください。

構成例：ノードの特性に応じてクライアントを使い分ける

デスクトップ：v2rayN

REALITYまたはVisionノードでは、対応するXrayコアを使用します。
起動ログで実際に動作しているコアとバージョンを確認します。
まずローカルプロキシの接続口をテストし、その後で分割ルーティングのルールを有効にします。

Android：プロトコルに合わせて選択

v2rayNGはXrayの機能が必要なノードに使用します。
v2flyNGはV2Flyの機能に対応するノードに使用します。
クライアントを切り替える前に、もう一方のクライアントのVPN接続を停止してください。

結論：サブスクリプションの提供元が同じでも、実行できる機能は各クライアント、コア、ノードのパラメーターによって異なります。

AndroidでVPNの許可を求められた場合は、システムの案内に従って承認してください。クライアントを切り替えた後は、アプリごとのプロキシ対象も確認します。特定のアプリが対象外だと、そのアプリだけアクセスできず、ほかのアプリは正常に動作することがあります。この現象だけでREALITYのパラメーターやコアの実装に問題があるとは判断できません。

7. コア切り替え時によくある質問

サブスクリプションはインポートできたのに、起動時に未知のセキュリティ形式と表示されるのはなぜですか？

接続できないノードの編集画面を開き、REALITYが選択されているか確認してから、起動ログでコア名を確認してください。V2Flyが実行中なら、該当する項目に対応したXray環境へ切り替えます。すでにXrayを使っている場合は、コアのバージョンとクライアントが生成した設定を確認してください。サブスクリプションの更新だけでは解決しません。

REALITYをTLSに変更すれば、v2flyNGで使えますか？

クライアント側の設定だけでは変更できません。両者ではハンドシェイクとサーバー設定が異なります。サーバー側で実際に対応するTLSノードを用意し、新しいパラメーターをインポートしてください。公鍵を消したりセキュリティ層の名前を変えたりしても、元のREALITY接続口が通常のTLS接続口に変わることはありません。

VMessノードがどちらのコアでも使える場合、切り替える必要はありますか？

現在のノード、DNS、分割ルーティングが正常に動作しているなら、名称が異なるという理由だけで切り替える必要はありません。移行する場合は、元の設定を残し、通信経路、TLSのサーバー名、証明書の検証を個別に確認してから、ルーティングルールを段階的に追加してください。

ログにエラーがないのにブラウザーが開けない場合、まず何を確認すればよいですか？

まず実際のローカルポートを指定して、明示的なプロキシリクエストを実行します。コマンドが成功したら、v2rayNのシステムプロキシメニューで現在の状態を確認し、ブラウザーに個別のプロキシ設定がないか調べてください。コマンドが失敗した場合はコアのログに戻り、ローカル接続拒否、リモートタイムアウト、ハンドシェイク失敗を切り分けます。

最終的には、ノードが必要とする機能、クライアントが設定をすべて解析できるか、実際のコアが対応しているか、生成された設定が正しいか、アプリの通信がプロキシを経由しているかの順に確認します。設定項目を詳しく確認する場合は設定ガイドを参照してください。初めて接続を確立する場合は、複数の項目を同時に変更するより、クイックスタートの手順に沿って進めると問題を特定しやすくなります。