Xray-coreとV2Fly-coreの違い：XTLS・REALITY対応と設定の互換性

成り立ち：クライアント・コア・ノード設定の関係

V2FlyはV2Rayを継続的に開発するコミュニティプロジェクトで、そのコアプログラムは一般にV2Fly-coreと呼ばれます。Xray-coreは2020年にV2Rayのコードを基盤として分岐し、その後は独自の機能開発とリリースを続けています。共通の起源を持つため設定構造には似た部分がありますが、新機能やデフォルト動作、項目名まで常に同じとは限りません。

v2rayNはデスクトップクライアントです。サブスクリプション管理やノード編集、設定生成を行い、選択したコアを起動します。プロキシ接続を実際に確立するのはコアのプロセスです。Android版ではv2rayNGがXrayコア、v2flyNGがV2Flyコアを使用します。クライアント名が似ていても、対応するノード機能が同じとは限りません。

サブスクリプション内の共有リンクは、どのコアでもそのまま実行できる完全な設定ではありません。クライアントがノード情報を対応するコアのアウトバウンド設定に変換し、ローカルのインバウンド、DNS、ルーティングを補います。サブスクリプションをインポートできても、リンク形式を認識したことを示すにすぎません。起動できるか、ハンドシェイクが完了するかは、生成された設定とサーバー側の要件をそれぞれ確認してください。

機能を比較：VLESS・XTLS Vision・REALITYは別の階層

VLESSはプロキシプロトコル、VisionはXrayでVLESSと組み合わせるフロー制御方式、REALITYは接続のセキュリティ層です。よくある「VLESS + TCP + REALITY + Vision」は、実際には4種類の設定を組み合わせています。REALITYをVLESSの別名と捉えたり、VLESSだから必ずXrayが必要だと判断したりしないでください。

Visionは通常、ユーザーオブジェクトのflow: "xtls-rprx-vision"で指定します。securityに「Vision」と設定するわけではありません。REALITYは通常、streamSettings.security: "reality"と対応するrealitySettingsで指定します。VisionはTLSまたはREALITYと組み合わせるのが一般的です。WebSocketノードにVision flowを安易に追加しないでください。

設定の互換性：フロー制御・セキュリティ層・トランスポートを確認

以下の2つの例は、パラメーター確認用であり、接続設定一式ではありません。1つ目はXray独自機能を使うノードの重要項目、2つ目は両コアで一般的に共通する項目を示しています。接続先アドレスや認証情報、セキュリティ設定は、実際のサーバー設定またはサブスクリプションを確認してください。ノード名から推測することはできません。

• ユーザーオブジェクト：id、flow、プロトコル固有の項目を確認します。VLESSのencryption: "none"は、接続全体にセキュリティ層がないという意味ではありません。TLSやREALITYは別の層で設定します。
• REALITYのパラメーター：serverName、fingerprint、shortIdと、サーバーから指定された鍵のパラメーターを確認します。Xrayのバージョンによって、項目名やエイリアスの対応状況が変わることがあります。古い設定にあるpublicKeyなどの表記は、実際に使うバージョンの仕様を確認してください。V2Flyにそのまま流用することはできません。
• トランスポート設定：networkと対応する設定オブジェクトを確認します。新しいXrayのドキュメントや生成設定ではrawなどの名称が使われることがありますが、V2Flyも同じ表記に対応するとは限りません。WebSocketのパスやリクエストヘッダーも忘れずに引き継いでください。
• セキュリティの確認：通常のTLSノードでは、証明書のドメイン名とSNIを確認します。証明書検証のスキップを一般的な移行手順にしないでください。プロトコルの不一致は解消されず、セキュリティ上の前提が変わってしまいます。

古い解説で単に「XTLS」と呼ばれている設定は、旧方式を指す場合があり、現在のVisionとは異なります。移行時には実際のflowの値とセキュリティ層を確認し、過去の設定を新しいバージョンにそのままコピーしないようにしてください。クライアントを更新した後は、クライアントのバージョン番号だけでなく、実際に起動したコアのバージョンも確認しましょう。

v2rayNでコアを切り替える：バックアップ後に最小構成で検証

v2rayNはバージョンによってメニュー名やコアの選択場所が異なる場合があります。まず「設定」→「パラメーター設定」でコア関連の項目を探してください。ノードの種類ごとにコアを選ぶバージョンでは、画面に表示される「Coreタイプ」などの項目を確認します。すべてのプロトコルを一括で別のコアに切り替えたうえで、DNSやルーティング、システムプロキシまで同時に変更するのは避けてください。

1. 現在の状態を記録：クライアント設定をバックアップし、クライアントのバージョン、ログに表示されるコアのバージョン、選択中のノード、ローカルの待ち受けアドレスとポートを記録します。機密性の高いサブスクリプションURLはローカルだけに保存してください。
2. 共通対応ノードを選ぶ：まずはVMess + WebSocket + TLSなど、両方のコアが対応するノードで検証します。REALITYノードしかない場合、V2Flyへの切り替えを同条件でテストすることはできません。
3. 変更は1項目ずつ：対象プロトコルのコア選択だけを変更し、接続を停止してから再起動します。新しいプロセスが起動したことを確認し、ログで実際のコアを確かめてください。古いプロセスがポートを使用し続けている可能性があります。
4. ローカルの接続口を確認：アプリのプロキシ方式とポートは変えずに、実際にWebページへアクセスします。遅延テストで数値が返っても、ブラウザーがシステムプロキシ経由で接続できるとは限りません。
5. 機能を段階的に戻す：基本接続が成功したら、カスタムルーティング、DNS、その他の詳細設定を1つずつ戻し、その都度テストします。互換性の問題を特定しやすくなります。

上記の数値はローカルの接続口とリモートの接続先を区別するための例であり、クライアントの固定デフォルト値ではありません。実際のポートは現在の設定を確認してください。ローカルで待ち受けるHTTP、SOCKS、混合プロキシの種類も合わせて確認が必要です。リモートサーバーが443を使っていても、ブラウザーのシステムプロキシをローカルの443に設定するわけではありません。

起動・接続のトラブル対処：設定チェックに通っても接続成功とは限らない

設定全体を手動で管理している場合は、まずコア付属の設定チェックを実行できます。以下はXrayとV2Fly v5でよく使われるコマンドラインの例です。client.jsonは、ローカルに保存済みの設定ファイルを指します。それ以外のバージョンでは、ヘルプコマンドで引数を確認してください。クライアントが一時的に生成したファイルをオフラインで検査する場合は、先にコピーしてバックアップします。

xray version
xray run -test -config client.json

v2ray version
v2ray test -c client.json

設定チェックでは、構文エラーや一部の無効な項目、非対応の組み合わせを検出できますが、接続先に到達できることや認証情報が正しいことまでは確認できません。コアの起動後は実際に接続し、アウトバウンドのハンドシェイクとリクエストが完了するかを確認します。以下では失敗した段階ごとに原因を分類し、すべてを「ノードが使えない」と決めつけないようにしています。

ルーティングで使うgeosite:やgeoip:は、データファイルの内容と読み込み先にも依存します。両方のコアが同じルール構文を認識しても、ローカルのデータに該当するカテゴリがあるとは限りません。移行時にはdomainStrategy、DNSサーバー、アウトバウンドのタグ、最終フォールバックルールも合わせて確認してください。確認しないと、起動できてもルーティング結果が変わることがあります。

よくある質問：コアの選び方と性能の見方