XrayコアとV2Flyコアの違いは？VLESS・REALITYの機能を解説

まずXray・V2Fly・Project Vの関係を整理

Project Vは初期のV2Ray技術体系の源流で、v2ray-coreは後にV2Flyコミュニティによって保守が引き継がれました。Xrayは同じコード基盤から分岐し、独自のプロトコル実装、設定項目、リリースサイクルを形成しています。両者にはインバウンド、アウトバウンド、ルーティング、DNS、VMess、VLESS、多様なトランスポートなど共通する基本概念が数多くありますが、すでに同じプログラムの別名と単純に考えることはできません。

コアはノード設定の解析、ローカルポートの待ち受け、リモートへの接続、DNSクエリの実行、ルーティングルールの適用など、実際の接続処理を担当します。v2rayN、v2rayNG、v2flyNGは操作画面と設定管理を担う層です。ユーザーが画面でノードを選ぶと、クライアントがコアで読み込める設定を生成し、対応するプロセスを起動します。そのため、同じサブスクリプションが異なるクライアントで同じ名前に見えても、基盤の機能まで完全に同じとは限りません。

両者の違いが主に現れるのは、新しいプロトコル拡張です。V2Flyは独自の設定体系、基本プロトコル、汎用トランスポートを重視し、XrayはVLESS、XTLS Vision、REALITYなどの組み合わせを継続的に拡張しています。ノードがVMess、TCP、WebSocket、標準TLSだけを使う場合は、どちらのコアでも処理できる可能性があります。一方、設定に特定のflow、REALITYの公開鍵、short IDが含まれる場合は、項目に応じてコアを選ぶ必要があります。

VMessとVLESSの違いは、コアの違いとは限らない

VMessはProject V体系で早くから使われてきたプロキシプロトコルで、ノードには通常、サーバーアドレス、ポート、ユーザーID、トランスポート、TLS設定が含まれます。VLESSは認証構造がよりシンプルですが、それだけでトランスポートや暗号化方式が決まるわけではありません。VLESSはTCP、WebSocket、gRPC、TLSと組み合わせられるほか、Xray系ではXTLS VisionやREALITYとも組み合わせられます。

したがって、「XrayはVLESSに対応し、V2FlyはVMessだけに対応する」という判断は正確ではありません。どちらのコアも基本的なVLESS構成に対応しており、本当に確認すべきなのはVLESSに続く組み合わせ項目です。特にノードリンクやサブスクリプションにflow=xtls-rprx-vision、security=reality、公開鍵、short ID、フィンガープリントの項目がある場合は、これらを解釈できるXrayコアを使用してください。

XTLS VisionとREALITYはそれぞれ何を解決するのか

XTLSはXray系におけるトランスポート最適化とトラフィック処理の仕組みで、現在の設定ではVLESSとxtls-rprx-visionの組み合わせがよく使われます。Visionは接続内容に応じてデータ処理を調整し、特定のTLS over TLS構成で発生する重複処理の削減を主な目的とします。独立したノードプロトコルではなく、VLESS、トランスポート層、サーバー側設定から切り離して単独で有効にすることもできません。

REALITYはXrayで使われるトランスポートセキュリティ方式の一つです。クライアント接続にはサーバーアドレスとポートに加え、serverName、公開鍵、short IDを正しく設定し、フィンガープリントやspiderXなどの項目が必要になる場合もあります。標準TLSとは設定方法が異なるため、セキュリティ方式だけをTLSからREALITYに変更して、他の項目をそのままにすることはできません。サーバーの秘密鍵とクライアントの公開鍵、許可されたserverName、short IDは一組で対応している必要があります。

一般的なREALITYノードではリモートポートに443が使われますが、ポート番号はプロトコルを識別する条件ではありません。443で標準TLSを使用することもでき、サーバー設定によっては他の利用可能なポートも使えます。判断の基準はサブスクリプション内のセキュリティ方式と関連項目であり、443を見ただけでREALITYと推測してはいけません。

REALITY設定はこの順番で確認

1. プロトコルがVLESSであることを確認し、サーバーアドレス、リモートポート、ユーザーIDを照合します。余分な空白や途中で切れた文字がないことも確認してください。
2. セキュリティ方式が標準TLSではなくREALITYであることを確認し、トランスポート方式もサーバー側と一致させます。
3. serverNameの完全なドメイン名を確認します。この項目はサーバーアドレスと異なる場合があり、ノードアドレスが数値のIPアドレスだからといってserverNameを削除してはいけません。
4. 公開鍵とshort IDを確認します。short IDは16進数で構成されるため、コピー時に引用符、カンマ、改行を含めないでください。
5. flow項目がある場合は、サーバー側と値が一致していることを確認します。一般的な値はxtls-rprx-visionで、visionだけと記述してはいけません。
6. 保存後に接続を再起動し、コアのログを確認します。古いプロセスが終了していない場合、変更前の設定が使われ続けることがあります。

サブスクリプションが同じなのに、コアを変えても失敗する理由

サブスクリプションはノード情報を伝えるものであり、すべてのクライアントが全項目を正しく解釈できることを保証するものではありません。一般的なサブスクリプション形式では、プロトコル、アドレス、ポート、ユーザーID、トランスポート、セキュリティ項目がリンクや構造化データにエンコードされます。生成側が新しいXray項目を使っていて、クライアントのパーサーに対応するマッピングがない場合、ノードは一覧に表示されても、公開鍵、flow、short IDが実際には空になっている可能性があります。

別の問題は設定変換に起因します。クライアントは通常、サブスクリプションの内容をそのままコアに渡さず、いったん独自のデータモデルへ変換してから実行設定を生成します。その過程でREALITYをTLSとして扱ったり、serverNameをサーバーアドレスとして扱ったり、flowを無視したりすると、コアのログに無効な項目、認証失敗、ハンドシェイク中断などが記録されます。この場合、サブスクリプションを何度更新しても解決しないため、ノード詳細を開いて一項目ずつ確認してください。

ルーティングルールも「コア非互換」に見える現象を引き起こします。ノードへの接続が確立していても、対象ドメインがルールによってダイレクト接続へ送られると、期待した結果になりません。トラブル対応では、まずシンプルなルーティングモードで基本接続を確認し、その後にドメイン、アドレス、ルールセットによる振り分けを戻します。DNSも個別に確認が必要で、特に名前解決の結果とルーティング条件が一致しない場合は注意してください。

ログから障害の層を特定する

• コアを起動できない: 設定構文、コアファイル、待ち受けポート、重複プロセスを確認します。ログにaddress already in useと表示される場合は、ポートを占有しているプロセスを終了するか、ローカルの待ち受けポートを変更してください。
• 接続直後に切断される: サーバーアドレス、ポート、ユーザーID、flow、セキュリティ方式、公開鍵、short IDを確認し、特に項目の欠落を調べます。
• 接続待ちの後にタイムアウトする: 現在のネットワークからリモートアドレスとポートへ到達できるかを確認し、サーバーが待ち受け中であることも確認します。複雑なルーティングルールの調整から始めないでください。
• コアは接続済みなのにウェブページを開けない: システムプロキシ、ローカルSOCKSまたはHTTPポート、DNS、ルーティングの送信先を確認します。
• 一部のドメインだけ正常で、他は失敗する: ドメインルール、アドレスルール、DNSの応答、振り分けの優先順位を確認し、すぐにコアを変更しないでください。

v2rayN、v2rayNG、v2flyNGの選び方

Windows、macOS、Linuxでは、通常v2rayNでデスクトップの接続を管理します。ノードを選ぶ前にプロトコルの詳細を確認してください。ノードがVLESS、XTLS Vision、REALITYを使う場合は、実際にXrayコアが起動していることを確認します。VMess、WebSocket、標準TLSだけを使う場合は、プロトコル名だけを理由に頻繁に切り替えず、検証済みの設定をそのまま使えます。

Androidでは、v2rayNGがXrayコアを使用するため、Xray拡張項目を含むサブスクリプションに適しています。v2flyNGはV2Flyコアを使用し、V2Flyの設定方式を維持したいユーザーに適しています。画面操作は似ていますが、基盤となる設定機能は項目ごとに同等ではありません。ノードを移行する際は、サブスクリプションのグループ名やノード名だけでなく、詳細画面を確認してください。

クライアント選びでは、ルーティングルールの出所も考慮する必要があります。XrayとV2FlyはどちらもルーティングとDNSに対応していますが、項目構造、ルール機能、バージョンの進化は異なります。高度な設定全体をそのままコピーすると、未知の項目エラーが発生することがあります。より安全なのは、まずノードの接続パラメータをインポートし、対象クライアントでルーティングルールを作り直してから、ログでドメインとアドレスが想定したアウトバウンドに入っていることを確認する方法です。

クライアント変更前に残しておく情報

• ノードのプロトコル、リモートアドレス、ポート、ユーザーID、トランスポート方式、セキュリティ方式を記録します。
• VLESSノードではflowも記録し、REALITYノードでは公開鍵、short ID、serverName、フィンガープリント、パス項目も記録します。
• 現在のローカルSOCKSとHTTPの待ち受けポートを記録し、システムプロキシが旧クライアントを参照し続けないようにします。
• ルーティングルールとノードパラメータを分けて保存し、ルーティングの異常をノードの無効化と誤認しないようにします。
• 切り替え後はまず単一ノードでテストし、その後にサブスクリプション全体のグループと自動更新タスクを更新します。

よくある質問: 互換性・速度・設定移行

コアの名前だけで接続速度が決まるわけではありません。実際の結果は、サーバー回線、混雑、往復遅延、パケットロス、トランスポートのカプセル化、TLS処理、端末性能、ルーティングルールにも左右されます。XTLS Visionは特定の状況で重複処理を減らすことを目的としますが、一定の速度向上率を導けるものではありません。

同様に、REALITYも通常のVMessノードで設定を1項目変更するだけで有効になる機能ではありません。サーバーとクライアント双方の設定が必要で、正しい鍵と識別項目にも依存します。サブスクリプションに関連パラメータがなければ、クライアントが自動で補完することはできません。接続エラーが発生したら、公開鍵やshort IDを適当に生成するのではなく、設定の提供元に戻って項目を確認してください。

コアを選ぶときのチェックリスト

コア選びでプロジェクトの歴史から推測する必要はありません。ノードの実際の項目を確認すれば判断できます。VMess、WebSocket、gRPC、標準TLSなどの一般的な組み合わせは、現在の互換性を優先してください。VLESS設定ではセキュリティ方式とflowを確認し、XTLS Vision、REALITY、公開鍵、short IDがある場合はXray系を選ぶのが近道です。

ノードには接続できるのにアクセス結果が異常な場合は、まずローカルポート、システムプロキシ、DNS、ルーティングの振り分けを確認してください。ログに未知の項目、設定解析失敗、プロトコルのハンドシェイク不一致が明確に示された場合に限り、コアの互換性を重点的に調べます。層ごとに対応すれば、ノード、コア、ルーティング、システムプロキシを何度も切り替えずに済みます。

1. プロトコルを確認: VMessかVLESSかを確認し、ノード名だけで判断しない。
2. セキュリティ方式を確認: 標準TLSとREALITYを区別し、serverNameを記録する。
3. flowを確認: xtls-rprx-visionがある場合はXrayを選び、サーバー側の設定と一致していることを確認する。
4. クライアントを確認: デスクトップではv2rayNで対応するコアを管理し、AndroidではXray系またはV2Fly系に応じてv2rayNG、v2flyNGを選ぶ。
5. ローカル待ち受けを確認: システムプロキシ、ブラウザーのプロキシ、クライアントのポートを一致させる。
6. ログを確認: コアの起動、リモート接続、TLSハンドシェイク、DNS、ルーティングのどの層で問題が起きているかを順番に判断する。
7. 最後に複雑な設定を戻す: 基本接続を確認してから、サブスクリプションの自動更新、DNSポリシー、ルールセットを有効にする。