XrayコアとV2Flyコアの違い｜バージョン系列・プロトコル対応・切り替え時の注意点

プロジェクトの関係：GUIクライアントとプロキシコアは別物

V2Fly-coreはProject VのV2Ray技術を引き継ぎ、V2Flyコミュニティが開発しています。Xray-coreはV2Rayのコードベースから派生し、その後独自の開発・リリース路線を歩んでいます。共通の出自を持ちますが、その後の機能や設定項目、デフォルトの動作が常に一致するとは限りません。Xrayを単に「新しいV2Ray」と捉えると、移行時に確認すべき違いを見落とすおそれがあります。

GUIクライアントはサブスクリプション管理、ノード編集、設定画面を担当し、コアは実際の設定を読み込み、ローカルの通信を受け付けてプロキシ接続を実行します。クライアントにノードが表示されていても、選択中のコアがすべての設定項目を利用できるとは限りません。サブスクリプションの読み込み、設定の生成、コアの起動は、それぞれ別の成功条件です。

• v2rayN：デスクトップ向けGUIクライアントです。利用できるコアや選択方法は、クライアントのバージョン、インストール内容、ノードの種類によって異なります。実際の画面と起動ログで確認してください。
• v2rayNG：Android向けクライアントで、Xrayコアを使用します。デスクトップ版の実行ファイルを置き換える方法を、そのままAndroid版に適用することはできません。
• v2flyNG：Android向けクライアントで、V2Flyコアを使用します。移行時はノードのパラメーターとサブスクリプションの解析結果を改めて確認してください。

バージョン系列：3種類のバージョンを分けて記録

クライアント、Xray-core、V2Fly-coreはそれぞれ別にリリースされます。クライアント更新で設定生成方式とコアファイルの両方が変わる場合もあれば、画面だけが変わる場合もあります。コアを手動更新しても、新しい設定項目へのクライアント側の対応が同時に進むとは限りません。問題を調べる際は「最新版に更新済み」とだけ記録せず、実際に使用した組み合わせを残してください。

過去の資料では、V2Flyのv4・v5系列や、Xrayの1.x系列、その後の日付ベースのバージョン表記を目にすることがあります。これらは共通の尺度ではないため、数字だけで機能の多さや互換性を判断できません。特にV2Flyのプログラムバージョンと設定形式は区別が必要です。v5だからといって古い設定全体を書き換える必要があるとは限らず、新しい形式の項目を古いツールが認識できるとも限りません。

1. クライアントの「バージョン情報」に表示された完全なバージョン、OS、プロセッサーのアーキテクチャを記録します。
2. 接続を一度開始し、ログで実際に呼び出されたコア名、バージョン、起動結果を記録します。
3. 通常のノードから生成された設定と、手動で管理しているカスタム設定を区別します。後者では、画面上の変換処理の一部を経由しない場合があります。
4. アップグレード前にクライアント設定とコアの組み合わせを保存します。問題が起きた場合は、ファイルひとつだけでなく組み合わせごと元に戻してください。

バージョン番号が同じでも、2台の端末で動作が完全に一致するとは限りません。ルーティング用データファイル、DNS設定、クライアントが生成するパラメーターも異なる場合があります。サブスクリプションも更新のたびに変わる可能性があるため、問題を再現するときは同じノード情報を使用してください。

プロトコルとトランスポート：名称が同じでも設定項目は共通とは限らない

VMess、VLESSはプロキシプロトコル、TCP、WebSocket、gRPCはトランスポートの選択肢です。TLS、REALITYは接続のセキュリティ方式に関わり、Visionは通信の両端で設定を合わせる必要があるフロー制御です。これらは自由に入れ替えられる「モード」ではありません。サーバーが要求する組み合わせによって、クライアントに必要な機能が決まります。

たとえば、VLESSノードがxtls-rprx-visionを要求する場合、flow項目を削除して通常のVLESSノードとして動作すると考えることはできません。REALITYのサーバー公開鍵、サービス名、短いIDにもそれぞれ役割があります。値が欠けていたり一致していなかったりする場合、コアを入れ替えるだけでは補えません。

コアの選び方：利用中のノード要件を基準にする

「新しいプロトコルなら必ず速い」という理由で切り替えるべきではありません。通信経路、サーバー負荷、通信事業者との接続品質、ルーティングルールなどが使用感に影響します。まずノードの要件を満たすコアを選び、そのうえで条件を揃えて安定性、リソース使用量、必要な機能を比較してください。

両方のコアで同じサーバー設定を利用できる場合は、ノード、測定時間帯、測定先を固定してから、接続成功率とログのエラーを比較してください。出口の異なる2つの接続を一度ずつ測定した結果から、コア自体の性能を判断しないでください。

切り替え手順：バックアップ後、最小構成で接続を確認

v2rayNでは、まず「設定」→「パラメーター設定」でローカルの待ち受け、DNS、ルーティング関連の項目を記録します。グループ名やコアの選択画面はバージョンによって変わる場合があります。現在の画面に移行先コアの選択肢がない場合、不明なファイルを古い手順に従って編集しないでください。サブスクリプションのグループ名をコアの選択欄と取り違えないようにしましょう。

1. 現在の状態を保存。クライアント設定、カスタムルール、必要なノード情報をバックアップします。バックアップにサブスクリプションURLや認証情報が含まれる場合は、アクセスを制限し、公開場所にアップロードしないでください。
2. 移行先の組み合わせを確認。ノードのプロトコル、トランスポート、セキュリティ方式、フロー制御を確認し、クライアントが移行先のコアで受け付けられる設定項目を生成できるか確認します。
3. 現在のコアを停止。クライアントの停止または再起動機能を使い、複数のコアが同じローカル待ち受けポートを同時に使用しないようにします。
4. 変更する要素はひとつだけ。まずコアかクライアントのどちらかを変更し、DNS、ノード、ルーティングは同時に変更しないでください。起動後、設定の解析結果と待ち受けログを確認します。
5. 最小構成で接続をテスト。まずパラメーターが揃っている既知のノードでプロキシ通信を確認します。その後、普段使っているルーティングルールに戻し、最後にサブスクリプションの更新をテストします。

ポートとログ：ローカル起動とリモート接続のハンドシェイクを切り分ける

以下の3つの数値はポートの役割を示す例であり、すべてのクライアントのデフォルト値ではありません。実際の値は端末の設定とノードのパラメーターで確認してください。ローカルプロキシのポートをサーバーのポートとして入力したり、リモートポートをシステムプロキシに設定したりすると、コア選択とは関係のない接続障害が起こります。

設定でHTTPプロキシが127.0.0.1:10809で待ち受けていることを確認済みの場合、以下のコマンドでその待ち受けを明示的に経由するHTTPSリクエストを検証できます。テスト用アドレスは接続確認にのみ使用します。応答結果だけで出口の場所や、すべてのアプリがプロキシ経由になっていることを証明することはできません。

curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/

• unknown fieldが表示される場合：まず設定項目と移行先コアのバージョンを確認してください。サーバーアドレスを先に変更しないでください。
• address already in useが表示される場合：古いコアや別のプログラムが待ち受けポートを使用していないか確認し、重複プロセスを停止してから起動します。
• ローカルでは待ち受けるが、リモートとのハンドシェイクに失敗する場合：サーバーポート、システム時刻、TLSサービス名、REALITYのパラメーターを確認し、エラーログ全体と合わせて判断してください。
• コマンドは成功するがブラウザーで失敗する場合：システムプロキシ、ブラウザー独自のプロキシ設定、ルーティングルールの適用先を確認してください。すぐにプロトコルの非互換と判断しないでください。

よくある質問：サブスクリプションの読み込み、切り替え失敗、復旧

最終的な選択では、次の3点を明確にできることが重要です。ノードがどの設定項目を要求しているか、クライアントが実際にどの設定を生成したか、ログでどのコアの起動が確認できたか。3点が一致してから更新や性能を検討してください。一致しないままバージョンを変え続けると、調査すべき要素が増えるだけです。さらに詳しく調べる場合は、トラブルシューティングの接続、サブスクリプション、ルーティングの手順に沿って確認してください。