プロジェクト、コア、プロトコル、クライアントの違いを把握してから、ノードの要件に合ったソフトウェアを選びましょう。V2FlyとXrayを比較している方や、デスクトップとAndroidで同じサブスクリプションを使いたい方に向けて、選ぶべきクライアント、確認するプロトコル項目、インポート後に接続できない場合の切り分け方を解説します。
4つの階層を整理：Project V、コア、プロトコル、クライアント
「V2Ray ダウンロード」と検索すると、Project V、V2Fly、Xray、v2rayN、v2rayNGが並んで表示されることがあります。しかし、これらは同じ階層の名称ではありません。プロジェクト群を指すもの、通信処理を担うプログラム、ユーザーが操作するGUIなど、それぞれ役割が異なります。すべてを互換性のあるソフトウェアと考えると、ダウンロード、インポート、トラブルシューティングで選択を誤る原因になります。
| 階層 | 名称の例 | 役割 |
|---|---|---|
| プロジェクト群 | Project V | ネットワークプロキシツールを中心とするプロジェクトと技術の体系。GUIクライアントの名称ではありません。 |
| コアと保守プロジェクト | V2Flyが保守するV2Ray、Xray-core | 設定を読み込み、インバウンド、アウトバウンド、DNS、ルーティング、接続を処理します。 |
| プロキシプロトコル | VMess、VLESS | クライアントとサーバー間で、プロキシリクエストや認証情報をやり取りする方法を定めます。 |
| GUIクライアント | v2rayN、v2rayNG、v2flyNG | サブスクリプション管理、ノード選択、プロキシのオン・オフ、ログ表示などの画面を提供し、コアを呼び出して接続します。 |
デスクトップのブラウザーでウェブページを開く場合、まずクライアントが選択したノードをコア用の設定に変換し、コアがルーティングルールに従って直接接続するか、プロキシサーバーへ転送するかを決めます。システムプロキシやTUNは、アプリの通信をこの経路に流す方法を制御します。サブスクリプションの一覧が同じでも、クライアントが生成する設定、使用するコアのバージョン、通信を取り込む範囲まで同じとは限りません。
プロジェクトの経緯：V2Flyコミュニティによる保守とXrayの派生
Project VはV2Rayなどのツールとともに発展し、V2Rayはインバウンド、アウトバウンド、ルーティングなどを組み合わせられる設計を採用しています。初期のプロジェクト運営体制が変わった後、V2FlyコミュニティがV2Rayの保守を引き継ぎました。そのため「V2Fly」は通常、保守コミュニティとそのプロジェクトを指し、「V2Ray」はそのコミュニティが保守するコアプログラムを指します。両者は密接に関係していますが、同時にインストールする2つのGUIソフトウェアではありません。
Xray-coreは2020年にV2Rayのコードを基に派生し、その後独自の保守方針で開発されてきました。共通の歴史を持ち、似た概念も多くありますが、新しい設定をそのまま相互利用できるとは限りません。特にVLESSのflow、REALITY、セキュリティ設定、トランスポートの項目は、実際に使用するコアの対応状況を確認してください。
- 共通する概念：インバウンドは端末内の通信を受け取り、アウトバウンドは接続先またはプロキシサーバーへ接続し、ルーティングは通信をどのアウトバウンドに流すかを決めます。
- 独自の進化を区別：設定項目、トランスポートの実装、デフォルトの動作は、それぞれのバージョンで異なる場合があります。JSONの見た目が似ているだけでコアを置き換えないでください。
- サーバーの要件に合わせて選択：現在のノードで接続できるかどうかは、「どのプロジェクトが新しいか」より、サービス提供元が指定するプロトコル、セキュリティ層、flowの情報で判断してください。
つまり、「XrayはV2Rayの新しい名称なのか」という問いへの答えは、いいえです。Xrayは独自に発展した派生プロジェクトであり、名称が一括変更されたわけではありません。Xrayの派生後も、V2Flyが保守するV2Rayは引き続き開発されています。共通のルーツがあるからといって完全互換と考えず、現在のノードで必要な機能を基準に選びましょう。
コアの選び方：まずノード要件を確認し、使い方に合わせて比較
一般ユーザーが、すべてのコアを個別にインストールしておく必要はありません。まずクライアントが必要なコアを利用できるかを確認し、次にノードの設定項目が対応しているかを調べましょう。以下では、現在利用しているサブスクリプションを前提に説明します。「おすすめ」はノードがXray固有の機能を明確に要求する場合を指し、別の保守系統がほかの用途に適さないという意味ではありません。
Xrayコア
推奨ノードにVLESS、REALITY、特定のVision flowが指定されている場合は、Xrayのバージョン要件とクライアントのインポート対応状況を優先して確認してください。ノード名にVLESSと書かれているかだけで判断しないでください。
適した用途：サーバーがXrayの機能を必要とする場合、または対応パラメーターがサブスクリプションに含まれている場合。
V2Flyが保守するV2Rayコア
既存の設定をV2Flyのドキュメントに沿って運用し、現在のバージョンで対応しているプロトコルとトランスポートを使っている場合は、この系統を引き続き利用できます。VMessなど共通で対応しているプロトコルでも、トランスポートやTLSの設定は項目ごとに確認してください。
適した用途：既存のV2Ray設定、動作確認済みのVMessノード、v2flyコアが明示的に必要な環境。
要点：ノードの設定を一つずつ確認する
ノードの編集画面を開き、プロトコル、ポート、トランスポート、セキュリティ層、flowを順に確認します。REALITYや特定のXrayパラメーターが含まれている場合は、ルーティングや速度測定に進む前にコアの対応状況を確認し、互換性のない組み合わせでノードを何度も切り替えるのを避けましょう。
VMessを使っていても、速度が同じとは限りません。遅延、パケットロス、サーバー負荷、出口帯域、トランスポートの組み合わせなどが通信品質に影響します。一方、コアを変更しても、サブスクリプションのサーバー回線が自動的に改善されるわけではありません。同じネットワーク、同じノード、同じ測定先で比較していない場合、1回の速度測定だけでプロジェクト全体を評価するのは適切ではありません。
対応クライアント：デスクトップはv2rayN、Androidはコアに合わせて選択
v2rayNはデスクトップ向けのGUIクライアントです。Windows、macOS、Linuxではそれぞれ対応するビルドを選び、OSとプロセッサーアーキテクチャの要件を確認してください。画面と設定の管理を担い、利用できるコアは現在のバージョンとインストール内容によって異なります。名前に「v2ray」が含まれているからといって、実行中のコアが必ずV2Fly製とは限りません。
Androidでは、名前の似た2つのクライアントを区別する必要があります。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。どちらもノード管理などの操作画面を備えていますが、採用するコアの系統は異なります。一方のクライアントが共有リンクを読み込めても、もう一方がリンク内のすべての拡張項目に対応するとは限りません。
構成例：デバイスとノード要件に合わせてクライアントを選ぶ
デスクトップ：v2rayN
- Windows、macOS、Linuxに合わせてビルドを選び、プロセッサーアーキテクチャを確認します。
- コアの設定と起動ログを見て、選択したノードで実際に使われているコアを確認します。
- まずシステムプロキシを確認し、アプリの要件に応じてTUNを検討します。
Android：v2rayNGまたはv2flyNG
- Xrayの機能が必要なノードにはv2rayNGを選び、対応バージョンを確認します。
- v2flyコアが必要で設定の動作確認も済んでいる場合は、v2flyNGを選びます。
- 初回接続時は、システムの案内に従ってVPN権限を許可し、通信を取り込むアプリの範囲を確認します。
どちらのデバイスでも同じサブスクリプションを利用できますが、解析できる設定、更新のタイミング、サーバー側の同時接続数制限は個別に確認してください。
AndroidのVPN権限は、ローカルの仮想ネットワークインターフェースを作成し、端末の通信をクライアントに渡すためのものです。利用可能なノードが自動で手に入るわけではありません。デスクトップのシステムプロキシも端末側の接続方法にすぎず、サーバーアドレス、認証情報、サブスクリプションサービスの代わりにはなりません。クライアントのインストール、設定のインポート、通信の取り込みを順に行う必要があります。
プロトコルとサブスクリプションを確認：インポートできても互換とは限らない
VMessとVLESSはプロキシプロトコル、WebSocketやgRPCなどはトランスポート方式、TLSとREALITYは接続のセキュリティに関わる設定です。これらを同じ項目の置き換え可能な選択肢として扱わないでください。VLESS自体はペイロードを暗号化しないため、適切なセキュリティ層と構成を踏まえて安全性を判断します。REALITYも独立したサブスクリプションURLではありません。
| 確認項目 | 具体例 | 間違えやすい点 |
|---|---|---|
| プロトコルと認証 | VMessまたはVLESSと、サーバーから割り当てられたUUID | プロトコル名を変更しても、既存ノードを別のサービスに変換することはできません。 |
| サーバーポート | サービス提供元が指定する443 | 443はポート番号の例にすぎず、TLSが有効だとは限りません。 |
| トランスポート | WebSocketのpathとHost、またはgRPCのserviceName | パスやサービス名はサーバー側の設定と一致させる必要があります。クライアント側で推測しないでください。 |
| セキュリティ設定 | TLSのserverName、またはREALITYの公開鍵とshortId | ノードのアドレスとserverNameは異なる場合があります。提供元が指定した値を使用してください。 |
| flow | xtls-rprx-vision | サーバーが必要としていて、組み合わせが対応している場合にのみ設定します。汎用的な高速化スイッチではありません。 |
サブスクリプションURLはノード一覧を配布し、共有リンクは通常、単一のノードを記述します。サブスクリプションからはリンクの一覧が返される場合も、特定のクライアント向けの形式が提供される場合もあります。ブラウザーでURLを開けても、アドレスにアクセスできることが分かるだけで、返された内容が現在のクライアントに適しているとは限りません。サービス提供元が形式別の入口を用意している場合は、クライアントに合うものを選んでください。
- まずサブスクリプションのURLを確認：サブスクリプション管理画面に完全なURLを追加して更新します。ノードのサーバーアドレス欄にサブスクリプションURLを入力しないでください。
- 次にノードの編集画面を確認：インポート後、ノードを一つ選び、ポート、トランスポート、serverName、flowを確認して、変換時に重要な項目が失われていないか調べます。
- 最後に接続を試し、ログを確認：コアが正常に起動したことを確認し、接続タイムアウト、認証失敗、設定項目の非対応を切り分けます。ノードが一覧に表示されたことだけで完了と判断しないでください。
トラブルシューティング：コア、通信の取り込み、ルーティングを順に確認
まず問題をノード一つ、アプリ一つに絞ります。通信を取り込むほかのソフトウェアを終了し、ルーティング設定は変えずに一度再現してください。サーバーへの接続前にログで設定エラーが出る場合は、項目またはコアの選択を修正します。コアは起動しているのにアプリの通信がプロキシ経路に入らない場合は、システムプロキシ、TUN、Androidのアプリ対象範囲を確認してください。
同じサブスクリプションなのに、v2rayNGでは接続できてv2flyNGでは接続できないのはなぜ？
まず両方のクライアントで同じ名前のノードを選び、プロトコル、セキュリティ層、flowを比較します。ノードがREALITYなどXray固有の機能に依存する場合は、v2rayNGを使用して必要なバージョンを確認してください。v2flyNGでノード名だけを変更しても解決しません。特定のコアを必要としない設定なら、サブスクリプションの更新時刻とログのエラーを比較します。
v2rayNをインストールした後、V2Flyも別途インストールする必要がありますか？
現在インストールされているファイルとコアの起動ログを確認してください。必要なコアがすでにあり、正常に起動できていれば、追加でインストールする必要はありません。ログに実行ファイルが見つからないと表示される場合は、現在のクライアントの説明に従って補ってください。切り替え前に実行中のコアを終了し、互換性のないファイルを手動で置き換えないようにします。
ノードのテストでは遅延が表示されるのに、ブラウザーでページを開けないのはなぜ？
まずv2rayNのメイン画面で「システムプロキシ」メニューから「システムプロキシを自動設定」を選び、システムプロキシに従うブラウザーで再試行します。メニュー名は現在のバージョンによって異なる場合があります。ブラウザーでは使えてほかのアプリでは使えない場合は、すぐにプロトコルを変更せず、アプリのプロキシ設定を確認するかTUNが必要か検討してください。
2台のデバイスで同じサブスクリプションを使うと、設定もすべて自動で同期されますか？
いいえ。各デバイスでサブスクリプションを更新し、ノード一覧を比較してください。ルーティング、DNS、アプリごとの対象範囲、システムプロキシのオン・オフは、それぞれのデバイスに保存されます。同時に接続できない場合は、サービス提供元のデバイス数制限や同時接続制限も確認してください。切断の原因をすべてコアのせいにすることはできません。
トラブルシューティング後は、クライアントとコアのバージョン、ノードのプロトコル構成、エラー発生時刻を記録しておくと、次回の更新前後で比較できます。ログを共有する際は、サブスクリプションURLやUUIDなどの機密情報を削除してください。エコシステムの選択で大切なのは、検証可能な組み合わせです。デバイスでクライアントを実行できること、コアが設定を解釈できること、サーバーがパラメーターを受け付けることを確認し、最後に通信の取り込みとルーティングでアプリの通信を適切な経路へ流します。