XrayカーネルとV2Flyカーネルの違い：対応プロトコル・性能・設定互換性を比較

まず結論：ノードのプロトコルでカーネルを選ぶ

XrayとV2Flyは、単純な「新しい版」と「古い版」の関係ではありません。近い設定構造を採用し、VMess、VLESS、SOCKS、HTTP、ローカルルーティング、DNSなどの基本概念も共有していますが、開発方針はすでに分かれています。選ぶ際はカーネル名だけで判断せず、遅延の数値だけにも頼らないでください。まずノードのプロトコル、トランスポート層、セキュリティ層、flowフィールドを確認し、クライアントが実際に呼び出しているカーネルを確かめます。

ノードがVLESS、REALITY、XTLS Visionの組み合わせを使用している場合は、Xrayを選択してください。REALITYとxtls-rprx-visionはXray体系の主要機能であり、V2Flyに切り替えると元のパラメータで同等の接続を確立できません。設定がVMess、通常のVLESS、WebSocket、gRPC、TLS、従来型のルーティングルールを中心としている場合は、どちらでも処理できる可能性がありますが、対応するバージョンとフィールドを確認する必要があります。

2つのカーネルの関係と役割

V2FlyはProject Vの従来の技術方針を継承しており、設定は通常、インバウンド、アウトバウンド、ルーティング、DNS、ポリシー、トランスポート設定を中心に構成されます。一般的なJSONのトップレベル構造にはinbounds、outbounds、routing、dns、logなどがあります。これらの構造に慣れていれば、Xrayの設定もまったく未知というわけではありません。

Xrayも同じ技術的な流れから発展し、多くの共通概念を引き継ぎながら、VLESS、XTLS、REALITY、トランスポート機構、ルーティング機能を拡張してきました。そのため、2つの設定には同じ内容が長く含まれる場合がありますが、セキュリティ層のフィールド、flowの値、トランスポートパラメータのいずれか一つだけで、互換利用できないことがあります。

「設定ファイルを読み込める」ことは、「接続動作が完全に同じ」という意味ではありません。未知のフィールドが解析時に無視される場合もあれば、起動エラーになる場合もあります。また、同じ名前のフィールドでも、受け付ける値や初期動作がカーネルのバージョンによって変わることがあります。設定を移行する際は、実行ログと接続結果を確認し、クライアントが起動したかどうかだけで判断しないでください。

カーネルとクライアントの画面は別の層

v2rayNはデスクトップクライアントで、サブスクリプション管理、ノード選択、システムプロキシ、ルーティングモード、カーネルプロセスの制御を担当します。実際に接続を処理するのは、クライアントが呼び出すカーネルです。バージョンやインストールパッケージによってカーネルの管理方法が異なるため、設定画面やログの冒頭で現在のカーネル名とバージョンを確認し、ウィンドウタイトルだけで推測しないでください。

Androidでは区別がより明確です。v2rayNGはXrayカーネルを採用し、v2flyNGはV2Flyカーネルを採用しています。操作画面は似ていても、プロトコル拡張、インポート結果、利用できるパラメータはカーネルの影響を受けます。ノード提供元がREALITYやVisionのパラメータを明示している場合は、それらのパラメータと対応するカーネルをセットで確認してください。

プロトコル対応の違い：VLESS・XTLS・REALITYを重点確認

VMess：共通の基盤があっても、すべての組み合わせが同じとは限らない

VMessは、どちらのカーネルでもよく使われるプロトコルです。典型的なVMessノードでは、TCP、WebSocket、HTTP/2、gRPCなどのトランスポートを組み合わせ、外側にTLSを使用することもあります。「VMess」と書かれているだけでは互換性を判断できません。トランスポートの種類、TLSのserverName、パス、Host、ポート、ユーザー識別子まで確認してください。

比較的従来型のVMess設定であれば、XrayとV2Flyは通常、十分な対応実績があります。ただし実際に移行する際は、旧フィールド、トランスポート名の変更、サブスクリプション変換結果に注意が必要です。インポート後にノードは存在するのに接続できない場合は、ノード詳細を開いて項目ごとに比較し、システムプロキシを何度も切り替えるのは避けてください。

VLESS：プロトコル名が同じでも、拡張機能は異なる場合がある

VLESSは認証情報とトランスポート・セキュリティ層の組み合わせを分けて扱います。ノードには通常、アドレス、ポート、ユーザー識別子、トランスポート方式、暗号化・セキュリティパラメータが含まれます。標準的なVLESS設定には実装間で一定の互換性がある場合もありますが、VLESS関連の拡張機能はXrayのほうが集中的に保守されています。特にVisionやREALITYとの組み合わせでは、その傾向が顕著です。

サブスクリプション項目にvless://とだけ書かれていても、2つのカーネルで直接使えるとは限りません。クエリパラメータのsecurity、flow、type、sni、fp、pbk、sidも確認してください。これらの一部はREALITYハンドシェイクに使われます。欠落すると、ハンドシェイク失敗、接続直後の切断、設定フィールド不足の警告などが起こりやすくなります。

XTLS Vision：通常のTLSスイッチとして扱わない

XTLS Visionは通常、flow=xtls-rprx-visionで識別されます。これは画面上で「TLSをXTLSに変更する」だけの単一オプションではなく、クライアント、サーバー、プロトコル、トランスポートの組み合わせを一致させる必要があります。ノードにVisionが指定されている場合はflowの値を完全な形で保持し、サブスクリプション変換や手動編集で削除しないでください。

Visionは主にXray体系を対象としています。同じノードをV2Flyに切り替えても、アドレス、ポート、ユーザー識別子が完全に同じだからといって接続できるとは限りません。サーバーが期待するハンドシェイクやフロー制御の動作が一致しなければ、タイムアウト、接続リセット、TLS関連エラーが発生する可能性があります。

REALITY：パラメータをまとめて確認する

REALITYはXrayでよく使われるセキュリティおよびハンドシェイク方式で、VLESS、TCP、Visionと組み合わせることが多い機能です。クライアント側では通常、serverName、公衆鍵、shortId、フィンガープリント、flowを確認します。サーバー側の秘密鍵はクライアントのサブスクリプションには含まれず、クライアントにはハンドシェイクに必要な公開パラメータが渡されます。

serverNameは、サーバー設定で許可された名前と一致していなければなりません。公衆鍵やshortIdは、1文字多くても少なくても失敗します。フィンガープリントはクライアントのハンドシェイク特性を示すため、カーネルが対応する値を使用してください。REALITYノードが利用できない場合は、まずこれらのフィールドを照合し、その後でシステム時刻、ネットワーク出口、サーバーの状態を確認します。

設定互換性：似たJSONで見落としやすい違い

XrayとV2Flyの基本設定は、どちらもJSONで記述することが一般的です。インバウンドは端末内のトラフィックを受け取り、アウトバウンドは宛先やプロキシサーバーへ接続し、ルーティングルールはトラフィックをどのアウトバウンドに渡すかを決めます。構造が似ているため、設定全体をコピーして実行カーネルだけ置き換える人もいます。この方法が適するのは、両方に共通する機能だと明確に確認できるフィールドだけです。

第1の違い：セキュリティ層とflow

streamSettings配下のセキュリティ種別を確認します。通常のTLS設定ではserverNameやALPNなどが関係し、REALITY設定では専用の設定項目が現れます。さらにVLESSユーザーまたはノード情報のflowも確認してください。Xray固有の値を残したままV2Flyに切り替えると、設定を起動できない場合や、起動しても接続を完了できない場合があります。

第2の違い：トランスポートパラメータとバージョン

WebSocketのパスとHost、gRPCのサービス名、TCPのヘッダー設定は、設定形式、バージョンの変化、サブスクリプション変換によって異なる場合があります。両方のカーネルが同じトランスポートに対応していても、クライアントが生成する最終的なJSONが完全に一致するとは限りません。調査時はサブスクリプションの原文だけでなく、クライアントが実際に書き込んだ設定を確認してください。

サーバーとクライアントのバージョン差が大きい場合、新しいフィールドを認識できない、旧形式が変更される、初期値が変わるといった問題も起こります。アップグレード前に、現在利用できるノード、ルーティングモード、カーネルの種類を記録してください。アップグレード後はまず1つのノードをテストし、その後で複雑な分流ルールを戻します。これにより、プロトコルの問題とルーティングの問題を切り分けられます。

第3の違い：DNSとルーティング

ルーティングルールは通常、ドメイン、IP、ポート、ネットワーク種別、インバウンドタグなどに基づいてアウトバウンドを選択します。両方のカーネルに関連機能はありますが、ルールのフィールド、マッチング動作、利用できる拡張機能はバージョンによって変わります。移行時はdomainStrategy、ルールの順序、アウトバウンドタグ、DNSの問い合わせ経路を重点的に確認してください。

ルールを上から順に評価する場合、前方の広いルールが先にトラフィックを処理し、後方の細かなルールが実行されないことがあります。「ノードには接続できるが、一部のサイトが想定した出口を通らない」場合は、いったん単純なグローバルテストモードに切り替えてください。カーネルとノードが利用可能だと確認したら、ドメインとIPの分流を1ルールずつ戻します。

第4の違い：タグ参照

設定内のtagは内部参照用の名前です。ルーティングルールが指すアウトバウンドタグは実際に存在し、DNSやインバウンド関連のルールも正しいオブジェクトを参照している必要があります。設定をコピーする際にアウトバウンドだけを移し、対応するタグを漏らすと、カーネルが対象不明のエラーを出したり、トラフィックがデフォルトのアウトバウンドへ流れたりします。タグ名自体はプロトコルを決めませんが、誤った参照はプロトコル非互換のように見える問題を引き起こします。

性能比較：1回の速度テストだけで判断しない

XrayやV2Flyという名前だけで速度が決まるわけではありません。実際のスループットと遅延は、サーバー回線、往復距離、混雑状況、端末性能、プロトコルの組み合わせ、トランスポート層、暗号処理、分流ルール、テスト先によって決まります。異なるノード、時間帯、ネットワークで行ったテスト結果は、直接比較できません。

同じ回線と近い設定条件であれば、XrayのVisionなどの方式は、特定の組み合わせで追加処理を減らし、現代的な接続方式向けに最適化できる場合があります。ただし、すべてのXray設定がすべてのV2Fly設定より速いという意味ではありません。一般的なVMessやVLESSノードでボトルネックがサーバー帯域やネットワーク経路にある場合、カーネルを切り替えてもほとんど変わらない可能性があります。

正しい比較方法

1. 同じ端末、同じローカルネットワーク、同じ時間帯に固定する。
2. 同じサーバー回線を使い、ポートとトランスポート条件を比較可能にする。
3. まず複雑なルーティングルールを無効にし、DNSと分流による影響を除外する。
4. 各組み合わせを少なくとも複数回テストし、接続確立時間、遅延、ダウンロード速度、長時間接続の安定性を個別に記録する。
5. クライアントログで再接続、タイムアウト、ハンドシェイクエラーを確認し、最高速度だけを記録しない。

メモリとCPU使用率も実際の利用環境で観察してください。同時接続数が多い場合、複雑なドメインルール、頻繁なDNS問い合わせはいずれもリソース消費を増やします。デスクトップ端末とAndroid端末ではバックグラウンド処理の方針が異なるため、両プラットフォームの数値をそのまま比較できません。

数分おきに接続が切れる場合は、まずネットワーク切り替え、省電力制限、サーバーのアイドルタイムアウト、クライアントのバックグラウンド状態を確認してください。カーネルを入れ替えるだけで一時的に症状が変わることはありますが、根本原因が解決するとは限りません。

サブスクリプション互換性：インポート成功とパラメータ完全反映は別

サブスクリプションはノード情報を一括で渡す仕組みですが、拡張フィールドを表現できる範囲は形式によって異なります。クライアントにノード名が表示されても、REALITYの公衆鍵、shortId、serverName、フィンガープリント、flowが最終設定に正しく書き込まれたとは限りません。

v2rayNにサブスクリプションをインポートしたら、ノード詳細を開き、プロトコル、トランスポート、セキュリティ種別、flowを確認してください。サブスクリプション更新前に手動で変更したフィールドは、次回更新時に上書きされる可能性があります。長期的に保持したいパラメータは、更新のたびに手入力するのではなく、サブスクリプション提供元から正しく渡される状態にしてください。

v2rayNGでXray系統のノードを扱う場合は、アプリのバージョンとノードパラメータが一致しているか確認してください。v2flyNGは、V2Fly向けであることが明確な設定に適しています。同じ高度なVLESSリンクを2つのクライアントにそれぞれインポートして、両方でノードが生成されたとしても、基盤機能が同じだとは判断できません。

サブスクリプション変換によって、フィールド名が変更されたり、認識できないパラメータが削除されたり、トランスポート種別が旧形式に変換されたりすることがあります。元の共有情報では使えるのに、サブスクリプションのインポート後に使えなくなった場合は、生成されたノード詳細を比較してください。まず不足しているフィールドを探し、ポートを変更したりセキュリティ設定を無闇に無効化したりしないでください。

利用シーン別にXrayとV2Flyを選ぶ

ケース1：ノードがREALITYまたはVisionを明示している

Xrayを選択してください。REALITYを通常のTLSに変更したり、表面的な互換性を求めてVisionのflowを削除したりしないでください。セキュリティ層とフロー制御はサーバー設定の一部であり、クライアントはサーバーの要件に従って接続する必要があります。デスクトップではv2rayNで実際に呼び出されているカーネルを確認し、Androidではv2rayNGを使用してインポートされたフィールドを確認してください。

ケース2：既存のV2Fly設定が安定して動作している

現在の設定が通常のVMess、VLESS、WebSocket、gRPC、TLS、DNS、ルーティングルールを使用し、サーバーとクライアントが長期間安定しているなら、名前を変えるためだけに移行する必要はありません。V2Flyを使い続ける場合は、現在のバージョンと設定構造を記録し、アップグレード後にノード、DNS、ルーティングの順で確認してください。

ケース3：1つのサブスクリプションに複数種類のノードが混在している

まずノードを機能別に分類します。通常のVMessや標準的なVLESSを一グループ、REALITYやVisionのノードを別グループに分けます。カーネルを切り替えたらグループごとにテストし、すべての失敗をサブスクリプションのせいにしないでください。クライアントがノードごとに適切なカーネルを選べる場合も、切り替え後に設定を再生成し、ログを確認してください。

ケース4：設定が複雑な分流に依存している

まずノードのプロトコルを完全にサポートするカーネルを選び、その後で分流ルールを移行します。ノード層でまだ接続できていない段階では、複雑なルーティングが変数を増やすだけです。まずローカルプロキシのインバウンドを1つとノードのアウトバウンドを1つだけ残して基本接続を確認し、その後、直接接続用アウトバウンド、ドメインルール、IPルール、DNSポリシーを追加してください。

ケース5：低遅延と安定した接続だけを重視する

サーバー設定と一致し、クライアントが正常に保守され、ログも確認しやすい組み合わせを優先してください。遅延差が小さい場合は、1回の速度テストの最高値より安定性のほうが参考になります。しばらく継続して使用し、切断、再接続、DNS失敗、バックグラウンド維持の状態を観察してから移行を決めてください。

V2FlyからXrayへ切り替える際のチェックリスト

1. 現在の環境を記録する。クライアントのバージョン、カーネル名、利用可能なノード、待ち受けポート、システムプロキシモード、ルーティングモードを記録します。
2. 設定内容をバックアップする。サブスクリプションURLとカスタムルーティングルールを保存し、アップグレードや切り替え後に復元できなくなる事態を防ぎます。
3. ノードのプロトコルを確認する。VMess、VLESS、トランスポート方式、セキュリティ層、flowをノードごとに記録し、ノード名だけで分類しないでください。
4. ローカルポートを確認する。SOCKSとHTTPのインバウンドポートが他のプロセスに使用されていないことを確認し、カーネル切り替え時に旧プロセスがバックグラウンドで動き続けないようにします。
5. まず1つのノードをテストする。複雑な分流を無効にし、パラメータが揃ったノードを1つ選んで基本接続を確認します。
6. 実行ログを確認する。設定解析、DNS、ハンドシェイク、認証、タイムアウト、ルーティングのエラーを区別します。エラーの種類によって確認すべき方向が異なります。
7. ルーティングルールを戻す。直接接続、プロキシ、ブロックのルールを簡単なものから順に追加し、変更するたびに代表的なドメインをテストします。
8. サブスクリプション更新後に再確認する。更新によって手動設定が上書きされていないか、特にREALITYとVisionに必要なフィールドを確認します。

XrayからV2Flyへ戻す場合も、まずXray固有の機能への依存を取り除き、カーネルファイルを直接置き換えるのは避けてください。ノードがREALITYやVisionを要求している限り、V2Flyでは同等の接続を提供できません。元のノードを使い続けるならXrayを維持し、V2Flyを使うならサーバーが明確に対応する設定の組み合わせを用意してください。

よくある質問

最終的な選択基準

Xrayの明確な強みは、XTLS、REALITY、そしてVLESSを中心とした継続的な拡張です。V2Flyは従来の設定体系と既存機能の方針を引き継ぐことに重点があります。どちらにも適した用途があり、判断の軸はブランドの好みではなく、サーバーの要件、ノードのフィールド、クライアントの対応状況、既存設定の移行コストです。

実際に選ぶ際は3段階で進めます。第1にノードにREALITYまたはVisionが含まれるか確認し、第2にクライアントで実際に動作しているカーネルを確認し、第3に複雑な分流を無効にして基本接続をテストします。基本接続が通ったら、サブスクリプション更新、DNS、ルーティングルールを戻します。この順序なら、カーネル互換性、サブスクリプションのフィールド不足、分流エラーを混同せずに済みます。