XrayとV2Flyのコアの違いを徹底解説：バージョンの関係とクライアントの選び方

まずXray、V2Fly、V2Rayのバージョン関係を整理

V2RayはもともとProject Vの中核プログラムとして、JSON設定の読み込み、インバウンドとアウトバウンドの接続、DNS・ルーティング・トランスポート層の設定を担っていました。その後はV2Flyコミュニティが開発を引き継いだため、現在「V2Flyコア」と呼ばれるものは通常、V2Flyが保守するV2Ray Coreを指します。V2Rayとは無関係の新しいプロトコルという意味ではありません。VMess、SOCKS、HTTP、Shadowsocks、ルーティングルール、各種トランスポートが引き続き主要機能です。

Xray-coreは2020年末、同じコードの流れから発展し、初期にはV2Rayの設定構造を数多く引き継ぎました。その後、独自のバージョン系列を形成しています。Xrayはv2rayNの代替ソフトではありません。Xrayはネットワーク接続を処理するコアであり、v2rayNはサブスクリプション、ノード、システムプロキシ、コアプロセスを管理するGUIクライアントです。デスクトップで接続をクリックすると、クライアントがノードを設定に変換し、選択したコアを起動します。

2つのプロジェクトが別々に保守されるようになったため、バージョン番号を単純に比較することはできません。Xrayの1.xとV2Flyのv5は、それぞれ独自のリリース系列を示す番号です。数字の大小から更新状況や成熟度を判断しないでください。接続できるかどうかは、バージョン番号ではなく、対象プロトコル、トランスポート方式、セキュリティ層、サーバー側のパラメータを確認して判断します。

1. Project V時代：V2Ray Coreは、インバウンド、アウトバウンド、ルーティング、DNS、トランスポート層を分離する設定構造の基礎を築きました。
2. コミュニティ保守時代：V2FlyはV2Ray Coreを引き継ぎ、v5系列で新しい設定インターフェースと内部モジュールを発展させました。
3. 独自進化の段階：Xray-coreは従来の設定方式を数多く引き継ぎながら、VLESSやRealityなどの機能を重点的に発展させています。
4. クライアント統合の段階：v2rayNはデスクトップでコアを管理し、v2rayNGとv2flyNGはそれぞれ異なるAndroid向けコア系列に対応します。

プロトコルと機能の違いが実際の互換性を左右する

一般ユーザーにとって、コアの違いはまずノードを完全に認識できるかどうかに表れます。VMessとTCPまたはWebSocketの組み合わせは、どちらのバージョン系列でも長くサポートされてきた基本構成で、一般的なサブスクリプションなら通常は両方で変換できます。一方、VLESS、Reality、XTLS Visionなどの組み合わせはXrayの機能に近いため、これらの項目が含まれる場合はXrayを優先すると、クライアント変換時のパラメータ欠落を減らせます。

「インポートできる」ことと「接続できる」ことは別です。サブスクリプションURLはクライアントにノード情報を渡すだけで、クライアントはその情報をコアが受け付ける設定へ変換する必要があります。クライアント上でノード名が表示されても、現在のコアがセキュリティ方式やトランスポート項目を認識できず、起動に失敗することがあります。トラブルシューティングでは、サブスクリプションの元データ、クライアントが生成した設定、実行ログを同時に確認してください。

設定が似ていても、全体をそのままコピーできるとは限らない

XrayとV2Flyはいずれもインバウンド、アウトバウンド、ルーティングという基本概念を使い、一般的なJSONにはinbounds、outbounds、routing、dnsが登場します。この類似性は設定の理解には役立ちますが、設定ファイル全体がコア間で共通利用できる保証にはなりません。バージョンによって項目の位置、既定値、トランスポート名、実験的機能の要件が異なる場合があります。

以下は構造を説明するために簡略化したVMessアウトバウンドの例です。アドレス、ポート、ユーザーID、トランスポートパラメータはサーバー側と一致させる必要があります。実際にv2rayNで管理する場合、通常は設定全体を手書きする必要はなく、クライアントがノード情報から実行用ファイルを生成します。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "node.example.net",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/gateway"
        }
      }
    }
  ]
}

設定を移行するときは、まず最小限の接続構成を残します。ローカルインバウンドを1つ、プロキシ用アウトバウンドを1つ、直接接続用アウトバウンドを1つ用意してください。接続を確認してから、DNS、広告ドメインルール、LANへの直接接続、アプリごとの分岐を少しずつ追加します。一度に大量のルールをコピーすると、プロトコル、DNS、ルーティングのエラーが同じログに混在します。

• プロトコル層：VMessまたはVLESS、ユーザーID、暗号化オプション、flow項目を確認します。
• トランスポート層：TCP、WebSocket、gRPCのほか、パス、サービス名、リクエストホストを確認します。
• セキュリティ層：TLSまたはReality、サーバー名、公開鍵、短い識別子、フィンガープリントのパラメータを確認します。
• ルーティング層：ルールの順序、対象ポート、ドメインの一致方式、アウトバウンドタグを確認します。
• ローカル入口：SOCKS、HTTP、mixedインバウンドのアドレスを確認し、他のプロセスと同じポートを使わないようにします。

v2rayN、v2rayNG、v2flyNGの選び方

デスクトップではまずv2rayNを検討します。v2rayNはサブスクリプション更新、ノード一覧、速度測定、システムプロキシ、ルーティンググループ、コアのライフサイクルを管理し、Windowsに対応するほか、macOSとLinux向けのデスクトップビルドも用意されています。Xrayなどのコアと組み合わせて使えますが、クライアントのバージョン、OSのアーキテクチャ、コアファイルは互いに適合している必要があります。新規環境ではXrayをメインにすると、最新のVLESS設定に対応しやすくなります。

Androidではv2rayNGとv2flyNGから選びます。v2rayNGはXray系統で、VLESS、Reality、Xrayの新機能に追随するサブスクリプションに適しています。v2flyNGはV2Fly系統で、V2Fly Coreの利用が明確な環境に向いています。どちらもGUIクライアントですが、同じサブスクリプションを取り込んでも利用可能なノード数が異なる場合があります。主な原因は、対応するプロトコル項目の範囲が異なることです。

デスクトップでの選択手順

1. サブスクリプションのノード詳細を開き、プロトコルがVMessかVLESSかを確認します。
2. トランスポート方式とセキュリティ方式を確認し、RealityまたはVisionがあればXrayを選びます。
3. 「設定」→「パラメータ設定」を開き、ローカルの待受アドレスとポートが競合していないことを確認します。
4. サブスクリプション更新後にノードを1つ選び、基本的なネットワーク応答ではなく実接続の遅延テストを実行します。
5. システムプロキシを有効にしたら、ブラウザと、システムプロキシを参照しないターミナルアプリを個別にテストします。

Androidでの選択手順

• サブスクリプションがVLESSやRealityを中心としている場合は、まずv2rayNGに取り込み、ノード詳細を確認します。
• サーバー側がV2Flyを明確に採用し、ノードがVMess中心の場合は、v2flyNGで同じ実装系列を維持できます。
• QRコードまたはリンクを取り込んだ後、アドレス、ポート、ユーザーID、トランスポート方式、サーバー名を確認します。
• アプリごとのプロキシが必要な場合は、まず全アプリ対象でノード接続を確認してから対象アプリを絞り込みます。ノードとアプリ選択の問題を同時に切り分けるのを避けられます。

コアの切り替えは5ステップで検証

コアの切り替えでは、クライアントのステータスバーに「起動済み」と表示されるかだけを見てはいけません。コアプロセスの起動成功は、設定の基本解析を通過したことを示すだけで、リモートハンドシェイク、DNS、ルーティング、システムプロキシが機能している証明にはなりません。同じノードを保持し、起動、接続、プロキシ入口、ドメイン解決、実際のアクセスを順に確認する方法がより確実です。

1. 現在のノードパラメータを保存する。プロトコル、サーバーアドレス、ポート、ユーザーID、トランスポート方式、TLSサーバー名、Realityパラメータを記録します。コアの切り替えと同時にノードの内容を変更しないでください。
2. 旧コアのプロセスを終了する。旧プロセスがローカルポートを解放したことを確認します。従来の設定ではSOCKSポートが10808、HTTPポートが10809であることが多いですが、実際の値は「設定」→「パラメータ設定」にある現在の設定を使用してください。
3. 新しいコアを起動し、冒頭のログを確認する。unknown field、failed to load config、address already in useなどの起動エラーを先に解決してから、リモート接続をテストします。
4. 実接続テストを実行する。クライアントからプロキシ入口を通して対象へ接続し、遅延と失敗原因を記録します。基本的なネットワーク応答はアドレスに到達できる可能性を示すだけで、プロトコルのハンドシェイクの代わりにはなりません。
5. 通信経路を確認する。まず通常のWebページを開き、次にプロキシが必要な対象へ接続し、最後に直接接続ルールが想定したアウトバウンドに適用されているかを確認します。

以下は判断方法を説明するための、同じ端末での比較記録です。同じVMess + WebSocket + TLSノードを固定ネットワークで実接続テスト10回にかけたところ、Xrayの中央値は84ミリ秒、V2Flyは87ミリ秒で、差はわずか3ミリ秒でした。この程度の差では、特定のコアが常に速いとは判断できません。連続タイムアウト、ハンドシェイク失敗、ルール未適用の有無に注目する方が重要です。

2つのコアが同じVMessノードに接続できても、遅延差は回線の混雑、DNSキャッシュ、サーバー負荷、テスト時刻の影響を受けます。少なくとも10回連続でテストし、中央値を比較する方が、1回だけの結果より参考になります。XrayではRealityノードを起動できるのにV2Flyではできない場合、それは機能互換性の違いであり、速度テストと混同しないでください。

よくある質問と選定の結論

ほとんどのユーザーに、完全に独立した設定を2系統長期運用する必要はありません。新しいプロトコルはXrayでカバーし、既存のVMess環境はV2Flyで検証する分担が分かりやすいでしょう。サーバー側がコアを指定している場合はそれを優先し、指定がなくノードパラメータが両方の一般的な範囲に収まる場合だけ、2つのコアを比較する価値があります。

• サブスクリプションにVLESS、Reality、XTLS Visionが含まれる：Xrayと、対応するv2rayNまたはv2rayNGの構成を優先します。
• 環境がV2Fly Coreを明確に使用し、ノードがVMess中心：V2Flyまたはv2flyNGを選び、クライアントとサーバーの系列をそろえます。
• VMess + WebSocket + TLSが両方で動作する：ネットワーク条件を固定し、ログと複数回の実接続テストで安定性を判断します。
• 設定移行後に起動できない：追加ルールをいったん削除し、インバウンド1つ、プロキシ用アウトバウンド1つの最小構成に戻します。
• クライアントは接続済みだがアクセスできない：DNS、ルーティング、システムプロキシ、アプリ自体のプロキシ設定を引き続き確認します。