XrayコアとV2Flyコアの違い：REALITY、XTLS Vision、設定の互換性

クライアント・コア・ノードのプロトコルを区別する

v2rayNはデスクトップ用クライアントで、サブスク管理、ノード編集、システムプロキシ、コアプロセスの管理を行います。XrayとV2Flyは、実際にプロキシ通信を処理するコアです。クライアントをインストールしただけでは、接続に使われるコアは特定できません。実行ログでコア名、バージョン、起動結果を確認してください。

V2FlyコミュニティはV2Rayプロジェクトを保守しています。XrayはV2Rayプロジェクトから派生し、その後、伝送方式やセキュリティ機構、設定項目を独自に発展させてきました。共通の起源があっても、新機能が両方に同時に追加されるとは限らず、JSON設定全体をそのまま相互に利用できるわけでもありません。

• クライアント層：v2rayN、v2rayNG、v2flyNGが操作画面を提供し、サブスクを読み込んでコアを起動します。
• コア層：XrayまたはV2Flyが設定を解析し、インバウンド／アウトバウンド接続を確立してルーティングルールを適用します。
• プロトコル層：VMess、VLESS、Trojanなどはプロキシ通信の方式を示すもので、クライアント名とは異なります。
• 伝送・セキュリティ層：TCP、WebSocket、TLS、REALITYなどの設定が接続条件を決めます。ノード一覧のプロトコル表示だけで判断しないでください。

Android版ではv2rayNGがXrayコア、v2flyNGがV2Flyコアを使用します。デスクトップ版v2rayNでは、現在のバージョンで選べるコアと、そのノードが実際に呼び出すコアを確認してください。画面にノードを保存できても、それは入力チェックを通過しただけで、コアによる接続の成功を意味しません。

REALITY・XTLS Visionと主要プロトコルを比較

REALITYとXTLS Visionは、解決する課題が異なります。REALITYはXrayが提供する伝送セキュリティ機構です。Visionはxtls-rprx-visionで指定するフロー制御モードで、VLESS設定でよく使われます。両者は組み合わせて使われることがありますが、同じ設定項目ではありません。条件を満たすTLS設定でもVisionを利用できます。

REALITYノードでは通常、サーバーから提供される公開鍵関連のパラメーター、serverName、shortId、クライアントフィンガープリントなどが必要です。サーバーの秘密鍵をクライアントに設定してはいけません。共有リンク、クライアントの入力欄、コアのJSONでは項目名が異なる場合があります。項目名を機械的にコピーせず、使用中のバージョンの説明に従って対応付けてください。

ノードの要件に合わせてXrayまたはV2Flyを選ぶ

サブスクにREALITYまたはVisionのノードが含まれている場合は、これらの機能に対応したXrayクライアントを優先してください。V2Fly環境で既存の設定を長期間使っており、双方が対応するプロトコルと伝送方式を使用しているなら、まず動作を確認してから移行を検討できます。コアの選択は速度ランキングではありません。実際の通信品質は回線の混雑、サーバー負荷、ローカルネットワークにも左右されます。

「新しいコアなら、古いノードもすべてそのまま読み込める」とは限りません。クライアントのサブスク解析機能も変換に関わるため、同じ共有リンクでもクライアントによって異なる項目として解析され、一部の拡張パラメーターが無視されることがあります。クライアントを切り替えたら、サブスクを何度も更新するより、まずノード編集画面で各項目を確認するほうが問題を特定しやすくなります。

設定移行時に確認したい5つの項目

移行時は、まずノードを1つだけ読み込み、接続できることを確認してからサブスク全体を読み込みましょう。設定全体にはリモート接続だけでなく、ローカル待ち受け、DNS、ルーティング、アウトバウンドタグも含まれます。ノード情報だけの移行なら変更箇所を絞り込めます。JSON全体を上書きすると、アプリの接続方式や振り分け結果まで変わる可能性があります。

1. 現在の環境を記録する。クライアントのログでコア名とバージョンを確認し、元の設定を保存します。v2rayNでは「設定」→「パラメーター設定」を開き、ローカル待ち受けに関する項目を確認できます。タブ名はバージョンによって異なる場合があるため、現在の画面に従ってください。
2. 接続先の情報を確認する。サーバーアドレス、ポート、UUIDまたはパスワードを確認します。ポートはサーバー側の指定に従うものです。別のノードが443を使っているからといって、現在のノードも443に変更してはいけません。
3. 伝送設定を確認する。WebSocketのpathとHost、TLSのserverName、REALITYの各パラメーターは、サーバー側の設定に合わせる必要があります。HostとserverNameは用途が異なります。値が同じでも、1つの項目にまとめることはできません。
4. セキュリティとフロー制御を確認する。TLSまたはREALITYの選択と、xtls-rprx-visionが必要かどうかを確認します。読み込み後にVLESSと表示されても、これらの追加条件がすべて保持されているとは限りません。
5. ローカルのルールを再設定する。DNS、ルーティングの順序、アウトバウンドタグ、システムプロキシを再確認します。存在しないoutboundTagを参照すると、設定の起動に失敗したり、意図しない振り分けになったりすることがあります。

V2Flyには複数の設定形式と独自の開発方針があり、Xrayでも設定項目や検証ルールが変更されます。そのため、どちらもJSONだからといって構造が同じとは限りません。不明な項目、無効な伝送方式、未対応のflowに関するエラーが出た場合は、まず設定を読み込んでいるコアと形式を確認し、エラーが示す項目を調べてください。エラー項目を一括削除するのは避けましょう。

この3つの数値はそれぞれ異なる役割を示しており、そのまま使う推奨設定ではありません。リモートポートはサーバーへの接続に使い、ローカルポートはアプリからプロキシへ接続する際に使います。たとえばブラウザーがローカルのHTTPポートを指定する場合、コアが実際にその待ち受けを提供している必要があります。混合ポートを使用中なら、実際の待ち受け方式に合わせて設定し、以前のクライアントのポート記録をそのまま使わないでください。

デスクトップとAndroidでのサブスク利用方法を整理する

1つのサブスクに複数のプロトコルが含まれることがあります。デスクトップで読み込みに成功しても、Androidがすべての項目に対応しているとは限りません。サービス提供元がクライアントの種類に応じて異なる内容を返すこともあるため、両方の端末でノード名が同じでも、プロトコル、伝送方式、セキュリティの項目を確認してください。

Macのシステムプロキシは、主にシステムプロキシ設定に従うアプリに影響します。一方、Androidクライアントは通常、システムVPNインターフェースを通じて通信を処理します。接続方式が異なるため、AndroidでWebページを開けても、Macのシステムプロキシが正しく設定されている証拠にはなりません。トラブル時は、まずコアの起動を確認し、次にアプリの通信がコアに届いているか調べてください。

読み込みは成功するのに接続できない場合の対処

「設定を起動できるか → リモートとのハンドシェイクが成功するか → アプリの通信がプロキシに入っているか」の順に確認してください。一度に変更するのは1つの項目群に限定し、最初に出た具体的なエラーを記録します。ノード一覧のテスト結果は特定のテスト先に対するものです。ブラウザー、DNS、ルーティングを含む全体の確認には代わりません。