· エコシステム · 約9分

Project Vのオープンソースエコシステム解説:V2Fly・Xrayと各クライアントの関係

Project Vの成り立ちとV2Fly・Xrayの違いを振り返り、v2rayN、v2rayNG、v2flyNGがそれぞれ採用するコアと、用途に応じた選び方を解説します。

この記事の概要

デスクトップではまずv2rayN、Androidではノードの要件に応じてv2rayNGまたはv2flyNGを選びましょう。Project Vはエコシステムを理解する出発点です。V2FlyとXrayはそれぞれ異なるコアプロジェクトで、クライアントはサブスクリプション、画面、設定を管理します。この記事では「プロジェクトの成り立ち → コアの機能 → クライアントの対応OS → ノードの設定」の順に整理し、初めて使う方のソフト選びと、利用中のサブスクリプションに必要なコアの判断をサポートします。

1. Project V、V2Ray、V2Flyとは

Project Vは、組み合わせて使えるネットワークプロキシツール群として始まりました。その中で特によく知られているのがV2Rayです。受信、ルーティング、外部への接続などをモジュールに分け、設定に応じて通信ごとに異なる経路を選べます。一方、日常会話では「V2Ray」がプロキシツール全体を指すことも多く、クライアント、コア、プロトコルが混同されやすい理由になっています。

V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、そのコアは一般にV2Ray Coreと呼ばれます。V2Flyは新しいノードプロトコルでも、Androidアプリの画面名でもありません。コアは設定を実行し、VMessなどのプロトコルは接続方式を定めます。両者は異なるレイヤーのものです。

そのため、「サブスクリプションにV2Rayノードがある」だけでは情報が足りません。互換性を左右するのは、ノードがVMessとVLESSのどちらを使うか、どのトランスポートを使うか、TLSやREALITYが有効か、サーバー側で追加パラメーターが必要か、といった点です。ソフトを選ぶ前にこれらを確認すると、製品名だけで判断するより確実です。

2. V2FlyとXray:共通のルーツ、それぞれの開発方針

XrayはV2Rayのコードを基盤として分岐し、その後独自の開発路線を歩んでいます。共通する概念や設定方法もありますが、すべての項目、トランスポート、新機能に互換性があるわけではありません。あるコアで起動できる設定でも、別のコアでそのまま動くとは限りません。

比較項目V2Fly / V2Ray CoreXray Core
プロジェクトの関係コミュニティが開発を継続するV2Rayコア実装V2Rayから分岐した独立コアプロジェクト
主な用途既存のV2Fly設定やVMessなどとの互換性が必要な場合VLESS、REALITY、Visionなどを組み合わせて使う場合
設定の互換性V2Flyの設定ドキュメントとバージョン情報を確認Xrayの設定ドキュメントとバージョン情報を確認
アップデート時の判断材料クライアントの対応範囲とノードで必要な機能クライアントの対応範囲とノードで必要な機能

VMessとVLESSはプロキシプロトコル、WebSocketはトランスポート、TLSは通信を保護する仕組みです。REALITYはXrayエコシステムのセキュアなトランスポート方式で、VisionはXrayのフロー制御機能に関係します。これらは組み合わせて使えますが、同じレイヤーの選択肢ではありません。「VLESS + TCP + REALITY」は異なるレイヤーの設定を組み合わせたもので、3つの独立したノードを意味するものではありません。

3. 3つのクライアントとコアの対応関係

Windows、macOS、Linuxのデスクトップではv2rayNから始めるとよいでしょう。Androidではv2rayNGとv2flyNGを使い分けます。クライアントとコアのバージョンは別々に確認してください。画面が更新されても、実行中のコアまで更新されたとは限りません。また、インストール先にコアのファイルがあっても、そのノードで実際に使われているとは限りません。

クライアント対応OSコアとの関係まず確認する点
v2rayNWindows / macOS / Linux複数のコアを管理可能。Xrayがよく使われます。V2Flyに対応するかは、バージョンと設定画面を確認してください。ノードが使用するコア、起動ログ、コアファイルの有無
v2rayNGAndroidXrayコアを採用アプリとコアのバージョン、ノードパラメーターの対応状況
v2flyNGAndroidV2Flyコアを採用ノードが現在のV2Flyコアの機能範囲に対応しているか

v2rayNは設定を生成してコアを起動するクライアントであり、「v2rayNはXrayそのもの」とは言えません。標準の選択肢、利用できるコア、メニュー構成はバージョンによって異なります。確認する際は、まず「ヘルプ」→「バージョン情報」でクライアント情報を見てから、メイン画面の起動ログで実際に起動したコア名とバージョンを確認してください。使用中のビルドでバージョン情報の場所が異なる場合は、実際の画面に従ってください。

  1. クライアントを記録:「最新版」だけで済ませず、v2rayN、v2rayNG、v2flyNGの正確なバージョンを書き留めます。
  2. コアを記録:コアの起動ログからバージョンを確認します。クライアントのバージョンをコアの欄に記入しないでください。
  3. ノードの設定を記録:VLESS、TCP、REALITY、Visionなどを個別に確認し、ノードのメモ名だけで済ませないようにします。
  4. 起動結果を記録:「設定の解析失敗」「ローカルでの待ち受け成功」「リモートとのハンドシェイク成功」を区別します。それぞれ意味が異なります。

AndroidクライアントのVPN許可は、ローカルに仮想ネットワークインターフェースを作り、通信をプロキシ処理に通すためのものです。サーバー側のプロトコルが変わるわけではありません。デスクトップのシステムプロキシやTUNも通信を取り込む方式であり、ノードプロトコルとの互換性確認に代わるものではありません。

4. 名前の評判ではなく、ノードの要件でコアを選ぶ

まず対応OSを確認し、サブスクリプションの説明やノード編集画面を見てください。以下の推奨には明確な前提があります。ノードがREALITYまたはVisionを要求している場合です。サーバーから既存のV2Fly設定が提供されているなら、先に別のコアへ移行して問題を調べるのではなく、まず設定の意図を保って使いましょう。

Xrayコアを使う場合

おすすめ

ノードでVLESS + REALITYまたはVisionが明示されている場合は、その組み合わせに対応するXrayのバージョンを選びます。デスクトップではv2rayNで実際のコアを確認し、Androidではv2rayNGを選んで必要なパラメーターを設定できるか確認してください。

おすすめのケース:REALITYまたはVision対応ノードを使い、必要な機能を利用したい場合

V2Flyコアを使う場合

使用可能なV2Fly設定がすでにある場合や、サーバーがV2Flyを前提に構成されている場合は、まず対応するコアをそのまま使いましょう。Androidではv2flyNGを利用できます。デスクトップでは、使用中のv2rayNビルドが必要な機能に対応するか確認してください。

おすすめのケース:既存のV2Fly設定を維持し、設定の一貫性を重視する場合

結論:サブスクリプションにREALITYとある場合は、まずXrayの対応状況を確認

ノードの編集画面で、公開鍵、サーバー名、Short ID、フロー制御など、サーバー側で指定された項目を確認してから、実際に起動しているコアをチェックします。プロトコルの不一致を解消しようとして、VMessに変更したりセキュリティ検証を無効にしたりしないでください。

通常のVMessノードだけを使う場合は、どちらの路線でも要件を満たす可能性があります。それでも、実際のトランスポートとコアのバージョンを確認してください。同じ端末、同じノード、近い時間帯でウェブページの読み込みと接続の安定性を比べ、一度に変更する項目は1つにします。地域やノードが異なる速度を比べても、コアの優劣を判断することはできません。

5. サブスクリプションの追加から通信の振り分けまで:設定の流れ

サブスクリプションはコア設定ファイルと同じものではありません。クライアントがサブスクリプションの内容を取得し、ノード情報として解析したうえで、ローカルポート、DNS、ルーティングルールを組み合わせて実行用の設定を生成します。サブスクリプションを更新できても、取得や解析の一部が成功しただけで、すべてのノードに接続できるとは限りません。

  1. サブスクリプションを追加:v2rayNの「サブスクリプショングループ」→「サブスクリプショングループの設定」でURLを追加し、「サブスクリプショングループ」メニューから更新します。メニュー名はバージョンによって多少異なる場合があります。
  2. ノードを確認:サーバーアドレス、リモートポート、ユーザーID、トランスポート、セキュリティ設定を確認します。REALITYノードでは、サーバーから指定された関連パラメーターも確認してください。
  3. コアを起動:リモートへの接続を調べる前に、設定の解析エラー、ファイル不足、ポートの競合がログに出ていないか確認します。
  4. アプリの通信を取り込む:システムプロキシを使う場合は、アプリがシステムプロキシに従うか確認します。TUNを使う場合は、権限、ルーティング、DNSも別途確認してください。
  5. 振り分けを確認:直接接続する宛先とプロキシを使う宛先にそれぞれアクセスし、ステータスバーのアイコンだけでなく接続ログでも出力先を確認します。

以下の2つのポートは関係を説明するための例で、すべての環境の初期値を示すものではありません。ローカルのクライアントが127.0.0.1:10808で待ち受け、リモートノードが443で待ち受けるとします。アプリはまずローカルに接続し、その後コアがリモートに接続します。2つのポートを同じ値にする必要はありません。例に合わせてサーバー側の設定を変更しないでください。

10808
ローカルプロキシのポート例(実際の値はクライアントの設定を確認)
443
リモートサーバーのポート例(実際の値はノード情報を確認)

ログにローカルの待ち受けアドレスが使用中と表示された場合は、端末上のプロセスかローカルポートを確認してください。リモート接続のタイムアウトが表示された場合は、リモートアドレス、ネットワークの到達性、サーバーの状態を確認します。ローカルポートを変更してもサーバーとのハンドシェイク設定の誤りは解決しません。また、コアを変更してもサーバー名の誤りは自動で修正されません。

6. クライアント選びと移行でよくある質問

v2rayNにノードをインポートできるのに、起動時に未対応の項目が表示されるのはなぜ?

インポート時はクライアントが解析し、起動時はコアが設定を実行します。まず起動ログでコア名とバージョンを確認し、エラーに出ている項目をもとにコアの選択を見直してください。ノードがREALITYやVisionを必要とする場合は、クライアントの画面を更新しただけでなく、対応するXrayを実際に使用しているか確認します。

Androidにv2flyNGをインストール済みです。REALITYノードはどうすればよいですか?

まず現在使える設定を残し、ノードの要件に対応したv2rayNGを使用してください。再インポートしたら、サーバー名、公開鍵、Short ID、フロー制御を1つずつ確認します。切り替えてテストする前に、元のクライアントのVPN接続を切断してください。通信の取り合いによる問題をプロトコルの不具合と誤認するのを防げます。

コアを切り替えた後も、元のルーティングルールをそのまま使えますか?

まず設定をバックアップし、ルールの形式、ルール用リソースファイル、DNS設定が移行先のコアで使えるか確認します。実行設定を丸ごとコピーするより、クライアントの画面でルールを作り直すか変換するほうが安全です。切り替え後は、まず明確なドメインルールを1つ使って出力先を確認し、その後で複雑なルールセットに戻してください。

ノードの遅延に数値が表示されます。コアの選択が正しいということですか?

必ずしもそうではありません。TCP遅延テストで分かるのは、リモートポートへの到達性の一部だけです。プロキシ認証やセキュアなハンドシェイクの成功までは確認できません。クライアントの実接続テストを実行し、ハンドシェイクのログを確認したうえで、ブラウザーから対象ページを開けるか試してください。

移行時は、動作確認済みのノードと設定を1つ残し、コア、ノードのパラメーター、ルーティングのうち、一度に変更する項目は1つにします。サポートを求める際は、クライアントとコアのバージョン、ノードのプロトコル構成、個人情報を伏せたエラーログを共有してください。サブスクリプションURL、ユーザーID、機密パラメーターは公開しないでください。

v2rayN をダウンロード · OSを選択