Project Vは初期のプロジェクト体系、V2FlyはV2Rayコアを引き継いで保守するコミュニティ系フォーク、Xrayは既存設定との互換性を保ちながらプロトコルとトランスポート機能を拡張した別系統のコアです。プロジェクト名・コア名・クライアント名を区別し、VMess、VLESS、XTLS Vision、REALITYなどの項目からクライアントを選べるようになります。
Project Vはプロジェクト体系であり、特定のクライアントを指すものではありません
Project Vは当初、ネットワークプロキシ機能を中心としたオープンソースツール群と仕様群を指す名称でした。V2Ray Coreはその中で接続、プロトコル、ルーティング、アウトバウンドを処理する中核プログラムです。日常会話ではProject V、V2Ray、GUI付きクライアントが一括りにされがちですが、それぞれ属する層は異なります。
コアは設定を受け取るとインバウンドとアウトバウンドの接続を確立します。リッスンアドレス、ポート、ユーザー識別子、トランスポート方式、TLSパラメータ、ルーティングルールを読み取り、トラフィックをどの出口から送るかを決めます。一方、クライアントはコアの外側でサブスクリプション更新、ノード一覧、遅延テスト、システムプロキシの切り替え、ログ確認を提供します。ボタンで実行できる操作はUIの実装に左右され、プロトコルで接続できるかは主に呼び出されるコアで決まります。
- プロジェクト層：Project Vは初期のエコシステムと発展の流れを表す名称で、インストール後に直接クリックして使うアプリ名ではありません。
- コア層：V2Ray Core、V2Fly Core、Xray Coreが設定の解析、プロトコル処理、ルーティング、接続確立を担います。
- クライアント層：v2rayN、v2rayNG、v2flyNGがサブスクリプション、ノード、ログ、システムプロキシなどの操作をUIとして提供します。
- サービス層：サブスクリプションがノードパラメータを提供し、クライアントが取り込んだ後に対応するコアへ渡して実行します。サブスクリプション自体はコアではありません。
V2FlyとXrayが2つの系統になった理由
プロジェクトがコミュニティ主体の保守段階に入ると、V2Flyは従来のV2Rayコード体系、設定構造、汎用プロキシ機能を引き継ぎました。VMess、VLESS、Shadowsocks、SOCKS、HTTPなど一般的なインバウンドやアウトバウンドを使う場合、V2Flyは現在も保守が続くコアの選択肢です。単なる旧名称の置き換えではなく、独自のリリースサイクルとドキュメント体系を持つコミュニティプロジェクトです。
XrayはV2Rayのコードを基盤に発展し、近いJSON設定構造を多く残しながら、VLESS、XTLS、Vision、REALITYなどの機能を継続的に拡張しています。歴史的なコード基盤が近いため基本フィールドを相互に解釈できる場面は多いものの、すべてのプロトコルパラメータ、トランスポート設定、ルーティング動作が完全に同じとは限りません。
| 比較項目 | V2Fly Core | Xray Core |
|---|---|---|
| 発展の関係 | V2Ray体系を引き継ぐコミュニティ保守系統 | V2Rayを基盤に発展した独立フォーク |
| 基本設定 | JSONでインバウンド、アウトバウンド、DNS、ルーティングを記述 | 近い構造を維持しつつ独自の拡張フィールドを追加 |
| 主なプロトコル | VMess、VLESS、SOCKS、HTTPなど | VMess、VLESSに加え、XTLS Vision、REALITYなどの組み合わせを重視 |
| 判断の目安 | サブスクリプションがV2Flyを明示的に要求する場合、または既存設定が同コアで安定稼働している場合 | ノードにXray拡張フィールドがある場合、またはXray Coreが明示的に要求されている場合 |
| 互換性の範囲 | Xray独自実装のパラメータはそのまま実行できません | 既存の多くの構造を読み込めますが、V2Flyと項目ごとの動作が一致するとは限りません |
結論：ノードのフィールドからコアを判断する
サブスクリプションにsecurity=reality、flow=xtls-rprx-vision、サーバー公開鍵、短いIDが含まれる場合は、まずXray Coreを選びます。VMess、WebSocket、TLSなど汎用フィールドだけなら、現在のクライアントとサーバーの説明に基づいて選択します。
バージョン番号も具体的な障害と合わせて判断します。新しいバージョンでは接続できるのに古いバージョンで「unsupported security」や「unknown field」が出る場合、設定に旧コアが実装していないフィールドが含まれている可能性があります。クライアントのUIだけを入れ替えず、実際の起動ログに記録されたCoreの名称とバージョンも確認してください。
v2rayN、v2rayNG、v2flyNGが呼び出すコア
この3つはいずれもクライアントの外殻であり、プロトコルそのものではありません。v2rayNはWindowsデスクトップ向けで、サブスクリプションのグループ、サーバー一覧、ルーティングルール、システムプロキシ、コアプロセスを管理します。v2rayNGとv2flyNGはAndroid端末向けで、最も大きな違いは標準のコア系統です。
以下のバージョンはUIとログの確認方法を説明するための例であり、対応上限を示すものではありません。検証記録ではv2rayN 7.12.5、v2rayNG 1.10.16、v2flyNG 1.10.13を使用しました。今後のバージョンでメニュー表記が変わる可能性はありますが、「クライアントが設定を管理し、コアが接続を実行する」という層構造は変わりません。
| クライアント | 対応プラットフォーム | コアとの関係 | 主な利用場面 |
|---|---|---|---|
| v2rayN | Windowsデスクトップクライアント | 通常はXray Coreを使用し、対応するパッケージではCoreの種類を管理可能 | サブスクリプションのグループ管理、一括テスト、システムプロキシ、細かなルーティングが必要な場合 |
| v2rayNG | Androidクライアント | Xray Core系統を使用 | ノードにVLESS、XTLS Vision、REALITYのパラメータが含まれる場合 |
| v2flyNG | Androidクライアント | V2Fly Core系統を使用 | サブスクリプションがV2Fly向けに明示的に調整されている場合、または検証済みのV2Fly設定を再利用したい場合 |
- 名前が似ていてもコアが同じとは限りません：v2rayNGとv2flyNGは似た操作感でも、拡張プロトコルフィールドを処理できるかどうかはそれぞれのコアで決まります。
- インポート成功は接続可能を意味しません：クライアントがリンクをノードカードに解析できても、コアが未対応のプロトコル、トランスポート、認証パラメータによって起動に失敗することがあります。
- 速度テスト成功はルーティングが正しいことを意味しません：遅延テストは特定の探測経路が応答したことを示すだけで、システムプロキシ、DNS、分流ルールは別途確認が必要です。
- ポート番号が同じでもノードが同じとは限りません：
10808、10809は通常ローカルのリッスンポートです。一方、リモートノードでよく使われる443はサーバー接続パラメータです。
クライアントで現在のコアを確認する
調査前に再現可能な記録を作ります。クライアントのバージョン、Core名、Coreバージョン、ノードのプロトコル、ローカルポート、最初に出たエラーログを記録してください。「接続できない」だけでは、サブスクリプションの無効化、コアの非互換、ポート競合、DNS異常、サーバーによる拒否を区別できません。
v2rayNのメニューではCoreの種類を直接確認できます。Androidではアプリ情報と実行ログを確認してください。コアを切り替える前に現在の接続を停止し、古いプロセスが127.0.0.1:10808を使い続けて新しいコアの起動時にリッスン失敗を起こさないようにします。
バージョンを記録する
クライアントの「概要」またはバージョン情報ページを開き、クライアントのバージョンを記録します。次に実行ログの冒頭からXray CoreまたはV2Fly Coreのバージョン行を探します。
種類を確認する
v2rayNで「設定」→「パラメータ設定」→「Coreの種類」を開き、対象ノードに対応するCoreが選択されていることを確認します。
プロトコルを照合する
ノードを編集し、アドレス、リモートポート、ユーザー識別子、トランスポート方式、TLS、SNI、Flowを確認します。REALITYノードでは公開鍵、短いID、フィンガープリントも照合してください。
コアを再起動する
設定を保存してサービスを停止し、コアを再起動します。ログに
address already in use、unknown field、認証失敗が出ていないことを確認してください。出口を検証する
システムプロキシを有効にして対象サイトへアクセスし、接続ログが想定したアウトバウンドタグに一致するか確認します。ルーティングで分流している場合は、ダイレクト接続とプロキシのルールが互いに上書きしていないかも確認してください。
メニューに切り替え可能なCoreの種類がない場合、別プラットフォームのコアファイルをコピーしてクライアントのディレクトリに上書きしないでください。v2rayNGとv2flyNGはそれぞれのコア系統に合わせて使用します。系統を変える必要がある場合は、先にサブスクリプションURLを保存または書き出し、対応するクライアントをインストールして再インポートしてください。
設定の互換性とプロトコル機能は別の話
V2Fly CoreとXray Coreはいずれも構造化設定で接続を記述するため、inbounds、outbounds、routing、dnsなどの一般的なフィールドは似て見えます。構造が似ているため基本設定は移行しやすいものの、互換性を決めるのは各プロトコルオブジェクト内部のフィールドの意味と、サーバーで実際に有効化されたトランスポートの組み合わせです。
VLESSを例にすると、プロトコル名だけでは不十分です。トランスポート層がTCP、WebSocket、gRPCのどれか、安全層がTLSかREALITYか、Flowがxtls-rprx-visionかを確認します。どちらもVLESSと表示される2つのノードでも、必要なコア機能がまったく異なる場合があります。
| サブスクリプションまたはログの手がかり | 確認すべき層 | 実行する操作 |
|---|---|---|
vmess:// |
VMessのユーザー情報とトランスポート方式 | ユーザー識別子、リモートポート、Host、Path、TLS設定を照合する |
vless:// |
VLESSの暗号化、安全層、Flow | VisionまたはREALITYのパラメータが含まれているかをさらに確認する |
security=reality |
Xrayの拡張機能 | Xray Coreを使用し、公開鍵、SNI、短いID、フィンガープリントを照合する |
unknown field |
設定構造またはコアのバージョン | インポート先とCoreの種類を確認し、不明なフィールドを直接削除しない |
address already in use |
ローカルのリッスンポート | 重複プロセスを終了し、10808と10809が使用中でないか確認する |
結論：まずハンドシェイクパラメータを判定し、その後で速度を確認する
コアがノードの安全層に対応していない場合、遅延の数値は選定材料になりません。まずログでプロトコルの初期化とハンドシェイクを完了させ、その後に実接続の遅延、パケットロス、ルーティング結果を比較します。
ルーティングルールにも実装上の違いがあります。ドメイン、IP、ポート、インバウンドタグによる基本的なマッチングは移行しやすい一方、複雑なDNS分流、ルールセットの読み込み方式、特定のアウトバウンドパラメータは移行先コアのドキュメントで再確認してください。移行後は少なくともプロキシ対象のドメイン、ダイレクト接続のドメイン、DNSクエリを1件ずつテストし、クライアントのステータスバーが「接続済み」になったかだけで判断しないでください。
よくある混同と具体的な対処法
最も多い誤りは、プロジェクト名を間違えることではなく、「クライアントへのインポート成功」を「コアが完全対応している」と捉えることです。サブスクリプションURLはパラメータを伝え、クライアントは解析・表示し、コアが実行します。どの層でもフィールドが失われれば、最終的に接続に失敗する可能性があります。
サブスクリプションにV2Rayと書かれている場合、どのクライアントを選ぶべき？
サブスクリプション名だけで判断しないでください。ノードの詳細を開き、まずプロトコルと安全層を確認します。REALITYまたはxtls-rprx-visionが含まれる場合、WindowsではXray Coreを搭載したv2rayN、Androidではv2rayNGを使用します。
VMessノードにはV2Flyが必須？
必須ではありません。V2Fly CoreとXray Coreはいずれも一般的なVMess設定を処理できます。トランスポート方式、TLS、Host、Path、ユーザー識別子、サーバー側の要件を確認し、現在のプラットフォームで正常に保守されているクライアントを選んでください。
v2rayNGをV2Fly Coreに直接変更できる？
アプリのディレクトリ内でコアを手作業で置き換えないでください。V2Fly系統が必要ならv2flyNGを使用し、サブスクリプションを再インポートしてノードのフィールドを確認します。実行ログで実際に起動したものがV2Fly Coreであることも確認してください。
Coreを切り替えた後にポートエラーが出る理由は？
まず古いCoreと重複して実行されているクライアントを停止し、ローカルの10808、10809がまだ使用中でないか確認します。リッスンポートを変更した場合は、ブラウザーまたはシステムプロキシの設定も同時に更新してください。
インポートは成功したのにREALITYノードへ接続できない？
Xray Coreを使用していることを確認し、サーバーアドレス、ポート、ユーザー識別子、SNI、公開鍵、短いID、フィンガープリント、xtls-rprx-visionを1項目ずつ照合します。いずれかのフィールドが欠けているだけでもハンドシェイクに失敗する可能性があります。
プラットフォームとノードのプロトコルに合わせて選ぶ
クライアント選びでプロジェクトの歴史を最初から詳しく調べる必要はありません。端末のプラットフォーム、サブスクリプションのプロトコルと拡張フィールド、デスクトップのルーティング・一括速度テストやAndroidでの常時接続の必要性という順に確認します。プロジェクトの沿革は違いを説明する材料であり、実際の選択基準はノードパラメータです。
- Windowsデスクトップ：v2rayNを選びます。サブスクリプションをインポートしたら「設定」→「パラメータ設定」→「Coreの種類」を確認し、REALITYとXTLS VisionのノードにはXray Coreを使用します。
- AndroidでXray機能が中心のサブスクリプション：v2rayNGを選び、VLESS、REALITY、SNI、公開鍵、短いID、Flowを重点的に確認します。
- Androidでサービス提供元がV2Fly対応を明示している場合：v2flyNGを選び、ノードのフィールドをサーバーの説明に合わせます。Xray固有のパラメータを流用しないでください。
- VMessまたは汎用VLESSのみ：どちらのコア系統も使える可能性があります。まず接続を確認済みの組み合わせを使い続け、ログを見て必要なら変更します。
- 手書きJSONから設定する場合：移行前に元の設定をバックアップし、インバウンド、アウトバウンド、DNS、ルーティングのフィールドを1つずつ確認します。「ファイルを読み込めた」だけで互換性が完了したと判断しないでください。