2026年9月8日 · コア選定 · 約9分

XrayコアとV2Flyコアの違い|v2rayNGとv2flyNGの選び方

Project V、V2Fly、Xrayの関係を整理し、対応プロトコルや設定方法の違いを比較。Android向けクライアントの選び方も解説します。

この記事の要点

Androidでは、まずノードの接続パラメーターに合うコアを選び、次に設定の入手元に合わせてクライアントを選びます。VLESS、REALITY、Visionの組み合わせが必要なら、v2rayNGに搭載されたXrayの対応状況を確認しましょう。V2Flyのドキュメントに沿って管理してきた設定がある場合は、v2flyNGが候補です。この記事ではクライアント、コア、サブスクリプションを分けて解説し、確認すべき項目や設定例、切り替え後の検証手順を紹介します。「インポートできた」ことと「接続できる」ことを混同しないためのポイントも説明します。

Project V、V2Fly、Xrayの関係

Project Vは、ネットワークプロキシツールを中心とするプロジェクト群で、V2Rayはその中核ソフトウェアです。V2FlyはV2Rayを引き継いでコミュニティ主導で開発されています。XrayはV2Rayから派生し、その後独自のプロトコル拡張と実装方針を築いてきました。設定の歴史には共通点がありますが、名前だけを変えた同一のプログラムではありません。設定ファイルがどちらもconfig.jsonだからといって、そのまま置き換えられるわけでもありません。

クライアントは、画面表示やサブスクリプション管理、システムのネットワーク制御などを担い、コアは設定の解析、接続の確立、ルーティングを担当します。v2rayNGはAndroid向けにXrayを、v2flyNGはV2Flyを搭載しています。デスクトップ版のv2rayNは、実際のバージョンやノードの種類、コア設定に応じて使用する実装を判断します。デスクトップ版でコアを選べる場合の使い勝手を、Android向けの2つのクライアントにそのまま当てはめることはできません。

レイヤー対象主な役割
プロジェクトと実装V2Fly、Xrayプロトコルの実装、設定の解析、接続処理を担います。
Androidクライアントv2rayNG、v2flyNGノードとサブスクリプションを管理し、Android VPNの権限を取得して、搭載されたコアを起動します。
デスクトップクライアントv2rayNデスクトップのプロキシ設定、ノード、コアの実行設定を管理します。
接続設定VMess、VLESS、トランスポート、TLSのパラメータークライアントとサーバーのネゴシエーション方法を定義します。実際に使用するコアの機能に合わせて設定する必要があります。

開発系統が異なるため、バージョン番号を単純に比べることはできません。アプリのバージョンとコアのバージョンは分けて記録しましょう。アプリを更新しても画面が変わるだけで、コアの系統は変わらない場合があります。ノードの接続エラーは、搭載コアが対応している設定項目に起因することもあります。調査時は「最新版をインストールした」とだけ記録するより、両方のバージョンを残すほうが役立ちます。

プロトコル対応:接続の組み合わせで判断

VMessとVLESSはプロキシプロトコル、WebSocketやgRPCなどはトランスポートの選択肢、TLSとREALITYは接続のセキュリティ設定に関わります。選定時には、これらのレイヤーをまとめて確認しましょう。vless://のリンクがあるだけでは、VLESSに対応するすべての実装で同じサーバーに接続できるとは限りません。

Xrayコア / v2rayNG

おすすめ

VLESS、REALITY、Visionを明示的に必要とするノードには、この組み合わせが有力です。クライアントに搭載されたXrayがサーバーの要件を満たすか確認してください。おすすめする理由はプロトコルの組み合わせが合うためであり、どのネットワークでも高速という意味ではありません。

おすすめの用途:ノードの説明でXrayが指定されている場合、またはVLESS + REALITY + Visionを使う場合。

V2Flyコア / v2flyNG

V2Flyのドキュメントに沿って作成し、動作確認済みの設定を引き続き使う場合に適しています。一般的なVMessやWebSocket/TLSの設定でも、トランスポート、パス、証明書の各パラメーターを照合してください。確認を省略することはできません。

おすすめの用途:既存の設定がV2Flyを前提としており、Xray固有の機能に依存していない場合。

ノードの説明主な確認項目選定の目安
VMess + WebSocket + TLSユーザーID、サーバーポート、パス、Host、TLSサーバー名。どちらの系統にも対応する実装があります。実際のバージョンと設定で検証してください。
VLESS + REALITY + Visionflow、security、サーバー名、鍵関連のパラメーター、short ID。v2rayNG / Xrayを優先。V2Flyへそのまま移行できる汎用設定として扱わないでください。
完全なカスタムJSON設定形式、プロトコル項目、トランスポート項目、リソースファイルのパス。ファイルの拡張子ではなく、設定を生成する対象コアに合わせて選びます。

結論:まずサーバーとの互換性を確認し、その後に使い勝手を比較

まず「プロトコル + トランスポート + セキュリティ層 + flow」の4項目を記録します。いずれかが対象コアの対応範囲外なら、遅延を測る前に互換性の問題を解消しましょう。

config.json:共通する構造と移行時の注意点

一般的な設定にはinbounds、outbounds、routingが含まれます。inboundはローカルアプリの通信を受け付け、outboundは接続先への通信方法を決め、routingは使用するoutboundを選択します。以下は、両方でよく使われる従来形式のJSONを用いた、ローカルSOCKSから直接接続する例です。項目の理解を目的としたもので、リモートプロキシノードは含まず、暗号化されたプロキシ接続も行いません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8"],
        "outboundTag": "direct"
      }
    ]
  }
}

ここでlistenはローカルの待ち受け範囲を制限し、tagは設定内で参照する名前です。outboundTagはoutboundのタグと一致させる必要があります。この例ではdirectのoutboundを先頭に置いているため、どのルールにも一致しない通信も直接接続されます。移行時にroutingだけをコピーして参照先のoutboundを移さないと、不足しているノードが自動で補完されるのではなく、設定の読み込みに失敗することがあります。

サブスクリプションのインポートとAndroid VPNによる通信制御

サブスクリプションはノード情報の配布方法であり、コアのプロトコルではありません。同じサブスクリプションURLを2つのクライアントに登録できても、両方がすべてのノード項目を認識できるとは限りません。変換時にトランスポートのパラメーターが失われる場合もあります。インポート後にノード数は同じなのに接続できない場合は、サブスクリプションを何度も更新するのではなく、ノードの編集画面を開き、元の接続パラメーターと照合してください。

移行手順:サブスクリプションとネットワークルールを個別に検証

現在のクライアントを維持する
  • アプリとコアのバージョンを記録する。
  • ノードのパラメーターとサブスクリプションURLをバックアップする。
  • アプリごとの対象リスト、DNS、ルーティングモードを記録する。
  • 動作確認済みの設定を一組残す。
移行先のクライアントを検証する
  • まずノードを1つインポートし、各項目を照合する。
  • 元のクライアントを停止してから、VPNサービスを起動する。
  • まず接続を確認し、その後アプリごとの設定とルーティングルールを戻す。
  • サブスクリプションを更新したら、重要なパラメーターを再確認する。

同じサブスクリプションで共有できるのはノード情報です。アプリごとの対象リスト、DNS、ルーティングまで自動的に一致するわけではありません。

Android VPNによる通信制御とプロキシコアは別のレイヤーです。クライアントはシステムのVPNインターフェースから通信を受け取り、内部の処理経路へ渡します。これは、リモートノードが一般的なVPNプロトコルを使うという意味ではありません。同じユーザーまたはプロファイル内で、通常、同時に有効にできるVPNサービスは1つだけです。v2rayNGとv2flyNGを切り替える際は、先に前者を停止してから、後者を許可して起動してください。システムが元のサービスを停止したことを、接続が不規則に切れたと誤認するのを防げます。

  1. 初回起動時にシステムのVPN権限を許可し、その後、クライアントに起動エラーが表示されていないか確認します。
  2. 特定のアプリを除外する場合は、クライアントのアプリ別プロキシ設定を開き、リストが「対象に含める」方式か「対象から除外する」方式かを確認してください。
  3. 画面を閉じると接続が停止する場合は、Androidのバックグラウンド実行制限とバッテリー最適化の設定を確認してください。先にサーバー側のプロトコルを変更しないでください。
  4. テスト中はVPNインターフェースを使う他のツールを一時停止し、通信制御の競合を減らします。

接続できないときの確認順:ポート、ハンドシェイク、DNS

コアを選ぶだけではネットワークの問題は解決しません。接続タイムアウトはサーバーポートに到達できないことが原因かもしれません。TLSエラーはサーバー名や端末の時刻に起因する場合があり、Webページが開かない原因はDNSの経路が想定と異なることかもしれません。以下の3つの数値は確認の目安であり、クライアントの初期値や性能測定の結果を示すものではありません。

10808
この記事の例で使用するローカルSOCKS待ち受けポート
443
TLSでよく使われるサーバーポート。実際の値はノードに従う
1
一度に変更する項目は1つにして、原因を特定しやすくする
症状まず確認する項目次の操作
起動直後に失敗する未対応の項目、設定形式、ポートの競合。最初に表示された明確なエラーを読み、コアのバージョンと項目の出典を確認します。
リモート接続がタイムアウトするアドレス、ポート、現在のネットワーク、サーバーの待ち受け状態。ノードの設定は変えずにネットワークを変えて検証し、DNSとプロトコルを同時に変更しないでください。
TLSまたは認証に失敗する端末の時刻、サーバー名、ユーザーID、セキュリティ層、鍵関連のパラメーター。サーバーの設定と項目ごとに照合します。証明書検証を無効にして解決しようとしないでください。
一部のドメインだけ接続できないDNSの名前解決経路、IPv6の到達性、ルーティングルールの順序。テストするドメインを固定し、名前解決の結果と適用されたoutboundを確認します。
特定のアプリだけ接続できないアプリ別リスト、UDPの要件、アプリ自体のネットワーク動作。まず、そのアプリがプロキシによる通信制御の対象に含まれているか確認します。

性能を比較するときも条件をそろえましょう。同じネットワーク、サーバー、時間帯、テスト先を使い、接続成功率、遅延、連続通信時の状態をそれぞれ記録します。1回の遅延測定だけでは、どちらのコアが省電力か、スループットが高いかは判断できません。モバイルネットワークの切り替え、端末の温度、バックグラウンド処理も結果に影響します。診断ログを共有する前に、サブスクリプションURL、ユーザー識別情報、鍵などの接続情報を削除してください。

v2rayNGとv2flyNGの選び方

サーバーがXray専用の接続構成を明示している場合は、v2rayNGを選ぶのが簡単です。V2Flyの設定を長く使っていて、新たなプロトコル要件がない場合は、v2flyNGを選ぶと移行時に変わる要素を減らせます。いずれも実際に接続できるか、設定項目に互換性があるかを基準に判断しましょう。コアの名称を理由に、動作確認済みの設定を無理に変更する必要はありません。

手順:ノードを1つ、ルールを1組、切り替えを1回

まず移行先のクライアントでノードを1つ検証し、その後にサブスクリプションとルーティングルールを追加します。移行先で実際にアクセスできることを確認するまでは、元の設定を残してください。問題が起きた場合に、すぐ元に戻して差分を特定できます。

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