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

XrayとV2Flyのバージョンの関係

V2FlyとXrayはいずれもProject Vエコシステムのプロキシ設定思想を受け継いでいます。どちらもインバウンド、アウトバウンド、ルーティング、DNS、トランスポート層を設定でき、構造化された設定で接続パラメータを記述します。共通する用語は多いものの、現在は別々に開発・リリースされる2つのコアブランチであり、バージョン番号を同じ時系列として扱うことはできません。

たとえば、Xray 25.3.6とV2Fly 5.28.0では、数字が大きいからといって後者のほうが新しいとは限らず、対応プロトコルが多い、性能が高いと判断することもできません。Xrayのバージョンには日付を思わせる特徴があり、V2Flyは長くセマンティックバージョニングを採用しています。バージョンを比較するときは、それぞれのリリース系列、クライアント内蔵バージョン、設定変更の説明を確認してください。

ユーザーから見ると、クライアントは画面、サブスクリプション管理、システムプロキシ、設定変換を担当し、コアは実際の接続確立とルーティングを担います。v2rayNGの接続ボタンをタップすると、画面上のノード、DNS、アプリ別プロキシ、ルーティング設定がコアの読み込める実行設定にまとめられ、その後ローカルプロキシサービスが起動します。そのため、同じサブスクリプションのノードを別のクライアントで使えるかどうかは、クライアントが対象コアに必要な項目を正しく生成できるかにも左右されます。

1. まずクライアントとコアを区別：v2rayNG、v2flyNG、v2rayNはユーザーが直接操作するクライアントで、XrayとV2Flyは接続処理を担うコアプログラムです。
2. 次にバージョン系列を区別：バージョン番号の大小を横並びで比較せず、同じコアのリリース系列内で新旧を判断してください。
3. 最後にノードの機能を確認：プロトコル名が同じでも拡張パラメータまで同じとは限りません。フロー制御、セキュリティ層、トランスポート方式を項目ごとに確認する必要があります。

プロトコル対応と設定の違い

VMess、VLESS、Shadowsocks、SOCKS、HTTPなどの名称から、両者が完全に同等だと思いがちです。しかし、基本プロトコルは最初の確認項目にすぎません。接続を確立できるかどうかは、TCP、WebSocket、gRPCなどのトランスポート方式に加え、TLS、REALITY、フロー制御、サーバーが要求するハンドシェイクパラメータも確認する必要があります。重要な項目が1つでも一致しないと、タイムアウト、ハンドシェイク失敗、接続後の通信不能として現れることがあります。

VMessとTCPまたはWebSocketの組み合わせは、2つのコアブランチで比較的互換性の高い構成です。このタイプのノードを移行する際は、サーバーアドレス、ポート、ユーザーID、alterId、トランスポート方式、Host、パスを重点的に確認します。新しい設定ではalterIdは通常0です。サブスクリプションに古いパラメータが残っている場合、クライアントがインポートできても、実際の接続はサーバー側の設定を基準にしてください。

REALITYは、特に注意して確認したい差分です。サブスクリプションにpublicKey、shortId、serverName、fingerprint、spiderXなどの項目がある場合、「VLESS」と書かれているだけで判断してはいけません。クライアントはこれらのパラメータを完全に保持し、使用するコアも対応機能を実装している必要があります。shortIdが欠けている、serverNameを間違えている、サーバーが要求するflowを空に変更しているといった場合、接続に失敗することがあります。

ルーティング構文もバージョンとともに変化しています。一般的なルールではdomain、ip、port、network、inboundTagなどで照合し、指定したoutboundTagへトラフィックを送ります。基本構造が似ていても、古い設定をいつまでもそのまま使えるとは限りません。大きくバージョンアップする場合は、廃止された項目、DNSクエリポリシー、ルールの照合動作を確認し、設定ファイルを解析できるかだけで判断しないでください。

v2rayNG、v2flyNG、v2rayNの対応関係

v2rayNGはAndroid向けクライアントで、標準ではXrayコアを中心に動作します。比較的新しいXrayパラメータを含む共有リンクやサブスクリプションのインポートに適しており、ルーティング設定、アプリ別プロキシ、LANのバイパス、ローカルDNSなど、モバイル向けの機能も備えています。VLESSとREALITYを組み合わせたノードでは、まずv2rayNGのバージョンと内蔵Xrayのバージョンを確認し、次にノードの項目がそろっているか確認してください。

v2flyNGもAndroid向けですが、V2Flyコアを使用します。v2rayNGの見た目を置き換えることが目的ではなく、V2Flyの実行環境を明確に用意できる点に価値があります。V2Flyサーバーの設定を再現したり、VMessや標準的なVLESSの互換性を検証したりする場合、v2flyNGを使うことで「画面は同じでも内部実装が異なる」ことによる判断のずれを減らせます。

v2rayNはWindows向けデスクトップクライアントです。バージョンによって設定項目が多少変わることはありますが、通常は「設定」→「パラメータ設定」からローカル待受、システムプロキシ、Core関連の項目を確認できます。よく使われるローカルSOCKSポートは10808で、HTTPポートは設定に応じてクライアントが生成する場合があります。ポートがほかのプログラムに占有されているとコアを起動できないことがあるため、空いているポートに変更してから再接続してください。

macOSやLinuxで設定ファイルから対応するコアを実行する場合も、基本的な考え方は同じです。まずサーバーが要求する機能の組み合わせを確認し、その設定を正しく解析できるコアを選びます。端末を統一するためにREALITY設定を通常のTLSへ無理に落としたり、あるクライアントでノードをインポートできただけで、サブスクリプションの全パラメータに完全対応していると判断したりしないでください。

• Androidの普段使い：サブスクリプションにVLESS、REALITY、XTLSのフロー制御が含まれる場合は、v2rayNGを優先してください。
• V2Fly設定の再現：ノードがV2Flyコアで実際にどう動作するか確認する場合は、v2flyNGで個別にテストしてください。
• Windowsでの管理：v2rayNでサブスクリプション、システムプロキシ、ルーティングを管理し、ノードに対応するCoreの種類を確認してください。
• プラットフォーム間の移行：移行するのはクライアントに表示されるノード名ではなく、接続パラメータ一式です。

設定を移行できるか確認する方法

互換性の検証は決めた順序で行います。まず、動作している元のクライアントとノードを残し、対象クライアントに同じサブスクリプションをインポートします。プロトコル、ポート、DNS、ルーティングを同時に変更しないでください。失敗したときに原因を特定しにくくなります。1回に1つだけ変えるほうが、ノードを何度も切り替えるより早く問題を特定できます。

インポート後はまずノードの詳細を開き、遅延の数値だけで実際の接続を判断しないでください。遅延テストはTCP接続の確立だけを確認する場合もあれば、コアのハンドシェイクまで含む場合もあり、クライアントによって実装が完全に同じではありません。比較するときは同じネットワーク、同じ時間帯、同じサーバーノードで行い、少なくとも3回連続でテストしてください。

1. 基本項目を確認：サーバーアドレス、ポート、ユーザーID、暗号化方式、プロトコル種別が途中で欠けていないことを確認します。
2. トランスポート項目を確認：TCP、WebSocket、gRPCを照合し、Host、path、serviceNameなどの項目が正しい位置にあることを確認します。
3. セキュリティ項目を確認：TLSまたはREALITY、serverName、fingerprint、publicKey、shortId、flowを照合します。
4. ローカル待受を確認：10808などのローカルポートが使用されておらず、システムプロキシが現在のクライアントの実際の待受ポートを指していることを確認します。
5. ログの順序を確認：まず設定解析、次にDNS、接続、TLSハンドシェイク、ルール照合の順に確認し、最後のエラー行だけを抜き出さないでください。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

この最小構成は、ローカルSOCKSインバウンド、ポート、アウトバウンドタグの関係を説明するためのもので、リモートノードの設定ではありません。実際のプロキシアウトバウンドには、プロトコルに対応するサーバー、ユーザー、トランスポートパラメータも必要です。検証では、まずコアが127.0.0.1:10808で待受できることを確認してからリモートアウトバウンドを追加すると、「ローカルポートの起動失敗」と「リモートハンドシェイクの失敗」を切り分けられます。

更新ペースとアップグレードのリスク

XrayとV2Flyはそれぞれ独自のリリースペースで保守されています。更新によってプロトコルパラメータが追加されることもあれば、DNS、ルーティング、トランスポート、設定検証が変更されることもあります。クライアントが新しいコアを統合するまでには時間がかかるため、「コアがリリースされた時点」と「クライアントで使える時点」は別です。実際の利用では、クライアントに内蔵されたバージョンと設定生成機能を基準にしてください。

頻繁にアップグレードしても、接続が必ず安定するとは限りません。本番環境や長時間稼働する端末では、回帰テストの手順を用意しておくのが適しています。現在のクライアントバージョン、コアバージョン、メインノードのプロトコル、ローカルポート、ルーティングモードを記録し、アップグレード後にサブスクリプション更新、TCP通信、UDP要件、DNS解決、ルール照合を順番にテストします。異常があれば、ノードを同時に変更せず、まず元の設定に戻して確認してください。

• マイナーアップグレード：まずVMessまたはVLESSの基準ノードを1つテストし、その後に完全なサブスクリプショングループへ戻します。
• メジャーバージョンをまたぐアップグレード：廃止された項目、DNSクエリポリシー、ルールの順序、ログレベルを改めて確認します。
• Androidのバックグラウンド動作：アップグレード後、システムのバックグラウンド制限が強化されていないことを確認し、プロセスの一時停止をコアの切断と取り違えないようにします。
• Windowsのシステムプロキシ：旧バージョンを終了した後、プロキシポートが解放されていることを確認し、2つのプロセスが10808を競合して使わないようにします。
• macOSとLinux：サービス管理ツールで実行する場合は、新しいバイナリに対応する設定ファイルが実際に起動時に使われていることを確認します。

更新が特定の問題を解決するためだけなら、その変更が問題に関係しているかを先に確認してください。たとえばサーバーがREALITYの新しい項目を要求している場合、Xrayとv2rayNGを更新する目的は明確です。一方、既存のVMess、WebSocket、TLSノードが長期間安定しているなら、バージョン番号が大きくなったという理由だけで全端末をすぐ移行しても、効果を評価するのは難しいでしょう。

利用シーンに合わせたコアとクライアントの選び方

多くのAndroidユーザーは、サブスクリプションの内容を起点に選ぶとよいでしょう。ノード詳細にVLESS、REALITY、XTLSのフロー制御、publicKey、shortIdが表示されるなら、v2rayNGとXrayの組み合わせが直接的です。VMess、TCP、WebSocket、TLSが中心で、V2Fly環境の再現も必要なら、v2flyNGで個別に検証できます。

v2rayNユーザーにとって重要なのは、設定画面でCoreの種類を何度も切り替えることではなく、現在のノードがどの機能を必要としているかを確認することです。切り替え後は設定を再生成し、実行ログを確認してください。ノード名、遅延表示、サブスクリプショングループが変わらなくても、別のコアが内部項目を同等に受け入れたとは限りません。

最終的な選び方は一言でまとめられます。サーバー設定の要件を基準にし、クライアントに内蔵された実際の機能を上限とします。Xrayの拡張機能が必要ならv2rayNGを使うか、v2rayNで対応するCoreを選択してください。V2Flyの実行環境を維持したい場合はv2flyNGを使います。どちらのブランチも成熟した基本的なプロキシとルーティングに対応できます。重要なのは、パラメータが完全で、バージョンが一致し、検証方法が統一されていることです。