2026年8月12日 · コア解説 · 約9分

XrayコアとV2Flyコアの違い|XTLS・REALITY対応と設定互換性を比較

XrayとV2Flyの開発経緯、プロトコル対応、設定項目の互換性を比較。v2rayNGとv2flyNGの用途も解説します。

この記事の要点

ノードにREALITYやxtls-rprx-visionが含まれる場合は、これらに対応したXrayコアを選びましょう。VMess、標準的なVLESS、TLSのみの場合は、通信方式と各設定項目を確認して互換性を判断します。Androidクライアントの選択、デスクトップ版コアの切り替え、サブスクリプションのインポートエラーの解決を検討している方向けに、プロトコル名だけでなく確認すべきパラメーターと、設定ミス・ネットワーク障害の見分け方を解説します。

プロジェクトの経緯とクライアントの役割

Xray-coreとV2Flyが保守するv2ray-coreは共通のプロジェクトにルーツを持ちますが、現在は異なる方針で機能が発展しています。Project Vはこのプロキシツール群を理解するうえでの背景です。V2Flyはコミュニティを引き継ぐ形でv2ray-coreを保守し、Xrayは独自の道を歩んでいます。どちらもプロキシ接続、ルーティング、DNSなどを処理するコアプログラムであり、クライアントの画面そのものではありません。

クライアントはサブスクリプションの管理、ノードの編集、コアの起動、ログの表示を担当します。コアは最終的な設定を読み込み、接続を処理します。そのため、「画面上でノードをインポートできる」ことと「コアでそのノードを実行できる」ことは別です。サブスクリプションのパーサーが一部の項目を認識しても、現在のコアに渡して実行できるとは限りません。

サブスクリプション解析 設定生成 コアの読み込み ルーティング判定 アウトバウンドのハンドシェイク

トラブルシューティングでは、クライアントのバージョンと実行中のコアのバージョンを両方記録してください。画面側のプログラムを更新しても、既存のコアファイルが同時に更新されるとは限りません。また、コアを入れ替えても、クライアントのエディターがすべての新しい設定項目を生成できるとは限りません。

プロトコル対応とXTLS・REALITYの比較

REALITYとXTLS Visionは、VMessやVLESSの別名ではありません。VLESSはプロキシプロトコル、REALITYはトランスポートのセキュリティ設定、Visionは特定の接続構成と組み合わせて使うフロー制御方式です。サブスクリプションにVLESS、REALITY、Visionが併記されている場合は、複数の設定レイヤーを確認する必要があります。「VLESS対応」だけを確認して終わりにしないでください。

機能・構成XrayコアV2Flyコア確認するポイント
VMess対応対応認証方式、通信方式、TLS設定
標準的なVLESS対応対応これだけでVision対応とは判断できない
WebSocket + TLS一般的な構成に対応一般的な構成に対応パス、Host、SNI、証明書
REALITY対応XrayのREALITY設定には非対応サーバーの公開鍵情報、shortId、serverName
xtls-rprx-vision対応する構成で利用可能このフロー制御方式には非対応フロー制御の値、通信方式、セキュリティレイヤーの組み合わせ
JSON設定全体Xrayの設定構文として解析V2Flyの対応する設定形式として解析設定ファイル全体の互換性は保証されない

ここでいうXTLSは、現在一般的なVisionの使い方を指します。古いチュートリアルにあるxtls-rprx-directなどの過去のフロー制御値を、xtls-rprx-visionに置き換えるだけで移行が完了するわけではありません。サーバー側も互換性のある構成である必要があります。クライアント側だけでフロー制御を変更すると、ハンドシェイクに失敗することがあります。

選び方の結論:まずセキュリティレイヤーとフロー制御を確認

ノードの編集画面にsecurity=realityまたはflow=xtls-rprx-visionがある場合は、まずXrayを選び、そのうえで通信方式の設定を確認してください。V2Flyコアに合わせるために、これらの項目を削除してはいけません。

REALITYとVisionが接続で果たす役割

REALITYはハンドシェイク時に、クライアントがサーバーの秘密鍵に対応する情報を検証し、接続先サイトに関連するパラメーターと組み合わせてTLSハンドシェイクの特徴を再現します。プロキシ通信をすべて接続先のWebサイトに転送する仕組みでも、認証をなくす仕組みでもありません。サーバー側では鍵、接続先、許可する名前を正しく設定し、クライアント側でも対応するパラメーターを一致させる必要があります。

Visionは主に、プロキシトンネルでTLS通信を運ぶ際の識別とデータ転送経路を扱います。条件を満たす場合、処理の重複やオーバーヘッドを減らせます。すべての接続で暗号化を省略するわけではなく、物理回線の混雑、地域間の往復遅延、通信事業者のネットワークで発生するパケットロスを解消するものでもありません。Webページの表示速度が改善するかどうかは、実際の用途に応じて判断してください。

VLESS + REALITY + Vision

プロキシプロトコル
VLESS
通信方式
TCP系の通信方式。名称は設定のバージョンに応じて確認
セキュリティレイヤー
REALITY
フロー制御
xtls-rprx-vision
認証情報
ユーザーID、公開鍵情報、shortIdなど

サーバーから提示されたパラメーターをすべて設定してください。REALITYのパラメーターを一般的なTLS証明書の設定として扱わないでください。

VMess + WebSocket + TLS

プロキシプロトコル
VMess
通信方式
WebSocket
セキュリティレイヤー
TLS
パスの例
/ws。サーバー側の設定と一致させる
名前に関する設定
WebSocketのHostとTLSのSNIをそれぞれ確認

どちらのコアにも一般的な実装があります。パスの例は共通の初期値ではないため、実際のノード設定を確認してください。

設定の互換性と項目の移行

従来のJSON設定には、inbounds、outbounds、routingなど、両方のコアで共通する構造が数多くあります。ただし、「項目名が同じ」に見えても、受け付ける値、既定の動作、子項目まですべて一致するとは限りません。V2Flyには複数の設定形式があり、それぞれ違いがあります。移行前に、現在のファイルがどの形式を使っているか確認してください。

従来型のJSONルーティングルールを例にすると、次のスニペットは「プライベートアドレスをdirectアウトバウンドに通す」設定です。ルーティング部分のみを示しており、単独で起動できる完全な設定ではありません。実際のファイルにはdirectというタグのアウトバウンドが必要です。また、ルールで使うデータファイルも用意してください。

routing.json · 設定スニペット
{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

設定の読み込みに成功したことと、各項目が実際に反映されたことも区別する必要があります。不明な項目はエラーになる場合もあれば、無視される場合もあります。プロセスが起動しただけでは、移行が成功したとはいえません。ログ、実際に使われたアウトバウンド、対象アプリの接続結果を確認してください。項目同士の関係はプロトコル設定ガイドも参照しながら確認できます。

ポートの確認とトラブルシューティングの手順

接続できないときは、まずローカル接続とリモート側のハンドシェイクを分けて確認します。以下のポート番号は確認方法を説明するための例であり、すべてのクライアントで使われる既定値ではありません。現在のインバウンド設定とノードのポート番号を基準にしてください。チュートリアルの値に合わせるために、正常に動作している待ち受け設定を変更する必要はありません。

10808
ローカルSOCKSインバウンドのポート例
443
リモートTLSサーバーのポート例
  1. アプリがクライアント経由で通信しているか確認。ローカルSOCKSインバウンドが127.0.0.1:10808で待ち受けている場合、アプリ側でも対応するアドレス、ポート、プロキシの種類を指定する必要があります。システムプロキシを有効にしても、すべてのアプリがその設定に従うとは限りません。
  2. コアが正常に読み込まれているか確認。起動直後に終了する、ログに設定項目を解析できないと表示される、フロー制御に対応していないと通知される場合は、まずコアの選択と設定形式を確認してください。最初にDNSを変更する必要はありません。
  3. リモート側に接続できるか確認。ローカルのインバウンドが正常なのにリモート接続がタイムアウトする場合は、ノードのアドレス、実際のサーバーポート、ネットワーク経路、サーバーの状態を確認します。ポートに到達できても、認証に成功するとは限りません。
  4. ハンドシェイクのパラメーターを確認。REALITYでは公開鍵情報、shortId、serverName、時刻の設定を重点的に照合します。標準的なTLSではSNI、証明書の有効期限、信頼チェーンを確認してください。証明書の検証を無効にして、設定ミスを隠してはいけません。
  5. ルーティングと名前解決を確認。一部のドメインだけ接続できない場合は、名前解決の結果と適用されたアウトバウンドを確認します。テスト中は一度に変更するパラメーターを一組に絞り、元に戻せるよう設定を保存してください。

トラブルシューティングの結論:起動、ハンドシェイク、振り分けの順に確認

まず、必要なパラメーターがすべて分かっているノードを一つ使って基本接続を確認し、その後でカスタムのルーティングとDNSを戻します。こうすれば、コアの機能不足、認証パラメーターの誤り、振り分けルールの問題を切り分けやすくなります。複数箇所を同時に変更して、原因を見失うのを防げます。

クライアント選びとサブスクリプションの移行

AndroidでREALITYまたはVisionを使うノードがある場合は、v2rayNGを優先してください。標準的なVMessまたはVLESSのノードで、サーバー側の案内がV2Flyの設定を前提としている場合は、v2flyNGを選べます。デスクトップでv2rayNを使う場合は、ノードが必要とする機能を確認してから対応するコアを選択してください。画面上の製品名だけでは互換性を判断できません。

サブスクリプションを移行するときは、新しいグループにインポートし、旧グループを戻せる状態で残しておくことをおすすめします。まずノードを一つインポートして設定を照合し、その後まとめて更新し、最後にルーティング設定を移行します。サブスクリプションの更新で手動編集したノード項目が上書きされる場合があります。インポート後にフロー制御やセキュリティレイヤーが欠けている場合は、何度も手入力するのではなく、サブスクリプションの形式とクライアントの解析機能を確認してください。

同じVMessノードが2つのクライアントで使えれば、設定全体に互換性があるといえますか?

確認できるのは、そのノードが現在使っているプロトコルと通信方式の組み合わせを、両方のコアで処理できるということだけです。DNS、ルーティング、インバウンドの待ち受け、ほかのノードのセキュリティレイヤーは異なる場合があります。JSON全体をエクスポートしても、項目ごとの確認が必要です。単一ノードで接続できたことを、設定全体の互換性を示す証拠にしないでください。

flowを削除したり、REALITYをTLSに変更したりしても、元のノードに接続できますか?

通常は接続できません。クライアントとサーバーで互換性のあるプロトコル構成を使う必要があります。パラメーターを削除しても、サーバーが自動的に別のモードへ切り替わるわけではありません。サーバー側で別の利用可能な設定を明示的に提供してもらうか、元の構成に対応したコアを使ってください。

サブスクリプションのインポートには成功したのに、すべて接続できません。まずコアを変更すべきですか?

まずログを確認し、ノードを一つ選んで動作を調べてください。対応していないプロトコル、フロー制御、セキュリティレイヤーがログに示されている場合は、コアの選択を見直します。タイムアウト、認証失敗、証明書エラーの場合は、それぞれネットワーク、アカウント情報、名前の設定を確認してください。サブスクリプションの管理方法はサブスクリプションのインポートガイドを参照してください。

クライアントをダウンロードプラットフォームとインストーラーの選択