· コア解説 · 約10分

Xray-coreとV2Flyの違いを比較｜対応プロトコル・設定互換性・クライアントの選び方

Project Vの2つのコアの成り立ちを解説。VLESSやREALITYの対応状況、設定の互換性を比較し、v2rayNGとv2flyNGの選び方を紹介します。

この記事の要点

コアはノード設定を実行できるかどうかを左右し、クライアントはインポートや編集、システムへの接続を担います。VLESS、REALITY、Visionの組み合わせが必要なら、まずXrayの対応状況を確認しましょう。既存のVMessノードやV2Fly設定を使っている場合は、名前だけを理由に移行せず、現在の設定が動作するかを先に検証してください。以下では、プロトコル、設定項目、クライアント、トラブルシューティングの順に、実用的な選び方を解説します。

1. Project V、V2Fly、Xray-coreの関係

Project Vは、V2Rayを中核とするネットワークツールと技術のエコシステムです。V2FlyコミュニティはV2Ray-coreの保守を続けています。一方、Xray-coreは2020年に関連コードから分岐し、独自の開発路線を歩み始めました。両者には共通のルーツがありますが、その後追加されたトランスポート方式や設定項目、実装の詳細に互換性があるとは限りません。

「V2Rayノード」はサブスクリプションサービス全般を指す呼び方として使われることがありますが、それだけではコアを特定できません。実際の接続プロトコルはVMessの場合もVLESSの場合もあり、トランスポートもWebSocketまたはTCPなどさまざまです。サブスクリプション内のグループ名ではなく、展開したプロトコルと設定値を確認してください。

2. プロトコルの対応状況：VLESS、REALITY、Visionを区別する

VLESSはプロキシプロトコル、REALITYはセキュアなトランスポート方式、xtls-rprx-visionはXrayで使われるフロー制御オプションです。これらは別々の設定であり、どれか1つの名称だけで接続全体を説明することはできません。よくある構成はVLESS、TCP、REALITYの組み合わせで、Visionはサーバーの指定に従って設定します。

機能・構成Xray-coreV2FlyのV2Ray-core確認するポイント
VMessと一般的なWebSocket/TLS設定対応する設定をサポート対応する設定をサポート認証パラメーター、パス、Host、TLSの名称
VLESSの基本プロトコル対応し、関連機能も継続的に拡張名称だけで非対応と判断せず、バージョンと実装範囲を確認するプロトコル名だけでなく、トランスポートを含む接続全体の構成
VLESS + REALITY主要な用途のひとつXrayのREALITY設定をそのままインポートして使うことはできないサーバー名、鍵関連のパラメーター、shortId
xtls-rprx-vision対応するフロー制御の組み合わせをサポート同じ名称でも、そのまま置き換えられる機能とは限らないクライアントとサーバーのflowが一致しているか
基本的なDNSとルールベースのルーティング対応対応フィールド構造、ルールの順序、データファイル形式

VMessでは認証方式も確認が必要です。一般的なAEADノードではalterId: 0を使います。古い手順書にある0以外の値をそのまま適用しないでください。これはプロトコルの互換条件であり、速度向上のために任意で値を上げる性能パラメーターではありません。

結論：接続全体の構成に合わせてコアを選ぶ

ノードでREALITYまたはxtls-rprx-visionが明確に必要な場合は、該当機能に対応したXray環境を選びましょう。VMess、WebSocket、TLSなどだけが必要なら、まず現在の環境で動作を確認してください。移行を速度向上の手段と考える必要はありません。

3. 設定の互換性：JSON形式が同じでも、そのまま交換できるとは限らない

どちらの系統にもinbounds、outbounds、routingなどの概念があります。しかし、フィールドが似ているのは共通のルーツがあるためで、完全な互換性を意味しません。新しいトランスポート方式やセキュリティ設定、DNSの動作、V2Flyの異なる設定形式などが、解析や実行に影響することがあります。

サブスクリプションのリンクは、さらに別の形式です。クライアントは通常、共有リンクを内部ノード形式に変換してから、対応するコア用の設定を生成します。そのため、「サブスクリプションをインポートできた」ことは、画面が内容を受け付けた証明にすぎません。生成された設定をコアが受け入れることや、リモートサーバーとのハンドシェイク成功までは保証しません。

  1. まずプロトコルの項目を確認：protocolがVMessかVLESSか、認証情報がサーバー側と一致しているかを確認します。スクリーンショットや公開ログに認証情報全体を載せないでください。
  2. 次にトランスポートの項目を確認：streamSettings内のnetworkとsecurityを確認します。TCPとWebSocketは互換ではなく、TLSとREALITYも別の選択肢です。
  3. フロー制御は個別に確認：サーバーがVisionを要求する場合は、生成された設定のflowがxtls-rprx-visionになっているか確認します。通常のVMessノードにはこの値を設定しないでください。
  4. 最後にルーティングを確認：各ルールが参照するアウトバウンドのタグが実在することを確かめます。タグは設定内の参照名にすぎず、「プロキシ」という名前を付けても自動的にプロキシ機能が備わるわけではありません。

以下は、参照関係を説明するためのルーティング項目の一部例です。起動可能な完全設定ではありません。directという名前の直接接続アウトバウンドがすでにあり、コアがprivateタグを含むGeoIPデータファイルを読み込めることを前提としています。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

4. クライアントの選び方：v2rayN、v2rayNG、v2flyNG

デスクトップでは、ノードの互換性を検討する前に、v2rayNが現在どのコアを使っているか確認します。Androidではプロジェクトの系統で選び分けられます。v2rayNGはXrayコアを、v2flyNGはV2Flyコアを使用します。名称が似ていてもプロトコル対応が同じとは限らず、同じサブスクリプションをインポートしても利用可能なノードが一致するとは限りません。

Xray系：v2rayNの対応コアまたはv2rayNG

おすすめ

ノードでVLESS、REALITY、Visionの組み合わせが必要な場合は、この構成を優先してください。クライアント内蔵のコアがサーバー側の具体的な設定に対応しているかも確認しましょう。

向いているケース：サブスクリプションにREALITYまたはVisionノードが含まれ、対応するプロトコル機能が必要な場合。

V2Fly系：v2flyNGまたは既存のV2Fly環境

動作確認済みのVMessなどの設定があり、V2Flyの設定体系に依存している場合は、そのまま使い続けられます。古い設定を一律に時代遅れとみなすのではなく、現在の設定を安定して実行できるかどうかで判断してください。

向いているケース：既存のV2Fly環境を保守し、互換性が確認されたノードやルーティングルールを再利用する場合。

v2rayNでは、まず「設定」→「パラメーター設定」でローカルの待ち受け設定や関連するコア設定を確認します。項目名や場所は配布版によって異なることがあります。想定していたコア設定が画面にない場合は、現在のリリース情報と実行ログを確認してください。互換性を確かめるために、プログラムのフォルダー内にある実行ファイルを安易に置き換えないでください。

導入方法：デスクトップとAndroidを個別に検証する

デスクトップ：v2rayN
  • 起動ログに記録されたコア名とバージョンを確認する。
  • ノードをインポートしたら、プロトコル、トランスポート、セキュリティ設定を確認する。
  • ローカルポートを確認してから、システムプロキシとルーティングルールを検証する。
Android：コアに合わせてクライアントを選ぶ
  • REALITY/Visionが必要なら、まずv2rayNGの対応状況を確認する。
  • 既存のV2Fly設定は、まずv2flyNGで検証する。
  • システムVPNの許可とアプリごとの設定が、対象アプリに適用されていることを確認する。

同じサブスクリプションを両方の端末で使えますが、プロトコルの解析結果、ルーティング方針、アプリの通信を取り込む範囲は、それぞれ個別に確認する必要があります。

5. 移行時の検証：まずコアの起動を確認し、次に通信がプロキシを経由することを確かめる

移行時は、一度に変更する要素を1つに絞ってください。まず既存のサブスクリプションとルーティング設定をバックアップし、互換性のある同じノードで新しいコアを検証します。ノード、DNS、ルーティングモード、ローカルポートを同時に変更すると、接続に失敗しても原因を特定しにくくなります。

  1. 起動を確認：クライアントのログを開き、設定の解析エラー、未知のフィールド、ポートの競合がないかを先に確認します。この段階では、リモート回線の速度を判断する必要はありません。
  2. 待ち受けを確認：v2rayNの「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。以下では有効化済みのSOCKS待ち受け127.0.0.1:10808を例にしますが、すべての環境で固定の値ではありません。
  3. プロキシを明示して指定：コマンドラインからリクエストを送り、ブラウザーがシステムプロキシを使うかどうかの影響を除きます。以下のコマンドは、ローカルで実際にSOCKSサービスが提供されている場合にのみ使えます。
  4. ルーティングを検証：テスト対象がプロキシアウトバウンドに一致するよう一時的に設定し、ログとあわせて実際に使われたアウトバウンドを確認します。リクエストに成功しても、直接接続のルールに振り分けられていないとは限りません。
  5. アプリで確認：次にシステムプロキシまたは対応するネットワーク制御を有効にして、普段使うアプリをテストします。Androidでは、そのアプリがアプリごとのルールで除外されていないことも確認してください。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

Windowsのターミナルでは、コマンドのエイリアスによる干渉を避けるためにcurl.exeを使えます。ここでのsocks5hは、接続先のドメイン名をプロキシ側で処理する指定です。これだけで最終的にリモートのプロキシアウトバウンドが選ばれるとは限らず、その後の動作はコアのルーティングルールに従います。例にある接続タイムアウト10秒、全体のタイムアウト20秒はテスト用の設定で、速度を保証するものではありません。

症状優先して確認する層次に行うこと
コアが起動直後に終了する設定の解析、ファイルパス、ローカル待ち受けログで最初のエラーを確認し、リモートノードはすぐに変更しない
ローカルポートへの接続が拒否されるコアのプロセス、アドレス、ポート待ち受けが有効で、テストに使うポートが設定と一致しているか確認する
REALITYのハンドシェイクに失敗するパラメーターの一致、システム時刻、サーバーへの到達性サーバー名、鍵関連のパラメーター、shortIdを確認する
コマンドラインでは成功するが、ブラウザーでは失敗するシステムプロキシ、ブラウザーのポリシー、拡張機能の設定まずプロキシの適用範囲を確認し、その後DNSとルーティングの違いを調べる

6. 性能の判断：コア名だけで性能を比べない

XrayとV2Flyの性能差は、プロトコルや回線の条件を抜きにして比較できません。出口側の混雑、往復遅延、パケットロス、サーバー負荷、端末が頻繁にスリープするかどうかなどは、コアの違いより大きく影響する場合があります。Visionは対象となる通信で処理の重複を減らす仕組みですが、それを理由にすべてのWebページが大幅に速くなるとは言えません。

結論：移行には明確な理由が必要

必要な機能がない場合、互換性の問題が確認された場合、または同じ条件で再現する不具合がある場合に限り、コアの変更を解決策として検討してください。ノード自体に接続できない場合は、まず回線と設定を確認しましょう。

7. よくある質問：インポート成功後の失敗と混在サブスクリプション

サブスクリプションは更新できるのに、REALITYノードに接続できないのはなぜですか？

更新成功で確認できるのは、サブスクリプションの取得に成功したことだけです。ノードの編集画面を開き、VLESS、REALITY、サーバー名、鍵関連のパラメーター、shortId、flowを順番に確認します。さらに起動ログを見て、該当機能に対応するXrayコアが実際に動作していることを確かめてください。

v2rayNGからv2flyNGに乗り換えても、以前のノードはすべて使えますか？

ノード数だけで判断することはできません。まずプロトコルとトランスポートの互換性が明確なノードを選んでテストしてください。REALITYやVisionが必要なノードを、一般的なVLESSノードとして扱わないでください。元のクライアント設定を残し、動作を確認してから普段使いの環境を移行しましょう。

コアを切り替えた後にポートが使用中と表示されます。10808以外に変更すべきですか？

まず、別のクライアントや終了せずに残ったコアのプロセスを停止し、「設定」→「パラメーター設定」にある待ち受けアドレスとポートを確認してください。ポートを変更する場合は、テスト用コマンドや、そのポートを使うアプリの設定もあわせて変更します。一か所だけ変更しないでください。

同じサブスクリプションにVMessとVLESSがあります。クライアントを2つインストールする必要がありますか？

プロトコルが混在しているという理由だけで、2つのクライアントをインストールする必要はありません。まず、1つのクライアントと現在のコアで、サブスクリプションに含まれる必要な構成を利用できるか確認します。同じ環境で検証できるノードはまとめて管理し、別の環境が必要なのは明確な機能上または互換性上の理由がある場合に限ります。

選択の順序は、まずサーバー側の要件を確認し、次にコアの機能を確かめ、最後にクライアントとシステムへの接続方法を決めることです。サブスクリプション、DNS、プロキシの適用範囲を引き続き確認する場合は、トラブルシューティングを使って原因を順番に特定できます。用語の意味は用語集をご覧ください。

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