Project Vのエコシステムを解説：V2Fly・Xrayコアとv2rayN・v2rayNGの違い

この記事のポイント

Project Vはプロジェクト全体を指し、V2FlyとXrayはそれぞれ異なる開発方針で保守されているコアです。v2rayN、v2rayNG、v2flyNGは設定を操作するクライアントです。クライアント選びやノード要件の確認、コアの切り替えを検討している方に向けて、まず画面・コア・プロトコルの違いを整理し、サーバー側の設定と互換性を確認します。

Project V・V2Fly・Xray：まずプロジェクトの関係を整理

これらは同じソフトの別テーマではありません。Project VはもともとV2Rayを中心に構築されたネットワークプロキシのツール群です。日常会話で使われる「V2Ray」は、プロジェクト全体を指す場合と、接続処理を担うコアを指す場合があります。インストールやトラブル対処では、この2つの意味を区別する必要があります。

2020年ごろから、元のプロジェクトのコミュニティによる保守は徐々にV2Flyへ引き継がれました。V2FlyはV2Rayコアの開発を継続しています。一方、Xrayは2020年にV2Rayのコードを基盤として分岐し、独自の方針で開発が進められています。共通のルーツはありますが、リリース時期や機能、設定の対応状況は完全には一致しません。一方のドキュメントを、もう一方の最新仕様として扱わないようにしましょう。

Project V / V2Ray プロジェクト群
└─ V2Ray のコードを基盤とする
   ├─ V2Fly：V2Rayコアの保守を継続
   └─ Xray：2020年に分岐した独立コア

GUIクライアント層
├─ v2rayN：デスクトップ向け。バージョンとノードの種類に応じて対応コアを使用
├─ v2rayNG：Android向け。主にXrayコアを使用
└─ v2flyNG：Android向け。V2FlyのV2Rayコアを使用

上図はコードの系譜と役割を示したもので、3つのクライアントが同じプロジェクトから一括リリースされているという意味ではありません。クライアントとコアのバージョン番号も別々です。画面側のプログラムを更新しても、実際に動作中のコアが同時に更新されるとは限りません。ウィンドウのタイトルだけで判断せず、起動ログで実際のバージョンを確認してください。

クライアントとコア：設定がネットワーク接続になるまで

GUIクライアントは、サブスクリプションやノード一覧、設定編集、システムプロキシ、プロセス管理を担当します。コアはローカルでの待ち受け、プロトコルのハンドシェイク、DNS、ルーティングを処理します。「接続」を押すと、クライアントは通常、実行用の設定を生成してからコアを起動または呼び出します。AndroidではシステムのVPNサービスを通じて端末の通信を取り込みますが、これは接続先ノードのプロトコルとは別の仕組みです。

名称	主な役割	確認場所
v2rayN	デスクトップでのノード管理、サブスクリプション、システムプロキシ、コアの制御。対応範囲はバージョンによって異なる	「設定」→「パラメーター設定」と起動ログ
v2rayNG	Androidでのノード管理。主にXrayを呼び出し、システムVPNサービスを使って通信を取り込む	サイドメニューの「設定」「ログ」
v2flyNG	Androidでのノード管理。V2Flyコアを呼び出す	アプリの設定とコアの起動ログ
V2Fly / Xray	設定を解析し、接続を確立してDNSとルーティングルールを実行	実際に使用中の設定とコアのログ

v2rayNは複数のコアに対応するクライアントです。選択できるコアは、利用中のリリース版で確認してください。切り替える場合は、「設定」→「パラメーター設定」にあるCoreまたはコア関連の項目を確認します。項目名やサブページの名称はバージョンによって異なることがあります。実行ファイルの名前を別のコアのファイル名に変更しても、設定形式が変換されたり、プロトコルへの対応が追加されたりすることはありません。

クライアントが起動しない：実行環境、フォルダーのアクセス権、プログラムのログを確認します。問題がコアの段階まで到達していない可能性があります。
コアの起動後すぐに終了する：設定の解析結果、項目の対応状況、待ち受けポートの競合を確認します。
コアは動作するがノードがタイムアウトする：接続先アドレス、ポート、トランスポート、TLS、認証パラメーターを確認します。

VMess・VLESS・REALITY：プロトコル対応だけでは設定の互換性は判断できない

VMessとVLESSはプロキシプロトコルの名称であり、クライアント名ではありません。WebSocketやgRPCはトランスポート方式、TLSとREALITYは接続のセキュリティ層に関する設定です。ノードを利用できるかどうかは、プロトコル、トランスポート、セキュリティ層、各バージョンの組み合わせで決まります。「VLESSが一覧にある」というだけでは判断できません。

特にVLESSとREALITYは区別が必要です。VLESS自体に暗号化機能はないため、実際の構成では適切なセキュアトランスポートと組み合わせます。VLESS + REALITYのノードでは、この組み合わせに明確に対応したコアを使い、serverName、publicKey、shortId、さらにサーバー側が求めるflowなどのパラメーターをすべて保持してください。一般的なVLESS + TLSとして読み込んで、あとから設定を1つ追加すればよいというものではありません。

Xrayコア

推奨

サーバー側がVLESS + REALITYを明示している場合や、Xray固有の機能を必要とする場合は、対応するバージョンのXrayを選びましょう。推奨の根拠はノード設定との互換性であり、あらゆるネットワーク環境で速度を保証するものではありません。

適した用途：サーバー側でXrayが指定されている場合、REALITY設定が必要なノード

V2FlyのV2Rayコア

V2Flyのドキュメントに沿って導入・検証済みの設定に適しています。VMessなどの既存ノードは、トランスポート方式とバージョンの対応状況をまず確認してください。コアの名称が異なるという理由だけで、サーバー側を変更する必要はありません。

適した用途：V2Flyを導入済みで、設定とドキュメントの整合性を保ちたい環境

結論：パラメーターをすべて確認してからコアを選ぶ

サービス提供元に、プロトコル、トランスポート方式、セキュリティ層、必要なコアの最低バージョンを確認しましょう。4項目を把握してからクライアントに読み込むほうが、コアを何度も切り替えて不足項目を推測するより、問題を特定しやすくなります。

サブスクリプション・JSON・ルーティング：移行できる設定とできない設定

サブスクリプションはノード情報をまとめて取得するための入口であり、別のプロキシプロトコルではありません。内容は共有リンクの一覧の場合もあれば、完全な設定データの場合もあります。クライアントが読み込めるかどうかは、データ形式と解析機能によって決まります。Base64は単なるエンコード方式であり、異なるクライアント間の設定互換性を自動的に保証するものではありません。

v2rayNでは「サブスクリプショングループ」→「サブスクリプショングループの設定」で購読URLを確認します。v2rayNGではサイドメニューから「サブスクリプショングループの設定」を開きます。項目名はバージョンによって多少異なる場合があります。
更新後、ノードの編集画面を開き、アドレス、ポート、ユーザーID、トランスポートの種類、TLSパラメーターを1つずつ確認してください。ノード名が表示されたことだけで判断しないようにしましょう。
「解析できません」と表示された場合は、返された内容がサブスクリプションデータであることを確認します。ログインページ、有効期限の通知、Webページのエラーが返っている可能性もあります。サブスクリプションURLにはアクセス情報が含まれるため、フォーラムなどにそのまま貼り付けないでください。
完全なJSON設定から移行する場合は、移行先のコアと設定形式を先に確認します。サブスクリプションを正常に解析できても、独自のDNS、ルーティング、ローカルのインバウンド設定まで一緒に移行されるとは限りません。

一般的なV2Ray / XrayのJSON設定では、inboundsがローカルの入口、outboundsが接続先への出口を定義し、routing.rulesが条件に一致した通信の出口を決めます。以下はルーティング部分のみの例で、local-socksからの通信をproxyアウトバウンドへ送る設定です。単体で起動できる完全な設定ではありません。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "proxy"
      }
    ]
  }
}

この設定を使うには、tagがlocal-socksのインバウンドと、tagがproxyのアウトバウンドが必要です。タグの綴りが違うと、意図したルーティングになりません。項目やルーティングルールの詳細はルーティング設定リファレンスを参照してください。異なる設定方式のコアに切り替える場合、このJSONをそのままコピーしないでください。

システムプロキシ・TUN・ポート：接続経路の確認方法

デスクトップのシステムプロキシは、システムプロキシ設定に従うアプリの通信をローカルの待ち受けポートへ送る仕組みです。TUNは仮想ネットワークインターフェースを通じて通信を取り込み、クライアントと対応するコアの両方が必要です。どちらもVMessやVLESSとは別の機能で、サブスクリプションを読み込めば必ず自動で有効になるわけではありません。

以下の3つのポートは接続経路を説明するための例であり、すべてのバージョンの既定値を示すものではありません。実際の設定でローカルの待ち受けポートを確認し、アプリのプロキシ設定と接続先ノードのポートを照合してください。接続先の443をブラウザーのローカルプロキシポート欄に入力しないよう注意してください。

10808

例：ローカルSOCKSインバウンドポート

10809

例：独立したHTTPインバウンドポート

443

例：接続先TLSサーバーのポート

ローカルの通信経路：アプリ → 127.0.0.1:10808のSOCKS待ち受け → コア。クライアントが混合インバウンドを使う場合、HTTPとSOCKSでポートを共有することがあります。現在の設定を確認してください。
接続先までの経路：コア → ノードのアドレスと接続先ポート → 目的のWebサイト。ローカルの待ち受けポートを変更しても、サーバー側の待ち受けポートは変わりません。
Androidの通信経路：アプリの通信 → システムVPNサービス → クライアントのコア。VPNアイコンが表示されても、確認できるのはローカルでの通信取り込みが確立したことだけです。ノードに接続できるかどうかは、アイコンだけでは判断できません。
TUNのトラブル対処：仮想インターフェース、権限、DNS、ルーティングによる通信の取り込みを確認してから、ノードとのハンドシェイクを調べます。TUNのスイッチを、すべてのコアで共通するJSON項目のように記述しないでください。

クライアントの選び方と切り替え：よくある質問

選ぶ順番は、プラットフォーム、ノードのパラメーター、コアの対応状況、最後に画面の好みです。デスクトップでは、使用中のv2rayNが対応するコアを確認してください。Androidではノードの要件に応じてv2rayNGまたはv2flyNGを選びます。移行前にサブスクリプショングループと独自ルールをバックアップし、テストでは一度に1項目だけ変更しましょう。

v2rayNをインストールした後、別のV2Rayクライアントも必要ですか？

通常は必要ありません。インストール済みのv2rayNを起動してノードを選び、ログに表示される実際のコア名とバージョンを確認してください。コアファイルが見つからないというメッセージが出た場合は、使用中のリリース版の説明に従って必要なコンポーネントを追加します。同じファイル不足を解決するために、複数のクライアントを重複してインストールする必要はありません。

v2rayNGとv2flyNGは名前が違うだけですか？

いいえ。それぞれXrayとV2Flyのコアを使用しており、対応機能はバージョンによって異なります。REALITYノードを使う場合は、まずXrayの対応状況を確認してください。既存のV2Fly設定は、対応するコアで先に検証しましょう。アプリアイコンや名前の似ている度合いだけで選ばないでください。

同じサブスクリプションがデスクトップでは使えるのに、Androidではタイムアウトするのはなぜですか？

まず両方の端末でノードの編集画面を比較し、特にトランスポートの種類、サーバー名、セキュリティ層のパラメーターを確認します。次に、それぞれのログでコアのバージョンを確認してください。設定が同じ場合は、AndroidのVPN権限、アプリごとの設定、端末の時刻、現在のネットワークを調べます。すぐにサブスクリプションの問題だと決めつけないようにしましょう。

コアを切り替えた後、すべてのルールを書き直す必要がありますか？

まずクライアントが管理するルールと手書きのJSONを区別してください。クライアント管理のルールはクライアントが再生成する場合がありますが、実際の動作確認は必要です。手書きのJSONは移行先コアのドキュメントに沿って項目ごとに検証します。まずノード1つと明確なルーティングルール1つでテストしてから複雑な振り分けを戻すと、複数の問題が同時に発生するのを避けやすくなります。

最終的に記録しておきたいのは、クライアントのバージョン、ログに表示されたコアのバージョン、機密情報を伏せたノード設定の3点です。問題を報告する際にこの3点と関連するエラー行を添えると、「V2Rayに接続できない」とだけ伝えるより、画面、設定、プロトコル、ネットワークのどこに原因があるかを判断しやすくなります。