コアを選ぶときは、まずノードの設定内容を確認し、その後にクライアントを選びましょう。VLESSとREALITYは別のもので、VLESSがXray専用というわけでもありません。REALITYやxtls-rprx-visionを含む設定は、Xrayの対応状況を基準に選んでください。既存のVMess設定が安定して使えているなら、名前が変わるという理由だけで移行する必要はありません。ここでは、プロジェクトの関係、プロトコルの組み合わせ、Androidクライアント、移行時の確認手順を順に解説します。
開発系統の分岐：XrayとV2Flyは同じコアの設定違いではない
Project Vは、関連ツールやプロトコルを含むプロジェクトのエコシステムです。その中でV2Rayは、広く知られているコアソフトウェアの名称です。V2Flyコミュニティはv2ray-coreの開発を継続しており、Xray-coreは2020年にV2Rayのコードをベースに分岐しました。歴史や設定の考え方には共通点がありますが、その後の機能開発、リリース周期、設定項目は完全には一致しません。
そのため、「V2Rayクライアント」という名称だけでは、どのコアが動作しているかは分かりません。クライアントはサブスクリプション管理、ノード選択、画面操作を担当し、コアは接続の確立、インバウンド・アウトバウンドの処理、ルーティングを担います。画面にノード名が表示されていても、実際に生成された設定が現在のコアで受け付けられるとは限りません。
- プロジェクト：V2FlyとXrayは異なる開発系統です。バージョン番号を数字の大小だけで比較することはできません。
- コア：ウィンドウのタイトルやインストール先のフォルダー名ではなく、起動ログに表示されたコア名とバージョンを確認してください。
- クライアント：v2rayNはデスクトップ向けクライアントです。この記事では、Android向けにv2rayNGとv2flyNGを比較します。
- ノード：同じプロトコル名でも、トランスポート、セキュリティ層、追加フィールドを含めて互換性を判断する必要があります。
プロトコル対応：VLESS・REALITY・Visionを分けて考える
ノードの互換性は、少なくとも4つの層で確認します。プロキシプロトコル、下位のトランスポート、トランスポートのセキュリティ、プロトコル固有の追加動作です。VMessとVLESSはプロキシプロトコル、WebSocketはトランスポート方式、TLSとREALITYはトランスポートのセキュリティに関わる設定です。xtls-rprx-visionは特定の組み合わせで使うflow値であり、単独のノードプロトコルではありません。
| 設定項目 | Xray | V2Fly | 確認ポイント |
|---|---|---|---|
| VMess + WebSocket + TLS | 主な対応状況 | 主な対応状況 | アドレス、ポート、パス、Host、TLSのサーバー名 |
| VLESS | 対応。設定全体の組み合わせを確認 | VLESSには対応しているが、Xray独自の拡張にも対応するとは限らない | トランスポート、セキュリティ層、flow、バージョン要件 |
| REALITY | 対応するバージョンと組み合わせで使用 | XrayのREALITY設定との互換性を前提にしない | サーバー名、公開鍵関連のパラメーター、shortId |
| xtls-rprx-vision | Xrayで対応する組み合わせとバージョンで使用 | そのflowをそのまま流用できない | サーバー側のflowとクライアントのトランスポート構成 |
たとえば、VLESSノードにsecurity=realityとflow=xtls-rprx-visionの両方が設定されている場合は、その組み合わせに対応するXrayコアを選んでください。逆に、vless://で始まるというだけでは、REALITYが必須とは限らず、すべてのVLESS対応クライアントで利用できるとも限りません。
- 互換性を「直す」ためにREALITYを通常のTLSへ変更しないでください。サーバー設定も同時に変更しない限り、同等の置き換えにはなりません。
- flowを削除しただけで互換性が確保されたと判断しないでください。設定を読み込めても、ハンドシェイクで失敗することがあります。
- VMessも時刻同期、ユーザーID、トランスポート設定の確認が必要です。プロトコルに対応していても、設定が正しいとは限りません。
クライアントの選び方：Androidはノードの要件から、デスクトップはコアの確認から
Androidでは、v2rayNGとv2flyNGの主な違いは、組み込まれているコアの系統です。Xrayの機能を必要とするノードにはv2rayNGが適しています。V2Fly向けの設定で運用していて、Xray固有の項目に依存しない環境なら、v2flyNGを引き続き利用できます。ここでのおすすめは設定の互換性に基づくもので、あらゆるネットワーク環境での性能ランキングではありません。
v2rayNG · Xrayコア
おすすめAndroidのノードにREALITYやVisionなどXrayの機能が含まれる場合は、該当フィールドを読み込めるバージョンのv2rayNGを優先してください。インポート後も、ノードの詳細と起動ログを確認しましょう。
おすすめ：AndroidでXray設定を使う場合、サブスクリプションにREALITYノードが含まれる場合。
v2flyNG · V2Flyコア
動作確認済みのV2Fly設定に適しています。VMessなど両方で使えるプロトコル構成は、実際のトランスポート設定を基準に判断してください。開発系統が分岐しているという理由だけで、クライアントを変更する必要はありません。
おすすめ：AndroidでV2Fly設定を継続し、既存のルーティングや使い方を維持したい場合。
デスクトップでv2rayNを使う場合は、現在のインストーラー、設定の種類、クライアントのバージョンで、どのコアを選べるか確認してください。すべてのバージョンで同じ場所に同じ切り替えボタンがあるとは限りません。設定を変更したら、選択した構成を再起動し、実際に読み込まれたコアをログで確認しましょう。ダウンロードフォルダーにコアのファイルがあっても、現在の接続で使われているとは限りません。
2つの設定環境に合わせた選び方
ノードがXrayの機能に依存する場合
- デスクトップ：v2rayNで対応するXray設定を使用
- Android：同じ提供元の互換性があるサブスクリプションをv2rayNGにインポート
- REALITYのパラメーターとflowを確認し、提供元の値をそのまま使用
既存のV2Fly設定が使える場合
- Android：v2flyNGで動作確認済みのノードを継続使用
- デスクトップ：v2rayNの現在のバージョンでの対応状況に合わせて設定
- 移行前にサブスクリプション、ルーティング、DNS設定をそれぞれ保存
同じサブスクリプションを使っていても、設定の配布元が同じというだけです。両方のクライアントでフィールドの解析、ルーティング、DNS設定を個別に確認してください。
切り替え時の確認：ローカルポート、サブスクリプション変換、ルーティング
コアを変更した後にWebページが開けなくても、プロトコルの互換性が原因とは限りません。以前のクライアントがローカルの待ち受けポートを使用中だったり、ブラウザーが古いポートを参照していたりする可能性があります。以下の2つの数値はSOCKSとHTTPの入口を示す例で、すべてのクライアントやバージョンのデフォルト値ではありません。実際の設定と起動ログを確認してください。
- 元の設定を保存する。サブスクリプションの配布元、選択中のノード、DNS、ルーティング、ローカルポートを記録してください。サブスクリプションURLにアクセス認証情報が含まれる場合があるため、バックアップを公開しないでください。
- 古い接続を停止する。別のクライアントのプロキシ接続を終了してください。Androidでは、先に既存のVPN接続を停止してから目的のクライアントを起動し、接続の引き継ぎ問題をプロトコルの問題と誤認しないようにします。
- サブスクリプションを再インポートする。提供元が出力する形式が、移行先のクライアントに適しているか確認してください。一方のコア向けの完全なJSONを、もう一方でも使える汎用設定としてそのまま渡さないでください。
- 実際の待ち受けポートを確認する。アプリの接続先が
127.0.0.1:10809なのに、ログに別のHTTPポートしか表示されない場合は、ノードを何度も切り替えるのではなく、アプリのプロキシ設定を修正してください。 - ルーティングを個別に確認する。まず目的の接続が確立することを確認し、次に直接接続すべき通信とプロキシ経由にすべき通信が意図した経路を通るか検証します。最後にカスタムルールを戻してください。
サブスクリプションの更新に成功したということは、内容を取得してクライアントで解析できたことを示すだけです。すべてのフィールドが保持されたとは限りません。移行後にノードの詳細からサーバー名、WebSocketパス、REALITYのパラメーターが欠けている場合は、名前から値を推測して書き足さず、設定の提供元に対応形式を問い合わせてください。カスタムDNS、ドメインのマッチング方針、ルールセットも、ノード一覧が同じだからといって自動的に同等になるわけではありません。
ログの見方：起動失敗と接続失敗を分けて確認
コアが起動したということは、少なくとも現在のバージョンで設定の読み込みを通過したという意味です。接続の失敗は、名前解決、TCP接続、TLSやREALITYのハンドシェイクなど、さまざまな段階で起こり得ます。「コアを変えたから遅くなった」と決めつけるより、どの段階で問題が起きたかを特定しましょう。
| ログの手がかり | まず確認すること | 次の対応 |
|---|---|---|
unknown fieldまたは設定の解析エラー |
フィールド、形式、コアのバージョンが不一致 | インポート形式、実際に使われているコア、エラーが出たフィールドを確認し、セキュリティ設定はすぐに削除しない |
address already in use |
ローカルの待ち受けポートが使用中 | 重複して起動しているクライアントを停止するか、待ち受けポートを変更してアプリのプロキシ設定も合わせる |
timeout |
ログの前後関係からタイムアウトが起きた段階を特定 | サーバーのアドレスとポート、ネットワークを確認し、その後ハンドシェイクのパラメーターを確認 |
| ハンドシェイクに関するエラー | セキュリティ層のパラメーターとサーバー設定が不一致 | サーバー名、時刻、認証パラメーターを確認し、設定の提供元に問い合わせる |
クライアント選びのQ&A：コア名だけで速度や互換性を判断しない
サブスクリプションがVMessだけの場合、Xrayに切り替える必要はありますか？
名称だけを理由に変更する必要はありません。まず現在のトランスポート方式、TLS、ルーティングが正常に動作しているか確認しましょう。既存のV2Fly設定が使えているなら、そのまま利用できます。移行する場合は、同じノードで機能を一つずつ比較し、DNSや振り分けルールを同時に変更しないようにしてください。
v2flyNGにVLESSをインポートしたのに接続できない場合、何を確認すればよいですか？
ノードの詳細を開き、REALITYまたはxtls-rprx-visionが含まれているか確認してください。これらのXray機能が必要な場合は、その組み合わせに対応するv2rayNGに切り替え、提供元から設定を再インポートしましょう。認識されないフィールドを削除するだけでは解決になりません。
同じノードなら、Xrayのほうが必ずV2Flyより速いですか？
そのようには判断できません。サーバー、トランスポートの組み合わせ、接続ネットワーク、テスト対象をそろえたうえで、接続成功率と実際の通信状況をそれぞれ確認してください。ノードまでの経路、サーバー負荷、DNSの違いは、コアの名称より結果に大きく影響することがあります。
コアを切り替えた後、TUNを再度有効にする必要はありますか？
まず、以前どの方法で通信を取り込んでいたか確認してください。ブラウザーがシステムプロキシを使用している場合は、TUNを無効のまま接続を検証できます。システムプロキシを参照しないアプリの通信も取り込む必要がある場合に限り、クライアントの手順に従ってTUNを有効にし、権限とルーティングを確認してください。
選び方は3段階で整理できます。まずノードがXrayの機能に依存しているか確認し、次に設定を正確に扱えるクライアントを選び、最後にログとローカルの通信入口を確認します。V2FlyとXrayの歴史的なつながりだけでは互換性を判断できず、クライアントの画面が似ていても、インポート後の設定が完全に一致するとは限りません。