コアを選ぶ前に、サーバー側のプロトコル、トランスポート方式、安全性に関するパラメーターを確認し、クライアントが各項目を正しく設定できるかを確かめましょう。VLESS・Vision・REALITYを組み合わせる場合は、その構成に対応したXray環境を優先します。既存のVMess設定が正常に動作しているなら、名称が違うという理由だけで移行する必要はありません。Androidクライアントやデスクトップのコアを切り替える方、カスタム設定をインポートする方に向けて、引き継げる項目と再確認が必要な項目を解説します。
分岐の経緯：プロジェクト・コア・クライアントの違い
このエコシステムを理解する出発点となるのがProject Vで、V2Rayはその中のプロキシソフトウェアです。V2Flyコミュニティはv2ray-coreのメンテナンスを続けています。一方、Xray-coreは2020年に当時のV2Rayのコードを基に分岐し、その後独自に開発が進められました。分岐前にコードや設定の慣習を共有していたからといって、その後の機能、設定形式、リリース時期まで一致するわけではありません。
一般に「V2Flyコア」はV2Flyがメンテナンスするv2ray-core、「Xrayコア」はXray-coreを指します。v2rayN、v2rayNG、v2flyNGはクライアントの名称で、ノード管理や画面上の設定、コアの起動を担います。クライアントとコアはそれぞれ別のバージョン情報です。問題を調べる際は、両方のバージョンを記録してください。
- プロトコル層：VMessやVLESSなどが、クライアントとサーバー間でプロキシリクエストをやり取りする方法を定めます。
- トランスポート・セキュリティ層：TCP、WebSocket、TLS、REALITYなどが、接続の運び方や安全なセッションの確立方法を定めます。
- コア層：設定を解析し、DNS、ルーティング、インバウンド、アウトバウンドの処理を実行します。
- クライアント層：サブスクリプションを読み込み、コア設定を生成し、システムプロキシやAndroidのVPNインターフェースを処理します。
そのため、「クライアントでリンクをインポートできること」と「コアで接続を確立できること」は別問題です。リンクのパーサーがVLESSを認識しても、サーバーが要求するフロー制御やセキュリティ関連の項目を引き継げない場合があります。画面にノードが表示されただけでは、設定が完全とは限りません。
機能の違い：VisionとREALITYの組み合わせに注目
VMessは両方のコアで使われるプロトコルのひとつですが、すべての機能が互換だとは限りません。VLESSはプロキシプロトコル、XTLSは関連する技術方式、Visionは一般的なフロー制御モード、REALITYはトランスポートのセキュリティ方式です。それぞれの階層が異なるため、互いに置き換えられる4種類のノードとして扱うことはできません。
| 確認項目 | Xray-core | V2Fly v2ray-core |
|---|---|---|
| VMess | 互換性のあるVMess設定で利用可能 | 互換性のあるVMess設定で利用可能 |
| WebSocket + TLS | パス、Host、サーバー名を確認 | トランスポートとTLSのパラメーターも確認 |
| VLESS | 一般的な利用例。トランスポートとフロー制御の適合が必要 | プロトコル名だけでは判断できない。過去の実装がXray拡張に対応するとは限らない |
| Vision | 該当するXTLS Visionの利用方法に対応 | Xray Visionの設定をそのまま置き換えることはできない |
| REALITY | 該当するREALITY設定に対応 | XrayのREALITYアウトバウンドを置き換えるコアとしては使えない |
| 完全なJSON設定 | Xrayの設定仕様に従って解析 | 該当バージョンのV2Fly設定仕様に従って解析 |
プロバイダーの指定がVLESS + TCP + REALITYで、フロー制御がxtls-rprx-visionの場合は、この組み合わせ全体に対応するコアを選びます。REALITYをTLSに変更したり、Visionの項目を削除したりしても、互換性のあるノードとして使えるようになるわけではありません。サーバー側にも該当する接続方式が必要です。
結論：サーバーのパラメーターをすべて確認してからコアを選ぶ
プロトコル、トランスポート、安全方式、flowの4項目をひとつのチェックリストにまとめましょう。いずれかがXray固有の機能に依存する場合は、互換性のあるXray環境で先に検証してください。項目を削除して動作を試すのは避けましょう。
設定の互換性：共有リンクは移行できても、設定全体をそのまま移すのは危険
「同じノードを使えるか」と「同じJSONを使えるか」は分けて考える必要があります。前者に関わるのは主に接続先のパラメーターですが、後者にはローカルのリスナー、DNS、ルーティングルール、アウトバウンドのタグ、コア固有のオプションも含まれます。どちらのファイルにもinboundsとoutboundsがあるからといって、内容をそのまま入れ替えられるわけではありません。
- まずノードのパラメーターを移行：アドレス、ポート、ユーザーID、トランスポート、安全性に関する設定をひとつずつ対応させます。共有リンクには、クライアント側のローカル設定がすべて含まれているとは限りません。
- 次にルーティングの方針を移行：直結するドメイン、プロキシ経由にするドメイン、ブロックするドメインを記録します。移行先のクライアントでルールを再設定し、適用順も確認してください。
- DNSは別途設定：リゾルバーのアドレス、問い合わせの出口、ドメインのマッチ方法を確認します。リモートDNSのアドレスが同じでも、同じポリシーとは限りません。
- 最後に固有の項目を確認：古い解説にあるXTLSの項目、設定形式によって異なるトランスポート名、REALITYのパラメーターは、実際に使うコアのバージョンに合わせて確認してください。
WebSocket + TLSを例にすると、接続先のポートがどちらも443だからといって、接続パラメーターが同じとは限りません。WebSocketのパスはHTTPアップグレードリクエストに、Hostはリクエストヘッダーに、TLSのサーバー名はハンドシェイクと証明書検証に使われます。3つは異なる値の場合があり、移行時にすべてサーバーのIPアドレスへ置き換えることはできません。証明書検証の無効化を通常の対処方法にするのも避けてください。
REALITYのサーバー名、公開鍵関連のパラメーター、short ID、フィンガープリントのオプションは、プロバイダーの情報と現在のクライアントの入力項目に従って設定します。バージョンによって画面上の項目名、JSONフィールド、共有リンクのパラメーター名が異なる場合があるため、名前が似ているという理由だけで手動変更しないでください。設定の共有やトラブル対処の際は、サブスクリプションURL、ユーザーID、その他のアクセス情報を先に削除してください。
クライアントの選び方：v2rayN・v2rayNG・v2flyNG
デスクトップでは、ウィンドウのタイトルだけで判断せず、v2rayNで現在のノードが実際にどのコアを起動しているか確認してください。一般的なノードではクライアントが設定を生成しますが、カスタム設定では指定したコアにファイルをそのまま渡して実行することがあります。ノード編集画面に項目がないからといってコアが非対応とは限りません。逆の場合も同様です。
Xrayを使う場合：v2rayN / v2rayNG
おすすめVLESS + Vision + REALITYを使う場合は、Xrayコアのバージョンと、クライアントが必要な項目に対応しているかを優先して確認します。Androidではv2rayNGを使用し、デスクトップではv2rayNで選択中の設定が実際にXrayを使っているか確認してください。
向いているケース：サーバーがXray拡張を明示的に要求する場合、または対応する共有リンクを使う場合
V2Flyを使う場合：v2flyNG
Androidで引き続きV2Flyの設定体系を使う場合は、v2flyNGを選べます。既存のVMess接続やルーティングポリシーが正常に動作しているなら、コアを変更する前に移行のメリットを確認してください。
向いているケース：既存のV2Fly設定を維持し、ノードがXray固有の機能に依存しない場合
ここでのおすすめは、解説したプロトコル要件に基づくもので、速度ランキングではありません。同じVMess回線でも、ダウンロード速度はサーバーの負荷、ネットワーク経路、輻輳制御、クライアントの設定に左右されます。異なる時間帯の速度測定の差をすべてコアの違いに結びつけることはできず、コアを変更すれば遅延が必ず短くなるとも限りません。
移行手順：最小構成で接続を確認してからローカル設定を戻す
デスクトップ：v2rayN
- 現在のノード、ルーティングモード、ローカルのリスナーポートを記録します。
- テスト用ノードをひとつ使い、コアとトランスポートのパラメーターを確認します。
- まず明示的にプロキシを指定して接続し、その後システムプロキシの設定を確認します。
Android：v2rayNG / v2flyNG
- 元のクライアント設定を保存してから、テスト用ノードをひとつインポートします。
- テスト中はVPNサービスをひとつだけ起動します。
- 接続を確認した後、アプリごとのプロキシ設定とDNSポリシーを戻します。
サブスクリプションから同じノードを取得できても、両方のクライアントのDNS、ルーティング、アプリごとの設定が自動で同期されるわけではありません。
確認の順序：ポート・設定の構文・実際の通信を分けてチェック
トラブル対処では、まず再現可能な基準を用意します。ここで示すポートはテスト例であり、すべてのクライアントのデフォルト値ではありません。サーバーのポートを443、ローカルのSOCKSインバウンドを手動で10808に設定した場合、テストするプログラムは実際に設定したアドレスとポートへ接続する必要があります。クライアントのバージョンによって混合インバウンドを使う場合は、画面または生成された設定に記載されたリスナーの値を確認してください。
JSONを直接管理する場合は、コアに付属するテストサブコマンドで構文を確認できます。次の例は、Xrayでよく使われるコマンド形式とV2Fly v5のコマンド形式です。実行ファイル名はOSやインストール方法によって異なります。稼働中のファイルを上書きせず、設定のコピーを使って確認してください。
# Xray：カレントディレクトリにある設定ファイルを確認
xray run -test -config config.json
# V2Fly v5：カレントディレクトリにある設定ファイルを確認
v2ray test -c config.json構文チェックに合格しても、設定を解析できたことが分かるだけで、接続先に到達できること、認証情報が有効であること、トラフィックが意図した経路を通ることまでは確認できません。コマンドのオプションが認識されない場合は、該当プログラムのヘルプを実行し、インストール済みバージョンで使える方法を確認してください。意味の分からない設定項目を削除して、チェックを通そうとするのは避けましょう。
- 起動ログを確認：まず未知のフィールド、設定形式のエラー、ローカルポートの競合に対処します。この時点では、まだ接続先とのハンドシェイクは始まっていません。
- ネットワーク接続を確認：タイムアウトが続く場合は、ユーザーIDを変更する前にサーバーアドレス、ポート、ネットワーク到達性を確認します。
- ハンドシェイクを確認：TLSまたはREALITY関連のエラーが出る場合は、サーバー名、安全方式、鍵のパラメーターを照合し、端末の時刻も正確か確認してください。
- 実際のリクエストを確認：プロキシを明示的に指定したプログラムで接続先にアクセスし、その後システムプロキシやAndroidの通信対象範囲を確認します。プロキシを経由していないリクエストをコアの障害と誤認しないようにしましょう。
- ルーティングとDNSを戻す：最小構成で接続できたら、項目をひとつずつ戻して変更のたびに再テストします。どのポリシーが結果に影響したかを特定できます。
移行前の最終確認：元に戻せるようにし、同じ変更を繰り返さない
両方のコアが既存ノードに対応している場合は、メンテナンスの手間と設定の検証しやすさを基準に選びます。VMess + WebSocket + TLSの設定が安定して動作しているなら、名称を統一するためだけにVLESSへ変更する必要はありません。一方、サーバーがすでにREALITYを要求しているなら、古い環境を使い続けるために接続パラメーターを無理に簡略化するべきではありません。
同じサブスクリプションがv2rayNGでは使えて、v2flyNGでは使えない場合、まず何を確認すればよいですか？
まずサブスクリプションURLだけでなく、実際にインポートしたノードの種類とパラメーターを比較します。サブスクリプションにはVMess、VLESS、異なるトランスポート方式が混在している場合があります。また、クライアントによってリンクパラメーターの解析方法も異なることがあります。同じノードを選び、flow、安全方式、トランスポートを照合してから起動ログを確認してください。VisionやREALITYに依存するノードは、対応するXray環境でテストします。
コアを変更すればDNSやルーティングの問題も自動的に直りますか？
自動では直りません。コアの変更によって設定の解析方法やデフォルト動作が変わる場合はありますが、ドメインルール、DNS問い合わせの出口、クライアントが通信を取り込む範囲に問題があれば、別途対処が必要です。移行後はDNSリクエストの経路、直結対象が引き続き直結するか、プロキシ対象が正しいアウトバウンドに一致するかを再確認してください。
トラブル対処のためにどのような記録を残せばよいですか？
クライアントのバージョン、コアのバージョン、OS、ノードのプロトコル構成、認証情報を削除したエラーログを残します。一度に変更するのはコアか接続パラメーターのひとつだけにし、同じ接続先で繰り返しテストしてください。設定の非互換、サーバー側の拒否、ローカルでの通信取り込みの失敗を切り分けやすくなります。
- 元の設定とテスト用設定は別々に保存し、サブスクリプションの更新で手動変更が上書きされないようにします。
- 別のサービスを起動する前にアプリを停止し、ローカルのリスナーポートが競合しないようにします。
- 移行が成功してから古い設定を整理し、動作確認済みの復旧手段をひとつ残しておきます。