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

1. Xray、V2Fly、クライアントの役割

V2Rayは、もともとプロキシツールのプロジェクトとそのコアプログラムの名称です。V2Flyコミュニティはv2ray-coreの開発を継続しています。Xray-coreは2020年に関連コードを基に分岐し、その後独自の機能と設定の進化を遂げました。共通の歴史はありますが、同じプログラムの表示名違いではなく、名称だけでどちらのバージョンが新しいかを判断することもできません。

コアはプロトコルのハンドシェイク、トランスポート、DNS、ルーティングなどを処理します。クライアントはサブスクリプション管理、ノード編集、起動操作、ログ表示を提供し、画面上の項目をコア設定に変換します。ノードを利用できるかどうかは、クライアントが必要な項目を設定できるか、コアが該当機能を実装しているかの両方で決まります。

• v2rayN：デスクトップ向けクライアントです。トラブル対処では、現在選択中のコアを確認してください。クライアントのバージョン番号をXrayやV2Flyのバージョン番号と混同しないようにしましょう。
• v2rayNG：Android向けクライアントです。この記事ではXrayコアの設定方法を扱います。REALITYやVisionなどを必要とするノードに適しています。
• v2flyNG：V2Flyコアを使用するAndroid向けクライアントです。選択する前に、ノードのプロトコル、トランスポート、設定形式が利用中のバージョンでサポートされているか確認してください。

ノードが一覧に表示されても、サブスクリプションがレコードとして解析されたことしか分かりません。コアが設定を読み込み、リモートとのハンドシェイクに成功して初めて、接続経路が利用可能だと確認できます。インポートの成功は互換性確認のゴールではありません。

2. 機能の違い：VisionとREALITYに注目

VMessとVLESSはプロキシプロトコル、WebSocketとTCPはトランスポート方式、TLSとREALITYは接続のセキュリティ層の選択肢です。XTLS Visionは、特定の接続構成で使用するフロー制御です。それぞれ異なるレイヤーに属するため、「VMessをREALITYに変更する」だけでは設定変更の全体を表せません。

Visionでよく使われる項目値はxtls-rprx-visionです。旧式のXTLS設定と同じものではなく、あらゆるトランスポートに追加できる高速化オプションでもありません。一般的な構成はVLESS、TCP、TLSまたはREALITYの組み合わせです。クライアントのフロー制御をサーバー側の設定に合わせる必要があります。

REALITYは証明書検証を無効にする機能でもありません。ハンドシェイクと認証に異なる仕組みを使うため、通常はサーバー公開鍵、許可されたサーバー名、short ID、フィンガープリントなどが必要です。通常のTLSノードのセキュリティ層をREALITYに変更しただけで接続できるとは限りません。

3. 2種類のノードで確認すべき主要項目

以下の2つのカードは設定項目の関係を確認するための例であり、そのままインポートできるノードではありません。ポートやパスは用途を示す例です。実際の値はノードの提供元から取得してください。サーバーの待ち受けポートが443でも、TLSやREALITYを使っているとは限りません。

REALITYの共有リンクでは、pbkがサーバー公開鍵、sidがshort ID、sniがサーバー名、fpがクライアントのフィンガープリント識別子に対応するのが一般的です。共有リンクの項目名、クライアントの入力欄名、ネイティブJSONのキー名は一致しない場合があります。対応形式を扱えるクライアントで正しくマッピングしてください。

4. 設定の互換性：共有リンクとネイティブJSONは別物

同じノードでも、共有リンク、サブスクリプションの項目、ネイティブJSONなど異なる形式で表現できますが、同じファイルではありません。共有リンクは主にノードの接続情報を記述します。ネイティブ設定にはローカルのインバウンド、DNS、ルーティング、ログ、複数のアウトバウンドなども含まれる場合があります。設定全体をノードリンクに変換すると、すべての動作を維持できないことがあります。

1. まず設定の種類を見分けます。vmess://とvless://は共有リンクの接頭辞です。オブジェクト形式のJSONは、コアの完全な設定の場合もあれば、サービス提供元のAPIレスポンスの場合もあります。
2. 次にJSONの方言を確認します。V2Flyの複数の設定形式と、進化を続けるXrayの項目を同一視しないでください。最上位にinboundsとoutboundsがあっても、ネストされた項目は異なる場合があります。
3. アウトバウンドを項目ごとに比較します。まずプロトコルとユーザー認証を確認し、次にトランスポート、セキュリティ層、フロー制御を確認します。REALITY専用の設定が足りない場合、通常のTLS設定で補わないでください。
4. 最後に環境設定を移行します。ローカルの待ち受けアドレスとポート、DNS、ルーティングタグ、ルールの順序を確認してください。ノードのハンドシェイクに成功しているのに経路選択がおかしい場合、UUIDや公開鍵を変更し続けるべきではありません。

XrayからV2FlyへネイティブJSONを移行する場合、実行ファイルを置き換えるだけでは不十分です。コアによっては未知の値を拒否したり、特定の解析経路で一部の項目を無視したりします。どちらも移行が成功したとは言えません。移行先コアで設定を検証してから、実際にプロキシ経由のリクエストを行ってください。

xray version
xray run -test -config client.json
v2ray version

以下のコマンドはデスクトップのコマンドライン環境向けです。最初の2行ではXrayのバージョン確認と既存のclient.jsonの検査を行い、3行目ではV2Flyのバージョンを確認します。対象ファイルを事前に用意してください。配布パッケージによってコマンドの引数が異なる場合があるため、先にhelpを確認しましょう。設定検査で分かるのは解析時や一部の初期化時の問題までで、ネットワーク接続の確認には代用できません。

5. v2rayNGとv2flyNGの選び方

Androidでは名前から推測するより、ノードの機能要件に合わせてクライアントを選ぶ方が確実です。提供元がVLESS + REALITY + Visionを明示している場合は、v2rayNGのXray経路を選び、クライアントと内蔵コアがサブスクリプションの項目を扱えることを確認してください。V2Flyのネイティブ設定を使う場合は、v2flyNGの設定画面とコアのバージョンがその形式に対応しているか先に確認しましょう。

• ノードがREALITYまたはVisionを必要とする：v2rayNGを使い、セキュリティ層、公開鍵、short ID、フィンガープリント、フロー制御がすべて設定されているか確認します。
• 既存ノードがVMess + WebSocket + TLS：どちらも使える場合があります。インポート、ハンドシェイク、ルーティングが正しく動作する構成を維持し、切り替え前にサブスクリプションとローカル設定をバックアップしてください。
• 独自のDNSやルーティングを使用している：ノードをインポートできるかだけで互換性を判断せず、クライアントが実際に生成する設定を確認してください。
• デスクトップでv2rayNを使う：クライアントと選択中のコアのバージョンをそれぞれ記録します。コアを切り替えた後は接続を再起動し、古いログで判断しないようにしてください。

「Xrayなら必ず速い」「V2Flyなら必ず安定する」とは言えません。ノードの場所、ネットワークのパケットロス、サーバー負荷、トランスポート方式、ルーティングなどが使用感に影響します。コアを比較する際は、同じサーバー、同じプロトコル構成、同じテスト対象、近い時間帯に条件をそろえてください。条件が異なると、コアではなく回線の差を測っている可能性があります。

6. インポートできても接続できない場合の確認手順

まず「ローカルのプロキシ入口」と「リモートサーバーのポート」を区別します。以下はトラブル対処用の数値例であり、すべてのクライアントの初期値や速度テストの結果を示すものではありません。ローカルポートは実際の設定、リモートポートはノード情報を確認してください。

1. 実行中のコアを確認します。現在のノードを起動して最新ログを開き、コア系列、バージョン、最初のエラーを記録します。インストーラーの名前だけを確認しないでください。
2. 設定の読み込み失敗に対処します。未対応のプロトコル、セキュリティ層、フロー制御の値が出たら、まず機能への対応状況を確認してください。コアが正常に起動していない場合、DNSを何度変更しても解決しません。
3. ネットワークに到達できない場合：サーバーアドレスを名前解決できること、リモートポートが正しいこと、ネットワーク上で接続が許可されていることを確認します。TCPポートに到達できても、トランスポートの入口にアクセスできると分かるだけで、認証の成功までは確認できません。
4. ハンドシェイクエラーに対処します。通常のTLSでは、端末の時刻、serverName、証明書チェーンを確認します。REALITYでは、サーバー公開鍵、short ID、許可されたサーバー名、フィンガープリントの設定を確認します。Visionを使う場合は、フロー制御も照合してください。
5. リクエストがプロキシを通らない場合：デスクトップではシステムプロキシやアプリのプロキシ設定を確認し、AndroidではVPNの許可とアプリごとのルールを確認します。接続が確立しているのに宛先の通信がプロキシを通らない場合、プロトコル項目を変更すると原因の切り分けが難しくなります。

デスクトップのローカルSOCKS入口が127.0.0.1:10808であることを確認できたら、次のコマンドでプロキシを明示してこのサイトにアクセスできます。socks5hでは宛先ドメインの名前解決をSOCKSプロキシ側で行うため、ローカルDNS経由の場合と切り分けやすくなります。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2rayid.com/

コマンドから応答があっても、現在のルールで対象へのリクエストがローカル入口経由で完了したことしか分かりません。コアのルールで直接接続されている場合、リモートプロキシの出口が正常とは確認できません。アクセスログでアウトバウンドを確認し、信頼できる外部IP確認サービスでも結果を照合してください。一度タイムアウトしただけでコアの互換性に問題があるとは限りません。ローカル接続、リモートとのハンドシェイク、宛先へのアクセスのどの段階で失敗したかを確認しましょう。

7. よくある互換性の疑問