XrayとV2Flyのコアの違い｜分岐の経緯・プロトコル対応・クライアントの選び方

分岐の経緯：V2FlyとXrayはクライアントの別テーマではない

Project Vは、関連ツールやプロトコルが発展してきたプロジェクトの背景です。V2Rayはその中で広く使われているプロキシコアです。V2FlyコミュニティはV2Rayコアと関連プロジェクトの保守を引き継いでいるため、「V2Rayコア」「V2Flyコア」という呼び方が併用されています。互換性を具体的に議論する際は、プロジェクト名、バージョン、設定形式を明記しましょう。「V2Rayを使っている」だけでは情報が足りません。

Xrayは2020年にV2Rayのコードを基に分岐し、その後は独自の方針で開発されています。分岐の背景には、当時のXTLS関連技術やプロジェクトの保守方針をめぐる意見の違いがありました。共通の出発点があるため、一部のプロトコルやルーティング項目は似ていますが、その後の機能や設定の意味には違いがあります。一方のプロジェクト向けに作成されたJSON全体を、もう一方でもそのまま使える汎用設定と考えることはできません。

• コア：プロトコルのハンドシェイク、インバウンド・アウトバウンド接続、ルーティング、DNSなどの低レベル処理を担当します。
• クライアント：ノード一覧、サブスクリプションのインポート、システムプロキシの切り替え、ログ画面などを提供し、設定をコアに渡して実行します。
• サブスクリプション：ノード情報を配布します。インポートできても、コアの機能がすべて対応しているとは限りません。

つまり、「v2rayNGにインポートできる」ことと「V2Flyで動作する」ことは別です。クライアントが共有リンクを認識できても、実行用設定の生成、コアの起動、接続先とのハンドシェイクで失敗する場合があります。

プロトコルの違い：VLESS・XTLS Vision・REALITYの役割

プロトコル名が同じでも、セキュリティ層、トランスポート方式、フロー制御の設定まで同じとは限りません。VLESSは主にプロキシプロトコルを定義するもので、単体では通信を暗号化しません。通常はTLSやREALITYなどの仕組みも必要です。XTLS Visionはフロー制御に関する方式で、REALITYは別の接続セキュリティ機構です。これらをひとまとめにして、自由に置き換えられる設定として扱わないでください。

表の「対応」は、過去のすべてのバージョンで利用できることを保証するものではありません。古いコアやクライアントの共有リンク解析機能では、後から追加されたパラメーターを扱えないことがあります。トラブルシューティングでは、クライアントのバージョンと実際に動作しているコアのバージョンを両方記録してください。画面上のアプリだけを更新しても、使用中のコアファイルが更新されているとは限りません。

クライアントの選び方：v2rayNGとv2flyNGを比較

Android版のv2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。アプリのアイコンや名前になじみがあるかではなく、ノードの構成を基準に選びましょう。以下の推奨は、サブスクリプションにREALITYやVisionが含まれる可能性を前提としています。どのネットワークでも特定のコアが速いという意味ではありません。

Androidクライアントを2つインストールして比較する場合、両方のVPN接続を同時に有効にしないでください。通常、同じユーザー環境でVPNチャンネルを使用できるアプリは1つです。後から起動した接続が先の接続を置き換え、「コアを変えたら突然切れた」と誤解することがあります。

複数端末で使う：サブスクリプションは共用できても、実行設定は端末ごとに確認

デスクトップとAndroidで同じサブスクリプションをインポートできますが、サービス提供元が利用端末数を許可しており、配信形式を両方の端末で読み取れることが前提です。ノード一覧が同じでも、ルーティンググループ、アプリごとのプロキシ設定、ローカルの待ち受けポート、DNSの動作まで引き継がれるとは限りません。

デスクトップでは接続できてAndroidでは接続できない場合、まず同じノードのアドレス、ポート、トランスポート方式、セキュリティ層、フロー制御パラメーターを比較しましょう。すぐにすべての違いをコアのせいにしないでください。両端末で同じ名前の別設定ノードを選んでいたり、一方だけサブスクリプションを更新していたりする可能性があります。

ポートと設定項目：「接続できない」を確認可能な設定に分解

以下の2つのポート番号はトラブルシューティング用の例であり、すべてのクライアントに共通する既定値ではありません。リモートポートはサービス提供元が指定し、ローカルの待ち受けポートはクライアントの設定で決まります。役割が異なるため、ローカルのSOCKSポートをリモートノードのポート欄に入力しないでください。

たとえば、ブラウザーやテストツールからローカルプロキシに接続する場合、使用が確認できている127.0.0.1:10808を指定できます。その後、コアがノードのリモートポートに接続します。「アプリからローカルの入口まで」と「コアからリモートサーバーまで」は別の区間です。ローカルに接続できても、リモートとのハンドシェイクが成功したとは限りません。

1. 基本接続：リモートアドレス、ポート、ユーザーID、システム時刻を確認します。VMessは時刻のずれに敏感です。TLS証明書の有効期間確認にも正確な時刻が必要です。
2. トランスポート層：WebSocketノードではパスとHostを確認します。WebSocketと生のTCPの設定を混在させないでください。
3. セキュリティ層：通常のTLSではサーバー名と証明書検証を確認します。REALITYではサービス提供元が指定したサーバー名、公開鍵関連のパラメーター、shortIdを確認します。
4. フロー制御：サービス提供元がxtls-rprx-visionを指定している場合は、その設定に合わせます。flowを変更しても、サーバー側のプロトコルが自動で切り替わるわけではありません。
5. 実行結果：「不明なフィールド」「ハンドシェイク失敗」「接続タイムアウト」を区別し、それぞれ互換性、認証パラメーター、ネットワーク到達性を確認します。

コアの切り替え前後：変更する条件は一度に1つ

「コアを変えたら速くなった」と比較するには、同じノード、近い時間帯、同じテスト先を使う必要があります。TCPingで主に確認できるのはTCP接続の到達性であり、プロキシのハンドシェイク成功を示すものではありません。実接続テストは実際のプロキシリクエストに近い確認方法ですが、継続的なダウンロード速度やすべてのサイトでの使い勝手を保証するものではありません。

1. 切り替え前にバックアップ：サブスクリプションの配布元、現在のノード設定、ルーティング、DNSの設定を保存します。スクリーンショットを共有する場合は、ユーザーIDやサブスクリプションURLを隠してください。
2. 起動を確認：まずコアを起動し、ログに設定の解析エラーがないか確認します。起動に失敗した場合、設定の問題を覆い隠すためにノードを何度も切り替えないでください。
3. プロキシリクエストをテスト：同じノードで実接続テストを実行し、同じブラウザーから同じ接続先にアクセスします。システムプロキシやVPNチャンネルが実際に有効か確認してください。
4. ルーティングを個別に確認：接続できた後で、直接接続とプロキシのルールを確認します。特定のサイトが直接接続に振り分けられても、新しいコアが通信を処理していないとは限りません。
5. 記録して元に戻す：クライアントとコアのバージョン、エラーの種類、変更した項目を記録します。結果が悪化したら元の設定に戻し、DNS、ルーティング、トランスポートの設定を同時に変更しないでください。

よくある質問：インポート成功、古いノード、移行の失敗