XrayコアとV2Flyコアの違いを比較：XTLS・REALITY対応と設定互換性

サブスクリプションにVMess、VLESS、Trojan、WebSocket、gRPC、REALITYのノードが混在している場合、ノードを起動できるかどうかを決めるのはクライアント名だけではありません。クライアントが呼び出すコアプログラム、コアが対応するトランスポートとセキュリティ層、そしてサブスクリプション変換後に生成される設定フィールドが重要です。XrayとV2Flyには共通する基盤が多くありますが、自由に置き換えられる同一のファイルではありません。

同じ起源からの分岐：2つのコアの関係

V2Rayは当初、インバウンド、アウトバウンド、ルーティング、DNS、ポリシー、トランスポート層で構成される設定モデルを確立しました。その後、プロジェクトがコミュニティによる保守段階に入ると、V2Flyはこのモデルを引き継ぎ、V2Ray Coreの保守を続けました。Xrayは同じ技術基盤から分岐し、多くの設定オブジェクトと一般的なプロトコルを維持しながら、VLESS、XTLS、REALITY、トランスポート実装、性能面を継続的に拡張しています。

つまり両者は、一方が他方を単純に置き換える関係ではなく、「共通の基本構文を持ち、それぞれが機能を拡張している」関係に近いといえます。VMess over TCP、VMess over WebSocket、一般的なVLESS over TCP、SOCKSインバウンド、ドメイン名によるルーティングなどの設定は通常よく似ています。一方、Xray固有のセキュリティ層やフロー制御フィールドを使う場合は、互換性の境界が明確になります。

• 共通の基盤：どちらもJSON形式の設定思想を採用し、inbounds、outbounds、routing、dns、policyなどの主要オブジェクトを含みます。
• 分岐のポイント：XrayはXTLSとREALITY関連の機能を追加・保守しており、一部のフィールドはXrayのみが解析できます。
• 選び方の原則：まずノードに必要な機能を確認し、次にクライアントが標準で呼び出すコアを確認します。「新しいか古いか」だけで判断してはいけません。

プロトコルとセキュリティ層の違い：XTLS・REALITY・VLESS

VMessは、どちらのコアでも扱える基本プロトコルの1つです。アドレス、ポート、ユーザー識別子、トランスポート方式、TLSパラメータがサーバー側と一致していれば、VMess over TCPやWebSocketでは、両方で構造の近いアウトバウンド設定を生成できます。ここでいう「近い」とは、設定全体をそのままコピーできるという意味ではありません。ログ、DNS、トランスポートの詳細、実験的なフィールドなどが異なる場合があります。

VLESS自体は軽量なプロトコルです。一般的なVLESSとTLSの組み合わせはXTLS Visionと同じではなく、サブスクリプションにVLESSが含まれていても、必ずXrayが必要とは限りません。確認すべきなのはflowフィールド、セキュリティ層の名称、対応する設定オブジェクトです。フロー制御の値がxtls-rprx-visionの場合は、そのフロー制御に対応するXrayコアを使い、インポート時にflowが破棄されていないことを確認してください。

REALITYはトランスポートのセキュリティ層に位置します。クライアントでは、アドレス、ポート、ユーザー識別子に加えて、serverName、fingerprint、公開鍵、shortIdなどのパラメータが必要です。サーバー側の待受ポートは443が一般的ですが、ポート番号はプロトコルを判定する根拠ではありません。導入環境によっては別のポートも使えます。ポート番号だけでREALITYノードかどうかを判断することはできません。

設定の互換性：再利用できるフィールドとできないフィールド

どちらのコアも階層型の設定を使います。inboundsはローカルアプリからの通信を受け取り、outboundsはリモートノードまたは直接接続の出口を定義します。routingはドメイン、IP、ポート、ネットワーク種別に応じて出口を選択し、dnsは名前解決の方法を決めます。これらの基本オブジェクトだけを使う場合、設定移行の成功率は比較的高くなります。

リスクの主因は拡張フィールドです。XrayのREALITY設定では、streamSettingsでsecurityをrealityに指定し、realitySettingsにサーバー名、クライアントフィンガープリント、公開鍵、短い識別子を保存します。XTLS Visionでは、VLESSのユーザーオブジェクト内にflowが含まれることが一般的です。V2Flyが認識できない重要な設定に遭遇すると、起動時にフィールドまたはセキュリティ層のエラーを直接出す場合があります。また、クライアントが設定生成時にノードの作成を拒否することもあります。

基本的な確認手順
outbounds → protocol → settings → ユーザーとサーバーのパラメータ
outbounds → streamSettings → network → トランスポート方式
outbounds → streamSettings → security → セキュリティ層
outbounds → streamSettings → tlsSettings / realitySettings
VLESSユーザーパラメータ → encryption / flow

サブスクリプションURL自体はコア設定ファイルではありません。サーバーは通常、共有リンクの一覧またはサブスクリプションデータを返し、クライアントが解析して実行時のJSONを生成します。同じサブスクリプションでもv2rayNとv2flyNGで結果が異なる場合、パーサーが該当フィールドに対応していないか、基盤となるコアがノードの要件を満たしていない可能性があります。トラブルシューティングでは、サブスクリプション全体を何度も削除して追加し直すのではなく、まず個別ノードの詳細を比較してください。

優先的に再利用できる部分

• ルーティングルールのdomain、ip、port、network、outboundTagなどの基本条件。
• VMessノードのアドレス、ポート、ユーザー識別子、alterId、トランスポート方式、一般的なTLSパラメータ。
• SOCKSとHTTPのローカルインバウンドポート。ただし移行後に、他のプロセスが使用していないことを確認してください。
• 一般的なDNSサーバーのアドレスと名前解決ポリシー。ただし、使用するバージョンが受け付けるフィールド名を再確認してください。

必ず再確認する部分

1. securityがrealityになっているか、realitySettingsが存在するか。
2. VLESSユーザーオブジェクトにxtls-rprx-visionのフロー制御が含まれているか。
3. トランスポート層が、対象コアの現行バージョンで対応しているネットワーク種別とパラメータを使っているか。
4. ルーティングルールが参照するoutboundTagが、対象設定に実際に存在するか。
5. DNSアウトバウンド、直接接続アウトバウンド、ブロックアウトバウンドのタグが、ルールと一致しているか。

クライアントの選び方：v2rayN・v2rayNG・v2flyNG

v2rayNはデスクトップ向けの設定管理ツールで、サブスクリプション、ノード、ルーティング、複数のコアを管理できます。VMess、VLESS Vision、REALITYが混在するサブスクリプションでは、該当ノードの実行コアとしてXrayを優先してください。一般的な確認手順は「設定」→「パラメータ設定」→「Coreタイプ設定」です。VLESSや関連するノード種別が、非対応のコアに割り当てられていないことを確認します。

ノードを実行したら、ログ欄で実際に起動したコア名を確認できます。ローカルSOCKSポートが10808、HTTPポートが10809の場合は、システムプロキシが現在のポートを指しているかも確認してください。ブラウザー拡張、古いコアプロセス、ほかのネットワークツールがポートを使用していると、ノード設定が正しくても通信を正常に引き継げません。

v2rayNGはAndroid端末向けで、Xrayコアを使用します。REALITY、VLESS Vision、VMess、一般的なサブスクリプションのインポートに適しています。インポート後はノード編集画面を開き、トランスポートプロトコル、偽装ドメイン、フィンガープリント、公開鍵、shortId、フロー制御を重点的に確認してください。ノードを長押しして実際の接続テストを行う前に、サービスを起動し、ステータスバーのリアルタイム通信量が変化していることを確認します。

v2flyNGはV2Flyコアが必要なAndroid環境向けで、V2Flyサーバーや既存のVMess設定との一貫性を保ちたい場合に適しています。サブスクリプションにREALITYノードが含まれている場合は、そのノードをv2rayNGで扱い、フィールドを削除して接続しようとしないでください。security、flow、公開鍵を削除しても、REALITYノードが一般的なTLSノードに変わるわけではありません。サーバー側のハンドシェイク方式は変わらないためです。

v2rayNでの実際の確認手順

1. サブスクリプショングループを開いてノード一覧を一度更新し、対象ノードが空のアドレスや0ポートとして解析されていないことを確認します。
2. 「設定」→「パラメータ設定」→「Coreタイプ設定」を開き、VLESSに割り当てられたコアを確認します。
3. ノードをダブルクリックし、security、flow、serverName、fingerprint、公開鍵、shortIdを確認します。
4. ノードを起動してログを開き、コアが10808または指定したローカルポートで正常に待ち受けていることを確認します。
5. システムプロキシを有効にして実際の接続先へアクセスし、送受信バイト数が増えているか確認します。

Androidでの実際の確認手順

1. v2rayNGまたはv2flyNGでサブスクリプションを更新し、インポートできないノードの種類を記録します。
2. 個別ノードの詳細を開き、サービス提供元が提示したプロトコルとトランスポートパラメータを照合します。
3. サービスを起動してから接続テストを実行し、サブスクリプション一覧に表示される遅延値だけに頼らないようにします。
4. 接続に失敗した場合は、まずログに出た最初のコアエラーを確認し、その後でDNSやルーティングの問題に対処します。

性能と安定性：コア名だけが変数ではない

同じサーバー、同じネットワーク、同じトランスポート方式であれば、2つのコアの日常的な通信速度の差よりも、プロトコルが適合しているかどうかのほうが重要です。サーバー負荷、回線のパケットロス、往復遅延、輻輳制御、TLSハンドシェイク、DNSの問い合わせ経路、クライアント端末の性能などが結果に影響します。1回の遅延テストだけでコアの優劣を決めると、結論が偏る可能性があります。

1つのノードを固定し、同じネットワークで3回連続してテストすることをおすすめします。接続確立時間、Webページの最初のレスポンスまでの時間、継続的なダウンロード速度、失敗回数を記録してください。たとえば往復遅延が約53ミリ秒、パケットロスが1％未満の場合、VMess over WebSocketの差は回線の揺らぎによる可能性があります。REALITYノードを使う場合、V2Flyではプロトコル機能が合わず、比較可能なテスト自体を行えません。

• まずプロトコルを確認：コアが、ノードで使われるプロトコル、セキュリティ層、フロー制御を完全にサポートしている必要があります。
• 次に条件を統一：サーバー、テスト時間、ネットワーク接続方式、DNS設定を固定します。
• 最後にログを確認：ハンドシェイク失敗、タイムアウト、DNSエラー、誤ったルーティング、ポート競合を切り分けます。

よくある問題：インポート、エラー、切り替えへの対処

互換性に関する問題の多くは、「サブスクリプションの解析、コアの起動、ハンドシェイクの確立、通信の引き継ぎ」という4つの段階から切り分けられます。まずどの層で失敗しているかを特定してから該当パラメータを変更するほうが、ノードを何度も切り替えたりクライアントを再インストールしたりするより効率的です。

最終チェックリスト

• サブスクリプションにREALITYまたはXTLS Visionが含まれる：Xrayコアを選択。
• v2rayNGを使用：Xrayノードのパラメータに沿ってサブスクリプション内容を確認。
• v2flyNGを使用：V2Flyの機能に合う既存ノードを優先して実行。
• v2rayNを使用：プロトコルに応じてコアを設定し、実行ファイルだけを置き換えない。
• ルーティングとDNSを移行：タグ、フィールド、対象バージョンの対応範囲を1つずつ確認。
• 性能をテスト：少なくとも3回連続で測定し、ログ、パケットロス、実際の通信量も同時に記録。