Project Vはプロジェクトの背景、V2FlyとXrayはそれぞれ異なるコアの開発・保守方針、v2rayN・v2rayNG・v2flyNGは操作に使うGUIクライアントです。クライアントの選択やサブスクリプションの移行、プロトコルの互換性確認をしたい方に向けて、各レイヤーの役割を整理します。ノードのプロトコル、通信方式の設定、実際のログを確認して組み合わせを判断し、名前だけで互換性を決めないことが大切です。
Project V・V2Fly・Xray：開発の経緯と製品の違い
Project Vは当初、モジュール型のネットワークプロキシツール群を目指しており、V2Rayはその中核となる実装でした。コアはローカル接続を受け付け、ルーティングを適用し、DNSを処理して、設定に従ってリモートへ接続します。初期には「V2Ray」が利用環境全体を指すことも多く、クライアント、プロトコル、コアが混同されがちでした。
2020年前後、V2FlyコミュニティがV2Rayコアの保守・開発を引き継ぎました。一方、Xray-coreは同年にV2Rayのコードをもとに分岐し、その後独自の方針で開発が進みました。共通の歴史はありますが、同じ配布パッケージではなく、「新しい名前が古い名前に置き換わった」と捉えるのも正確ではありません。以降の機能、設定項目、リリース状況はそれぞれ確認が必要です。
- Project V：プロジェクトとツール群の背景を指します。クライアントで直接選ぶプロキシプロトコルではありません。
- V2Fly：V2Rayコアを保守するコミュニティです。技術的な問題を相談するときは、V2Rayコアの実際のバージョンも明記しましょう。
- Xray：関連プロジェクトを指すほか、Xray-coreの略称としても使われます。独自のプロトコル実装と設定の進化があります。
- GUIクライアント：ノード一覧、サブスクリプション管理、設定画面を提供します。接続設定を実行するのは、あくまでコアです。
2つのコアには、インバウンド、アウトバウンド、ルーティングルールなど共通する設定概念があります。ただし、概念が似ていても、設定を何でも相互に使えるわけではありません。特定のセキュリティ機能、フロー制御パラメーター、新しい通信方式を使う場合は、利用中のコアのドキュメントを確認してください。JSONの見た目が似ているという理由だけで、設定一式をコピーするのは避けましょう。
3つのクライアント：アプリ名だけでは使用中のコアはわからない
v2rayNはデスクトップ向けのGUIクライアントで、設定、サブスクリプションの整理、接続の制御を行います。V2Rayコアの別名ではなく、特定のコアだけを実行するものとも限りません。対応プラットフォーム、選択できるコア、設定画面は配布パッケージによって異なるため、使用中のインストーラーと画面で確認してください。
| クライアント | 対応プラットフォーム | コアとの関係 | 確認する場所 |
|---|---|---|---|
| v2rayN | デスクトップ | ノードの種類とクライアントの設定に応じて利用可能なコアを呼び出します。クライアント名だけでは決まりません。 | コアの選択設定、起動ログ |
| v2rayNG | Android | Xrayコアでプロキシ接続を処理 | アプリのバージョン情報、実行ログ |
| v2flyNG | Android | V2FlyのV2Rayコアを使用 | アプリのバージョン情報、実行ログ |
クライアントのバージョンとコアのバージョンは別々の情報です。GUIを更新しても、「バージョン情報」にあるアプリのバージョンだけでプロトコルの対応状況が変わったと判断することはできません。接続を再起動し、ログで実際に読み込まれたコアの名称、バージョン、起動エラーを確認してください。デスクトップ向け配布パッケージによってはコアを個別に管理するため、古いプロセスが終了していないと特に誤認しやすくなります。
- v2rayNの「設定」→「パラメーター設定」を開き、使用中のバージョンでコア関連の項目を確認します。別にコア管理画面がある場合は、そちらも確認してください。
- ノードを選んで接続を再起動し、メイン画面のログ欄で起動情報を確認します。実際に使われているコアの名称とバージョンを記録してください。
- Androidではv2rayNGまたはv2flyNGのバージョン情報と実行ログをそれぞれ確認します。アイコンやサブスクリプション名だけで判断しないでください。
- 問題を報告する際は、クライアントとコアのバージョン、OS、エラーメッセージをあわせて記載してください。共有する前にサブスクリプションURL、UUID、認証情報を削除しましょう。
バージョンによってメニュー名が変わる場合があります。項目が見つからないときは、「コア」「パラメーター設定」「ログ」などを手がかりに該当機能を探してください。古いスクリーンショットを見て、関係のない設定を変更するのは避けましょう。画面から設定できないコア機能は、サブスクリプションを差し替えるだけでは有効になりません。
プロトコル・通信方式・セキュリティ設定：互換性をレイヤーごとに確認
VMessやVLESSはプロキシプロトコル、WebSocketやgRPCは通信方式に関する項目です。TLSやREALITYは接続のセキュリティ機構に関わります。それぞれ分類の階層が異なります。「ノードはVLESS」という情報だけでは、特定のクライアントで接続できるかどうかは判断できません。
VMessは特定のGUIクライアント専用のプロトコルではなく、VLESSとREALITYも同じものではありません。XrayとV2Flyでは対応する機能に違いがあり、特にXray固有のパラメーターを含むノード設定を、あらゆるVLESS実装が処理できるとは限りません。対応状況はコアのバージョンとクライアントのインポート機能にも左右されます。
| 設定レイヤー | 具体例 | 確認ポイント |
|---|---|---|
| プロキシプロトコル | VMess、VLESS | サーバーとクライアントでプロトコル、ユーザーID、認証パラメーターが一致している |
| 通信方式 | WebSocket、gRPC | パス、Host、serviceNameがサーバー側の設定と一致している |
| 接続のセキュリティ | TLS、REALITY | サーバー名、証明書の検証、公鍵など、関連パラメーターが正しく設定されている |
| 特定のフロー制御 | xtls-rprx-vision | コアが対応しており、サーバー・クライアント・通信方式の組み合わせが一致している |
| ローカル接続先 | 127.0.0.1:10808 | ローカル端末で待ち受けるアドレスの例です。リモートサーバーのポートとは分けて記録してください。 |
ポート番号の例は共通のデフォルト値ではありません。ローカルプロキシの接続先を127.0.0.1:10808に設定した場合、ブラウザーなどのアプリはこのローカル接続先に接続します。ノードのサーバーアドレスとリモートポートは、引き続きサーバー側の設定に従います。ローカルポートを変更しても、リモート側の認証エラーは解消されず、プロトコルの対応機能も増えません。
サブスクリプションURLは設定を配布するための入口であり、プロキシプロトコルではありません。クライアントがサブスクリプションをダウンロードできたとしても、確認できるのは応答を受け取ったことだけです。ノードを解析できても、すべての項目が保持されているとは限りません。移行後はノード詳細で通信方式、セキュリティ設定、フロー制御の項目を確認してから、実際に接続テストを行いましょう。
コアの選び方：名前ではなく、利用中のノード設定で判断
まずサーバーが実際に要求する設定を確認し、そのうえでクライアントとコアを選びます。現在使えている標準的なVMessやVLESSの設定なら、分岐名が違うという理由だけで移行する必要はありません。サーバーがREALITYや特定のフロー制御を明示的に要求する場合は、その組み合わせを完全に実装できるクライアントとコアを選んでください。
Xrayコアを使う構成
おすすめサーバーがVLESS、REALITY、Vision関連の組み合わせを明示的に要求する場合は、これらのパラメーターに対応するXrayのバージョンを優先し、クライアントで該当する設定を作成できることも確認してください。これは該当ノードの要件に基づく推奨であり、あらゆるネットワーク環境での性能順位を示すものではありません。
向いているケース：Xray固有の機能が必要な場合。Androidではv2rayNGを使い、デスクトップではv2rayNのコア設定を確認します。
V2Flyコアを使う構成
サーバーと設定をV2Flyに合わせて運用している場合は、対応するV2Rayコアを継続して利用できます。移行前に通信方式、セキュリティ、ルーティングの設定を一つずつ確認し、別の系統に固有の項目をそのまま適用しないでください。
向いているケース：動作確認済みのV2Fly設定を使っており、Androidではv2flyNGを利用して、従来の設定体系を維持したい場合。
結論：ノードの設定を確認してから、1つのノードで接続テスト
元の設定を残し、テスト用のノード1つだけでクライアントまたはコアを切り替えます。設定が保持され、正常に起動し、目的のWebサイトにアクセスできることを確認してから、ほかのノードへ移行してください。一度に変更するのは1つの要素だけにすれば、原因がプロトコル対応、インポート処理、ルーティング設定のどれかを判断できます。
接続速度もコア名だけでは判断できません。サーバーの設置場所、回線の混雑、パケットロス、端末性能、通信方式などが結果に影響します。比較する場合は、同じノードと接続先を使い、時間帯も近づけてください。接続の成否、再接続の有無、ログのエラーをそれぞれ記録し、回線の違いをコアの差と取り違えないようにしましょう。
デスクトップとAndroidの移行：サブスクリプションを共有し、端末ごとの設定を管理
同じサブスクリプションを複数端末の設定取得元として使えますが、形式とノードの組み合わせが移行先のクライアントに対応していることを先に確認してください。デスクトップとAndroidではローカル接続先、システムへの適用方法、アプリの除外ルールが異なることが多く、これらの設定がサブスクリプションと一緒に同期されるとは限りません。
構成の方針：ノードの取得元を統一し、通信経路は端末ごとに検証
デスクトップ：v2rayN
- サブスクリプションを追加したら、ノードを1つ選び、プロトコル、通信方式、セキュリティ設定を確認します。
- ログで実際に使用されているコアを確認し、ローカルの待ち受けポートを記録します。
- 必要に応じてシステムプロキシまたはTUNを設定し、対象アプリごとにテストします。
- 移行時にDNSやルーティング設定も同時に変更しないよう、既存のルールを残しておきます。
Android：v2rayNGまたはv2flyNG
- ノードの要件に合わせてXrayまたはV2Flyの構成を選びます。
- 同じサブスクリプションを追加し、ノード数と重要な設定項目を確認します。
- 接続を開始し、システムVPNの許可を確認します。ほかの接続が使用中でないかも確認してください。
- アプリごとのルールを設定し直し、バックグラウンド実行の制限も個別に確認します。
サブスクリプションで配布されるのはノード設定です。更新のタイミング、ローカルルーティング、DNS、対象アプリの範囲は、各端末で個別に管理する必要があります。
デスクトップのシステムプロキシが影響するのは、通常、その設定に従うアプリだけです。すべてのプログラムの通信がコアを経由するわけではありません。AndroidのVPNによる通信制御やアプリごとの選択にも、それぞれ適用範囲があります。そのため、「デスクトップでは使えるがAndroidでは使えない」という状況だけで、2つのコアの優劣を決めるべきではありません。
- 元のクライアント設定をエクスポートまたはバックアップし、ルーティングとDNSの設定を別途保存します。
- 移行先のクライアントにサブスクリプションを追加し、移行元と同じノードを選んでテストします。
- まずコアが正常に起動することを確認し、次にシステムやアプリの通信が実際にクライアントへ流れているか確認します。
- 最後にルーティングとDNSの設定を一つずつ戻します。変更のたびに再テストし、元に戻せる設定を残してください。
よくある質問：名前が似ている場合の切り分け方
v2rayNをインストールすれば、V2Flyコアが選ばれたことになりますか？
いいえ。「設定」→「パラメーター設定」でコア関連の項目を確認し、選択したノードの接続を再起動して起動ログを確認してください。実際に動作しているコアの名称とバージョンが判断基準です。クライアント名だけでは、そのノードをどのコアが処理しているかはわかりません。
サブスクリプションを追加できたのに、接続を押すとすぐ失敗するのはなぜですか？
ノードの詳細を開き、プロトコル、通信方式、セキュリティ、flowの各項目を確認してから、ログで未対応の項目、認証エラー、ポートの競合がないか調べてください。追加に成功しても、確認できたのは解析処理だけです。ローカルポートが使用中なら、重複して起動しているクライアントを終了してください。リモートポートをすぐに変更する必要はありません。
VLESSノードをv2rayNGからv2flyNGへそのまま移せますか？
まず設定の組み合わせ全体を確認してください。REALITYなどXray固有のパラメーターを含む設定は、一般的なVLESSノードと同じようには扱えません。移行元の設定を残したうえで、移行先の項目とログを確認します。移行先のコアが対応していない場合は、そのノードに合ったクライアントを使うか、サーバー側で互換性のある設定を用意してください。
画面では接続中なのにWebサイトが開けません。まずコアを変更すべきですか？
最初にWebサイトへアクセスし、該当するリクエストがログに記録されているか確認してください。リクエストがない場合は、システムプロキシ、VPNの許可、アプリごとの適用範囲を確認します。リクエストがある場合は、DNS、ルーティング、リモート側のエラーを調べてください。画面上の接続状態だけでは、Webサイトまでの経路が確立しているとは限りません。
アップデート後に問題が起きた場合、何を記録すればよいですか？
アップデート前後のクライアントのバージョン、実際に使用しているコアのバージョン、ノードのプロトコルと通信方式、最初に発生した関連エラーを記録してください。元のノードとルーティング設定で再現し、元に戻せる設定も残します。ログを共有する前に、サブスクリプションURL、サーバーの認証情報、ユーザーIDを削除し、問題の切り分けに必要な内容だけを共有してください。
コア選びでは、設定全体を正しく反映し、安定して実行できるかが判断基準です。プロジェクトの経緯、コアの機能、クライアントの画面、システム通信の入口を分けて記録しておけば、今後のアップデートや移行、トラブルシューティングも順序立てて確認できます。初めて設定する方はインストール・設定の手順を、起動や通信の制御で問題が起きた場合はヘルプセンターをご覧ください。