Project Vはプロジェクト全体を指し、V2FlyとXrayはそれぞれ異なる方針でコアを開発しています。v2rayN、v2rayNG、v2flyNGは設定を管理し、コアを起動するGUIクライアントです。複数の端末でサブスクリプションを使いたい方や、VLESS・REALITYへの対応状況を確認したい方に向けて、名称の違い、ノード設定とコアの機能、クライアントの選び方を解説します。
Project V、V2Rayと2つのコア開発系統の関係
Project Vは当初、モジュール式のネットワークプロキシツールを中心に展開し、その中でもV2Rayが広く知られるようになりました。初期のドキュメントでは「V2Ray」がプロジェクト全体を指す場合と、通信を実行するコアプログラムを指す場合があります。現在、問題を調べる際は具体的な実装とバージョンを確認しましょう。「V2Ray対応」という表現だけでは、どの設定に対応するか判断できません。
V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、一般に「V2Rayコア」「v2flyコア」はこの系統を指します。Xray-coreはV2Rayのコードを基盤に分岐し、その後独自の機能とリリースサイクルを持つようになりました。共通の出自があっても、新機能や設定項目、デフォルトの動作が常に同じとは限りません。
- プロジェクト：Project Vはエコシステムの成り立ちを示す名称で、スマートフォンの接続ボタンを指すものではありません。
- コアプログラム：V2Flyが保守するV2RayとXray-coreが、プロトコル処理、トランスポート、DNS、ルーティングなどを実行します。
- GUIクライアント：v2rayN、v2rayNG、v2flyNGは、サブスクリプションの取り込みや設定編集、プロセス管理、システムへの接続設定を行います。
- 接続設定：サーバーアドレス、ポート、ユーザーID、トランスポート方式、セキュリティ設定などを指し、上記のいずれのプロジェクトとも別のものです。
そのため、「v2rayNGをインストールしている」と「Xrayコアを実行している」は両立します。前者は操作画面、後者は実際に通信を行うプログラムを示します。エラーが発生した場合は、クライアントとコアの両方のバージョンを記録してください。アプリ名だけでは、特定の設定項目に対応しているか判断できないことがあります。
3つのクライアントと対応するコア
v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けです。名前の大文字・小文字も区別しましょう。v2rayNとv2rayNGは別のアプリであり、v2flyNGもv2rayNGの画面を置き換えたものではありません。まず利用するOSを確認し、次に実際に使うコアを確かめてください。
| クライアント | 対応プラットフォーム | コアとの関係 | 選ぶ前に確認すること |
|---|---|---|---|
| v2rayN | Windows、macOS、Linuxのデスクトップ | 複数のコアに対応するデスクトップ設定管理ツール。実際に使うコアはバージョン、設定、コアの選択内容によって異なります。 | 現在の設定で呼び出すコア、インストールパッケージに含まれるコンポーネント、システムプロキシまたはTUNの接続方式。 |
| v2rayNG | Android | Xrayコアを採用。 | ノードが必要とするXrayの機能、アプリに組み込まれたコアのバージョン、VPN接続の許可。 |
| v2flyNG | Android | V2Flyが保守するV2Rayコアを採用。 | ノードの設定項目が使用中のコアのバージョンに対応しているか。特に別系統独自の拡張項目を確認してください。 |
v2rayNという名前でも、V2Flyのコアしか使えないわけではありません。一方、デスクトップ版でコアを選択できても、設定ファイルを読み込むだけでAndroidアプリの内蔵コアを置き換えられるわけではありません。インストーラー、GUI、コアプログラムには、それぞれバージョン上の制約があります。
v2rayNG：Android向けのXray系クライアント
おすすめノードでXrayのVLESS、REALITY、Vision関連機能が明示的に必要な場合は、まずこの組み合わせを確認してください。ここでのおすすめは該当するノード要件に対するもので、あらゆるネットワーク環境で高速になるという意味ではありません。
おすすめの用途：Androidで使い、サーバー側のドキュメントがXrayの設定を前提としている場合。
v2flyNG：Android向けのV2Fly系クライアント
V2Flyのドキュメントに沿って管理された設定を使う環境に適しています。VMess、WebSocket、TLSなどの一般的な組み合わせも、対応状況はバージョンや設定によって異なります。プロトコル名だけで互換性を判断しないでください。
おすすめの用途：V2Fly用の設定があり、Xray固有の拡張機能を必要としない場合。
v2rayN：デスクトップで設定とコアを管理
デスクトップでサブスクリプションやルーティングをまとめて管理できます。ノードを移行する際は、一覧に表示されているかだけでなく、現在の設定がどのコアを呼び出しているかを確認してください。
おすすめの用途：システムプロキシやローカル待ち受けを管理したいWindows、macOS、Linuxのデスクトップ環境。
VMess、VLESS、WebSocket、REALITYは同じ階層の用語ではない
1つのノード設定に複数の用語が含まれることがあります。たとえば「VLESS + WebSocket + TLS」は、3つから1つを選ぶプロトコルボタンではなく、認証・プロキシプロトコル、トランスポート方式、セキュリティ層を組み合わせた設定です。いずれかの階層を取り違えると、一覧には表示されてもハンドシェイクに失敗することがあります。
| 階層 | 主な名称・設定項目 | 確認ポイント |
|---|---|---|
| プロキシプロトコルと認証情報 | VMess、VLESS、UUID | プロトコルをサーバー側の設定に合わせます。VLESS自体にはペイロードを暗号化する機能がないため、安全性は使用するセキュリティ層と併せて判断してください。 |
| トランスポート方式 | TCP、WebSocket、gRPC | トランスポートの種類に加え、WebSocketのpathやHost、gRPCのserviceNameなど、対応する設定項目を確認します。 |
| 接続のセキュリティ | TLS、REALITY、serverName | サーバーが要求する名前とセキュリティ設定を確認します。REALITYは汎用的なトランスポート方式ではありません。 |
| フロー制御と拡張機能 | flow、xtls-rprx-vision | 使用中のコアが指定値に対応しているか、その値が現在のトランスポートの組み合わせで使えるかを確認します。 |
VLESSという名称だけでは、設定がXray専用とは判断できません。重要なのは、どの拡張機能と組み合わせているかです。VLESS + REALITYと標準的なVLESS設定では要件が異なります。v2flyNGでセキュリティ方式をTLSに変えれば、同等の設定として移行できるわけではありません。サーバー側に対応するTLSの接続口がなければ、クライアント側の設定変更だけで互換性が生まれることもありません。
結論：設定の組み合わせ全体でコアを選ぶ
まずノードの編集画面を開き、プロトコル、トランスポート、セキュリティ方式、flowの4項目を記録します。REALITYまたはxtls-rprx-visionが含まれる場合は、該当バージョンのXray要件を確認してください。「VLESS」という名前だけでクライアントを選ばないようにしましょう。
共有リンク、サブスクリプション、完全な設定ファイルの互換性
「インポートできた」ことは、クライアントが入力形式を認識したという意味にすぎず、使用するコアがすべての設定項目に対応するとは限りません。移行時は、単一の共有リンク、サブスクリプションの内容、完全なJSON設定を区別しましょう。それぞれ含まれる情報が異なります。
- 単一の共有リンク：通常は1つのアウトバウンド接続を記述します。VMessの共有リンクではBase64でエンコードされた内容が一般的です。VLESSの共有リンクでは、URIのクエリパラメーターにトランスポートやセキュリティ設定が含まれることがあります。インポート後に編集画面を開き、重要な項目が欠けていないか確認してください。
- サブスクリプションURL：複数の設定をまとめたデータを取得するURLです。サーバーからBase64形式の共有リンク一覧が返る場合もあれば、クライアントごとに異なる内容が返る場合もあります。同じURLを使っていても、取得できる項目や設定が完全に一致するとは限りません。
- 完全なJSON設定：インバウンド、アウトバウンド、DNS、ルーティング、ログ、参照タグなどが含まれる場合があります。2つのコアに同じ名前のトップレベル項目があっても、具体的な意味や選択肢、必要なバージョンが異なることがあるため、そのまま置き換えて実行しないでください。
たとえば、Xray固有のセキュリティ項目を含む完全なJSONをV2Fly環境に読み込むと、設定の読み込み時に未対応エラーが発生したり、接続時に問題が表面化したりすることがあります。まずノードを1つだけ移行し、移行先クライアントのインバウンド設定とルーティング設定は維持してください。接続を確認してから、ほかの機能を順に移行する方法が安全です。
デスクトップとAndroidでサブスクリプションを共有する手順
複数の端末で使う場合は、まず同じノード情報を取得できる状態にし、その後、各端末で接続方法を設定します。v2rayNのシステムプロキシは、主にシステムプロキシ設定に従うアプリで利用されます。v2rayNGとv2flyNGは、AndroidのVPNサービスを通じて通信を取り込むことが一般的です。これはOSの接続インターフェースの違いであり、コアの優劣を示すものではありません。
設定方針：ノード情報は共有し、システムへの接続方法は個別に設定
デスクトップ：v2rayN
- 「サブスクリプショングループ」→「サブスクリプショングループの設定」からURLを追加し、「サブスクリプショングループ」メニューで更新します。項目名はバージョンによって異なる場合があります。
- ノードを1つ選び、使用するコアとセキュリティ設定を確認してから接続を開始します。
- ブラウザーで使う場合は「システムプロキシを設定」を選びます。ターミナルアプリでは、プロキシの環境変数も別途確認してください。
Android：v2rayNGまたはv2flyNG
- v2rayNGの場合、サイドメニューの「サブスクリプショングループの設定」からURLを追加し、メイン画面に戻って「サブスクリプションを更新」を実行します。
- インポートした設定のトランスポート、セキュリティ方式、flowを確認します。ノードを選択して接続ボタンをタップしてください。
- 初回接続時にAndroidのVPN接続を許可します。アプリごとにプロキシを設定する場合は、端末のアプリ一覧から個別に設定してください。
サブスクリプションの共有でノードの登録作業は減らせますが、更新タイミング、ルーティング、DNS、アプリの接続方法は各端末で確認が必要です。
ローカル接続を調べる際は、「サーバーポート」と「ローカルの待ち受けポート」を区別してください。前者はリモートサーバーの接続口、後者はブラウザーやターミナルがローカルプロキシに接続するための入口です。以下は接続経路を理解するための例であり、3つのクライアントに共通するデフォルト値ではありません。
HTTP待ち受けを実際に127.0.0.1:10809に設定した場合、別の端末のSOCKSポートをそのまま使うことはできません。v2rayNでは「設定」→「パラメーター設定」からローカル待ち受け関連の項目を確認できます。バージョンによってはHTTPとSOCKSで1つのポートを共有する混合待ち受けに対応しています。現在の画面表示と実行ログを確認してください。
- まずコアの動作を確認：設定の読み込み失敗や待ち受けポートの競合などのエラーがログにないか確認します。
- 次にアプリの接続を確認：デスクトップのブラウザーがシステムプロキシを使っているか、AndroidでVPN接続が確立しているかを確認します。
- 最後にルーティングを確認：リクエストが想定したアウトバウンドに振り分けられているか確認します。「直接接続」のルールは、ノードを切り替えても自動でプロキシ接続には変わりません。
クライアント選びと移行でよくある4つの質問
クライアント、コア、ノード設定にはそれぞれ異なる役割があります。ここでは操作時によくある疑問を取り上げ、接続失敗をすべて「コアの互換性」の問題と決めつけないための確認方法を紹介します。
v2rayNとv2rayNGは名前が似ていますが、設定フォルダーを丸ごとコピーできますか？
設定フォルダーを異なるプラットフォーム間の移行形式として使うことはできません。移行元のクライアントで単一の共有リンクを書き出し、移行先で「クリップボードからインポート」などの機能を使って取り込んでください。サブスクリプションURLも再登録できます。ローカルポート、システムプロキシ、アプリごとの設定は移行先で設定し直してください。
同じサブスクリプションがv2rayNGでは使えるのに、v2flyNGでは失敗します。まず何を確認すればよいですか？
同じノードの編集画面を開き、プロトコル、トランスポート、セキュリティ方式、flowを比較します。REALITYまたはxtls-rprx-visionが含まれる場合は、項目を削除して無理に保存しないでください。該当する組み合わせに対応したXray環境を使うか、V2Fly向けに調整された別の接続設定をサービス提供元に確認しましょう。
コアを切り替えた後、遅延テストは正常なのにブラウザーで接続できない場合は？
まずテストの種類を確認します。TCP接続テストでわかるのは、通常、対象ポートに到達できるかどうかであり、プロキシ経由の通信が成功することまでは保証しません。次に、ブラウザーがローカルプロキシを使っているか、適切なアウトバウンドが選択されているかを確認し、ログでハンドシェイクやDNSのエラーを調べてください。問題を切り分けずにサブスクリプションを何度も更新するのは避けましょう。
クライアントを更新すれば、サーバーの新機能に必ず対応できますか？
必ずしもそうではありません。「バージョン情報」または起動ログでクライアントとコアのバージョンを記録し、編集画面で新しい設定項目を保存できるか確認します。GUIが設定項目を認識し、実行コアがその機能を実装している必要があります。片方だけを更新しても、項目が失われたり、設定の読み込みに失敗したりする場合があります。
最終的には、端末のOS、ノードが必要とする設定の組み合わせ、現在のバージョンでその設定を入力・実行できるか、という3点で選べます。すでに安定して接続できているなら、コアの系統名だけを理由に移行する必要はありません。移行が必要な場合は元の設定を残し、まずノードを1つ使って動作確認してから、サブスクリプション、DNS、ルーティングへと範囲を広げてください。