Project V オープンソースエコシステムの全体像：V2Fly、Xray と v2rayN/v2rayNG の関係を整理

まず関係図を見る：プロジェクト、コア、クライアントの3層構造

V2Ray エコシステムを理解する際に起こりやすい誤解は、Project V、V2Ray、V2Fly、Xray とクライアント名を同じ種類のものとして捉えることです。実際には、それぞれ異なる階層に属します。Project V はこの技術エコシステムの歴史的な名称と上位概念、V2Fly と Xray は進化を続ける2つのコア系列、v2rayN・v2rayNG・v2flyNG はユーザー操作向けのクライアントです。

Project V と V2Ray：ツール名から設定言語へ

Project V は当初、ネットワークプロキシツール、プロトコル、組み合わせ可能な設定を中心に発展しました。その中で V2Ray が最も広く知られた中核実装となったため、長い間「V2Ray」はプログラム、設定形式、ノードの種類、さらにはツールエコシステム全体を指す言葉として使われてきました。現在も「V2Ray ノード」「V2Ray 設定」「V2Ray クライアント」といった表現を見かけますが、必ずしも同じソフトウェアパッケージを意味するとは限りません。

エンジニアリングの観点では、V2Ray の価値は単一のプロトコルだけでなく、組み合わせ可能なデータフローモデルにあります。接続は inbounds から入り、ルーティング判定を経て、outbounds から送出されます。DNS、ポリシー、ログ、トランスポート層がそれぞれ補助機能を提供します。VMess はこのエコシステム初期の重要なプロトコルですが、V2Ray の設定が VMess と同義ではなく、クライアントに「V2Ray 設定」と表示されていても vmess:// リンクしか読み込めないとは限りません。

{
  "inbounds": [
    {
      "tag": "local",
      "protocol": "socks",
      "port": 10808
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {}
    }
  ],
  "routing": {
    "rules": []
  }
}

上の構造は、コアが動作する基本的な境界を示しています。ローカルアプリがトラフィックをインバウンドへ渡し、ルーティングモジュールがドメイン、アドレス、ポートに基づいてアウトバウンドを選択し、アウトバウンドがノードのプロトコルに従って接続を確立します。GUI クライアントは、ノードの入力情報、サブスクリプション、ユーザー設定を同様の実行設定へ変換してからコアを起動します。ユーザーに見えるのはスイッチや一覧ですが、実際に接続を実行するのはバックグラウンドのコアです。

V2Fly と Xray：共通の基盤から分かれた2つのコア系列

プロジェクトの進化に伴い、V2Ray のコミュニティメンテナンスは V2Fly 系列へ発展し、Xray は近いコードと設定基盤から別のコア系列として成長しました。両者はインバウンド、アウトバウンド、ルーティング、DNS、VMess、VLESS、多様なトランスポート方式など、多くの歴史的概念を共有しています。そのため基本設定が似て見えることはよくありますが、「似ている」ことは、すべてのフィールド、プロトコル拡張、動作が完全に一致することを意味しません。

V2Fly 系列

V2Fly は V2Ray のモジュール構造を受け継いでおり、標準的な V2Ray 設定モデル、VMess 接続、一般的なルーティング機能に依存する環境に適しています。V2Fly は独立して保守されるプロキシコアであり、GUI クライアントではありません。デスクトップや Android の画面は、コアの起動、設定の生成、ログの読み取りを通じて、初めて実際の接続を完了できます。

Xray 系列

Xray は近いモデルを基盤に、プロトコルとトランスポートの機能を継続的に拡張しています。実際の選定で最も分かりやすい分岐点は、通常 REALITY です。ノードに security=reality、公開鍵、ショートID、サーバー名などのパラメータが明記されている場合は、対応機能を備えた Xray コアを使用してください。対応実装のないコアへリンクを読み込むだけでは、起動できない、フィールドが無視される、接続ハンドシェイクに失敗するといった問題が起きる可能性があります。

2つの系列は単純な「新しい版と古い版」という関係ではありません。それぞれが独自にバージョンを管理し、問題を修正し、機能を調整しています。バージョン番号もプロジェクトをまたいで直接比較できません。たとえば、ある Xray のバージョン番号が大きくても、それが特定の V2Fly バージョンの直接的なアップグレード版という意味ではありません。信頼できる判断材料は、ノードが必要とするプロトコル機能、現在のクライアントに組み込まれているコア、そしてパラメータが正しく読み込まれたことを示す実行ログです。

クライアントとコア：画面層と実行層の連携

v2rayN、v2rayNG、v2flyNG はいずれもクライアントと呼べますが、プロキシプロトコルそのものではありません。クライアントが主に解決するのは設定管理です。共有リンクの受け取り、サブスクリプションURLの保存、ノード一覧の表示、実行設定の生成、システムプロキシの切り替え、ログの確認、必要に応じたコアの起動・停止を担います。

コアが担うのはネットワークの実行処理です。ローカルポートの待ち受け、宛先アドレスの解決、ルーティングルールの適用、リモート接続の確立、トランスポートとセキュリティパラメータの処理を行います。2つの層を分けて考えると、よくある現象も説明しやすくなります。

• リンクは正常に読み込めるのにノードへ接続できない：クライアントは共有形式を認識できても、コアの接続段階でプロトコルパラメータ、ネットワーク経路、サーバーの状態が原因で失敗することがあります。
• サブスクリプションの更新は成功したのに一覧のノードが使えない：サブスクリプションは設定の一覧にすぎず、更新に成功しても、一覧内のすべてのリモート接続先が利用可能とは限りません。
• 同じノードでもクライアントを変えると動作が異なる：両者で異なるコア系列、コアバージョン、またはデフォルトの DNS やルーティング設定を使っている可能性があります。
• コアのログは正常なのにブラウザがプロキシを経由しない：接続の実行層は起動していますが、システムプロキシまたはアプリのプロキシ入口がクライアントの待ち受けポートを向いていません。

共有リンクの解析は通常クライアントが行います。たとえば vmess:// や vless:// には、ノードに必要なプロトコル、アドレス、ポート、トランスポート情報が含まれます。サブスクリプションURLは、更新可能なノード一覧を返します。クライアントはこれらの外部形式を内部設定へ変換しますが、サブスクリプションのグループや画面上のメモ名を自動管理するのはコアではありません。

v2rayN、v2rayNG、v2flyNG：対応関係と用途

v2rayN：デスクトップでの設定管理とシステムプロキシ制御

v2rayN はデスクトップ環境向けで、サーバー一覧、サブスクリプショングループ、ルーティングモード、システムプロキシ、コアプロセスを一元管理することが主な役割です。VMess、VLESS など一般的なノードを扱う場合、通常は Xray 系列を中心に接続機能を提供します。REALITY が必要なノードでは、現在の v2rayN のバージョンと、実際に呼び出される Xray コアのバージョンも確認してください。

デスクトップ版の利点は状態を確認しやすいことです。ローカルの待ち受けポート、システムプロキシモード、リアルタイムログ、ルーティング結果を確認できます。Windows ユーザーは通常デスクトップ版をそのまま使用します。macOS と Linux では、ダウンロードページのプラットフォーム別ビルドから対応ファイルを選び、プロセッサーのアーキテクチャが一致することを確認してください。異なるプラットフォームのアーカイブや実行ファイルは共用できません。

v2rayNG：Android 向け Xray 系列

v2rayNG は Android クライアントで、Xray コアを使って接続を処理します。VMess、VLESS、REALITY など Xray の機能を必要とするノードに適しています。QRコードのスキャン、クリップボードからのインポート、サブスクリプショングループ、ルーティングルール、アプリ別プロキシなど、モバイル向けの操作機能を備えています。REALITY と明記された VLESS ノードを受け取った場合、v2rayNG は通常、3つのクライアントの中で最も直接的な Android の選択肢です。

モバイル端末で「テストでは遅延が表示されるのにアプリへ接続できない」場合、ノードのテストを繰り返すだけでは不十分です。現在の設定が有効になっているか、システムの接続許可が反映されているか、アプリ別リストから対象アプリが除外されていないか、ルーティングルールが対象ドメインを誤ったアウトバウンドへ送っていないかも確認してください。

v2flyNG：Android 向け V2Fly 系列

v2flyNG は V2Fly コアを使いたい Android 環境向けです。画面上の用途は v2rayNG と近いものの、基盤となるコア系列が異なります。既存のノードや設定が V2Fly の標準機能を前提としている場合、または V2Fly 環境での接続動作を再現したい場合は、v2flyNG の方がコアを統一しやすくなります。

v2flyNG を選ぶ際は、「リンクを読み込めた」ことからすべての拡張機能が使えると判断しないでください。特に設定が Xray 環境から提供されたものなら、プロトコル、セキュリティ方式、トランスポートのフィールドを一つずつ確認します。コアが対応していない拡張に遭遇した場合は、アドレス、ポート、ローカルプロキシのスイッチを何度も変更するのではなく、適合するコア系列へ切り替えるのが正しい対処です。

プロトコルからコアを選ぶ：VMess、VLESS、REALITY

クライアントを選ぶ最も実用的な方法は、ソフトウェア名を先に比べるのではなく、まずノードのパラメータを確認することです。プロトコル、トランスポート方式、セキュリティ層によって、接続に必要な機能が決まります。

VMess は Project V エコシステムで長い歴史を持つプロトコルです。ノード情報には通常、ユーザーID、アドレス、ポート、トランスポート種別、TLS 設定が含まれます。VLESS はより簡潔なプロトコル設計ですが、VLESS が自動的に REALITY を意味するわけではありません。リンクや設定で REALITY のセキュリティ方式が明示されている場合に限り、公開鍵、ショートID、フィンガープリント、サーバー名を確認します。

WebSocket、gRPC、TCP などはトランスポート層の選択であり、TLS や REALITY は接続のセキュリティとハンドシェイク方式に関わります。同じプロトコルでもトランスポートパラメータが異なれば、一方のノードは使えても、もう一方は失敗することがあります。たとえばサーバーが WebSocket 用に設定されているのに、クライアントが TCP を選択すると、アドレスとポートが完全に正しくても想定した接続は確立できません。

設定の互換性と移行：再利用できるもの、できないもの

V2Fly と Xray は多くの設定概念を共有しているため、単純なインバウンド、アウトバウンド、DNS、ルーティングルールは移行できる場合があります。ただし移行前に、設定を「共通構造」と「コア固有の拡張」に分けて確認してください。共通構造にはタグ、ポート、ドメインのマッチング、アドレス範囲、基本的なプロトコルパラメータが含まれます。コア固有の拡張には、特定のセキュリティ方式、フロー制御オプション、トランスポートフィールドなどが含まれる場合があります。

1. まず設定の出所を確認します。どのクライアントまたはサーバー環境で生成された設定かを確認し、元々使われていたコア系列を記録します。
2. 次にプロトコルフィールドを確認します。protocol、network、security と、ハンドシェイクに関係するパラメータを特定します。
3. ルーティングを個別に確認します。ドメインルール、アドレスルール、アウトバウンドのタグが対応している必要があります。移行時にノード部分だけをコピーしてはいけません。
4. ログで検証します。まず設定を起動できることを確認し、次にドメイン解決、ルーティングの適用、リモートハンドシェイクを確認します。すべての失敗をノードの問題と決めつけないようにしましょう。

共有リンクの移行は完全な JSON より簡単に見えますが、クライアントによってメモ、グループ、サブスクリプション識別子、追加フィールドの扱いが異なる場合があります。単一のリンクをコピーしても、通常はノード自体しか移行されず、元のクライアントのグローバル DNS、LAN 除外ルール、システムプロキシ設定、アプリ別リストまでは引き継がれません。そのため、「同じリンク」でも両端の実行環境が完全に同じになるとは限りません。

実際の選び方：ノードの要件をクライアントへ反映する

実行しやすい選択手順だけを知りたい場合は、次の4ステップで進めてください。

ステップ1：デバイスのプラットフォームを確認

デスクトップ環境ではまず v2rayN を確認し、Android では v2rayNG と v2flyNG から選びます。デスクトップ用パッケージを Android に入れたり、モバイル用インストールファイルをデスクトップのコアとして使ったりしないでください。

ステップ2：ノードのプロトコルを確認

共有リンクの先頭が vmess:// か vless:// かを確認します。サブスクリプションから取得した場合は、まずクライアントで更新し、具体的なノードパラメータを確認してください。プロトコル名は最初の確認項目にすぎず、トランスポート方式とセキュリティ方式も続けて確認する必要があります。

ステップ3：コアが必要とする機能を特定

REALITY など Xray 系列の機能が必要な場合、デスクトップでは正しく設定した v2rayN、Android では v2rayNG を使います。設定が明確に V2Fly を基盤とし、Xray の拡張に依存しない場合は、Android で v2flyNG を選ぶと、コア間の移行による変数を減らせます。

ステップ4：バージョンとログを確認できる状態にする

クライアントのバージョンとコアのバージョンは別の情報です。クライアント画面が正常に開いても、コアのバージョンが新しいノードパラメータに対応しているとは限りません。接続に失敗したら、まずログを開き、設定解析エラー、DNS エラー、接続タイムアウト、ハンドシェイク失敗、ルーティング設定ミスを切り分けてから、コアの更新、ルールの調整、ノードの変更を判断してください。

デスクトップと Android の両方を使う場合は、クライアント名だけでなく、サブスクリプションの出所、ノードのプロトコル、必要なコアを統一して記録しておくと便利です。端末を切り替える際に、そのノードを v2rayNG と v2flyNG のどちらへ入れるべきかすぐ判断でき、Xray 専用設定を汎用的な V2Ray 設定と誤認することも防げます。

よくある質問