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

1. XrayとV2Fly：同じ系譜でも設定は共通ではない

Project Vは、ネットワークプロキシツールやプロトコル、設定機能を中心としたプロジェクト群です。V2Rayはその中核となる実装の一つです。V2FlyコミュニティはV2Rayの開発を続け、Xrayは2020年にV2Rayのコードベースから分岐した後、独自に進化しました。そのため、inbound、outbound、ルーティング、DNSの構造には共通点が見られますが、同じプログラムの別名というわけではありません。

コアは実際の通信を担い、ローカルのリクエストを受け付け、接続先を選択し、通信を確立してプロトコルのやり取りを行います。クライアントは画面表示、サブスクリプション管理、パラメーター生成、プロセス制御を担当します。クライアントに選択肢が表示されても、起動中のコアがその機能を実行できるとは限りません。逆に、コアが対応する設定項目でも、GUIから入力できるようになるまで時間がかかる場合があります。

互換性を判断するには、この流れに沿って確認します。共有リンクをインポートできても、クライアントがリンク形式を認識したことしか分かりません。設定ファイルを読み込めても、構文や一部の項目が検証を通過しただけです。接続が確立し、認証が完了して、接続先から応答を受け取れて初めて、その接続経路が正常に動作していると判断できます。

2. XTLS VisionとREALITYの役割

XTLS VisionはXrayのフロー制御機能で、一般的な設定値はxtls-rprx-visionです。プロキシ接続におけるTLS通信の処理を最適化し、プロトコル、トランスポート、セキュリティ層の組み合わせが適切な場合に、不要な処理を抑えます。サーバーアドレスだけで使える独立したプロキシプロトコルでも、あらゆるノードを高速化する設定でもありません。

REALITYはXrayが提供するセキュリティ層で、TLSハンドシェイクの仕組みと特定の認証パラメーターを組み合わせて使用します。通常のTLSとは設定方法や検証方法が異なり、一般にサーバー名、サーバーが提供する公開鍵情報、Short IDなどが必要です。一般的なREALITY構成では、プロキシの入口に通常のTLS用ドメイン証明書を設定する必要はありませんが、接続先、ハンドシェイク、認証の各設定が正しいことは必要です。

VisionとREALITYは同じノードで併用できますが、同じ機能ではありません。また、Visionは対応する通常のTLS構成でも使えます。古い資料に記載された別のXTLS flow名をVisionに置き換えることもできません。プロトコル、フロー制御、トランスポート、セキュリティ層をひとまとまりで確認してください。対応範囲は両端のコアのバージョンにも左右されます。

3. 設定の比較：画面上の項目名が同じでもJSONは同じとは限らない

以下の2つのカードは、よくある構成の確認ポイントを示したもので、接続に使えるノード設定ではありません。サーバーアドレス、ユーザーID、認証情報は、実際のサーバー設定を確認してください。カード内の/wsは例示用のパスです。サーバーとリバースプロキシも同じパスを使用している場合に限り有効です。

一般的なXray設定では、streamSettings.securityでトランスポートのセキュリティ層を選択し、flowは該当するユーザー設定に属します。両者は置き換えられません。TLSのサーバー名とWebSocketのHostには同じドメイン名を設定することがよくありますが、前者はTLSハンドシェイクと証明書検証に使われ、後者はHTTPリクエストの情報です。トラブルシューティングでは別々に確認してください。

• 構造の互換性：inbounds、outbounds、routingなどの名前が似ていても、すべての内部項目が同じとは限りません。
• プロトコルの互換性：VMess、Trojan、Shadowsocksなど、一般的に対応しているプロトコルでも、暗号化方式、トランスポートの組み合わせ、バージョンまで確認してください。プロトコル名だけの比較では不十分です。
• バージョンの互換性：V2Flyの設定形式やXrayの項目は、それぞれ変更されることがあります。古いガイドにある項目の位置や名前を、現行バージョンでも固定の仕様として扱わないでください。
• リソースの互換性：geosite:やgeoip:を使うルーティングルールでは、対応するデータファイルと読み込みパスも正しく設定する必要があります。

4. v2rayN・v2rayNG・v2flyNGとコアの関係

v2rayNGはXrayコアを使用するAndroidクライアント、v2flyNGはV2Flyコアを使用するAndroidクライアントです。名前や一部の画面が似ていても、一方のクライアントでインポートできたノードが、もう一方でも動作するとは限りません。特にREALITYやVisionを使うノードでは、まずコアの対応状況を確認し、インポート時に各パラメーターが正しく引き継がれたかを確かめてください。

v2rayNはデスクトップクライアントです。画面上のクライアントと、実際に動作するコアプログラムは分けて考える必要があります。トラブルシューティングでは、現在の設定、起動ログ、実際に呼び出されているコアを確認してください。クライアント名だけから、すべてのノードが同じコアで動作すると判断することはできません。メニューの表示はデスクトップ版によって変わる場合があるため、設定を記録する際はクライアントとコアの情報もあわせて記録しましょう。

1. まずクライアントを確認：「バージョン情報」などの画面でクライアント名を記録します。インストーラーのファイル名だけでは不十分です。
2. 次にコアを確認：起動ログでコア名とバージョンを確認します。起動に失敗する場合は、まず設定の解析エラーを確認してください。
3. ノードの詳細を確認：プロトコル、トランスポート、セキュリティ層、サーバー名、flowを一つずつ確認します。ノード名だけで判断しないでください。
4. 最後にアプリの接続設定を確認：AndroidではVPN接続の許可とアプリごとの設定を、デスクトップではアプリが使用するローカルプロキシのアドレスとポートを確認します。

5. サブスクリプションとカスタム設定の移行：段階ごとに検証

サブスクリプションは設定を配布する仕組みであり、共通のコア設定規格ではありません。同じサブスクリプションでも、クライアントによって解析方法や項目のマッピング、デフォルト値の補完方法が異なることがあります。名前、アドレス、ポートが表示されても、REALITYのパラメーター、フロー制御、ルーティングルールがすべて引き継がれたとは限りません。移行前に現在使えている設定を保存し、移行先のクライアントではノードを一つずつ検証してください。

この2つのポートは、異なる接続段階で使われます。リモートの接続先ポートは別の番号でも、ローカルのリスニングポートは変更しても構いません。同じ番号にする必要はありません。ブラウザーのプロキシをリモートの443番に設定したり、ノードのサーバーポートをローカルの10808番に変更したりしても、コアの非互換性は解消できません。

1. 現在の設定を保存：接続できるノードを一つ選び、プロトコル、トランスポート、セキュリティ層、ルーティングの設定を記録します。認証情報などの機密情報はローカルにのみ保存してください。
2. 最小構成で接続を確認：複雑なルーティングの移行は後回しにし、まず移行先のクライアントでノード一つが接続できるか確認します。DNS、ルーティング、プロトコルを同時に変更しないでください。
3. インポートした項目を確認：元のノードでVisionを使っている場合は、flowがxtls-rprx-visionのままか確認します。REALITYを使う場合は、サーバー名、Short ID、公開鍵情報を確認してください。
4. ルーティングを戻す：ルールを一つずつ移行し、各outboundTagが定義済みのアウトバウンドに対応しているか、ルールの順序が正しいかを確認します。
5. 更新時の動作を確認：サブスクリプションを手動で一度更新し、独自の変更が上書きされないか確認します。継続して使う変更は、クライアントが提供する永続的な設定欄に保存してください。

サーバー名を任意の人気ドメインに置き換えることはできません。また、REALITYの公開鍵情報をクライアント側でその場で生成して代用することもできません。いずれもサーバー側の設定に関係します。サブスクリプションに項目が不足している場合は、コアを何度も切り替えて補うのではなく、設定の提供元に必要なパラメーターを確認してください。

6. エラーの切り分け：設定解析、リスニング、リモートハンドシェイク

効率よく原因を探るには、まずどの段階で失敗しているかを確認します。設定の解析に失敗している状態では、速度測定やDNSの変更をしても意味がありません。コアが正常に起動して接続がタイムアウトする場合も、タイムアウトだけで特定のプロトコルが非対応だとは判断できません。以下のログ例は一般的な意味を示すものです。実際の表記はバージョンやOSによって異なります。

一時的にログの詳細度を上げると原因を調べやすくなりますが、確認後は通常のレベルに戻してください。ログを共有する前に、サーバーアドレス、ユーザーID、サブスクリプションURL、認証情報を削除します。証明書検証を無効にしたまま通常のTLSを使うことは、恒久的な解決策ではありません。証明書チェーン、サーバー名、システム時刻に問題がある場合は、原因を修正してください。

7. コア選びとよくある質問