XrayコアとV2Flyコアの違い｜系譜・対応プロトコル・クライアントの選び方

系譜を整理：V2Ray、V2Fly、Xray

V2Rayは、プロキシツールのエコシステムを指す場合と、特定のコアプログラムを指す場合があります。Project Vはこのツール群のプロジェクトとしての背景にあたり、接続を実際に処理するコアは設定を読み込み、ローカルの接続口を作成し、出力先を選んでルーティングを行います。これらの名称を混同すると、名前の似たクライアントなら対応プロトコルも同じだと思い込む原因になります。

2つのコアの系譜を理解するうえで、2020年は重要な節目です。V2FlyコミュニティはV2Rayコアの開発と保守を引き継ぎました。一方、Xrayは当時のV2Rayのコードをベースに分岐し、その後独自に開発が進みました。両者には共通の歴史や設定の概念がありますが、同じプログラムの別スキンではありません。一方のバージョン番号から、もう一方の新旧を判断することもできません。

• V2Fly：V2Rayコアを保守し、独自のプロトコル実装、通信方式、設定体系を発展させています。
• Xray：Xray-coreを保守し、REALITYやXTLS Visionなどの機能を追加してきました。
• GUIクライアント：サブスクリプションやノードの編集、プロキシの切り替えを提供し、設定内容をコアに渡して実行します。

そのため、「サブスクリプションのインポートに成功」と表示されても、クライアントが設定を解析・保存できたことを示すだけで、実行中のコアがすべての項目を受け入れたとは限りません。互換性を判断するときは、クライアントのバージョン、実際に動作しているコア、ノードのプロトコル構成をあわせて確認してください。

プロトコル対応：VMessとVLESSだけで比べない

ノードの設定は通常、複数の層で構成されます。VMessとVLESSはプロキシプロトコル、TCP・WebSocket・gRPCなどは通信方式、TLSとREALITYは接続のセキュリティ層に関わる項目です。VisionはXrayのフロー制御機能に関係します。それぞれの役割は異なり、REALITYをVLESSと同列の、単独で置き換えられるプロキシプロトコルとして扱うことはできません。

ここでいう「対応」は、過去のすべてのバージョンで利用できるという意味ではありません。サブスクリプションに新しい通信方式や項目が含まれると、古いクライアントでは解析時に失敗することがあります。画面上で認識されても、コアが古ければ起動時にエラーになる場合もあります。使用中のバージョンの機能説明を確認し、同じプロトコル名だから常に互換性があるとは考えないでください。

クライアントの選び方：デスクトップとAndroidを分けて考える

v2rayNはデスクトップ向けのGUIクライアントです。名前に「v2ray」とあるだけで、実際に使われるコアを判断することはできません。利用できるコアや切り替え方法はリリースによって異なるため、端末の設定画面や起動ログで確認してください。REALITYを使う場合は、インストールフォルダーにXrayのファイルがあるかだけでなく、そのノードを実際にXrayが処理していることを確かめましょう。

ここでのおすすめは、記事で取り上げるXrayの機能が必要な場合を対象としており、あらゆるネットワーク環境での性能ランキングではありません。クライアントの画面とコアは別々に更新されます。入力欄が表示されても、実行中のコアがその設定を処理できるとは限りません。

サブスクリプションを確認：ノードの編集画面で設定値をチェック

v2rayNでは、「サブスクリプショングループ」→「サブスクリプショングループ設定」からURLとグループを確認し、「サブスクリプショングループ」メニューから対象のグループを更新できます。更新コマンドの表記はバージョンによって異なることがあるため、使用中のメニューから選んでください。更新後はサーバーの項目をダブルクリックし、プロトコル、アドレス、ポート、通信方式を確認します。ノード名だけで判断しないでください。

1. まずプロトコルを確認。項目がVMessかVLESSかを確かめます。ノード名にある「高速」「専用回線」などの文言はプロトコルのネゴシエーションに関係せず、コアを選ぶ根拠にはなりません。
2. 次に通信方式を確認。WebSocketではパスとHost、gRPCではサービス名を重点的に確認します。サーバー側の通信方式に合わせて、クライアントにも対応する設定を入力してください。
3. セキュリティ層を確認。TLSではサーバー名と証明書の検証を確認します。REALITYでは、サーバーから指定された公開鍵やshort IDなども確認してください。項目名は使用中の画面に表示されるものを基準にします。
4. 最後にフロー制御を確認。サーバーがVisionを要求する場合は、flowがxtls-rprx-visionになっていることと、対応するコアを使っていることを確認してください。

v2rayNGやv2flyNGでも、サブスクリプショングループから更新してから、対象ノードの編集画面で設定を確認します。同じURLでも、クライアントのバージョンやフィルター設定、配信側の応答によって一覧が異なることがあります。

デスクトップとAndroidの併用：まずノードを確認し、設定を個別に合わせる

デスクトップとAndroidで同じサブスクリプションを使うことはできますが、実行設定一式をそのままコピーするのは避けてください。デスクトップのシステムプロキシ、AndroidのVPN接続、アプリごとの設定、ローカルの待ち受けアドレスは端末環境に依存します。ノードと一緒にコピーするのではなく、サーバー情報だけを共有してください。

パソコンでは使えるのにスマートフォンでは使えない場合は、まずノードの具体的な設定値を比較し、次に端末の時刻、VPNの許可、アプリごとの対象範囲を確認してください。一部のアプリだけで問題が起きるなら、2つのコアのプロトコル対応の違いと決めつけず、通信の対象範囲やDNSを先に確認しましょう。

ポートとトラブルの切り分け：ローカルの接続口とサーバー側を区別

ポート番号は具体的な設定値であり、コアの種類を示すものではありません。ここでは、ローカルのSOCKS接続口の例として10808、リモートサーバーのポートの例として443を使用します。どちらも必須のデフォルト値ではなく、相互に置き換えることもできません。実際の値はクライアントの設定とノードの編集画面で確認してください。

たとえば、アプリにSOCKSプロキシを手動で設定する場合、クライアントが実際にそのポートで待ち受けていることを確認したうえで、アドレスに127.0.0.1:10808を指定できます。ノードの編集画面にあるリモートポートは、提供元の指定値を使用してください。通常のローカル利用ではループバックアドレスで待ち受ける設定にし、トラブル調査のためだけにすべてのネットワークインターフェースへ公開しないでください。

移行の判断：再現できる設定を基準として残す

コアを変更する前に、現在使えているノードとルーティング設定を保存してください。GUIクライアントは、起動時やノード切り替え時にconfig.jsonを再生成することがあります。そのため、この記事では一時生成ファイルを直接編集せず、画面から設定を変更して記録を残す方法を推奨します。XrayとV2Flyには共通する設定項目もありますが、設定全体を含むJSONファイルをそのまま相互利用できるわけではありません。

• ノードがREALITYまたはVisionを要求する：互換性のあるXray対応クライアントを使い、クライアントとコアのバージョンを確認する。
• 既存のVMessノードが安定している：現在の構成を維持し、明確な必要性がある場合にのみ移行する。
• 速度の改善だけが目的：ノード、ネットワーク、接続先、測定時間帯を固定して、遅延と継続的な通信速度を比較する。接続経路の変化をコアの効果と混同しない。
• 移行後に問題が発生した：まず動作していた元の設定に戻し、プロトコル、通信方式、セキュリティ層、通信の対象範囲、ルーティングを1項目ずつ比較する。設定をすべて同時に変更しない。