XrayコアとV2Flyコアの違いを比較|VLESS・XTLS Vision・REALITY対応状況

Project Vの系譜を共有するXrayとV2Fly。対応プロトコルや伝送方式、設定項目の違いを整理し、v2rayNGとv2flyNGの選び方を解説します。

この記事の要点

ノードにREALITYまたはxtls-rprx-visionが含まれる場合は、まずXrayの対応状況を確認しましょう。一般的なVLESS、VMess、Trojanノードでも、伝送方式や設定項目の確認が必要です。カーネルの切り替えやAndroidクライアントの選択、サブスクリプションの互換性を調べたい方に向けて、プロトコル名ではなく接続パラメーターから判断する方法を解説します。

カーネルとクライアントの役割を区別する

Xray-coreとV2Flyが開発するV2Ray-coreは、別々のカーネルプロジェクトです。技術的なルーツは共通していますが、それぞれ独自に進化しています。カーネルは受信接続の処理、ルーティングルールの照合、プロキシ経由の送信を担います。クライアントはサブスクリプションの管理や画面操作、設定の生成を担います。クライアントにノードが表示されても、使用中のカーネルがそのノードのすべての設定項目を処理できるとは限りません。

サブスクリプションの解析 設定の生成 カーネルの読み込み ルーティングの照合 送信接続

v2rayNはデスクトップクライアントで、実際の接続機能は選択したカーネルとそのバージョンによって決まります。Androidでは、この記事はv2rayNGでXrayカーネルを、v2flyNGでV2Flyカーネルを使う場合を扱います。アプリのバージョンとカーネルのバージョンは別々に記録してください。問題の切り分けでは、アプリのバージョン番号だけでプロトコル対応を判断しないことが重要です。

この3段階はそれぞれ独立して失敗することがあります。たとえば、クライアントへのインポートは成功しても、生成された設定にREALITYの公開鍵が含まれていない場合があります。カーネルが起動していても、サーバーとクライアントのshortIdが一致しないこともあります。「一覧にノードがあること」と「ノードに接続できること」は分けて確認しましょう。

プロトコル比較:VLESSとREALITYは別物

VLESSはプロキシプロトコル、XTLS Visionは特定のフロー制御方式、REALITYはXrayのセキュリティレイヤーです。それぞれ異なる階層に属します。サブスクリプションのリンクがvless://で始まることだけでは、V2Flyで使えるかどうかは判断できません。伝送方式、セキュリティレイヤー、flowも確認する必要があります。

機能または組み合わせXrayV2Fly確認ポイント
VMess一般的な組み合わせに対応一般的な組み合わせに対応伝送方式、TLS、クライアントとサーバーのバージョン
基本的なVLESS対応基本プロトコルに対応拡張機能も同等とは限らない
Trojan対応対応TLSの名称とパスワード、伝送方式の組み合わせ
VLESS + Vision対応状況はバージョンと設定によるXrayのVision flowには非対応xtls-rprx-vision
VLESS + REALITY対応状況はバージョンと設定によるXrayのREALITYには非対応公開鍵、serverName、shortId、フィンガープリント
WebSocket + TLS一般的な設定に対応一般的な設定に対応path、Host、serverNameは別々の項目

ここでいう「対応」は、あらゆる設定を相互に置き換えられるという意味ではありません。同じプロトコルが両方に実装されていても、共通の機能があることを示すだけです。新しい伝送方式や設定形式、拡張パラメーターは、実際に使うバージョンで確認してください。特に、Xrayの新しい伝送方式の項目をそのままV2Flyの設定にコピーしないでください。

結論:設定の組み合わせ全体でカーネルを選ぶ

まずsecurityとflowを確認し、次に伝送方式を確認します。REALITYまたはxtls-rprx-visionが含まれていれば、Xrayで動作を検証してください。一般的なTLSと共通プロトコルだけを使う場合は、V2Flyとの設定互換性を確認しましょう。

XTLS、Vision、REALITY:設定名の違いに注意

古いチュートリアルにあるXTLSを、現在一般的なVisionの設定とそのまま対応づけることはできません。xtls-rprx-directのような過去のflow名を新しい設定にコピーしないでください。一般的なVisionの設定ではflow: xtls-rprx-visionを使い、セキュリティレイヤーにはTLSまたはREALITYを指定できます。Visionの利用にREALITYが必須というわけではありません。

REALITYはTLS証明書の検証を無効にする仕組みではありません。クライアント側で、サーバーから提供された公開鍵、許可されたserverName、shortId、フィンガープリントなどを確認する必要があります。サーバーの秘密鍵はサーバー側だけに保管し、サブスクリプションの項目としてクライアントに渡してはいけません。一般的なTLSでは通常、証明書チェーンと名前を検証します。証明書エラーが起きたら、まず名前とシステム時刻を確認してください。

VLESS + REALITY + Vision

伝送方式
TCP/raw(名称はバージョンによって異なる)
セキュリティレイヤー
REALITY
Flow
xtls-rprx-vision
認証パラメーター
公開鍵、shortId、serverName
カーネルの選択
Xray

サーバーが指定する組み合わせに従い、使用するXrayのバージョンに合わせて項目名を確認してください。

VMess + WebSocket + TLS

伝送方式
WebSocket
セキュリティレイヤー
TLS
パスの例
/ws
名称の例
example.com
カーネルの選択
XrayまたはV2Flyで項目ごとに確認

パスと名称は説明用の例です。中継を経由するかどうかはサーバーの構成によります。

WebSocketノードに安易にVision flowを追加したり、TLSノードのsecurityをREALITYに変更したりしても、自動的に互換性が得られるわけではありません。こうした変更は接続プロトコルそのものを変えるため、サーバー側にも対応する設定が必要です。サブスクリプションの情報が不足している場合は、不足しているパラメーターを確認してください。別のノードから公開鍵やshortIdをコピーしてはいけません。

設定の移行:ポートが同じでも設定は同じとは限らない

カーネルを切り替える前に、元の設定を保存し、まずノードを1つ検証してください。サブスクリプションリンク、クライアントに保存されたノード情報、カーネルのJSONは、それぞれ異なる形式のデータです。どちらもJSONであっても、設定形式が異なる場合があります。V2Flyの各種設定形式と、Xrayで一般的なJSON設定の互換性は、ファイル拡張子だけでは判断できません。

443
サーバー側のTLS/REALITYポートの例
10808
ローカルSOCKS受信ポートの例
127.0.0.1
ローカル待ち受けアドレスの例

上記の数値は問題切り分け用の設定例であり、すべてのバージョンの既定値ではありません。サーバー側のポート443とローカルポート10808は、通信の方向が異なります。ローカルポートが使用中の場合、サーバー側のポートを変更しても通常は解決しません。サーバーが443で対応するサービスを提供していなければ、ローカルの受信設定が正常でもプロキシ接続は完了しません。

  1. 現在の環境を記録:クライアントのバージョン、起動ログに表示されるカーネルのバージョン、ノードの伝送方式とセキュリティレイヤーを記録し、元に戻せる設定を保存します。
  2. 共通プロトコルから試す:パラメーターがそろったVMess + WebSocket + TLSなど、両方に共通する組み合わせで基準を作ります。拡張ノードをまとめて移行するのは避けてください。
  3. 生成された設定を確認:protocol、伝送設定、TLS名、送信タグを確認します。ログを共有する前に、認証情報を削除してください。
  4. ルールの依存関係を確認:geosite.datとgeoip.datが使用中のカーネルから参照でき、ルールで指定したカテゴリが存在することを確認します。
  5. 機能を一つずつ戻す:DNS、ルーティングの振り分け、TUNの順に戻し、複数の設定変更による問題が重ならないようにします。

ルーティングとDNSも付随的な設定ではありません。同じドメインでも、名前解決を行う場所、IPv6の利用可否、ルールの順序によって異なる経路を通ることがあります。カーネルを比較する際は、これらの設定を固定してください。速度が変わっても、プロキシ経由から直接接続に変わっただけかもしれず、プロトコルの効率を示すとは限りません。ルールについて詳しくは応用設定のDNS設定をご覧ください。

クライアントの選び方:v2rayNGとv2flyNGを比較

Androidクライアントを選ぶときは、まず現在のサブスクリプションが必要とする機能を確認し、次に操作性を比べましょう。REALITYまたはVisionを含むノードには、対応するXray機能を備えたバージョンのv2rayNGを選びます。既存のV2Fly設定を使い、共通プロトコルでV2Flyカーネルを継続利用したい場合は、v2flyNGを検討できます。ノード数や画面の見た目だけで判断せず、対応プロトコルを確認してください。

ノードの項目を手動で補えば接続できるのに、同じサブスクリプションをインポートすると失敗する場合は、カーネルではなくクライアントの解析処理に問題がある可能性があります。反対に、画面ではすべての項目を保存できても、カーネルがflowに非対応と報告するなら、サブスクリプションURL自体の問題ではありません。原因を切り分ければ、問題箇所を変えないまま再インストールを繰り返すのを避けられます。

結論:ノードを1つ検証してからサブスクリプションを移行

現在使えているクライアントの設定を残し、パラメーターがそろったノードを1つ使って新しいクライアントを検証します。接続、DNS、振り分けが想定どおりと確認できてから、残りのグループをインポートしてください。カーネルの切り替えと同時にすべてのルールを書き直すのは避けましょう。

トラブル対処の順序:項目、ハンドシェイク、ネットワークの順に確認

「起動に失敗する」場合と「起動後にアクセスできない」場合では、問題が異なります。前者では設定形式、項目の対応状況、ポートの競合を優先して確認します。後者ではアドレス解決、ハンドシェイクのパラメーター、ルーティングを確認してください。エラーメッセージの原文が重要です。以下はよくある意味の説明で、どのバージョンでも同じ文言が出るとは限りません。

症状まず確認する項目次の手順
設定の読み込み時に未知の項目または未対応のflowが表示されるカーネルのバージョン、項目名、プロトコルの組み合わせXrayの拡張機能をV2Flyで使おうとしていないか確認
ローカルの待ち受けに失敗する127.0.0.1:10808がすでに使用中でないか重複するプロセスを終了するか、受信側と利用側のポートを同じ値に変更
TLS名または証明書の検証に失敗するserverName、証明書の有効期間、システム時刻パラメーターを修正し、検証を無効にしたまま使わない
REALITYのハンドシェイクに失敗する公開鍵、shortId、serverName、フィンガープリント、サーバーログサーバーから提供された設定と項目ごとに照合
設定エラーはないがタイムアウトするドメイン名の解決、サーバーポート、ルーティング、ネットワーク到達性正しいアドレスに接続できているか確認してから、プロトコルのパラメーターを確認
一部のドメインにはアクセスできるDNSの設定、IPv6、ルールの順序、送信タグ同じ接続先を使い、実際に適用されたルールを確認

速度測定では条件をそろえてください。TCPハンドシェイクに成功しても、その時点で接続先のポートに到達できたことしか分からず、VLESS認証やTLS、REALITYのハンドシェイク完了を意味しません。XrayとV2Flyを比較する際は、両方が対応する同じプロトコルの組み合わせ、同じ出口、同じテスト先を使います。実際のリクエスト遅延とダウンロード速度を別々に記録し、ひとつの「速度」スコアにまとめないでください。

選び方はシンプルです。REALITYまたはVisionが必要ならXrayを、共通プロトコルを使うなら設定の互換性と現在の運用方法を基準に選びます。カーネル名だけで安定性は決まりません。接続を再現可能にするには、必要なパラメーターがそろっていること、バージョンが合っていること、DNSとルーティングが正しく設定されていることが重要です。

v2rayN をダウンロード対応プラットフォームとインストーラーを確認