Project Vはプロジェクト全体のエコシステム、V2FlyとXrayは異なる開発・保守方針を持つカーネルです。v2rayN、v2rayNG、v2flyNGは設定を管理し、カーネルを起動するGUIクライアントです。選ぶ際は、ノードが必要とするプロトコル、トランスポート、安全機能を確認し、クライアントが実際に使用するカーネルを調べましょう。複数端末でサブスクリプションを使う方、既存設定を移行する方、V2RayとXrayの違いが分かりにくい方に向けて解説します。
1. Project V・V2Ray・V2Fly：名前と役割を整理
Project Vは当初、V2Rayを中心に展開し、プロキシ通信を組み合わせ可能なモジュールとして設計しました。インバウンドが接続を受け付け、ルーティングが宛先を決め、アウトバウンドが接続先へつなぎます。VMessはこのエコシステムで使われるプロキシプロトコルの一つであり、プロジェクト全体を指す名称ではありません。「V2Rayを入れたらVMessしか使えない」と考えると、その後のプロトコル選びの幅を狭めてしまいます。
元プロジェクトの保守体制が変わった後、V2FlyコミュニティがV2Rayコアと関連ドキュメントの保守を引き継ぎました。現在「V2Fly」は、一般にコミュニティやその保守方針を指し、「V2Ray Core」は実際に動作するプロキシカーネルを指します。どちらも順番にインストールするGUIソフトではなく、V2Flyをサブスクリプション提供元と捉えるのも誤りです。
- Project V：エコシステムとプロジェクトの経緯
- プロジェクトの成り立ちやモジュール設計、周辺ツールを話題にするときに使う名称です。独立したノードプロトコルではありません。
- V2Ray Core：設定を実行するカーネル
- インバウンド、アウトバウンド、DNS、ルーティングを処理します。V2Flyコミュニティが保守するコアも、この名称を引き継いでいます。
- Xray Core：独自に発展したフォーク
- V2Rayをベースに開発が始まり、その後、独自のリリースサイクルと機能方針を持つようになりました。設定の基本構造には共通点がありますが、すべての項目に互換性があるとは限りません。
- GUIクライアント：設定と実行の入り口
- ノード、サブスクリプション、システムプロキシ、ログを管理し、ユーザーの選択をカーネル用の設定に変換します。画面に項目が表示されていても、使用中のカーネルが対応しているとは限りません。
そのため、トラブル対処では「どのクライアントを使い、どのカーネルを呼び出し、どのプロトコル構成で接続しているか」をまとめて確認しましょう。「V2Rayにつながらない」だけでは、サブスクリプションの読み込み、設定生成、接続先とのハンドシェイクのどこに問題があるのか判断できません。
2. V2FlyとXray：共通の基盤があっても相互互換とは限らない
Xrayは2020年末、V2Rayのコードをベースに分岐し、その後独自に開発が進みました。どちらもプロキシ、ルーティング、DNSなどの基本機能を備え、一般的な接続方式を複数扱えます。違いは単純に「新しいか古いか」ではなく、各バージョンがどのプロトコル、トランスポート、設定形式、安全機能に対応しているかです。
| 確認項目 | V2Fly系 | Xray系 |
|---|---|---|
| 一般的な基本機能 | VMess、SOCKS、HTTPなどに対応。組み合わせはバージョンごとのドキュメントを確認 | 一般的なプロキシ機能に対応し、プロトコルやトランスポートの実装を独自に拡張 |
| VLESSの確認方法 | 名称だけで互換性を判断せず、使用するバージョンと設定全体を確認 | VLESSノードでよく使われる機能。flow、トランスポート、安全機能も確認が必要 |
| REALITYとVision | Xray用の該当設定を、そのままV2Flyに渡すことはできない | VLESS + REALITY、XTLS Visionでよく使われる実装方式。対応バージョンの確認が必要 |
| 設定の移行 | 従来形式の設定と、バージョンに対応した設定形式を確認 | 固有フィールド、廃止項目、トランスポート名を確認。実行ファイルの差し替えだけでは不十分 |
VLESS + REALITYを例にすると、VLESSはプロキシプロトコル、REALITYは接続を保護する仕組みです。設定にはTCPトランスポートや、flowとして xtls-rprx-vision が指定される場合もあります。これらは互いに置き換えられる名称ではありません。プロトコルをVLESSに変えただけで、サーバー名や公開鍵のパラメーター、flowを設定しなければ、元のノードと同じ接続にはなりません。
選び方の結論：ノードの要件を組み合わせで確認
まず「プロトコル + トランスポート + 安全機能 + flow」を記録し、その組み合わせに対応するカーネルを選びます。REALITYが必須のノードでは、Xrayの対応バージョンを優先して確認しましょう。既存のVMess + WebSocket + TLS設定は、名称を新しくするためだけに移行せず、まず互換性を確認してください。
3. GUIクライアント3種：デスクトップ用とAndroid用を選ぶ
v2rayN、v2rayNG、v2flyNGはそれぞれ別のプロジェクトで、同じソフトにプラットフォーム別の接尾辞を付けたものではありません。名前が似ていても、対応機能の確認は必要です。特にv2rayNは、画面のバージョン、利用できるカーネル、インストールパッケージの内容が同時に変わる場合があります。最新のクライアント説明と実際の起動ログを確認しましょう。
v2rayN：デスクトップ向け設定クライアント
おすすめデスクトップ向けで、サブスクリプション、ノード、ルーティング、システムプロキシの管理に適しています。対応プラットフォームやカーネルの選択肢はリリースごとに異なる場合があるため、特定バージョンのメニュー画面を全バージョン共通の機能一覧と見なさないでください。
おすすめの用途：設定をまとめて管理し、カーネルのログも確認したいデスクトップ
v2rayNG：Android向けXray系クライアント
AndroidのシステムVPNインターフェースを利用して端末の通信を処理します。一般的なカーネルはXray系です。新しいパラメーターに対応するかどうかは、クライアントに同梱されたコアのバージョンや、共有リンクの解析機能にも左右されます。
おすすめの用途：VLESS、REALITYなどXrayの機能を使うノードに接続するAndroid端末
v2flyNG：Android向けV2Fly系クライアント
V2Fly系カーネルを使用し、V2Ray Coreの設定が必要な環境に適しています。同じサブスクリプションを読み込めるからといって、Xray独自のパラメーターも認識して実行できるとは限りません。
おすすめの用途：既存設定がV2Flyカーネルと互換性があると確認済みのAndroid端末
上記のおすすめは、デスクトップでの設定管理を基準にしたもので、プラットフォームをまたいだ性能ランキングではありません。Windows、macOS、Linuxでは、v2rayNのインストールパッケージがOSとCPUアーキテクチャに合っているかを確認してください。Androidでは、ノードの要件に応じてv2rayNGとv2flyNGのカーネル系統を選びます。3つのクライアントの違いはクライアント比較をご覧ください。
- クライアントを更新：サブスクリプションの解析、画面上の選択肢、設定生成方法、同梱カーネルのバージョンが変わる場合があります。
- カーネルを更新：接続の実装や設定の対応範囲が変わりますが、古い画面が新しい項目を自動で認識するとは限りません。
- サブスクリプションを更新：ノード情報を取得し直します。カーネルは自動更新されず、ローカルのルーティングルールも同期されるとは限りません。
4. サブスクリプションとJSON：読み込めても、そのまま移行できるとは限らない
サブスクリプションは、設定を配布するための入り口です。クライアントが内容を取得した後、共有リンクや対応する設定形式を解析し、独自の実行設定を生成します。そのため「同じサブスクリプションURLを開けた」ことが示すのは取得成功までです。ノード情報が完全か、パラメーターが保持されたか、接続できるかは、それぞれ別に確認する必要があります。
- まず解析結果を確認。サブスクリプションを更新したら、ノード名、アドレス、ポート、プロトコルを確認します。一覧が空の場合は、レスポンス内容や形式が合っていない可能性があります。すぐに接続先サーバーが原因だと決めつけないでください。
- 次に重要な項目を確認。VMessではUUIDとトランスポート設定、VLESSではUUID、暗号化設定、flowを確認します。REALITYでは、サーバー名、公開鍵のパラメーター、short IDなども確認してください。
- ローカルで生成された設定を確認。共有リンクでは一部のデフォルト値が省略されることがあり、クライアント側で独自のデフォルト値が補われる場合もあります。比較する際はノード名だけでなく、最終的にカーネルへ渡される内容を確認してください。
- 最後に実行ログを確認。設定の解析エラー、接続エラー、ハンドシェイクエラーを切り分けます。不明な項目が表示されたら、まずカーネルのバージョンを調べましょう。ノードのパスワードを何度も変更する必要はありません。
同じサブスクリプションを2台で使っていても、ノード一覧が異なる場合があります。一方の端末でまだ更新していない、対応しない種類がフィルタリングされている、解析機能が一部のパラメーターを保持していない、といった原因が考えられます。サブスクリプションURLにアクセス情報が含まれることもあるため、トラブル対処の際はURL全体や個人情報を公開しないでください。
5. デスクトップとAndroidで同じサブスクリプションを使う：ノードを共有し、通信の扱い方は分けて考える
複数端末で使う場合、共通にするのはノードの提供元と接続に必要なパラメーターです。一方、システム通信の扱い方をそのまま当てはめるのは避けましょう。デスクトップのシステムプロキシは、その設定に従うアプリで主に使われます。AndroidのVPNモードはシステムインターフェースを通して通信を処理します。対象となるアプリの範囲は異なるため、「別の端末で使えた」ことだけでは、現在の端末の設定が正しいとは判断できません。
設定例：同じサブスクリプションを使い、端末ごとの実行環境を確認
デスクトップ：v2rayN
- ノードの要件に合う対応カーネルを選び、実際に起動したバージョンを記録します。
- サブスクリプショングループの設定にURLを追加し、更新後にノードのパラメーターを確認します。
- システムプロキシを使う場合は、ブラウザーがその設定に従っているか確認します。
- ルーティングとDNSの設定は個別にバックアップし、サブスクリプションの一部と考えないようにします。
Android：v2rayNGまたはv2flyNG
- Xray系かV2Fly系かに応じてクライアントを選び、同じサブスクリプションを読み込みます。
- 起動時にシステムVPNの許可を確認し、ほかのVPNとの競合にも注意します。
- 必要に応じてアプリごとのプロキシを設定し、対象アプリが除外されていないか確認します。
- Wi-Fiとモバイルネットワークでそれぞれ接続を確認し、ネットワークの違いをカーネルの違いと混同しないようにします。
同じサブスクリプションを使えばノードの提供元を統一できますが、更新時刻、ルーティング、DNS、アプリ通信の対象範囲は端末ごとに確認が必要です。
移行時は一度に変更する要素を一つに絞ります。たとえば、ルーティングとDNSを変えずにクライアントだけを切り替え、ノードを一つ検証します。成功を確認してから分割ルーティングを調整しましょう。こうすれば問題が起きても、カーネルの互換性、設定生成、通信を処理する範囲のどれが変わったのか切り分けやすくなります。
6. ポートとログで確認：どのレイヤーが動作しているか
以下の3つの数値は接続経路を理解するための設定例です。すべてのバージョンのデフォルト値ではなく、性能テストの結果でもありません。実際の利用時は、クライアントに表示される待ち受けポートと、ノードで指定されたサーバーポートを確認してください。
ローカルのSOCKS入口が 127.0.0.1:10808 に設定されている場合は、プロキシに対応したコマンドラインツールで、この入口だけを個別に確認できます。以下のコマンドを使うにはcurlがインストールされ、接続先サイトが利用可能である必要があります。ドメイン名の名前解決はSOCKSプロキシ側に任せますが、端末上のすべてのアプリがプロキシを使っていることを示すものではありません。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/- すぐに接続拒否と表示される：まずローカルポート、待ち受けアドレス、カーネルの起動状態を確認します。この時点では、リモートとのプロトコルハンドシェイクに到達していません。
- ローカル入口には接続できるが、ログにハンドシェイクエラーが出る：プロトコル、安全機能、システム時刻、認証情報を確認し、サーバー側の設定と照合します。
- コマンドでは接続できるのに、ブラウザーでは失敗する：システムプロキシ、ブラウザーのプロキシ設定、拡張機能の競合を確認します。すぐにカーネルを切り替える必要はありません。
- 一部のアプリだけ接続できない：アプリごとのプロキシ、ルーティング、DNSの対象範囲を見直し、特定のドメインやアプリに関係する問題か確認します。
最後に：検証済みの設定を基準として残す
クライアントのバージョン、カーネルのバージョン、プロトコルの組み合わせ全体、ローカルポートを記録します。以後の更新では、この設定を基準に接続を確認してから、ほかのサブスクリプションや分割ルーティングのルールを戻します。「V2Rayを使っている」とだけ記録するより、端末間の違いを特定しやすくなります。
Project Vのエコシステムには多くの名称がありますが、選び方の軸はシンプルです。ノードが接続要件を示し、カーネルが接続を実装し、クライアントが設定をカーネルに渡して端末の通信を処理します。まずこの3つの役割をそろえ、その後で画面の使いやすさや複数端末の管理方法を検討しましょう。インポートと起動の手順はクライアントの使い方ガイド、プロトコル項目の意味は用語集をご覧ください。