· コア解説 · 約10分

XrayコアとV2Flyコアの違い｜VLESS・XTLS・REALITYを比較

Project V系のXrayとV2Flyを比較。VLESS、XTLS Vision、REALITYの対応状況や設定方法を解説し、v2rayNGとv2flyNGの選び方を紹介します。

この記事の要点

コアを選ぶときは、クライアント名だけでなくノードの要件を確認しましょう。クライアント、プロトコル、トランスポート、安全レイヤーの違いを整理し、VLESSとREALITY、XTLS Visionと通常のTLSがそれぞれ別物であることを解説します。Androidでの選び方、デスクトップでの設定確認、移行に失敗した場合のチェック手順も紹介。VMessノードを使っている場合に、コアを変更すべきか判断する際にも役立ちます。

1. XrayとV2Fly：共通のルーツと異なる設定仕様

このエコシステムを理解するには、まずProject Vを押さえておきましょう。V2Rayはその中核となるプロキシツールで、V2Flyコミュニティが開発を担っています。Xray-coreはV2Rayから分岐し、その後、独自の機能と設定体系を発展させてきました。入出力やルーティングの考え方は共通していますが、あらゆるJSON設定をそのまま相互利用できるわけではありません。

クライアントはノード一覧、サブスクリプションの更新、画面設定、起動管理を担当し、コアは実際の接続処理、プロトコルのハンドシェイク、ルーティングを担当します。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。デスクトップ版v2rayNで使えるコアや呼び出し方は、配布パッケージや設定形式によって異なります。トラブル時は、起動ログに表示される実行ファイルとバージョンを確認してください。

2. VLESS・XTLS Vision・REALITYの対応状況

VLESS自体には通信を暗号化する機能がなく、一般的にはTLSやREALITYと組み合わせて使います。V2FlyにもVLESSの実装があるため、「VLESSなら必ずXrayが必要」というわけではありません。確認すべきなのは、flowやセキュリティレイヤー、トランスポートの具体的な組み合わせです。Xrayの拡張機能に同名のV2Fly対応があるとは限りません。

設定項目XrayコアV2Flyコア選択時の確認事項
VMess対応対応トランスポート、TLS、サーバー側の設定も確認
基本的なVLESS対応対応する実装ありすべての拡張機能の組み合わせが共通設定として使えるわけではありません
XTLS Vision対応するフロー制御をサポートXrayのVisionフロー制御には非対応xtls-rprx-visionが指定されている場合は、対応するXray環境を選択
REALITY対応XrayのREALITY設定には非対応鍵情報、SNI、shortId、フィンガープリントの設定を確認
ルーティングルール設定に対応ルール設定に対応設定形式、ルールの仕様、データファイルを確認

XTLS Visionはフロー制御の仕組みで、設定値にはxtls-rprx-visionがよく使われます。トランスポート名ではなく、ノードのTLS設定をVisionに変更すれば有効になるわけでもありません。一方、REALITYはXrayのセキュリティ機能です。クライアントとサーバーで一致するパラメーターが必要で、サブスクリプションの形式でも、単独で動作するクライアントでもありません。

通常のTLSは一般に証明書とドメイン名の検証に依存します。REALITYは異なるハンドシェイク方式と認証パラメーターを使用するため、証明書検証を無効にして代用することはできません。サーバーで許可されたserverNameと、クライアントの鍵情報およびshortIdが一致している必要があります。どれか一つでも違えば、ポートに接続できてもプロキシのハンドシェイクは成功しません。

3. 設定方法：flowとsecurityの位置を確認

以下は、フィールドの階層を確認するためのXray outbound設定例です。VLESS、Vision、通常のTLSを組み合わせています。ドメインには例示用の予約ドメインを、UUIDには形式確認用の値を使用しており、そのまま使えるノードではありません。実際の環境では、サーバーから提供されたアドレス、ユーザーID、証明書のドメインに置き換え、サーバー側で対応するフロー制御が有効になっていることを確認してください。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "e1dd2b67-68ca-4c8f-a92b-27eb305d91e7",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    }
  ]
}

例のencryption: "none"はVLESSのユーザー設定であり、接続全体が暗号化されないという意味ではありません。外側のsecurity: "tls"が通信のセキュリティを担います。flowはユーザーオブジェクト内に、securityはstreamSettings内に記述します。階層を間違えると、エラーになったり設定が意図どおりに反映されなかったりすることがあります。

4. v2rayNG・v2flyNG・v2rayNの選び方

現在のサブスクリプションにVLESS、Vision、REALITYの組み合わせが明記されている場合、AndroidではXray環境のv2rayNGを優先しましょう。既存の設定がV2Flyの設定体系に基づき、Xray固有の機能を使わない場合はv2flyNGを選べます。正常に動作しているVMess設定を、名前が違うという理由だけで移行する必要はありません。

Xrayコア環境

おすすめ

この記事で扱うVLESS、Vision、REALITYの利用には、Androidではv2rayNGを選びましょう。デスクトップではv2rayNで、対象ノードが実際にXrayコアを呼び出していることを確認してください。

おすすめの対象：サーバーがXrayの拡張機能を必要とするノード。

V2Flyコア環境

Androidではv2flyNGを使い、既存のV2Fly設定に沿った動作を維持できます。基本的なプロトコルで接続できるかどうかも、具体的なトランスポートとパラメーターが一致しているかによります。

おすすめの対象：利用可能なV2Fly設定があり、VisionやREALITYに依存しない場合。

確認手順：デスクトップとAndroidで個別に検証

デスクトップ：v2rayN
  • インポート後、プロトコル、トランスポート、セキュリティ方式、flowを確認します。
  • 接続を開始し、ログに表示されるコア名とバージョンを確認します。
  • システムプロキシが現在のローカル待ち受けポートを指していることを確認します。
Android：コアに応じて選択
  • REALITYまたはVisionを使うノードにはv2rayNGを使用します。
  • V2Flyの設定はv2flyNGにインポートし、設定内容を確認します。
  • VPN接続を許可した後、アプリごとのプロキシ対象範囲を確認します。

同じサブスクリプションを両方の端末で使えますが、ノード名が同じでも、読み込まれる項目や対応機能が完全に一致するとは限りません。

5. コア変更後に接続できない場合：ポートからハンドシェイクまで順に確認

まず「コアが起動していない」のか、「コアは起動したがリモート接続に失敗している」のかを切り分けましょう。前者はJSON、対応フィールド、ファイルパス、ローカルポートの競合を確認します。後者はサーバーアドレス、セキュリティ関連のパラメーター、ネットワーク接続、システム時刻を確認してください。すべての失敗をコアの速度のせいにすると、修正できる設定上の問題を見落とします。

443
この記事の例で使うリモートTLSポート
10808
ローカルSOCKSの確認用ポート例
127.0.0.1
ローカルのループバック待ち受けアドレス

上記のローカルアドレスとポートは確認方法を示す例であり、すべてのクライアントのデフォルト値ではありません。まず、現在のクライアントに表示されているSOCKSの待ち受けポートを確認してください。実際のポートが10808と異なる場合は、以下のコマンドを変更します。リモートポート443とローカルプロキシポートは別々の接続に属するため、相互に置き換えることはできません。

curl --proxy socks5h://127.0.0.1:10808 https://example.com/
  1. ローカルの待ち受けを確認：ローカルプロキシにすぐ接続できないと表示される場合は、まずコアが正常に起動していること、ポートが一致していること、同じポートを使用する古いプロセスが停止していることを確認します。
  2. インポート内容を確認：元のノード情報と照らし合わせ、UUID、サーバーポート、flow、SNI、REALITYのパラメーターを確認します。Base64は単なるエンコード方式であり、不足している項目を補うものではありません。
  3. リモートのハンドシェイクを確認：TLSまたは認証エラーが発生した場合は、システム時刻、ドメイン、鍵情報を確認してください。検証を無効にする方法を一般的な解決策として使わないでください。
  4. プロキシの適用範囲を確認：コマンドでは接続できるのにブラウザーでは接続できない場合は、システムプロキシ、アプリごとのプロキシ、ルーティングルール、DNSを確認します。この段階で、まずサーバーのプロトコルを変更する必要はありません。

コアの違いを検証するときは、同じノード、ネットワーク、接続先を使い、時間帯もできるだけそろえましょう。まずMuxなどの追加要素を無効にし、ログと接続結果を確認します。ノードの負荷、ネットワーク経路、サーバーの帯域制限、接続先サイトの応答も速度に影響します。対応プロトコルが多いからといって、どの回線でも通信速度が上がるわけではありません。

6. コア選びに関するよくある質問

サブスクリプションにVLESSとあるのに、v2flyNGで使えないのはなぜ？

まずノードの詳細を開き、REALITYやxtls-rprx-visionが含まれていないか確認してください。これらの拡張機能は、基本的なVLESSと同じものではありません。ノードが対応機能を必要とする場合は、v2rayNGに元のリンクをインポートし、各項目が正しく読み込まれていることを確認しましょう。

v2rayNのコアファイルを入れ替えたのに、起動時にエラーが出るのはなぜ？

まず起動ログを読み、実際に呼び出されるファイルとバージョンが変わったことを確認してから、生成された設定を調べてください。古いクライアントでは、以前の項目名を使ったJSONが生成されることがあります。実行ファイルだけを入れ替えても、クライアントの設定生成機能が新しいコアに対応するとは限りません。

REALITYのポートには接続できるのに、Webページがタイムアウトする場合は？

ポートに到達できることから分かるのは、基本的なネットワーク接続が成立していることだけです。SNI、shortId、鍵情報、フィンガープリント、flowを確認し、リモート側のハンドシェイクログも確認してください。プロキシの直接テストが成功してアプリだけ失敗する場合は、システムプロキシとルーティングルールを調べましょう。

以前から使っているVMessノードが正常なら、Xrayへ移行する必要はありますか？

プロトコル名だけを理由に移行する必要はありません。まず現在の設定を維持してください。サーバーから新しいノードが提供された場合、現在のクライアントが必要な機能に対応していない場合、または明確な互換性の問題が確認された場合に限り、ノードごとに移行をテストしましょう。

最終的な選択は、サーバーの要件を確認し、クライアントがどの項目を生成できるかを確かめ、実際に起動するコアがその項目を受け付けるか確認する、という流れで判断できます。この3つを分けて考えるほうが、クライアント名だけで互換性を推測するより確実です。

クライアントをダウンロードv2rayN / v2rayNG