XrayとV2Flyのコア比較：プロトコル対応、更新ペース、選定のポイント

XrayとV2Flyはそれぞれ何を解決するのか

Xray と V2Fly はいずれも Project V に関連する技術体系に由来し、インバウンド、アウトバウンド、DNS、ルーティングルール、多様なプロキシプロトコルを扱えます。基本的な設定概念にも共通点が多く、inbound でローカル通信を受け、outbound でリモートサーバーへ接続し、routing ルールで出口を決めます。ただし、両者は独立して保守されているプロジェクトです。プロトコル拡張、フィールド定義、デフォルト動作、リリースペースが完全に同じだと考えてはいけません。

Xray を選ぶ際の要点は、新しいプロトコルとトランスポートの組み合わせです。VLESS、REALITY、XTLS Vision などのパラメータを含むノードは、通常 Xray エコシステムを前提に構成されています。デスクトップでは v2rayN、Android では v2rayNG を利用できます。クライアントが設定を生成して Xray コアを呼び出すため、ユーザーはサブスクリプションのインポート、ノード選択、システムプロキシまたは VPN モードの有効化を行うだけで、完全な JSON を手書きする必要はありません。

V2Fly の主な価値は、V2Ray 系設定の継続的な保守と既存設定との互換性にあります。VMess、WebSocket、TLS、TCP が中心のノードでは、V2Fly も検討できる実行コアです。Android で V2Fly の利用が明確に必要な場合は v2flyNG を選び、実行ログで実際に読み込まれたコアと設定を確認してください。

プロトコルとトランスポートパラメータからコアを判断する

最も早い判断材料は、サブスクリプションから生成されたノード詳細です。まずクライアントのノード編集画面を開き、アドレス、ポート、プロトコル、トランスポート方式、セキュリティ方式、フロー制御の各フィールドを記録します。ノード名にある「高速」「中継」などの表記だけで判断しないでください。これらのメモはコアのハンドシェイクには関係ありません。

VLESS だからといって、すべての実装をそのまま置き換えられるわけではありません。セキュリティ方式が REALITY か、フロー制御が xtls-rprx-vision か、トランスポート層が TCP、gRPC、その他のどれかを確認してください。共有情報に REALITY の公開鍵、ショート ID、serverName、Vision のフロー制御が含まれている場合は Xray を優先し、これらのフィールドを完全な状態で保持します。

サブスクリプションに VMess しか表示されない場合は、同じネットワーク環境で実際の接続を10回テストします。毎回いったん既存の接続を切断し、対象ノードへ接続して同じテスト先にアクセスし、成功回数、最初のレスポンスまでの時間、ログのエラーを記録してください。遅延差が20〜30ミリ秒程度なら、それだけでコアを決める材料としては不十分です。連続した成功率とページ表示の安定性を重視しましょう。

設定に互換性があっても、そのまま入れ替えられるとは限らない

両方のコアが構造化設定を使用し、インバウンド、アウトバウンド、DNS、ルーティングを表現できるとしても、フィールドが同じなのは表面的な互換性にすぎません。各フィールドが使えるかどうかは、コアのバージョン、プロトコル実装、トランスポートモジュールにも左右されます。完全な設定を別の実行コアでそのまま動かすと、未知のフィールド、アウトバウンドの初期化失敗、起動はするものの接続ハンドシェイクに失敗するといった問題が起こる可能性があります。

クライアント間の移行には、完全な JSON よりサブスクリプションリンクのほうが適しています。サブスクリプションサービスは通常、VMess または VLESS の共有情報を出力し、クライアントが自身のコアに応じて最終設定を生成します。移行時はまず元のサブスクリプションをインポートし、クライアントのキャッシュディレクトリをコピーしないでください。更新後は3つのノードを無作為に確認し、プロトコル、セキュリティ方式、SNI、トランスポート方式、ポートが失われていないことを確認します。

1. 元の設定を保持する。現在のサブスクリプション設定をエクスポートするか、サブスクリプションアドレスを記録し、まだ動作しているノード一覧を上書きしないでください。
2. 実際のコアを確認する。v2rayN では「設定」→「パラメータ設定」を開き、コア関連の項目を確認します。v2rayNG または v2flyNG では「設定」を開き、バージョン情報と実行ログを確認してください。
3. 設定を再生成する。移行先のクライアントでサブスクリプションをインポートして更新し、対象コアに合わせてクライアントにフィールドを生成させます。
4. まず1つのノードで試す。プロトコルフィールドが完全なノードを1つ選び、接続、DNS 解決、ウェブアクセスをテストしてから一括移行します。
5. 最後にルーティングを戻す。基本接続が正常になってから、ドメイン、IP、プロセス、アプリごとのルールを追加します。コアとルーティングの問題を同時に切り分ける事態を避けられます。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs"
  }
}

上記の断片は、ローカル SOCKS インバウンドとルーティングポリシーのみを示しており、リモートの認証情報は含みません。テスト時はブラウザーまたはデバッグツールを 127.0.0.1:10808 に向け、クライアントが HTTP プロキシを同じ SOCKS ポートに誤設定していないことも確認してください。HTTP インバウンドを別に設定する場合は 10809 を使用し、2つのポートが他のプロセスに占有されていないか確認します。

更新ペースと保守方法が選択に与える影響

更新が速いからといって、接続が自動的に安定するわけではありません。新バージョンでプロトコルパラメータが追加されたり、ハンドシェイクの問題が修正されたり、基盤依存が調整されたりする一方、古い設定の境界的なフィールドが問題として表面化することもあります。実際の利用では、まず新バージョンが現在の問題を解決するか確認し、動作中の環境をバージョン表示だけで即座に置き換えないようにしましょう。

Xray は通常、エコシステム内のプロトコル拡張をより早く取り込みます。サーバー側が REALITY や新しい Vision の動作を採用している場合、クライアントのコアもサービス提供者が求めるバージョンに到達している必要があります。一方、V2Fly は独自の方針で V2Ray の設定、トランスポート、プラットフォーム機能を保守しています。両者のリリース番号に単純な大小関係はなく、数字が大きいほうが高機能とは判断できません。

クライアントのバージョンとコアのバージョンも分けて記録してください。v2rayN、v2rayNG、v2flyNG は画面、サブスクリプション、ルーティングの入口、システムネットワークの制御を担当し、コアは最終設定を解析して接続を確立します。トラブルシューティングでは少なくともクライアントのメジャーバージョン、コアのバージョン、ノードのプロトコル、エラー発生時刻を記録します。「最新版」とだけ書いても問題は再現できません。

• 安定版の組み合わせを維持：本番利用のノードは検証済みの組み合わせに留め、新バージョンでは少なくとも接続、DNS、ルーティング、スリープ復帰の4項目をテストします。
• 復旧用の情報を残す：アップグレード前にクライアントのバージョン、コアのバージョン、サブスクリプションの更新日時を記録し、問題が起きたら同じノードで再テストします。
• サーバー側の変更を切り分ける：複数の端末が同時に失敗した場合は、まずノードの状態を確認します。1台だけが失敗する場合に、ローカルのコアとシステムプロキシを調べてください。
• リリースノートを確認する：現在利用中のプロトコル、トランスポート方式、設定フィールドを重点的に検索し、環境と無関係な変更まで逐一追跡する必要はありません。

ノードの種類に合わせて実際の構成を選ぶ

初めて使う場合は「プロトコル優先」の順序で進めます。まずサブスクリプション内で最も多いノードの種類を確認し、そのうえでクライアントを決めます。主なノードが VLESS + REALITY なら、デスクトップは v2rayN、Android は v2rayNG を選びます。Android のサブスクリプションが V2Fly 用に明確に生成されている場合は v2flyNG を使い、最も単純な VMess またはサーバー指定ノードからテストを始めてください。

既存ユーザーは、コア名だけを理由に頻繁に移行する必要はありません。現在の VMess + WebSocket + TLS ノードが長期間安定しているなら、既存環境をそのまま使えます。サーバー側のプロトコル更新、設定フィールドの未認識、要件を満たさないバージョン、REALITY の必要性が生じた場合にのみ、対応する Xray 構成へ切り替えます。

10分で判断する手順

1. ノード詳細を開き、プロトコル、ポート、トランスポート、セキュリティ方式、SNI、flow を記録します。
2. REALITY、ショート ID、xtls-rprx-vision が見つかったら、Xray を選択します。
3. VMess しかない場合は、まず現在のコアをテストし、移行のためだけに移行しないでください。
4. 接続後にログを確認し、unknown field、failed to listen、connection refused、timeout がないことを確認します。
5. ウェブアクセス、DNS 解決、サブスクリプション更新、ルーティング分岐を検証し、その組み合わせを日常の設定にします。

connection refused と判断したら、まず方向を切り分けます。ログにリモートアドレスとサーバーポートへの接続拒否が表示される場合は、ノード側のポートがリッスンしていない、アドレスが誤っている、サーバー側に異常があるといった原因が考えられます。ローカルの 127.0.0.1:10808 に接続できない場合は、コアが起動しているか、ポートが一致しているか、システムプロキシが古いポートを指していないかを確認してください。

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

コアの選択に関する問題は、サブスクリプションのキャッシュ、ポート競合、ルーティングルールと混同されがちです。トラブルシューティングでは、まず最小構成を作ります。ノードを1つだけ残し、カスタムルーティングを無効にし、デフォルト DNS を使用して、システム時刻が正確であることを確認してください。最小構成で接続できたら、機能を1つずつ戻します。

最終的な選択は、次の1つのルールにまとめられます。サーバー側のプロトコルがコアの下限を決め、クライアントの機能が操作方法を決め、実測結果が長期利用するかどうかを決めます。REALITY と Vision は Xray を優先し、一般的な VMess 設定はまず既存環境で検証し、V2Fly を明示的に要求するサブスクリプションには V2Fly を使います。クライアント名、1回の遅延、バージョン番号だけで結論を出さないでください。