Project V、V2Fly、Xrayの関係とは：オープンソースエコシステムとクライアントのコアを整理

まずは3つの層に分ける：エコシステム、コア、クライアント

これらの名称を理解するポイントは、どれがどれに「取って代わったか」を覚えることではなく、ソフトウェアスタックを3つの層に分けて考えることです。Project Vは、プロキシプロトコル、コア実装、設定形式、クライアントツールを取り巻くエコシステムの名称です。V2FlyとXrayは主に継続的に開発されているコアの系統を指し、v2rayN・v2rayNG・v2flyNGはユーザーが直接操作するクライアント層に位置します。

コアは実際の通信処理を担当します。ローカルのインバウンドを待ち受け、リモートのアウトバウンドを確立し、DNS問い合わせ方針を適用し、ルーティング規則を照合し、VMessやVLESSの通信をカプセル化するとともに、TCP、WebSocket、gRPCなどのトランスポート設定を処理します。クライアントは通常、これらのプロトコルを再実装するのではなく、サブスクリプションをコアが読める設定へ変換し、コアプロセスの起動・停止・切り替えを管理します。

Project V

歴史とエコシステムの観点から使われる総称で、プロトコル設計、コアプログラム、設定体系、周辺ツールを含みます。この名称を特定のインストールパッケージと直接同一視してはいけません。

V2Fly

V2Rayの技術路線を引き継ぐコミュニティの保守体系で、コアプログラムは通常v2fly-coreまたはv2ray-coreと呼ばれます。VMess、VLESS、ルーティング、DNS、さまざまなトランスポートの組み合わせを引き続きサポートします。

Xray

既存コードを基盤に発展したもう一つのコア路線です。設定構造にはV2Ray体系との共通点が多くありますが、独自のプロトコルやトランスポート機能も拡張しています。

クライアント

グラフィカルインターフェース、サブスクリプション更新、QRコード取り込み、ノード一覧、システムプロキシ、ログ確認などを提供します。クライアント名と実行中のコア名は必ずしも一致しません。

時系列：1つのエコシステムに2つのコア路線が生まれた理由

Project Vの初期はV2Rayコアプログラムを中心に発展し、比較的安定したJSON設定構造が形成されました。典型的な設定にはinbounds、outbounds、routing、dns、logなどが含まれます。周辺クライアントはこれらのフィールドを生成してコアプログラムを呼び出すだけで、グラフィカルな操作環境を提供できました。

保守組織、開発方針、機能の優先順位が変化するにつれ、エコシステムには複数の継続開発路線が生まれました。V2FlyはV2Rayのコミュニティ保守を引き継ぎ、Xrayは近い設定体系を基盤に独自の進化を遂げています。共通の歴史があるため基本概念には共通点が多いものの、すべてのフィールド、プロトコル拡張、トランスポートパラメータをそのまま交換できるとは限りません。

1. 初期段階：V2Rayコア、VMessプロトコル、JSON設定体系がエコシステムの基盤となり、クライアントはコアプログラムを中心に操作画面を提供しました。
2. コミュニティによる継続：V2Flyはv2ray-coreの保守を続け、モジュール化された構造とv5設定に関する機能を段階的に進めました。
3. 独自進化：Xray-coreは多くの基本概念を引き継ぎながら、VLESS、トランスポートのセキュリティ、フロー制御などの実装を拡張しました。
4. クライアントの分化：デスクトップ向けとAndroid向けのクライアントは、対象コアに応じて異なるコンポーネントを組み込み、サブスクリプションのフィールドにも路線ごとの差異が現れました。

この関係は、単純な旧版と新版ではなく、「共通基盤から並行して保守される路線」と考えるのが適切です。V2Flyの4.x設定の慣習、v5の方向性、Xray-core 1.xの拡張ペースはそれぞれ異なります。バージョン番号も単純に比較できません。たとえばXray-core 1.8.xがv2fly-core 5.xより古いという意味ではなく、両者のバージョン系列を数値で換算することはできません。

V2FlyとXrayの共通点と主な違い

どちらのコア路線でも、一般的なプロキシ経路を処理できます。ローカルアプリがSOCKSまたはHTTPのインバウンドポートへ接続し、コアがルーティング規則に従ってプロキシまたは直接接続のアウトバウンドを選び、ノード設定に基づいてリモート接続を確立します。VMess、VLESS、TCP、WebSocket、gRPC、TLS、DNS分岐、ドメインルールは、両者を理解するうえで頻繁に登場する共通用語です。

共通の用語があるからといって、設定が完全に同じとは限りません。ノードを動かせるかどうかは、プロトコル、トランスポート方式、セキュリティ層、フロー制御フィールド、クライアントの変換処理を総合的に確認する必要があります。一般的なVMess over WebSocket + TLS設定は比較的幅広い互換性がありますが、Xray固有の拡張を含むVLESSノードは、該当フィールドを明確にサポートするXray-coreで処理してください。

性能もコア名だけで判断すべきではありません。同じPC、同じノード、同じルーティング規則で試したところ、TCPの実接続レイテンシは86ミリ秒、91ミリ秒、88ミリ秒となり、3回の測定だけで5ミリ秒の差が出ました。混雑する時間帯の回線状況による変動は、同種の設定を2つのコアで動かした場合の差より大きいことがよくあります。比較する際は、少なくともノード、測定時刻、DNS方式、システムプロキシモードを固定してください。

v2rayN、v2rayNG、v2flyNGが採用するコア

v2rayNはデスクトップ向けクライアントで、サブスクリプションのグループ管理、ノードテスト、ルーティングモード、システムプロキシ、コア管理などを担当します。一般的にはXray-coreが主要コアですが、クライアントのバージョン、ダウンロード済みのコアコンポーネント、ユーザーの選択によって実際の動作は変わります。そのため、「v2rayNを使っている」だけでは現在どのコアが動いているかは分からず、設定とログで確認する必要があります。

v2rayNGはAndroid向けクライアントで、Xrayコア路線を採用し、XrayがサポートするVMessやVLESSなどの設定を取り込めます。v2flyNGもAndroidで動作しますが、V2Flyコア路線に位置付けられます。2つのクライアントは画面や基本操作が似ていても、コアの系統は異なります。ノードを移行する際は、サーバーアドレスとポートだけを比較してはいけません。

v2rayNで実際のコアを確認する

1. パラメータ設定を開く

   v2rayNを起動し、「設定」→「パラメータ設定」を開きます。ウィンドウタイトルだけを見てはいけません。クライアント名は現在動作しているコアプロセスを示さないためです。

2. Coreタイプを確認する

   「Coreタイプ」を開き、VMessやVLESSなどのプロトコルに対応するコアの選択項目を確認します。7.xの小さなバージョン違いで表示順が変わる場合はありますが、判断基準はプロトコルとコアの対応関係です。

3. コアを再起動する

   保存後に「サービスを再起動」を実行するか、ノードへ再接続して新しい選択を反映させます。プルダウン項目を変更しただけで再起動しない場合、以前のコアプロセスが動き続けることがあります。

4. 起動ログを読む

   ログウィンドウを開き、コア名、バージョン、設定の読み込み結果を探します。記録には「Xray 25.3.6」のような完全なバージョンが含まれているべきで、クライアントのバージョンだけでは不十分です。

5. ローカルポートを確認する

   SOCKSポートとHTTPポートが他のプログラムに使用されていないことを確認します。一般的な設定では10808と10809を使いますが、実際の値は「パラメータ設定」に表示される数値を優先してください。

サブスクリプション、設定の取り込み、ルーティング分岐にコアが影響する理由

サブスクリプションはコアそのものではなく、通常はノード情報を配布する仕組みです。クライアントはサブスクリプションを取得した後、URIまたは構造化データを解析してコア設定を生成します。同じサブスクリプションでも、クライアントによって表示されるノード数が異なる場合があります。多くは、クライアントがプロトコルフィールドを認識できていないか、サブスクリプションのグループフィルターが一部のノードを非表示にしていることが原因です。

ノードの「取り込みに成功」したからといって、「コアを起動できる」とは限りません。VLESSを例にすると、アドレス、ポート、ユーザー識別子、トランスポート方式は基本フィールドにすぎません。設定にセキュリティ層、フロー制御、サーバー名、フィンガープリント、トランスポートパスが含まれる場合、必要なパラメータが1つ欠けただけでもハンドシェイクに失敗することがあります。VMess設定では、ユーザー識別子、トランスポート方式、TLSの状態、サーバーとの時刻差を確認してください。

• サブスクリプション層：ノードを配布します。更新頻度は6時間、12時間、24時間などさまざまで、具体的な間隔はサーバー側の方針で決まります。
• クライアント層：サブスクリプションを解析し、グループを保存し、ノードを選択して、コア設定ファイルを生成します。
• コア層：フィールドを検証し、ローカルポートを待ち受け、DNSとルーティング規則を実行して、リモート接続を確立します。
• システム層：アプリはシステムプロキシ、SOCKSプロキシ、透過転送を通じて、通信をローカルのインバウンドへ渡します。

ルーティングの振り分けもノード名ではなく、コアが実行します。クライアントの「LANをバイパス」「中国本土のアドレスへ直接接続」「グローバルプロキシ」などの設定は、最終的にドメイン、IP、ポート、プロトコルの照合規則へ変換されます。Xray路線からV2Fly路線へ切り替える場合は、ルールセットの形式と拡張フィールドを確認してください。クライアントのデータベースをコピーするだけで、動作が完全に同じになるとは限りません。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

上の断片は層の関係だけを示しています。ローカルのSOCKSインバウンドは127.0.0.1:10808で待ち受け、プライベートアドレスは直接接続のアウトバウンドへ渡します。実際の設定には完全なアウトバウンド、DNS、ログの各セクションも必要です。待受アドレスを0.0.0.0に変更すると、同一ネットワーク上の端末から接続できる可能性があるため、クライアントのLAN接続設定、OSのファイアウォール、アクセス制御を同時に確認してください。

よくある誤解と移行時の確認ポイント

最もよくある誤解は、関連するソフトウェアをすべて「V2Ray」と呼ぶことです。日常会話では通じやすいものの、トラブルシューティングでは情報が不足します。正確には、クライアント、コア、プロトコル、トランスポート、エラーが発生した段階を含めて説明します。たとえば「v2rayNGでVLESSノードの取り込みには成功したが、Xray-coreの起動後にトランスポートフィールドが無効と表示された」のように記録します。

2つ目の誤解は、同じサブスクリプションなら3つのクライアントで必ず同じ結果になると考えることです。実際には、サブスクリプションの解析、フィールドのマッピング、デフォルトのルーティングはそれぞれクライアントの実装に属します。コアが処理するのは、クライアントが最終的に生成した設定だけです。ノードが表示されない場合は、まずサブスクリプションを更新してグループフィルターを解除し、現在のクライアントバージョンがそのプロトコルを認識できるか確認してください。

移行時に残しておく確認記録

1. クライアント名とバージョンを記録します。例：v2rayN 7.11.3。「デスクトップ版」とだけ書くのは避けてください。
2. ログに表示されたコア名とバージョンを記録します。例：Xray-core 25.3.6、または対応するv2fly-coreのバージョン。
3. ノードのプロトコル、リモートポート、トランスポート方式、セキュリティ層、サーバー名を記録します。
4. ローカルのSOCKSポート、HTTPポート、システムプロキシモードを記録します。
5. サブスクリプション更新、コア起動、TCPの実接続レイテンシ、ウェブページへのアクセスを個別に確認し、異なる段階の問題を混同しないようにします。

まとめると、Project Vは歴史とエコシステムを理解する入口です。V2FlyとXrayは共通基盤を持ちながら独立して保守される2つのコア路線で、v2rayN・v2rayNG・v2flyNGは各プラットフォーム向けのクライアントです。選択時に、どの名称がより「正統」かを議論する必要はありません。クライアントがサブスクリプションを完全に解析できるか、コアがノードのフィールドをサポートするか、ルーティング規則が期待どおりに動くかを確認しましょう。