XrayとV2Flyカーネルの違い：バージョン体系とクライアントの選び方

クライアント・カーネル・サブスクリプションの関係を整理する

v2rayN、v2rayNG、v2flyNGは、ノードの保存、サブスクリプションの更新、システムプロキシの切り替え、実行用設定の生成、ログ表示を担うGUIクライアントです。一方、XrayとV2Flyは接続を実際に処理するカーネルで、ローカルポートの待ち受け、ルーティングルールの実行、プロトコルハンドシェイク、リモートサーバーへの通信を担当します。画面が正常に開いても、カーネルの起動に成功したとは限りません。

サブスクリプションはその中間に位置します。サブスクリプションサービスがノード一覧を返し、クライアントがリンク内のプロトコル、アドレス、ポート、トランスポート層、TLSパラメータをカーネル設定へ変換します。同じサブスクリプションを別のクライアントに読み込んでも、最終的に生成されるJSONは同一とは限りません。クライアントがローカルのインバウンド、DNS、ログ、ルーティング設定を補うためです。

そのため、「V2Rayノード」はエコシステム全体を指す通称にすぎず、内部で必ずV2Flyが動作しているとは限りません。VLESS、REALITY、XTLS Visionのパラメータを含むノードはXray向けの傾向があり、従来型のVMess、WebSocket、TLSの組み合わせは両方のカーネルで成熟した実装を利用できる場合があります。ただし、フィールドとバージョンの確認は必要です。

判断の順番：まずノードのパラメータ、次にクライアント名

ノードにREALITY、shortId、spiderX、またはXTLS Visionのフロー制御パラメータがある場合は、まずXrayを選びます。VMess、WebSocket、TLSなど一般的なフィールドだけの場合は、利用中のクライアントと設定の互換性を確認して選択してください。

V2FlyとXrayのバージョン関係

どちらも初期のProject Vエコシステムに関係しますが、現在のXrayをV2Flyの「上位モード」と考えたり、V2FlyをXrayの旧版と見なしたりするべきではありません。それぞれ独自のリリース周期、機能方針、バグ修正経路を持っています。設定形式に共通点が多いのは、インバウンド、アウトバウンド、ルーティング、トランスポート層のモデルを近い形で受け継いでいるためです。

V2FlyはV2Rayコミュニティのメンテナンス方針を引き継ぎ、従来の設定モデルとの連続性を保ちながら、v5設定体系を発展させています。一般的な設定はinbounds、outbounds、routing、dns、logなどで構成されます。既存のVMess環境、標準的なトランスポート構成、V2Flyの動作に依存する環境では、通常こちらの系統が適しています。

Xrayは近いコードベースから独立して発展し、バージョン番号には1.x系列を使用しています。主な機能はVLESS、REALITY、XTLS Visionなどです。V2Flyと一部のJSONフィールドは似ていますが、新しく追加されたすべてのフィールドを相互利用できるとは限りません。Xrayの設定をそのままV2Flyに渡すと、未知のフィールド、未実装プロトコル、認識できないフロー制御値などのエラーが発生することがあります。

バージョン番号を単純に比較しない

Xray 1.xとV2Fly v5は同じリリース系列の数字ではないため、数値の大小から新旧を判断できません。重要なのは、対象プロトコルが実装されているか、設定フィールドが認識されるか、そしてクライアントに含まれるカーネルのバージョンがノードの要件を満たすかです。

プロトコル対応と設定フィールドの違い

VMessは両方の系統で使われる従来型プロトコルですが、トランスポート層、暗号化オプション、互換性はバージョンによって異なります。既存のVMess + TCPやVMess + WebSocket + TLSノードを移行する場合は、元のアドレス、ポート、UUID、Host、パス、TLSドメイン名をまず保持し、複数のパラメータを同時に変更しないでください。

VLESSは認証と暗号化トランスポート層を分けて設定します。実際のクライアント環境では、VLESSはXrayのREALITYやXTLS Visionと組み合わせて使われることがよくあります。このタイプのノードでは、サーバーアドレスとUUIDに加え、serverName、publicKey、shortId、spiderX、フィンガープリント、xtls-rprx-visionフロー制御値が必要になる場合があります。必須項目が1つでも欠けると、ハンドシェイク失敗や、接続後に有効な通信が発生しない状態につながります。

ルーティング構造も「同じように見える」ことによる誤判断が起きやすい部分です。両方のカーネルでドメイン、IP、ポート、インバウンドタグに基づくルールを実行できますが、ルールデータファイル、フィールド拡張、DNSの挙動はバージョンによって変わる場合があります。routing.rulesを移行するときは、domain、ip、port、network、outboundTagを1つずつ確認し、参照先のタグが実際に存在することを確認してください。

v2rayN・v2rayNG・v2flyNGの選び方

Windowsデスクトップでは通常v2rayNを優先し、クライアントからXrayカーネルを管理します。サブスクリプションの読み込み、ノードの一括テスト、システムプロキシ、ルーティング、ログ確認に適しています。ノードにREALITYやXTLS Visionが含まれる場合、この組み合わせなら設定変換による不確実性を減らせます。

v2rayNでカーネルを確認する場合は、まず「設定」→「パラメータ設定」を開き、カーネル、基本設定、起動パラメータに関する項目を確認します。バージョンによって項目名は多少異なる場合があります。その後メイン画面に戻ってサービスを再起動し、すぐにログを確認してください。ログの最初の画面にXrayのバージョン情報が表示されていれば、プログラムフォルダのファイル名ではなく、実際にXrayが動作していると判断できます。

Androidでは、カーネルの系統に応じてv2rayNGとv2flyNGを選びます。v2rayNGはXrayカーネルと組み合わせ、VLESS、REALITY、XTLS Visionを含むサブスクリプションに適しています。v2flyNGはV2Flyカーネルと組み合わせ、V2Flyの動作に明確に依存するノードや設定に適しています。操作画面が似ていても、プロトコル拡張まで完全に同じとは限りません。

ローカルポートもあわせて確認

• v2rayNでよく使われるローカルSOCKS待ち受けポートは10808です。HTTPポートには隣接するポートが使われる場合がありますが、最終的には「設定」→「パラメータ設定」のローカル待ち受け設定を確認してください。
• ブラウザーや他のプログラムでプロキシを手動設定する場合、プロキシの種類を待ち受ける種類に合わせる必要があります。HTTPリクエストをSOCKSポートへ送ると、接続拒否やページが読み込み中のままになることがあります。
• カーネル交換後にポートが解放されていない場合、ログにaddress already in useと表示されることがあります。まだ動作中の古いプロセスを終了してから、クライアントを再起動してください。
• システムプロキシを有効にしても接続できない場合は、まず単一ノードの遅延をテストし、次にルーティングルールが対象ドメインをdirectアウトバウンドへ送っていないか確認してください。

ログで現在動作しているカーネルを確認

クライアントのタイトル、サブスクリプション名、ノードのメモだけでは、実際のカーネルを証明できません。最も確実なのは起動ログです。サービスを停止して一度再起動し、1行目からバージョン識別子、設定の読み込み先、待ち受けアドレス、エラー内容を確認してください。「起動に失敗しました」という最後の行だけを切り取らないでください。本当の原因はその前に出ていることが多いためです。

正常な起動では通常、設定生成、設定解析、インバウンドポートの待ち受け、サービス稼働という段階をたどります。解析段階で停止した場合はJSON構文とフィールドを確認します。127.0.0.1:10808で待ち受けた後にリモート接続が失敗する場合は、アドレス、ポート、TLS、SNI、REALITY公開鍵、ルーティングルールを確認してください。

起動確認の順番
1. カーネル名とバージョン行を確認
2. 設定ファイルが正常に読み込まれたことを確認
3. 127.0.0.1:10808の待ち受け開始を確認
4. ノードテストまたはWebリクエストを1回実行
5. 最初のwarning / errorから上にさかのぼって周辺のログを確認

1. unknown fieldが表示された場合：現在のカーネルが設定フィールドを認識していません。まずそのフィールドがどちらのカーネル系統に属するか確認し、次にクライアントが互換性のない拡張パラメータを生成していないか調べます。
2. failed to listenが表示された場合：ローカルポートが使用中か、待ち受けアドレスが無効です。重複して起動しているクライアントを終了するか、SOCKSポートを10808から未使用のポートへ変更してください。
3. invalid userが表示された場合：UUID、ユーザー識別子、プロトコルの種類を確認してください。VMessとVLESSのリンクは、プロトコル名だけを変更しても利用できません。
4. handshake failedが表示された場合：システム時刻、サーバー名、TLSパラメータ、REALITY公開鍵、短い識別子、クライアントフィンガープリントを確認してください。最初にルーティングルールを変更するのは避けます。
5. 起動成功後も通信がない場合：システムプロキシ、DNS、アウトバウンドタグを確認してください。ルーティングルールが存在しないoutboundTagを参照していると、特定のリクエストが意図した通りに送信されない場合があります。

よくある選択の疑問と対処法

カーネルの選択は一度決めたら終わりではありません。サブスクリプション提供元がノードのプロトコルを変更したり、クライアントがカーネルを更新したり、サーバー側で設定を移行したりすると、互換性を再確認する必要があります。検証済みのノードを1つ残し、使用プロトコルとトランスポートパラメータを記録しておくと、次回のトラブル対処を大幅に短縮できます。