Project Vはプロジェクト群の名称で、V2Rayはその中核となるツールです。V2FlyはV2Rayの保守を引き継ぎ、Xrayは独立して発展したフォークです。v2rayN、v2rayNG、v2flyNGはユーザー向けのクライアントであり、3種類のプロキシプロトコルではありません。ノードやサブスクリプションを使ったことはあるものの、名称の違いが分かりにくい方に向けて、まず歴史と役割を整理し、サーバー設定に合ったコアを選び、最後にデスクトップとAndroidでのインポート、ルーティング、更新の手順を解説します。
Project VからV2Flyへ：プロジェクト名と保守主体
Project Vは、すべての接続を一つのプロトコルや通信方式に限定せず、組み合わせて使えるネットワークプロキシツールを提供することを目指して始まりました。V2Rayはその中で最も広く使われているコアツールで、インバウンドの受け付け、アウトバウンド接続、ルーティング、関連プロトコルの処理を担います。初期の解説ではProject VとV2Rayが並んで登場することが多く、日常の会話では混同されることもありますが、同時にインストールする2種類のクライアントを指すわけではありません。
その後のエコシステムの変化は、以下の節目を押さえると理解しやすくなります。年はプロジェクトの発展段階を把握するための目安であり、その年に公開された古いバージョンを現在もそのまま導入すべきという意味ではありません。対応機能は、利用中のバージョンの説明と設定ドキュメントで確認してください。
- 2015年頃：V2Rayプロジェクトが始動。設定可能なインバウンド、アウトバウンド、ルーティングの仕組みを中心に開発が進み、VMessは代表的なプロトコルの一つとなりました。コマンドラインのコアとGUIクライアントの役割も、次第に明確になりました。
- 2019年頃：V2Flyコミュニティによる保守体制が形成。元のプロジェクトの保守状況が変化した後も、コミュニティがV2Rayのコード、ドキュメント、リリースの保守を継続しました。「V2Fly」は主に保守コミュニティとそのプロジェクト群を示す名称で、コアの名称は引き続きV2Rayと呼ばれることが多くあります。
- 2020年末：Xrayがフォーク。XrayはV2Rayのコードを基盤に分岐し、その後独立して保守されています。共通の出自は一部の設定構造が似ている理由になりますが、その後の機能が常に一致することを意味しません。
- 2023年：REALITYがXrayの機能に加わる。REALITYは接続のセキュリティ機構であり、VMessやVLESSと同じ階層の独立したプロキシプロトコルではありません。利用時は、プロトコル、トランスポート、セキュリティ設定の組み合わせを確認してください。
したがって、「V2Flyが保守を引き継いだ」からといって、すべてのユーザーがクライアントをv2flyNGに変える必要があるわけでも、既存のノードをすべて別のプロトコルに変更する必要があるわけでもありません。保守主体、コアプログラム、GUIはそれぞれ別の問題です。古いチュートリアルを読む際は、「V2Ray」がコアを指すのか、プロトコルエコシステムの総称なのか、あるいは解説者が操作しているクライアントなのかをまず確認すると、無駄なトラブルシューティングを避けられます。
Xrayの分岐：共通の出自は設定の恒久的な互換性を意味しない
XrayとV2Flyの関係は、まずコード上の歴史であり、上下関係ではありません。分岐後は、それぞれが機能、設定項目、トランスポートの実装、デフォルト動作を独自に変更できます。どちらもプロキシコアとして利用できますが、「どちらもV2Ray由来」という理由だけで実行ファイルを入れ替え、既存の設定がそのまま動くと考えることはできません。
| 比較項目 | V2Flyが保守するV2Ray | Xray |
|---|---|---|
| プロジェクトの関係 | V2Rayのコミュニティ保守とリリースを継続 | 共通のコード基盤から分岐した独立プロジェクト |
| 設定の確認 | 利用するバージョンと設定形式を確認 | 利用するバージョン、項目、機能の組み合わせを確認 |
| VMessなど共通する機能 | トランスポートとセキュリティ層のパラメーターも確認が必要 | トランスポートとセキュリティ層のパラメーターも確認が必要 |
| REALITYの利用 | 名称が似ているだけで互換性があるとは判断できない | クライアントで該当設定が可能か、コアが対応しているかを確認 |
| GUIクライアントとの関係 | クライアントによって呼び出すコアや設定の生成方法が異なる | クライアントによって呼び出すコアや設定の生成方法が異なる |
たとえば、サーバー側の設定がVLESS＋REALITYの場合、クライアントはVLESSに対応するだけでなく、サーバーから指定されたサーバー名、公鍵、short IDなどのパラメーターを保存して渡せる必要があります。バージョンによって項目名やインポート時の対応付けが変わることもあるため、該当バージョンのドキュメントと照合してください。インポート後にノード名が表示されていても、接続に必要なパラメーターがすべて保持されているとは限りません。
結論：接続パラメーターからコアを決め、その後クライアントを選ぶ
まずサーバー側で必要なプロトコル、トランスポート、セキュリティ設定、フロー制御パラメーターを整理し、クライアントとコアのバージョンを確認します。既存の設定が安定している場合は、新機能が必要なときや不具合を修正するときに限って切り替えを検討し、元に戻せるよう既存設定を保存してください。
コア、プロトコル、トランスポート、クライアントの4層の役割
ノードで接続できるかどうかは、通常、複数の層の設定が同時に一致するかで決まります。VMessやVLESSはプロキシプロトコル、TCPやWebSocketなどはデータを運ぶトランスポート方式、TLSやREALITYはセキュリティ設定にあたります。この分類は機能を理解するためのもので、任意のプロトコル、トランスポート、セキュリティ設定を自由に組み合わせられるという意味ではありません。
- クライアントのGUI：サブスクリプションのグループ管理、QRコードやクリップボードからのインポート、ノード選択、ログ表示、システムプロキシやAndroidのVPN接続などを操作します。
- プロキシコア：クライアントが生成した設定を読み込み、待ち受けポートを起動して、プロトコルのハンドシェイク、DNS処理、ルーティング判定、アウトバウンド接続を行います。
- ノードのパラメーター：サーバーのアドレス、ポート、ユーザー識別子、プロトコル関連項目を指定します。アドレスが同じでも設定が同じとは限りません。
- 端末からの接続方法：アプリの通信をどのようにコアへ渡すかを決めます。システムプロキシ、プロキシポートの手動設定、仮想ネットワーク接続では対象範囲が異なります。
端末上のポートを例に、以下の数値は役割を説明するための設定例であり、3つのクライアントに共通するデフォルト値ではありません。実際に利用する際は、現在のクライアントの待ち受け設定を確認し、他のプロセスが同じポートを使用していないことを確かめてください。
ブラウザーに127.0.0.1:10809を設定した場合、接続先は端末上のHTTPプロキシの入口であり、リモートサーバーの443番ポートへ直接接続するわけではありません。その後、コアがノードとルーティングの設定に従ってアウトバウンド接続を確立します。端末上の待ち受けポートをサーバーポート欄に入力したり、ノードだけ変更してアプリの通信をプロキシに渡さなかったりすると、「設定はあるのにアクセスできない」という状態になります。
3つのクライアント：プラットフォームとサーバーの条件から選ぶ
v2rayNは主にデスクトップ環境で使われ、ノード、サブスクリプション、ルーティング、コア関連の設定を管理できます。対応プラットフォーム、画面、コアの選択肢は、利用する配布パッケージによって異なります。v2rayNGはAndroid向けで、Xrayコアを使用します。v2flyNGもAndroid向けで、V2Flyが保守するV2Rayコアを使用します。クライアント名に似た文字が含まれていても、バージョンを相互に置き換えられるわけではなく、クライアントのバージョン番号からコアのバージョン番号を推測することもできません。
v2rayN：デスクトップでの設定管理
おすすめこの記事では、デスクトップのノードとルーティングを整理したい方に向け、デスクトップの入口としてv2rayNをおすすめします。使用するOSとアーキテクチャに合ったインストーラーを選び、メイン画面に表示されたノードの種類だけで判断せず、現在の設定が実際にどのコアを呼び出しているかを確認してください。
おすすめの用途：デスクトップでのサブスクリプション管理、ログ確認、ノード要件に応じたコア設定の確認。
v2rayNG：AndroidとXray
Xrayの機能が必要なAndroid設定に適しています。インポート後は、トランスポート、セキュリティ設定、フロー制御の項目を一つずつ確認してください。AndroidのVPN権限とアプリごとの接続範囲も別途確認が必要です。
おすすめの用途：REALITYが必要な設定を含め、互換性を確認済みのXrayノードをAndroidで利用する場合。
v2flyNG：AndroidとV2Fly
V2Flyの設定環境をすでに利用しているAndroidユーザーに適しています。判断基準はサーバーのパラメーター、コアの機能、インポート形式が一致するかどうかであり、V2Rayに近い名前だからといって、すべてのノードに対応するわけではありません。
おすすめの用途：動作確認済みのV2Fly接続設定をAndroidで継続利用する場合。
おすすめの表示は、ここで取り上げるデスクトップ管理の用途に限ったもので、3つのクライアント全体の順位を示すものではありません。プラットフォームが異なれば接続の仕組みや操作方法も異なります。同じノード名がサブスクリプションに表示されても、各端末で生成される設定を確認してください。ダウンロード先とプラットフォームの説明はクライアントページ、各用語の違いはプロトコル解説をご覧ください。
デスクトップとAndroidでサブスクリプションを共有：ノードは同期、設定すべては同期されない
サブスクリプションURLは、ノード設定の一覧を取得するためのものです。コアでもルーティングルールの共通規格でもなく、2台の端末でDNS、システムプロキシ、アプリの除外設定、更新間隔を自動的に統一するものでもありません。個別の共有リンクは通常、1つの接続設定を示します。貼り付けてインポートした後、サーバー側で変更があっても、端末上の設定に自動で反映されるとは限りません。
設定例：同じサブスクリプションを使い、端末ごとに検証
デスクトップ：v2rayN
- 「サブスクリプショングループ」→「サブスクリプショングループ設定」からURLを追加します。メニュー名は利用中のバージョンによって異なる場合があります。
- サブスクリプションを更新したらノードを1つ選び、プロトコル、トランスポート、セキュリティの各項目を確認します。
- 待ち受けポートとシステムプロキシの状態を確認し、実際のアプリで通信がコアに届いているか検証します。
Android：v2rayNGまたはv2flyNG
- 「サブスクリプション設定」で同じURLを追加し、「サブスクリプションを更新」を実行します。メニューの場所はバージョンによって変わる場合があります。
- 該当するコアの対応範囲に基づいてインポート結果を確認します。ノード数が同じだからといって、互換性があるとは判断しないでください。
- 接続を開始してAndroidのVPN権限を許可し、アプリごとの設定と実際のアクセス結果を確認します。
サブスクリプションで同じノードを取得できても、端末ごとのルーティング、DNS、アプリの接続範囲は個別に設定して検証する必要があります。
移行時は、ノードデータと端末側のポリシーを区別してください。サブスクリプションの更新でノード項目が再生成される場合があります。サブスクリプション経由のノードを手動で編集する前に、クライアントの保存動作を確認し、必要に応じて手動設定として別途保存してください。サブスクリプションURLにアクセストークンが含まれていることもあります。スクリーンショット、ログ、問い合わせ情報を共有する際は、URL全体とユーザー識別子を隠してください。
- 現在の状態を記録：クライアントとコアのバージョン、ノードの種類、現在利用できるネットワークを記録し、元の設定を保存します。
- 一度に一項目ずつ変更：まずノードに接続できるか確認し、次にDNS、最後にgeositeやgeoipなどのルーティングルールを調整します。複数の層を同時に変更しないでください。
- ルールデータを確認：参照先の分類データが存在することと、ルールの順序を確認します。ファイル名が同じでも、データの内容や更新日時が同じとは限りません。
- 実際のアクセスを検証：直接接続する宛先とプロキシ経由にする宛先をそれぞれ確認し、ログで使用された経路を判断します。遅延テストに成功しても、すべてのアプリが使えるとは限りません。
エコシステムの名称に関するよくある質問と確認手順
クライアント選びの問題は、インポート、更新、端末の切り替え後に表面化することがよくあります。クライアントの接続設定 → コアの起動 → ノードのハンドシェイク → DNSとルーティング → アプリの接続、の順に確認すると、クライアントを何度も入れ替えるより原因を特定しやすくなります。
v2rayNをインストールすれば、V2Flyコアもインストール済みですか？
名称だけでは判断できません。利用している配布パッケージの説明を確認し、クライアントのコア設定と起動ログから、実際に呼び出されたプログラムとバージョンを確認してください。ノード編集画面にVMessやVLESSと表示されていても、分かるのは設定されたプロトコルの種類だけで、バックグラウンドで動いているコアまでは特定できません。
同じサブスクリプションがデスクトップでは使えるのに、Androidにインポートすると接続できないのはなぜですか？
同じノードを選び、サーバーポート、トランスポート、セキュリティ設定、フロー制御の各項目を順に比較し、Android側のコアログも確認してください。パラメーターが一致し、ハンドシェイクにも成功している場合は、AndroidのVPN権限とアプリごとの設定を確認します。原因を調べるための基準を失わないよう、サブスクリプション全体をすぐ削除して再登録するのは避けてください。
Xrayに切り替えた後、ルーティングを再設定する必要がありますか？
一律に書き直すのではなく、互換性を再確認してください。ルール項目がサポートされているか、geositeとgeoipのデータを読み込めるか、ルールの順序が維持されているか、direct、proxy、blockの各タグが引き続き正しく対応しているかを確認します。まず明確なテストルールを1つ使って経路を検証し、その後で完全なルールセットに戻してください。
VLESSノードには必ずREALITYが必要ですか？
必要ではありません。VLESSはプロキシプロトコルで、REALITYは特定の設定で利用できるセキュリティ機構です。サーバーが指定する組み合わせに従って設定してください。サーバー側がTLSを要求している場合は、独断でREALITYに切り替えないでください。また、VLESSという表示だけを見て、サーバー名、公鍵、short IDを推測することもできません。
Project Vエコシステムでの選び方は、実行可能な手順にまとめられます。まずサーバーの接続パラメーターを確認し、次にコアの機能を照合して、利用するプラットフォームに合ったクライアントを選び、最後にサブスクリプション、ルーティング、アプリの接続を検証します。歴史を知ると名称の由来は理解できますが、接続結果を決めるのは現在のバージョンと実際の設定です。インポートの手順から始める場合は、入門ガイドをご覧ください。