XrayコアとV2Flyコアの違い｜XTLS Vision・REALITY・設定の互換性

クライアントとコアの役割を整理する

v2rayN、v2rayNG、v2flyNGは、ユーザーが操作するクライアントです。サーバー一覧、サブスクリプションのインポート、システムプロキシの切り替え、画面上の設定はクライアント側が担当します。一方、設定の読み込み、接続の確立、ルーティングルールの適用、通信の転送は主にコアが行います。クライアントに項目が表示されていても、現在実行中のコアがその機能に対応しているとは限りません。

Androidでは、v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。デスクトップ版のv2rayNは、バージョンやノードの種類、実際の実行ログを確認して、使用中のコアを判断してください。デスクトップのショートカット名だけでは特定できません。問題の切り分けでは、クライアントとコアそれぞれのバージョンを記録しましょう。両者のバージョン番号は別のものです。

• サブスクリプションをインポートできない：まずサブスクリプションの内容と、クライアントの解析対応状況を確認します。この段階では、コアがまだ起動していない場合があります。
• コアが起動しない：生成された設定、項目の型、ポートの競合、コアの機能対応状況を確認します。
• コアは起動するが接続できない：サーバーの接続情報、ハンドシェイクのログ、実際のネットワーク経路を確認します。

XrayとV2Fly：共通のルーツがあっても設定の互換性は保証されない

V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、コアプログラムは一般にV2Ray Coreと呼ばれます。Xrayは2020年にV2Rayのコードを基盤として分岐し、その後独自に発展しました。インバウンド、アウトバウンド、ルーティング、DNSなど共通する概念は多いものの、機能や設定構造にはすでに違いがあります。

そのため、「どちらもプロキシ通信を処理できる」ことと、「実行ファイルをそのまま置き換えられる」ことは別です。移行時、プロトコル名が同じでも、対応するのは最初の段階にすぎません。トランスポートのパラメーター、セキュリティ層、ルーティングの記述、DNS設定まで一致するとは限りません。

XTLS VisionとREALITY：フロー制御とセキュリティ層の違い

一般的なVLESS設定では、XTLS Visionはflow: xtls-rprx-visionで指定します。条件に合った通信に特定の処理経路を適用する機能であり、独立したサブスクリプション形式でも、任意のトランスポート構成に追加できる高速化スイッチでもありません。サーバー側で対応するフロー制御が設定されていなければ、クライアントにVisionを指定しても利用できません。

REALITYはセキュリティ層に位置し、サーバー認証や関連するハンドシェイクパラメーターに関わります。通常、クライアント側ではサーバー名、公鍵、Short IDなどを確認します。画面上で公鍵の情報がPublic keyと表示される場合や、バージョンによって別の名称が使われる場合もあります。表示名が異なるからといって、パラメーターを入れ替えないでください。サーバーの秘密鍵をクライアントの公鍵欄に入力してはいけません。

• VisionはREALITYと同じではありません：Visionは対応するTLS構成でも使用できます。Visionが指定されているだけでは、セキュリティ層を判断できません。
• REALITYは特定のポートを指すものではありません：ポートには443がよく使われますが、ポート番号だけでプロトコルやセキュリティ層が決まるわけではありません。
• VLESSはVisionと同じではありません：「VLESS対応」と書かれているだけでは、xtls-rprx-visionにも対応しているとは判断できません。
• WebSocketに置き換えない：上記のVision構成を単純にWebSocketへ変更しても、同じ機能を期待して接続できるとは限りません。

設定の互換性：4つの層を個別に確認し、一括置換はしない

共有リンク、サブスクリプションのテキスト、クライアントに保存されたデータ、コアが読み込むJSONは、それぞれ異なる層のものです。vless://リンクをインポートできても、それはクライアントがリンクを解析できたというだけです。生成された実行用設定にフロー制御、セキュリティ層、トランスポートのパラメーターが保持されているかも確認してください。逆に、完全なJSON設定でも、通常のノードリンクとしてインポートできるとは限りません。

1. プロトコル層を確認：VMessまたはVLESSの別、ユーザー識別子、認証パラメーターを確認します。古いVMess設定には過去の互換性パラメーターが含まれる場合があります。移行時はサーバー側の情報と現在の実装を照合し、古い解説記事の固定値をそのままコピーしないでください。
2. トランスポート層を確認：TCP/RAW、WebSocketなどの種類に加え、パスやHostなどの項目を確認します。バージョンによって名称や設定方法が変更されている場合があるため、画面上の表示だけで比較しないでください。
3. セキュリティ層を確認：TLS、REALITY、またはセキュリティ層を使用しない設定のいずれかを明確にします。サーバー名、証明書の検証、鍵情報、フィンガープリントの要件を確認してください。証明書検証を無効にしても、あらゆる問題が解決するわけではありません。
4. 実行環境を確認：インバウンドのリッスンアドレスとポート、ルーティングタグ、DNS、ファイルパスを比較します。プロトコルのハンドシェイク設定が正しくても、アウトバウンドタグの参照先が無効なら、想定どおりに通信を振り分けられないことがあります。

V2FlyではV4とV5の設定体系も区別する必要があります。拡張子がどちらも.jsonでも、設定項目の構造が同じとは限りません。設定一式を移行する場合は、移行先コアのドキュメントに沿って構造を確認してください。一般ユーザーには、サービス提供元が用意した対応リンクをインポートし、クライアントに実行用設定を生成させる方法が適しています。

移行の検証：ローカルの待ち受けとリモートのハンドシェイクを分けてテスト

2つのコアを比較するときは、サーバー、ネットワーク、テスト先を固定し、各テストの条件を記録してください。以下の数値はローカルで比較するための設定例であり、クライアントの初期値でも速度測定の結果でもありません。例ではローカルHTTPプロキシを10809番ポートに設定し、ループバックアドレスのみで待ち受けます。テスト用ポートをLANに公開しないための設定です。

まず設定をコアが読み込めるか確認する

以下はコマンドラインでの確認例です。あらかじめ対象のコアが読み込めるclient.jsonを用意してください。Xrayの例ではXrayのコマンドライン形式を、V2Flyの例ではV5のコマンドライン形式を使用します。配布パッケージによって異なる場合は、該当プログラムのヘルプコマンドで確認してください。設定テストで確認できるのは読み込み段階までで、リモートサーバーへの接続可否は確認できません。

# Xrayの設定を確認
xray run -test -config client.json

# V2Fly V5のコマンドラインで設定を確認
v2ray test -c client.json

次にリクエストがローカルプロキシを経由しているか確認する

テスト用の設定を起動したら、ローカルプロキシのアドレスを明示してリクエストを送信します。以下では10809番ポートでHTTPプロキシが待ち受けているものとします。SOCKSインバウンドのみの場合、http://をそのまま使うことはできません。テスト先のhttps://example.com/は、アクセスできることを確認済みのHTTPSアドレスに置き換えられます。

curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 30 -I https://example.com/

• ローカルで接続が拒否される：リモートのプロトコルをすぐに変更せず、コアが起動しているか、正しいポートで待ち受けているかを確認します。
• リモート接続がタイムアウトする：サーバーアドレス、ポート、ファイアウォール、ネットワーク経路を確認します。タイムアウトだけでは、コアの互換性がないとは判断できません。
• ハンドシェイクまたは認証エラー：UUID、Flow、サーバー名、公鍵、Short IDを一つずつ確認し、一度に複数の項目を変更しないでください。
• リクエストは成功するが一部のサイトに接続できない：DNS、ルーティング、接続先サイト固有の問題を確認します。特定のサイトだけの障害を、プロトコル全体の不具合と混同しないでください。

10809番ポートを使用する設定を2つ同時に起動しないでください。比較テストの前に前の設定を停止し、ローカルポートとテストコマンドを統一します。そうしないと、ポートの競合やリクエストが古いプロセスに送られる問題を、コアの違いと誤認するおそれがあります。

選び方：ノードの機能とメンテナンスの手間で判断する

現在正常に動作している設定なら、「別のコアが更新された」という理由だけで、すぐに移行する必要はありません。新バージョンを導入する価値は、修正内容、プロトコル対応、クライアントとの互換性を踏まえて判断しましょう。更新前にクライアントとコアのバージョン、利用可能なノードを記録し、復元できる設定のコピーを残しておくと、すばやく元に戻せます。

よくある誤解：インポート、起動、接続の成功はそれぞれ別に確認する