Project Vはプロジェクト全体を指し、V2FlyとXrayは異なるコアの開発系統、v2rayN・v2rayNG・v2flyNGはユーザーが操作するクライアントです。ダウンロードするファイルの選択、ノードとの互換性確認、「インポートできたのに接続できない」といった問題の切り分けに役立つ内容です。プロジェクト、コア、クライアント、プロトコルの関係を整理してから、プラットフォームとサーバー設定に合わせて選びましょう。
Project V、V2Ray、V2Fly：プロジェクトと実装の違い
Project Vは当初、モジュール型のネットワークプロキシツールを中心に展開されました。その中核的な実装としてよく知られているのがV2Rayです。特定のプロキシプロトコルだけでなく、インバウンド、アウトバウンド、ルーティング、DNSなども扱います。そのため、日常的に使われる「V2Rayノード」という呼び方は広い意味を持ち、VMessを使っているとは限りません。また、クライアントがV2Flyのコアを実行しているとも限りません。
V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、コアプログラムは現在も通常V2Rayという名称です。一方、XrayはV2Rayのコードを基盤に分岐し、独自に開発が進むXray-coreとして発展しました。共通の歴史はありますが、同じプログラムの表示名が異なるだけではなく、順番にインストールする必要がある依存関係でもありません。
- プロジェクト：Project Vはエコシステムの成り立ちを理解するための背景であり、個別にインストールするデスクトップアプリではありません。
- 接続コア：V2FlyのV2RayとXray-coreが設定を解析し、接続を確立してルーティングを実行します。
- GUIクライアント：v2rayNなどがサブスクリプション管理、ノード一覧、設定編集、コアの起動を担います。
- 接続プロトコル：VMess、VLESS、Trojan、Shadowsocksは接続方式を定めるもので、クライアント名とは異なります。
この4つの層を理解すれば、「v2rayNを使い、VLESSノードをインポートして、Xrayで接続する」という説明に矛盾がないとわかります。3つの名称はそれぞれ、画面、プロトコル、実行プログラムを指しています。問題を調べる際も、「V2Rayがつながらない」と一括りにせず、この3項目を分けて記録しましょう。
V2FlyとXray：共通の基盤と異なる機能範囲
どちらの系統も、複数プロトコルのプロキシ、ルーティング、DNSなどの基本機能を備えています。ただし、具体的なトランスポート方式、設定項目、拡張機能はバージョンによって異なります。「あるコアがVLESSに対応している」からといって、「あらゆるVLESSの組み合わせに対応する」とは限りません。プロトコル、トランスポート、セキュリティ層、拡張パラメーターを含む全体の構成を照合する必要があります。
| 比較項目 | V2Fly / V2Ray | Xray-core |
|---|---|---|
| プロジェクト上の関係 | V2Rayの開発を引き継ぐコミュニティ系統 | V2Rayから分岐し、独自に開発 |
| 基本機能 | インバウンド、アウトバウンド、DNS、ルーティング、プロトコル処理 | インバウンド、アウトバウンド、DNS、ルーティング、プロトコル処理 |
| 設定の互換性 | 該当バージョンのV2Ray設定仕様に準拠 | 共通する設定基盤はあるが、拡張項目を一律に置き換えることはできない |
| 代表的な注意点 | Xray独自の機能を共通機能として扱わない | REALITYやXTLS Visionなどは、対応する実装とバージョンに合わせた設定が必要 |
| この記事で扱うAndroidクライアント | v2flyNG | v2rayNG |
たとえばサーバー側でVLESS、REALITY、xtls-rprx-visionが必要な場合は、クライアントが実際に呼び出すコアがこの構成に対応していることを確認し、公開鍵、Short ID、サーバー名、flowも照合してください。プロトコルの選択をVLESSに変えるだけ、あるいはプログラムのファイル名を置き換えるだけでは、必要な条件を満たせません。
結論：ノードの設定に合わせてコアを選ぶ
まずサーバーが要求するプロトコル、トランスポート、セキュリティ層を確認し、次にコアの対応範囲を調べましょう。クライアント名に「v2ray」とあることだけで互換性を判断してはいけません。Xray固有の機能が必要な場合は、実際に対応バージョンのXrayが動作しているかを確認してください。
3つのクライアント：対応プラットフォームとコアの比較
クライアントはグラフィカルな操作画面を提供し、実際の接続はコアが担います。クライアントの更新では画面や設定生成の仕組みが変わることがあり、コアの更新ではプロトコル実装や設定の検証ルールが変わることがあります。両者のバージョンは個別に確認し、「最新版」の一言で済ませず、それぞれ記録しましょう。
| クライアント | 対応プラットフォーム | コアとの関係 | 選び方のポイント |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | デスクトップクライアント。Xray、sing-boxなどのコアを利用できます。選択肢はバージョンと配布パッケージによって異なります | まずOSとアーキテクチャを選び、プロトコルに合ったコア設定を確認 |
| v2rayNG | Android | Xrayコアを使用 | Xray対応のプロトコルや拡張機能が必要な場合は、組み込みコアのバージョンを確認 |
| v2flyNG | Android | V2FlyのV2Rayコアを使用 | V2Fly系を使う場合は、ノードのトランスポート方式とセキュリティ層への対応を確認 |
v2rayNはV2Flyコアの別名ではありません。また、複数のコアをサポートしていても、すべての配布パッケージに選択可能なプログラムが一式含まれているとは限りません。デスクトップ版と従来型の画面では、利用できる機能や設定画面が異なる場合があります。実際にどのコアが動作しているかは、設定と起動ログで確認してください。sing-boxは別系統のコア実装であり、V2FlyとXrayの間のバージョンアップにあたるものではありません。
v2rayNGとv2flyNGは名前が似ていますが、アイコンだけを変えた同じインストールパッケージではありません。どちらもAndroid向けですが、コアの系統が異なります。同じ共有リンクをインポートできても、トランスポート拡張や設定項目への対応は異なる場合があります。クライアントを切り替える前に元のノード情報を保存し、インポート時に変換された設定をサーバーの元設定と混同しないようにしましょう。
v2rayNで実行中のコアを確認する
以下では中国語UIのv2rayNを操作例として説明します。デスクトップ版によってタブ名が多少異なり、「Coreタイプ」が「Coreタイプ設定」と表示されることもあります。設定を確認したうえで再起動後のログと照合する方法が、プログラムフォルダー内のファイル名から推測するより確実です。
-
バージョンを確認
「ヘルプ」→「バージョン情報」を開き、クライアントのバージョンを記録します。次にメイン画面のログでコアの起動情報を確認し、コア名とバージョンを記録してください。トラブル情報を共有するときは、両方を記載しましょう。
-
コアの割り当てを確認
「設定」→「パラメーター設定」→「Coreタイプ」を開き、現在のプロトコルに割り当てられているコアを確認します。そのバージョンに該当項目がない場合は、他のバージョンの画面を参考にせず、起動ログで確認してください。
-
ノード設定を確認
ノード一覧で対象を選択し、右クリックして「サーバーを編集」を開きます。プロトコル、ポート、トランスポート方式、TLSまたはREALITYの設定を項目ごとに照合してください。画面上でインポートに成功したことは、設定情報が登録されたことを示すだけで、コアがその設定を受け付けたことまでは意味しません。
-
再接続する
設定を保存したら対象ノードを右クリックし、「アクティブサーバーに設定」を選んで現在の設定を反映します。接続テストの前に、ログで未対応の設定項目、コアの起動失敗、ポートの競合がないか確認してください。
接続中にコアの実行ファイルをむやみに置き換えないでください。画面側の設定生成方式とコアが受け付ける形式には互換性が必要です。更新後に設定の解析エラーが起きた場合は、まず動作するクライアント一式に戻し、差異を一つずつ特定しましょう。複数のコアファイルを続けて置き換えるより、問題を再現しやすくなります。
ポート、システムプロキシ、ルーティング：別々の設定項目
コアの起動に成功しても、アプリの通信をクライアントへ流す設定が必要です。デスクトップではシステムプロキシや、アプリごとに指定するローカルプロキシが一般的です。TUNは仮想ネットワークインターフェースとルーティングの制御を伴います。Androidクライアントでは通常、システムのVPN許可を通じて通信を取り込みますが、この許可画面からノードのプロトコルが決まるわけではありません。
これらはポートの用途例であり、すべてのバージョンで設定すべき既定値ではありません。バージョンによっては混合インバウンドを使い、HTTPとSOCKSが同じポートを共有します。別々のポートで待ち受ける設定もあります。「設定」→「パラメーター設定」のローカル待ち受け関連項目で実際の値を確認し、ログと照合してください。リモート側のポートはサーバーが決めるため、TLSという理由だけで443に変更してはいけません。
- ローカル接続口：アプリは
127.0.0.1とクライアントの待ち受けポートに接続します。ポートが使用中だと接続口を確立できません。 - システムプロキシ：システム設定に従うアプリにプロキシの利用を指示します。すべてのアプリがこの設定を参照するわけではありません。
- ルーティング：コアに入ったリクエストをプロキシ、直接接続、遮断のどれにするか決めます。システムプロキシを有効にしても、すべての通信がリモート経由になるとは限りません。
- DNS：名前解決の経路、ルールによる振り分け、対象ドメインの一致条件が結果に影響するため、ログと合わせて確認してください。
サブスクリプションはインポートできるのに接続できない：層ごとの確認方法
サブスクリプションは設定を配布する方法であり、新しいプロキシプロトコルではありません。更新によって複数の異なるプロトコルのノードを取得できても、クライアントに不足しているコア機能が追加されるわけではありません。QRコード、クリップボード、サブスクリプションのいずれから読み込んでも、最終的にはクライアントでの解析、設定生成、コアの実行を経由します。
同じサブスクリプションなのに、クライアントによって結果が違うのはなぜ？
まず同じノードのプロトコル、トランスポート、セキュリティ層、拡張パラメーターを照合し、それぞれの起動ログを確認してください。一方でREALITYの公開鍵やflowが欠落している場合は、元のリンクから再インポートして編集画面を確認します。ノード名だけを比べても原因は特定できません。
Xrayに変えれば必ず接続できる？
まずノードが実際にXray固有の機能を必要としているか確認し、次にアドレス、ポート、認証情報、サーバー名、端末の時刻を調べてください。コアの互換性で解決できるのは実装機能の問題です。サーバーに到達できない、証明書が一致しない、認証情報が無効といった場合は、やはり接続に失敗します。
遅延は表示されるのに、Webページが開かない？
まずテストの種類を確認しましょう。TCPポートに到達できても、プロキシ経由の通信全体が成功したとは限りません。システムプロキシが指定するローカルポートを確認してから、実際の接続をテストします。ログを見てリクエストがコアに届いているか、どのルーティングルールが適用されたかを確認してください。
クライアント更新後、サブスクリプションを再追加する必要はある？
通常は不要です。元のサブスクリプショングループとノードが残っていることを確認し、更新後のコア選択、ローカル待ち受け、ルーティング設定を照合してください。再インポートが必要な場合は、先に設定をバックアップします。ログを公開する前に、サブスクリプションの完全なURLと認証情報を削除してください。
選ぶ順番：プラットフォーム、設定、コア、動作確認
普段使いのクライアントを選ぶ際、2つのコアに一律の優劣をつける必要はありません。デスクトップではv2rayNの対応OSとプロセッサーアーキテクチャから確認し、Androidではノードの要件に応じてv2rayNGとv2flyNGを比較します。まずサーバーのプロトコル構成を満たし、そのうえでサブスクリプション管理、ルーティング編集、操作性を検討しましょう。
- 利用するプラットフォーム（Windows、macOS、Linux、Android）を確認し、対応するプロセッサーアーキテクチャを選びます。
- 必要な設定をすべて確認します。プロトコル、アドレス、ポート、トランスポート、セキュリティ層、必須の拡張項目を把握してください。
- クライアントと実際に使うコアのバージョンを確認し、その組み合わせが設定を認識できることを確かめます。
- インポート後にログを確認し、ローカル接続口、システムプロキシ、実際のWebリクエストをテストします。
プロトコルとセキュリティ層の違いを詳しく知りたい場合はプロトコル解説をご覧ください。メニュー、サブスクリプションの更新、ルーティング設定については使い方ガイドをご利用ください。「クライアントのバージョン、コアのバージョン、プロトコル構成、エラーログ」の4項目を記録しておくと、クライアントを何度も入れ替えるより問題の特定に役立ちます。