XrayとV2Flyのコアを比較：VLESS・XTLS・REALITYの対応状況

1. XrayとV2Fly：コアとクライアントの違い

V2Rayはプロキシツールのプロジェクト名であり、同種のツール全般を指す言葉として使われることもあります。V2FlyはV2Rayを保守するコミュニティプロジェクトです。コアは受信接続、ルーティング判定、プロトコル処理、外部への接続を担います。XrayはV2Rayのコードベースから派生して開発されました。共通の歴史を持つ一方、現在は機能開発や設定仕様がそれぞれ独自に進んでいます。Xrayを単なるV2Flyの名称変更版と考えるのは正確ではありません。

クライアントはサブスクリプションの管理、ノードの編集、システムのネットワーク設定を担当し、コアが実際の接続を処理します。Android版ではv2rayNGがXrayコアを、v2flyNGがV2Flyコアを使用します。デスクトップ版のv2rayNでは、現在の設定がどのコアを呼び出しているか確認してください。メイン画面のタイトルだけでは判断できません。クライアントを更新した後は、起動ログで実際に読み込まれたコアの名称とバージョンも確認しましょう。

この流れから、異なる2種類の障害を切り分けられます。ノードが一覧に表示されるのは、クライアントがサブスクリプションを解析できたということにすぎません。コアが設定を読み込み、接続先とのハンドシェイクを完了して初めて、ノードが利用可能になります。画面にプロトコル名が表示されていても、現在のコアがその組み合わせに含まれるすべての設定項目に対応しているとは限りません。

2. VLESS・XTLS・REALITYの対応範囲

プロトコル、通信方式、セキュリティ層はそれぞれ異なる要素です。VMessとVLESSはプロキシプロトコル、TCPとWebSocketはデータを運ぶ通信方式、TLSとREALITYは接続の安全性に関わる方式です。XTLS Visionは、条件に合う通信を特定のフロー制御で処理し、効率化します。ノード名に「VLESS」と書かれているだけでは、どのコアを使うべきか判断できません。セキュリティ層とflowも確認しましょう。

VLESS自体にはペイロード暗号化機能がありません。一般的な設定ではTLSやREALITYなどのセキュリティ方式と組み合わせます。VMessを置き換える新バージョンという単純な関係でもありません。対応状況を判断するときは、先頭の項目だけを比べるのではなく、「VLESS + TCP + REALITY + Vision」のようにノード全体の組み合わせを確認してください。

3. 2種類の設定例：セットで確認すべき項目

以下の2つのカードは、設定項目を見分けるための例であり、そのまま使えるノードではありません。ドメイン名には予約済みの例示用ドメインを使い、パスとポートも説明用の値を記載しています。実際の接続には、サーバーまたはサブスクリプションで提供された設定値を使用してください。特に、あるノードのUUID、別のノードの公鍵、さらに別のノードのサービス名を組み合わせてはいけません。

REALITYのクライアント設定にサーバーの秘密鍵を入力する必要はありません。クライアントにはサーバーに対応する公鍵などの認証情報を設定し、秘密鍵はサーバー側に保管します。shortIdは16進数で表され、使用できる値はサーバー側で決まります。メモとして扱ったり、サブスクリプションの値を独自に生成した値へ置き換えたりしないでください。サービス名は通常、serverNameまたはリンクのsniパラメーターで指定し、サーバー側の設定と一致させます。

クライアント設定の「フィンガープリント」は、通常TLS ClientHelloの特徴を模擬する設定であり、端末の識別番号ではありません。fingerprintをchromeに変えても、公鍵・UUID・ポートの誤りは解決しません。REALITYを使うからといって、必ずしもVisionも有効にするわけではありません。両者は別の設定項目です。サーバー側が該当する組み合わせを使用している場合にのみ、対応するflowを設定します。

• VLESS：UUID、encryption、flowを確認します。一般的なencryptionの値はnoneです。VMessのautoをそのままコピーしないでください。
• WebSocket：pathとリクエストヘッダーのHostを確認します。TLSのserverNameとWebSocketのHostは別の設定項目です。
• TLS：証明書の検証を有効にしてください。証明書やサービス名の誤りを、検証の無効化で回避しないでください。
• REALITY：公鍵、サービス名、shortId、フィンガープリント、コアのバージョンを確認します。バージョンによって画面上の項目名やJSONのフィールドが異なる場合があります。現在のコアの説明とクライアントが生成した設定を基準にしてください。

4. 設定の移行：JSONの構造が似ていても互換性があるとは限らない

XrayとV2Flyの従来形式の設定には、inbounds、outbounds、routingなど共通の構造があります。しかし、構造が共通していても、すべてのフィールドを相互に使えるわけではありません。V2Flyの設定形式も複数あり、それぞれに違いがあります。移行時は、まず移行先のコアが受け付ける設定形式を確認し、プロトコルや通信方式の各項目を点検してください。Xrayの設定ファイル全体をそのままV2Flyに渡すと、読み込み時点で失敗することがあります。

以下は、Xrayでよく使われるVLESS + TLS + Visionのoutbound設定例です。flowがどの階層にあるかを確認するためのもので、完全な設定ではありません。例示用ドメインとすべてゼロのUUIDは明らかな仮の値であり、実際のノードには使用できません。この例にはREALITYの設定が含まれていないため、tlsをrealityに変更するだけでは変換できません。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "node.example.com",
          "allowInsecure": false
        }
      }
    }
  ]
}

1. まず現在の設定を保存する。クライアントとコアのバージョン、使用中のノード、ルーティングのプリセットを記録します。バックアップファイルには認証情報が含まれる場合があるため、安全に保管してください。
2. ノードを1つだけ移行する。移行先のクライアントが対応するノードリンクまたはサブスクリプションから再読み込みし、生成された設定を確認します。ルーティングやDNSの設定を一度にすべて上書きしないでください。
3. まずコアが起動するか確認する。ログに不明なプロトコル、不明なセキュリティ方式、未対応のflowが表示された場合は、設定を修正するか対応するコアを選んでください。ネットワークの遅延を何度も測定しても解決しません。
4. その後、ルーティング設定を戻す。ルールが参照するoutboundのtag、ドメイン・IPデータファイル、DNSの処理方法を確認してください。ノードに接続できても、以前のルールが正しく移行されたとは限りません。

5. v2rayNGとv2flyNGの選び方と動作確認

REALITYまたはVisionを使うノードがあるAndroidユーザーには、通常v2rayNGが適しています。V2Flyの設定をすでに使っていて、ノードが一般的な互換構成で正常に動作しているなら、v2flyNGを継続して使えます。デスクトップではv2rayNは管理画面です。重要なのは、現在のノードがどのコアを呼び出しているか、そのコアが設定に対応しているかです。

コア、ノード、DNS、ルーティングのプリセットを一度に変更しないでください。変更を1つずつ行えば、問題の原因を特定できます。以下の数字は各ポートの役割を説明するためのもので、速度測定の結果でも、すべてのクライアントの初期値でもありません。実際にこれらのポートを使うかどうかは、現在の設定に従ってください。

接続先の443番ポートにTCP接続できても、その層まで到達できたことを示すだけです。VLESS認証、TLS、REALITYのハンドシェイクが成功した証明にはなりません。ローカルの10808番ポートが使用中だと、コアが起動できない場合があります。これは接続先プロトコルとの互換性とは別の問題です。DNSリクエストにも独立した通信経路があります。ブラウザーでドメイン名を解決できても、コアが使うリゾルバーに同じように到達できるとは限りません。

• コアのログ：まず起動成功の記録と実際のバージョンを確認してから、接続エラーを調べます。設定読み込み、DNS、ハンドシェイク、タイムアウトのどの問題かを切り分けてください。
• 接続の入口：デスクトップではシステムプロキシが有効か、AndroidではVPNの許可とアプリごとのプロキシ対象を確認します。入口が有効でなければ、通信はコアに届きません。
• 同じ条件でテスト：同じネットワーク、同じノード、同じルーティング設定を維持し、実際にWebページへアクセスして確認します。1回の遅延テストだけで互換性を判断しないでください。
• ログを共有する場合：サブスクリプションのトークン、UUID、接続先アドレス、認証情報を隠してください。エラーの種類、バージョン、発生時刻が分かれば、原因の特定に役立ちます。

6. よくある質問：読み込み・起動・接続の違い