XrayコアとV2Flyコアの違いを比較：機能差とクライアントの選び方

2つのコアの分岐点

V2FlyとXrayはいずれもV2Rayの技術体系を源流とし、基本構造はよく似ています。設定には通常、インバウンド、アウトバウンド、ルーティング、DNS、ログ、ポリシーの各モジュールが含まれます。どちらも一般的なプロキシプロトコルに対応し、ドメイン、IP、ポート、ルールセットに応じてアウトバウンドを選択できます。違いはプロキシを起動できるかどうかではなく、その後に追加されたプロトコル拡張、トランスポート実装、設定項目、メンテナンス方針にあります。

V2FlyはコミュニティによってV2Ray Coreのメンテナンスが続けられ、v5設定とAPIの整備が進められています。VMess、VLESS、Trojan、Shadowsocks、WebSocket、gRPCなどの一般的な構成に依存する環境に適しています。一方、Xrayは既存設定との互換性を保ちながら、VLESS、XTLS Vision、REALITY、関連するフロー制御機能を継続的に発展させています。ノード設定にこれらの固有項目が含まれる場合、コアの選択は好みではなく、設定を解析して接続できるかどうかの問題になります。

メンテナンス状況は、問題の切り分けにも影響します。エラーが発生したら、単に「V2Rayの接続に失敗」と書くのではなく、クライアントのバージョン、コアのバージョン、プロトコル、トランスポート方式、セキュリティ層を記録してください。たとえば、テスト環境でXray-core 25.6.8とV2Ray 5.30.0を固定して得た結果は、その組み合わせにのみ有効です。アップデート後に設定の解析ルールが変わった場合は再テストが必要で、以前の結論を新バージョンへそのまま適用してはいけません。

• 共通する基盤：インバウンドとアウトバウンドのモデル、ルーティングのマッチング、DNS処理、ログレベルなどの概念は共通しています。
• Xrayの方向性：REALITY、XTLS Visionなど、Xray系の機能を優先的にカバーします。
• V2Flyの方向性：V2Ray Coreのコミュニティメンテナンスを引き継ぎ、独自のv5設定体系を発展させています。
• 移行の原則：まず固有項目を特定し、次にプロトコルとトランスポートを検証し、最後に性能を比較します。

VLESS、REALITY、XTLSの対応範囲

VLESSだけを根拠に判断することはできません。どちらのコアにもVLESSの利用場面はありますが、具体的な設定には異なるフロー制御、セキュリティ層、トランスポートパラメータが含まれる場合があります。アドレス、ポート、ユーザー識別子、TCP、TLSだけで構成されたVLESSノードと、REALITYの公開鍵、短い識別子、サーバー名、フィンガープリント、Visionフロー制御を同時に含むノードでは、実際の依存関係が大きく異なります。

REALITYはXray系の機能です。共有リンクでよく見られる関連パラメータにはsecurity、pbk、sid、sni、fp、flowがあります。ノードがsecurity=realityを要求する場合、クライアントにはこの機能に対応したXrayコアが必要です。対応する項目を認識できないコアへリンクを渡すと、インポート時に項目が失われたり、起動時に未知の設定として扱われたり、接続確立直後に切断されたりすることがあります。

XTLSでは、過去の名称と現在のフロー制御を区別する必要があります。現在の設定では、VLESSにflow=xtls-rprx-visionを組み合わせる構成が一般的です。これはTLSのスイッチ名を変えるだけではなく、Xrayのデータ経路とフロー制御の実装に関わります。サーバーがVisionを要求する場合、クライアントも同じflowを維持してください。この項目を削除しても通常のTLSへ自動的にフォールバックするわけではなく、双方のパラメータが一致しなくなります。

設定ファイルはそのまま交換できるか

基本的なJSON構造が似ていても、完全な設定を無変更で交換できるとは限りません。一般的なinbound、outbound、routing、dnsモジュールが似ているため、「実行ファイルを変えるだけで動く」と考えがちですが、コアはプロトコル項目、トランスポート層の項目、オブジェクト階層を個別に検証します。固有項目を認識できない場合、クライアントのインポーターが無視するだけで済むこともあれば、コアの起動に失敗することもあります。

以下は、XrayのREALITYノードを識別するための簡略化した構造です。直接接続できる完全な設定ではありませんが、securityがrealityであること、flowがxtls-rprx-visionであること、さらにrealitySettings内にpublicKeyとshortIdがあることを確認できます。

{
  "protocol": "vless",
  "settings": {
    "vnext": [{
      "address": "example.invalid",
      "port": 443,
      "users": [{
        "id": "00000000-0000-0000-0000-000000000000",
        "encryption": "none",
        "flow": "xtls-rprx-vision"
      }]
    }]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "serverName": "server.example",
      "fingerprint": "chrome",
      "publicKey": "サンプル公開鍵テキスト",
      "shortId": "0123456789abcdef"
    }
  }
}

サブスクリプションを移行する際は、「サブスクリプションの内容」と「コアの設定」を区別する必要があります。サブスクリプションは通常、まずクライアントが共有リンクを解析し、その後コアが必要とするJSONへ変換します。同じリンクを2つのクライアントに読み込ませても、既定のフィンガープリント、Muxの設定、DNSポリシー、ルーティングルールの違いによって生成結果が変わる場合があります。インポートに成功したことは、クライアントがテキストを認識したことを示すだけで、コアがすべての項目に対応しているとは限りません。

1. 変更前に元の設定をコピーし、現在のコアのバージョンを記録してください。唯一の利用可能な設定を直接上書きしてはいけません。
2. ノードの詳細で、プロトコル、トランスポート、セキュリティ層、flow、SNI、ALPN、フィンガープリントを確認します。
3. コアを切り替えたら、まず単一のノードを起動し、コアのログにunknown field、failed to parse、handshakeなどのエラーが出ていないか確認します。
4. SOCKSポート10808などのローカル待受ポートが、別のプロセスに使用されていないことを確認します。
5. DNS解決、TCPによるページアクセス、継続的な通信の順にテストし、1回の遅延値だけで判断しないでください。

性能差はどうテストするか

同じノードを2つのコアで使った際の遅延差が数ミリ秒程度なら、通常は一方のコアが速い証拠にはなりません。ネットワーク経路、サーバー負荷、DNSキャッシュ、接続の再利用、テスト時刻によって結果は変わります。より信頼できる方法は、ノード、設定、ネットワーク、テスト対象を固定し、複数回交互に実行して、中央値、失敗回数、継続的な通信の安定性を比較することです。

再現性のあるデスクトップテストは、次のように設定できます。ローカルSOCKSポートを10808、接続タイムアウトを2秒に固定し、経路を変える追加のチェーンプロキシは無効にします。各コアで短時間の接続を50回実行し、その後、5分間の継続通信を3回行います。テスト中はサブスクリプションの更新や速度測定を同時に実行しないでください。コアのログや帯域が競合し、結果が乱れるためです。

• 接続確立：50回中の成功回数と所要時間の中央値を記録し、1回だけの最小値は使いません。
• 継続通信：5分間の計測中に再接続、停止、ハンドシェイクエラーが発生しないか確認します。
• リソース使用量：同じ接続数でメモリとプロセッサの使用量を記録し、少なくとも60秒待ってから測定します。
• ログの結果：プロトコルエラー、DNSエラー、タイムアウト、ポート競合を分けて集計します。

一般的なVMess + WebSocket + TLSノードでは、2つのコアが実効スループットで近い結果になることが多く、わずかな数値差よりもクライアントの操作性と設定の安定性が重要です。REALITYやVisionノードでは、テストの前提がすでにXrayに限定されています。対応する項目をサポートしないコアを速度比較に参加させても、接続能力そのものが同等ではないため意味がありません。

v2rayN、v2rayNG、v2flyNGの選び方

クライアント名とコア名は同じ概念ではありません。クライアントはサブスクリプション、画面、ルーティングの入口、システムプロキシ、設定生成を担当し、コアは実際の設定解析と通信転送を担当します。選ぶ際は、まずプラットフォーム、次にノードが必要とする機能、最後にクライアントが対応する設定項目を確認してください。

v2rayNはWindowsデスクトップ環境に適しており、グループ管理、コアログの確認、ルーティングの切り替えが簡単です。現在の設定を確認するには、「設定」→「パラメータ設定」を開き、コアの種類、ローカル待受ポート、DNS関連の項目を確認してください。バージョンによってメニューの表記は多少異なりますが、コアログは実際に動作しているコンポーネントを判断する直接的な手がかりです。

v2rayNGはXrayコアを使用し、AndroidでのREALITY、XTLS Vision、一般的なVMess、VLESS、Trojanノードに適しています。インポート後はノードの詳細を開き、トランスポート層、セキュリティ種別、SNI、フィンガープリント、flowを確認できます。サブスクリプション更新後に突然接続できなくなった場合は、設定をすべて削除する前に、更新前後の項目を比較してください。

v2flyNGはV2Flyコアを使用し、V2Flyの設定経路を維持したいAndroidユーザーに適しています。既存のVMess、標準TLS、WebSocket、gRPCなどの組み合わせに向いています。サーバーがREALITYまたはVisionを明示的に要求している場合、項目を削除して無理にインポートせず、その設定に対応したXrayクライアントへ切り替えてください。

よくある選択の疑問とトラブルシューティング

コアの不一致には、比較的明確な兆候があります。インポート後に重要な項目が空になる、コアが起動しない、ログに未知の項目が表示される、ハンドシェイクが繰り返し失敗する、通常のノードは使えるのにREALITYノードだけすべて失敗する、といった症状です。切り分けでは、まずコアが本当に起動しているかを確認し、次にノードパラメータ、最後にシステムプロキシとルーティングを確認します。

最終的な選択は3段階にまとめられます。まず設定にREALITYまたはVisionが含まれているか確認し、次にクライアントが実際に使用しているコアを確認し、最後にログと複数回の接続テストで検証します。通常のノードは2つのコア間で頻繁に移行する必要はありません。固有プロトコルは実装を厳密に一致させてください。1回の遅延、ノード名、クライアント名だけで判断するより確実な方法です。