コアを選ぶ際は、まずノードが必要とするプロトコル、トランスポート、安全レイヤーを確認し、クライアントが正しい設定を生成できるかをチェックしましょう。v2rayNを利用中の方や、Androidでv2rayNGまたはv2flyNGを検討している方に向けて、REALITYとVisionの依存関係、設定をそのまま相互利用できない理由、切り替え後に元へ戻せる状態を保つ方法を解説します。
クライアント・コア・サーバーの違い
v2rayNは、サブスクリプション管理やノード編集、プロキシの切り替え、設定生成を行うデスクトップ用GUIクライアントです。Xray-coreや、V2FlyがメンテナンスするV2Rayは、実際の接続処理を担います。クライアントの画面が開いても、コアが正常に起動したとは限りません。また、ノードが一覧に表示されても、その設定項目すべてが現在のコアで使えるとは限りません。
XrayとV2Flyには共通の技術的な歴史がありますが、現在はそれぞれ独自の方針で開発が進んでいます。Xrayを「どんな場合でも置き換え可能な新しいV2Ray」と捉えるのは正確ではありません。同様に、両方の設定にinboundsやoutboundsがあるからといって、完全に互換性があるとは限りません。
- デスクトップ：v2rayNを使う場合は、現在のクライアントバージョンが対応するコアとノードの種類を確認し、インストール先のファイル名だけで判断せず、起動ログで実際に動作しているコアを確かめましょう。
- Android：v2rayNGはXrayコアを使用し、v2flyNGはV2Flyコアを使用します。同じアプリの外観テーマを切り替えるような関係ではありません。
- サーバー：クライアントとサーバーで同じ名前のコアを使う必要はありませんが、双方が同じプロトコル構成に対応し、認証・トランスポート・セキュリティの各パラメーターが一致している必要があります。
プロトコル対応の違い：VLESSやVMessの名称だけでは判断できない
ノードが必要とする機能は、通常、プロキシプロトコル、トランスポート方式、安全レイヤーの組み合わせで決まります。VLESSはプロキシプロトコル、WebSocketはトランスポート方式です。TLSとREALITYは接続のセキュリティ機構に関わり、VisionはXrayの特定の構成で使われるフロー制御です。それぞれの階層は異なり、互いに置き換えることはできません。
| ノードの要件 | Xray | V2Fly | 選択前の確認事項 |
|---|---|---|---|
| VMess + WebSocket + TLS | 主な対応状況 | 主な対応状況 | 認証パラメーター、パス、Host、TLSのサーバー名 |
| VLESSの基本プロトコル | 対応。独自の拡張機能も利用可能 | 一部のバージョンまたは設定方式で実装あり。利用するバージョンを確認 | VLESSという名称だけで完全な互換性があるとは判断できない |
| VLESS + REALITY | Xrayでよく使われる構成 | XrayのREALITY設定をそのまま使用できない | 公開鍵、サーバー名、short ID、トランスポート要件 |
| xtls-rprx-vision | 対応するXrayのバージョンと構成が必要 | このXrayのフロー制御値には非対応 | サーバーがこのflowを明示的に要求しているか |
| SOCKS / HTTPのローカルプロキシ入口 | 一般的なローカルプロキシ入口に対応 | 一般的なローカルプロキシ入口に対応 | 待ち受けアドレス、ポート、アプリのプロキシ設定 |
特に、「V2FlyがVLESSに対応しているか」をバージョン条件なしの恒久的な結論にまとめないようにしましょう。実際の確認では、使用中のバイナリ、設定形式、ノードの要件を照らし合わせます。ただし、サブスクリプションにsecurity=realityやflow=xtls-rprx-visionが明記されている場合、一般的なVLESSノードとしてV2Flyで動かすことはできません。
結論：ノードの要件からコアを選ぶ
ノードがREALITYまたはVisionを明示的に要求する場合は、その構成に対応したXray環境を選びましょう。VMess + WebSocket + TLSのノードがすでに安定して使えているなら、コアの名称を変えるだけのために設定を作り直す必要はありません。
設定項目の互換性：JSONを読み込めても接続できるとは限らない
両者の設定には似た名前の項目が含まれることがありますが、配置場所や値の制約、実行時の意味が異なる場合があります。V2Flyの設定形式も一括りにはできません。クライアントが生成する設定全体には、通常DNS、ルーティング、ローカルのインバウンドも含まれます。アウトバウンドのオブジェクトを一つコピーしただけでは移行は完了しません。
以下の2つのカードは、項目ごとに確認すべきパラメーターの組み合わせを示すもので、インポート可能なノード設定ではありません。サーバーアドレスや認証情報も含まれていません。WebSocketのパス/wsはあくまで例です。実際の設定はサーバー側の値を確認してください。
VLESS + REALITY + Vision
- プロトコル
- VLESS
- トランスポート
- TCP。画面上の名称はバージョンによって異なる場合があります
- セキュリティ
- REALITY
- Flow
xtls-rprx-vision- 確認する項目
- サーバー名、公開鍵、short ID
この構成には対応するXrayの機能が必要です。別のコアで動かすためにセキュリティ項目を削除しないでください。
VMess + WebSocket + TLS
- プロトコル
- VMess
- トランスポート
- WebSocket
- パスの例
/ws- セキュリティ
- TLS
- 確認する項目
- UUID、Host、サーバー名
どちらのコアにも一般的な対応例がありますが、各設定形式に合わせて項目を生成する必要があります。
- プロトコル項目：UUID、暗号化パラメーター、flowを確認し、あるプロトコルの認証項目を別のプロトコルへそのまま流用しないでください。
- トランスポート項目：パス、リクエストヘッダー、トランスポート名を現在のバージョンと照らし合わせてください。古い解説にある名称が、新しい設定でも使えるとは限りません。
- セキュリティ項目：TLSのサーバー名とWebSocketのHostは役割が異なります。例で同じドメインが指定されていても、常に一致するとは限りません。
- ルーティング項目：アウトバウンドのタグが残っているか確認してください。ルールが古いタグを参照している場合、問題が起きているのはプロトコルのハンドシェイクではなく、ルーティングの段階かもしれません。
サブスクリプションのインポートとルーティング：切り替え後に再確認
サブスクリプションURLはノードを配布するための入口であり、コアそのものではありません。更新に成功した場合も、完了したのはダウンロードや解析の一部にすぎないことがあります。クライアントのバージョンによっては、認識できない項目が無視されたり、対応するアウトバウンドを生成できなかったりします。そのため、サーバー数が増えたことを確認した後も、ノードの編集画面で重要なパラメーターをチェックしてください。
- 元のグループを残す：必要な設定をエクスポートし、サブスクリプションURLを安全に保存してから、新しいグループでテストしてください。唯一使える設定を上書きしないようにしましょう。
- インポート結果を確認：提供元の説明と照らし合わせ、プロトコル、ポート、トランスポート、セキュリティ、flowを確認してください。REALITYノードでは、公開鍵、サーバー名、short IDもチェックします。
- 動作中のコアを確認：接続を再起動し、ログでコアの識別情報、起動エラー、待ち受け情報を確認してください。ノード名を変更しただけでは、コアは切り替わりません。
- アウトバウンドを個別に確認：まず指定したノードでテスト先に接続できるかを確認し、次に直接接続するドメインとプロキシ経由のドメインが想定どおりのルールに一致するかを確かめてください。
ルーティングの振り分けは、ルールの順序、DNSの解決方法、ドメイン・IPルールのデータ、スニッフィング設定に左右されます。異なるルールファイルやDNS設定で行った2回のテスト結果の差を、XrayまたはV2Flyの違いだけに結び付けることはできません。システムプロキシとTUNでは通信を制御する範囲も異なるため、コアを比較する際は同じ方式を使ってください。
ローカルポートとハンドシェイクのエラー：接続段階ごとに切り分ける
「切り替え後にインターネットへ接続できない」というだけでは、どちらのコアが優れているか判断できません。コアの起動失敗、ローカルの入口の不具合、リモートとのハンドシェイク失敗を切り分けましょう。ノードを何度も変更するより効果的です。以下の数値は接続の流れを説明するための設定例であり、すべてのクライアントの初期値を示すものではありません。
| ログまたは症状 | まず確認すること | 次に行うこと |
|---|---|---|
unknown fieldまたは設定の読み込み失敗 | 項目の配置、設定形式、コアのバージョン | 認識できない項目を安易に削除せず、現在のクライアントで設定を再生成する |
address already in use | ローカルの待ち受けポートが使用中か | 重複して起動しているプロキシプロセスを終了するか、待ち受けポートとアプリ側のポートを合わせて変更する |
connection refused | エラーがローカルとリモートのどちらを示しているか | まずローカルの待ち受けを確認し、その後、リモート側でサービスが公開されているか、ポートが正しいかを確認する |
| 証明書の名前が一致しない | TLSのサーバー名、証明書、システム時刻 | 名前と時刻を修正し、検証のスキップを通常の解決策にしない |
| ハンドシェイク失敗または接続タイムアウト | プロトコルのパラメーターとネットワーク到達性 | パラメーターを確認してからネットワークを調べる。エラーメッセージだけでは原因を特定できない |
たとえば、アプリから127.0.0.1:10808への接続が拒否された場合は、まずコアがそのアドレスで待ち受けているか確認してください。すぐにリモートの443を疑う必要はありません。ローカルの入口が使える一方で、ログにリモートとのハンドシェイク失敗が記録されている場合は、UUID、サーバー名、セキュリティパラメーターを確認します。この2つの段階では、対処方法がまったく異なります。
更新頻度と性能の比較：一度に変更する条件は一つだけ
XrayとV2Flyはそれぞれ独自のリリース履歴で開発されています。バージョン番号を単純に大小比較したり、リリース日だけで現在のノードに適しているか判断したりすることはできません。実際に使えるかどうかは、GUIクライアントが新しい項目に対応しているか、同梱コアが適切か、サーバーが該当機能を採用しているかにも左右されます。
性能も環境を切り離して結論づけることはできません。回線の混雑、サーバー負荷、トランスポート方式、DNS、ルーティングなどが速度測定に影響します。プロトコルや回線が異なるテストを並べても、特定のコアが常にどれだけ速いかは判断できません。
- 基準値を記録：クライアントと実際に動作しているコアのバージョン、ノードのパラメーター、プロキシモード、ルーティング設定を記録し、現在使えているインストーラーと設定のバックアップを保存します。
- 条件をそろえる：両方が対応する同じプロトコル構成で比較し、サーバー、テスト先、通信の制御方式を固定します。
- 複数回テストする：各構成で同じ条件のテストを少なくとも3回行い、接続の成否、応答時間、連続通信の状態をそれぞれ記録します。1回の遅延値だけで判断しないでください。
- 更新内容を確認：新バージョンで修正された内容が現在の利用環境に関係するか確認し、アップグレード後に起動ログ、DNS、直接接続、プロキシ経由の接続を改めてチェックします。
結論：元に戻せる状態を保ってから更新を検証
クライアントだけを更新した場合も、コアだけを置き換えた場合も、設定の生成機能と実行機能が合わなくなることがあります。まずクライアントの説明で対応範囲を確認し、バックアップを取ってからテストしてください。問題が起きたら複数の設定を続けて変更せず、動作確認済みの組み合わせに戻しましょう。
ノードに合わせて選ぶ：3つの利用パターン
コアを選ぶ際は、「現在のノードに必要な機能」と「使用中のクライアントで正しく生成できる設定」に立ち返りましょう。名称を統一するためにすべての端末を置き換える必要はありません。一方、サーバー側で接続要件が変わったのに、古い設定を維持することに固執するのも避けましょう。
- ノードがREALITYまたはVisionを要求：デスクトップではv2rayNで対応するXray構成を使用しているか確認します。Androidでは必要な機能に対応するv2rayNGを選び、インポートした項目を一つずつチェックしてください。
- V2Flyの設定が安定して動作中：ノードが対応するプロトコル構成を使い、新しい機能も必要ない場合は、そのまま利用できます。Androidでは、V2Flyの機能に合ったノードにv2flyNGが適しています。
- 別のコアへ移行する：元のサブスクリプションまたはサーバーのパラメーターから設定を再生成し、プロトコル、セキュリティ、DNS、ルーティングを個別に確認してください。古いJSON全体を汎用設定ファイルとして流用しないでください。
適切なコアを選べたかどうかは、コアが正常に起動すること、ノードのパラメーターがそろっていること、目的の接続が成功すること、ルーティングの結果が想定どおりであることで判断できます。これらを満たしたうえで更新のしやすさや設定の管理コストを検討する方が、プロジェクト名だけで一律に順位を付けるより実用的です。