XrayコアとV2Flyコアの違い｜プロトコル対応と設定方法を比較

クライアント、コア、Project Vの違い

コアは実際の接続、プロトコル処理、DNS問い合わせ、ルーティングを担い、クライアントはそれらの機能を操作するための画面を提供します。v2rayN、v2rayNG、v2flyNGはクライアント名です。Xray-coreと、V2Flyが開発するv2ray-coreがコアにあたります。クライアントとコアのバージョンは別々に管理されるため、アプリを更新してもコアが切り替わるとは限りません。

Project Vは、V2Rayを中心に形成されたツールとプロトコルのエコシステムです。V2Flyコミュニティはv2ray-coreの開発を引き継ぎ、Xray-coreは2020年に関連コードを基盤として派生し、その後は異なる方針で機能を開発してきました。共通の歴史があるためJSONの構造が似ている場合もありますが、すべての設定項目を相互に使えるわけではありません。

この流れを理解すると、「サブスクリプションを読み込めるのに接続できない」理由も分かります。読み込みに成功したのは、クライアントがデータの一部を解析できたということにすぎません。コアがすべての機能に対応していることや、サーバーのアドレス、認証情報、通信パラメーターが一致していることまでは保証されません。

• v2rayN：デスクトップ向けクライアントです。利用できるコアや切り替え方法はインストールしたバージョンによって異なるため、問題を調べる際は、対象ノードが実際にどのコアで動作しているか確認してください。
• v2rayNG：Android向けクライアントです。この記事では、Xrayコアを使う場合を取り上げます。
• v2flyNG：V2Flyコアを使うAndroid向けクライアントです。画面が似ていても、Xray専用の設定項目をそのまま設定できるとは限りません。

プロトコル対応を比較：VLESSとREALITYは別のもの

1つの接続は通常、プロキシプロトコル、通信方式、安全性を担うレイヤーの組み合わせで構成されます。VLESSとVMessはプロキシプロトコル、TCPとWebSocketは通信方式、TLSとREALITYは接続の安全性に関わる仕組みです。XTLS Visionは特定のフロー制御とデータ処理方式を指し、TLSのスイッチを別の名前に置き換えたものではありません。

「V2FlyはVLESSにまったく対応していない」「VLESSに対応していればREALITYにも接続できる」という説明は、どちらも断定しすぎです。前者はバージョンや実装の違いを見落とし、後者はプロトコルとセキュリティレイヤーを混同しています。古い資料にあるXTLSの旧フロー制御も、Visionと同じものとして扱えません。特に、古い値を新しい設定にそのままコピーしないでください。

設定チェック：よくある2つの構成で確認する項目

次の2つのカードは設定項目を確認するためのもので、接続可能なノードやサーバー認証情報は含まれていません。例のパス/proxyは項目の位置を示すだけです。実際のパスにはサーバー側で指定された値を設定してください。REALITYのカードは一般的なVLESS + TCP + Visionの構成例であり、すべてのVLESSでVisionを有効にする必要があるという意味ではありません。

HostとSNIは同じ値になることがよくありますが、用途は異なります。WebSocketのHostはHTTPリクエストで指定する接続先ホストの情報で、SNIはTLSハンドシェイク時に送信するサーバー名です。接続先アドレスはさらに別の項目で、最初に接続するネットワーク上の宛先を指定します。サーバー側が3つに異なる値を指定している場合、「見た目をそろえる」ために同じ値へ変更しないでください。

JSONの書き方：構造が似ていても設定全体を共用できるとは限らない

XrayとV2Flyの一般的な設定では、inbounds、outbounds、routingなどの項目名を使います。V2Flyには複数の設定バージョンや構造があり、クライアントが共有リンクを解析してから独自のコア向けJSONを生成することもあります。そのため、共有リンクが同じであること、画面上の項目が似ていること、最終的なコア設定に互換性があることは、それぞれ別の話です。

以下は従来形式のJSONにおけるstreamSettingsの一部で、WebSocketとTLSの階層を示しています。example.comは例示用に予約されたドメインであり、利用可能なサーバーアドレスではありません。入出力の設定や認証情報も含まれていないため、この断片だけでは動作しません。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com"
    },
    "wsSettings": {
      "path": "/proxy",
      "headers": {
        "Host": "example.com"
      }
    }
  }
}

• 通信方式の項目：networkで通信方式の実装を選びます。ドキュメントに記載されたTCPやRAWなどの名称は、バージョンによって変わることがあります。画面上の表示だけで、基盤となるJSONの値を判断しないでください。
• セキュリティの項目：通常のTLSには対応するTLS設定を使います。XrayのREALITYには専用の設定構造があるため、tlsという文字列をrealityに置き換えるだけでは移行できません。
• フロー制御の項目：一般的なXrayのVLESS出力設定では、flowはユーザー設定項目です。streamSettings内に置かないでください。
• バージョンによる項目の違い：REALITYクライアントの公開鍵に関するパラメーターは、Xrayのバージョンによってドキュメントや画面上の名称が異なる場合があります。古い例のpublicKeyと、新しいドキュメントのpasswordは、実際に使うコアのバージョンを確認して判断してください。バージョンが分からないまま機械的に置き換えるのは避けましょう。

移行時は、サービス提供元が配布する完全なサブスクリプションを再読み込みし、生成された設定を確認するのが最も確実です。JSON全体の手動移行は、移行元と移行先のバージョン、設定形式を把握している場合に限ってください。構文チェックに通っても、設定項目が実際に反映されているとは限りません。

ポートとルーティング：ローカルの接続口とサーバー側の機能を混同しない

コアはルーティングを処理しますが、リクエストがまずコアに届く必要があります。システムプロキシの設定が適用されるのは、その設定に従うアプリだけです。TUNは仮想ネットワークインターフェースを通じて対象の通信を取り込み、通常は追加の権限を必要とします。どちらもプロキシの出力先を選ぶ設定ではなく、コアに届いたリクエストはさらにルーティングルールに従って振り分けられます。

これらはアドレスとポートの例であり、速度測定の結果でも、すべてのクライアント共通の初期値でもありません。アプリに127.0.0.1:10808を設定する場合は、クライアントが実際にローカルのそのポートで待ち受けていることと、接続方式がアプリの要件に合っていることを確認してください。HTTPプロキシかSOCKSかは、ポート番号だけでは判断できません。

1. v2rayNの「設定」→「パラメーター設定」で、ローカルの待ち受け先と関連項目を確認してください。項目の分類名はバージョンによって異なる場合があるため、現在の画面を基準にしてください。
2. システムプロキシまたはアプリのプロキシ設定が、実際に待ち受けているアドレスを指しているか確認してください。以前のクライアントのポートが残っていないかも確認しましょう。
3. 現在のルーティングモードと、適用されるルールを確認してください。geosite:cnはドメイン分類の参照、geoip:cnはIP分類の参照で、どちらも対応するデータファイルが必要です。
4. 別のコアに移行した後は、ルールファイルの場所、タグ名、出力先タグが引き続き対応しているか確認してください。ルーティング項目をコピーするだけでは不十分です。

「直接接続のサイトは開くが、プロキシ経由のサイトは失敗する」場合、リクエストは何らかのルールに届いているものの、プロキシの出力先に問題がある可能性があります。「クライアントを切り替えてもすべてのアプリで変化がない」場合は、まず接続口と通信の取り込み方法を確認しましょう。すぐにコアの速度が原因だと決めつけず、通信経路に沿って調べてください。

Androidでの選び方：サブスクリプションの要件を少数の設定で確認

現在のノードがXrayのREALITYやVisionを明確に要求しているなら、対応機能を備えたv2rayNGを選ぶのが簡単です。V2Fly向けに動作確認された設定をサービス側が提供している場合は、v2flyNGを使い続けても問題ありません。専用機能が不要なら、設定を完全に読み込めるか、ログを確認しやすいか、現在のルーティングを維持できるかを優先して選びましょう。

1. 利用環境を記録：クライアントとコアのバージョン、プロトコル、通信方式、セキュリティレイヤー、TUNの有効・無効を記録します。「最新版」だけでは情報が足りません。
2. 以前の設定を残す：移行前にサブスクリプションのグループとカスタムルーティングをバックアップしてください。機密性のあるサブスクリプションのURLを公開の場に投稿しないでください。
3. テスト項目は1つだけ読み込む：元の設定と照らし合わせ、ポート、SNI、パス、Flow、REALITY関連の項目を確認してください。重要な項目が欠けている場合は、テストを中止してください。
4. 複数のクライアントで同時に通信を取り込まない：別のクライアントを試す前に、現在のクライアントのプロキシ接続や仮想ネットワーク接続を停止して、接続口の競合を避けてください。
5. 変更は一度に1項目だけ：同じネットワーク、同じサーバー、同じ宛先へのリクエストを使って結果を比較してください。DNS、ノード、ルーティングモードを同時に変更しないでください。

よくある質問：読み込み成功後のエラー、ハンドシェイク失敗、更新の順序