コアを選ぶ際は、まずサーバー側の要件を確認し、次にクライアントが設定を正しく反映できるかを見ます。VMessノードは、名称が異なるというだけで移行する必要はありません。REALITYやXTLS Visionが明示的に求められるノードでは、対応する機能を備えたバージョンのXrayを使いましょう。この記事では、コアの切り替えやJSON設定の移行、インポート失敗の原因調査を行う方向けに、プロトコルの機能、設定項目の互換性、クライアントによる設定生成の3点を整理します。
1. 分岐の背景：共通のルーツ、異なる開発方針
V2RayはもともとProject Vの一環として開発されたプロキシツールです。V2Flyコミュニティが関連するコードやドキュメントの保守を引き継ぎ、コアの実行ファイル名は現在も一般にv2rayです。Xrayは2020年にV2Rayのコードをベースにフォークされ、当初はXTLSに関連する開発方針を背景に、その後独自に進化しました。両者には共通の歴史がありますが、リリースや実装、設定インターフェースはそれぞれ独立して保守されています。共通のルーツがあるからといって、以降の機能がすべて同時に追加されるわけではありません。
クライアントとコアも分けて考える必要があります。v2rayNはデスクトップ向けの画面、サブスクリプション管理、設定生成を担い、実際の接続は選択したコアが処理します。v2rayNGはXrayコアを使用するAndroidクライアントで、v2flyNGはV2Flyコアを使用します。クライアントにノード名が表示されるのは、その情報が保存されているということにすぎません。実行中のコアがノードの全パラメーターに対応しているとは限りません。
- クライアント：共有リンクのインポート、サブスクリプションの保存、ノードの選択、画面上の設定をコア用の設定に変換します。
- コア：接続の確立、プロトコルの処理、DNSやルーティングルールの適用、実行ログの出力を担います。
- サーバー：受け付けるプロトコル、伝送方式、安全設定を決定します。ローカルのコアを入れ替えても、サーバー側の機能は変わりません。
2. プロトコルの機能：VLESSとREALITYは別の層
VMessとVLESSはプロキシプロトコル、TCPやWebSocketなどは接続を運ぶ方式、TLSやREALITYは接続のセキュリティ機構に関わるものです。これは機能を分類したもので、自由に組み合わせられる互換性一覧ではありません。サーバー側の組み合わせに合わせて、クライアントが各機能に対応し、パラメーターを正しく設定する必要があります。
| 確認項目 | Xray | V2Fly |
|---|---|---|
| VMess | 対応。伝送方式とセキュリティ関連の設定も要確認 | 対応。伝送方式とセキュリティ関連の設定も要確認 |
| VLESSの基本プロトコル | 対応。関連機能も継続的に拡張 | 基本的な実装あり。Xrayのすべての拡張機能に対応するとは限らない |
| REALITY | 対応。バージョンとサーバー側の設定を合わせる必要あり | XrayのREALITY設定をそのまま置き換える実装ではない |
| XTLS Vision | 該当するVLESS flowに対応。組み合わせの条件を満たす必要あり | XrayのVision設定をそのまま実行することはできない |
| ルーティングとDNS | 関連機能を提供。項目や動作は使用中のバージョンで確認 | 関連機能を提供。項目や動作は使用中のバージョンで確認 |
そのため、「VLESSノードには必ずXrayが必要」と言い切るのは大ざっぱです。また、「VLESSが使えればREALITYも使える」とは限りません。ノードでsecurity=realityやflow=xtls-rprx-visionが指定されている場合、別のコアが基本的なVLESSに対応しているという理由だけで置き換えることはできません。プロトコル、伝送方式、セキュリティ設定、flowをまとめて確認しましょう。
REALITYの設定には通常、サーバー名、サーバーが提供する公開鍵関連のパラメーター、short ID、クライアントフィンガープリントなども含まれます。具体的な項目名はバージョンやクライアントの画面によって異なる場合があるため、securityをtlsからrealityに変えるだけでは移行できません。一方、通常のVMess + WebSocket + TLSノードが安定して動作しているなら、コアを変えるためだけにサーバー側を変更する必要もありません。
3. 設定の互換性：JSONの構造が似ていても、そのまま使えるとは限らない
両方のコアの一般的な設定には、inbounds、outbounds、routingなどの構造が見られます。しかし、構造が似ているのは共通の設計基盤があることを示すにすぎません。各項目を受け付けるか、デフォルト値が何か、特定の伝送方式の実装に依存するかは、設定を実行するバージョンによって異なります。V2Flyの各種設定形式と、Xrayで一般的なJSON設定も、区別せずにそのまま置き換えないでください。
- まず設定形式を確認：ファイルの形式と読み込み方法を確認し、異なる形式の設定を別のパーサーに渡さないようにします。
- 次にアウトバウンドのパラメーターを確認：ノード名だけでなく、プロトコル、アドレス、ポート、ユーザーID、伝送方式、SNI、パス、セキュリティ設定を一つずつ照合します。
- 続いて固有の項目を確認：REALITY、Vision、特定のコアで追加された伝送オプションは、移行先コアのドキュメントに沿って確認します。エラーになった項目を削除して、そのまま使い続けてはいけません。
- 最後に実行時の依存関係を確認：ルールデータファイル、証明書のパス、相対パスの基準となる作業ディレクトリも起動結果に影響します。
共有リンクやサブスクリプションは、コアの設定全体を含むものではありません。クライアントにvmess://やvless://をインポートした後、各パラメーターが実際の設定にどう反映されるか確認が必要です。通常、サブスクリプションの更新で更新されるのはノード情報であり、DNS、ルーティング、カスタムテンプレート全体まで自動で照合されるわけではありません。移行時は生成された設定や起動ログを確認し、画面で指定した内容がコアに渡されているか確かめましょう。
4. コアの選び方：現在のノードと運用方法に合わせる
ここでの「推奨」は、REALITYやVisionを明確に使う場合に限ったもので、もう一方のコア全体が劣っているという意味ではありません。既存のノード、設定テンプレート、運用手順がV2Flyを前提に構築されているなら、検証済みの組み合わせを維持するほうが、移行して調査する手間を抑えられます。サーバー側でXrayの機能が明確に求められている場合は、互換性の条件を優先しましょう。
Xrayコア
推奨サーバーでREALITYまたはXTLS Visionが必要な場合は、該当機能に対応したバージョンのXrayを選び、必要な項目をクライアントがすべて正しく生成できるかも確認します。
適した環境：Xray固有の機能を使うことが確認できているノード、同じXray設定に揃える必要がある環境。
V2Flyコア
対応するVMessなどの組み合わせやV2Fly用の設定テンプレートをすでに使っている場合は、検証済みの環境を継続できます。移行のメリットは、プロジェクト名の比較ではなく、実際の必要性に基づいて判断しましょう。
適した環境：既存のV2Fly設定が安定しており、現在のルールや保守手順を引き継ぎたい環境。
利用環境ごとのクライアント構成
サーバーでREALITY / Visionを使用
- デスクトップではv2rayNでXrayが選択されていることを確認します。
- Androidではv2rayNGを使い、内蔵コアのバージョンを確認します。
- サーバー名、鍵関連のパラメーター、flowを一つずつ確認します。
既存のV2Fly設定を継続して使用
- デスクトップでは、現在のv2rayNのバージョンがどの範囲でV2Flyに対応しているか確認します。
- Androidではv2flyNGを選び、ノードの組み合わせごとにインポート結果を確認します。
- 既存のDNS、ルーティング、ルールデータに関する記録を残します。
同じサブスクリプションから機能の異なるノードが配信される場合があります。両方の端末でインポートできたノード数が同じでも、すべてのノードが両方のコアで使えるとは限りません。
性能をコア名だけで順位付けするのも適切ではありません。遅延やスループットは、サーバー負荷、ネットワーク経路、伝送方式、端末の性能、同時接続数などに左右されます。比較する際は端末、ノード、測定時間帯を揃え、ルーティング方針も同じにします。VMess + WebSocketからVLESS + REALITYに同時に変更した場合、結果を単純に「コアを変えたから」と判断することはできません。
5. 切り替え手順：現状を記録し、一度に一つずつ検証する
まずクライアントの設定とカスタムテンプレートをバックアップし、現在接続できるノードとコアのバージョンを記録します。v2rayNのメニューやコア選択の場所は、バージョンや画面の系統によって変わるため、現在の画面と起動ログを基準にしてください。以下のポート番号は再現性のある確認に使う例であり、3つのクライアント共通のデフォルト値ではありません。実際のテストでは、端末上で現在待ち受けているポートに置き換えてください。
- 現状を記録：旧コアで接続できるノードを一つ確認し、ローカルの待ち受けアドレスとポート、システムプロキシの状態、ルーティングモードを記録します。
- コアだけを変更：ノード、DNS、ルールはそのままにします。一度のテストでTUNの有効化、ルールファイルの差し替え、伝送パラメーターの変更を同時に行わないでください。
- 生成された設定を確認：移行先のコアに、プロトコルとセキュリティ関連の項目がすべて渡されているか確認します。クライアントが必要な項目を生成できない場合は、まずクライアントの対応状況を解決します。
- 起動と接続を確認：最初に設定の解析が成功するか、次にローカルポートが待ち受けているか、最後にサーバーへの接続と宛先へのリクエストを確認します。
- 通常の利用設定に戻す：基本的なプロキシ接続が動作した後、分岐ルール、システムプロキシ、TUN設定を一つずつ戻し、変更のたびにログを確認します。
自分で管理する単体の設定ファイルは、事前に設定テストを実行できます。次のコマンドはXray用と、該当するコマンドインターフェースを備えたV2Fly用です。実際にインストールされているコアに合わせて、いずれか一方を使ってください。Windowsでは対応する実行ファイル名に置き換えます。古いバージョンで引数が異なる場合は、先にヘルプコマンドで確認してください。
# Xray：ローカルのconfig.jsonをテスト
xray run -test -config config.json
# V2Fly：ローカルのconfig.jsonをテスト
v2ray test -c config.json設定テストに成功しても、確認できるのはそのファイルが現在のコアに受け付けられることだけで、サーバーに接続できるとは限りません。ローカルで127.0.0.1:10808のSOCKS入口を実際に利用できる場合は、次のコマンドでプロキシ経路を個別にテストできます。socks5hは宛先ドメインの名前解決をプロキシ側で行う指定で、ローカルでの名前解決と区別するのに役立ちます。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://v2ray-home.com/このコマンドは成功するのにブラウザーで失敗する場合は、ブラウザーが実際に使用しているプロキシ入口、システムプロキシの状態、アプリ独自の設定を確認します。ログに最初にaddress already in useと表示された場合は、まずポートの使用状況を調べます。設定の読み込みが成功していない段階では、リモートDNSの調整やサーバーポートの変更を先に行う必要はありません。
6. よくある質問：インポート、ハンドシェイク、切り戻し
サブスクリプションをインポートできたのに、コアを切り替えたらノードが使えなくなったのはなぜ？
まずノードの編集画面で、プロトコル、伝送方式、セキュリティ設定、flowを確認し、次に起動ログで実際に使われているコアを調べます。インポートに成功したということは、クライアントがノード情報を受け付けたというだけです。ノードでREALITYを使っているのに実際にはV2Flyが起動している場合は、その組み合わせに対応するXrayに戻してください。セキュリティ項目を削除して無理に起動させる方法は避けましょう。
同じVMessノードでも2つのコアで結果が違う場合、まず何を確認すればよい？
まず生成された設定で、アドレス、ポート、ユーザーID、WebSocketパス、Host、TLSのサーバー名を照合し、端末の時刻と証明書の検証設定を確認します。続いてルーティングとDNSが一致しているか調べます。証明書検証の無効化を通常の解決策として使わないでください。エラーログを見れば、証明書の問題と伝送パラメーターの問題を切り分けやすくなります。
Android版のv2rayNGで、V2Flyに直接切り替えられる？
デスクトップ版でのコア選択の感覚を、そのままAndroidに当てはめないでください。v2rayNGはXrayを使用します。V2Fly環境を検証する場合は、v2flyNGに対応するノードを個別にインポートし、ルールとDNS設定を確認してください。テスト時は、もう一方のクライアントのプロキシサービスを停止し、接続中の通信やシステムVPNの状態が干渉しないようにします。
コアを切り替えた後、元に戻すにはクライアントを再インストールすればよい？
まず以前保存したコアの選択、設定テンプレート、ルーティング、DNSの設定を復元し、基準にしたノードを選び直します。ローカルの待ち受けポートを変更していた場合は、システムプロキシの接続先も元に戻してください。ログに表示されるコアのバージョンがバックアップの記録と一致したことを確認してから、同じプロキシテストをもう一度実行します。再インストールだけでは古い設定が引き継がれることがあり、かえって変更箇所を特定しにくくなる場合があります。
コア選びでは、再現できる互換性の組み合わせを見極めることが重要です。サーバーが必要な機能を決め、クライアントがパラメーターを正しく設定に反映できるかを左右し、コアが接続を実行します。既存の設定が安定しているなら、元に戻せる基準環境を維持しましょう。新機能が必要な場合は、クライアントの対応状況とサーバー側のパラメーターも合わせて検証します。各項目の詳しい意味はプロトコル解説を、基本的なインポートと接続の手順は入門ガイドをご覧ください。