この記事は、v2rayNで使用するコアの選択、古いノードの移行、プロトコルの互換性問題を確認したい方向けです。判断は2段階です。まずノードのプロトコル、セキュリティ層、flowを確認し、それらを完全に認識できるコアを選びます。REALITYやXTLS Visionを使うノードはXray、通常のVMess、Shadowsocks、標準的なトランスポートのノードは、現在の設定のままV2Flyを利用できます。
2つのコア分岐の関係と位置づけ
V2Flyはv2ray-coreの汎用プロキシフレームワークを引き継いでおり、設定は引き続きインバウンド、アウトバウンド、ルーティング、DNS、ポリシー、トランスポートなどのモジュールで構成されます。Xray-coreも同じ技術体系から分岐して発展したため、JSON設定の構造、VMessノードの表現方法、一般的なトランスポート層には多くの共通点があります。ただし、似ているからといって設定を自由に相互利用できるわけではありません。片方の分岐固有のセキュリティ層、flow値、トランスポートパラメータが含まれる場合、もう一方のコアは起動を拒否したり、認識できないフィールドを無視したりすることがあります。
XrayはVLESS、XTLS Vision、REALITY、および関連するトランスポート機能を重視しています。一方、V2Flyは汎用プロキシコア、VMess互換性、モジュール式設定の維持を重視します。ここでいう「コア」とは、設定を読み込み、アウトバウンド接続を確立し、トラフィックを処理するバックグラウンドプログラムです。v2rayNはデスクトップ向けの管理画面で、ノードの保存、設定生成、コアの起動、システムプロキシの制御を担います。両者は同じコンポーネントではありません。
- 共通する基盤：どちらもインバウンドでローカルアプリの通信を受け取り、ルーティング規則に従ってプロキシまたはダイレクトのアウトバウンドへ転送できます。
- 主な違い：XrayはREALITYとXTLS Vision関連の実装を提供しており、設定には
security: realityやflow: xtls-rprx-visionがよく登場します。 - バージョンの影響：同じ分岐でも新旧バージョンによってフィールドが異なる場合があります。互換性を判断する際は、コアの名称とバージョンを同時に確認してください。
- クライアントの役割：サブスクリプションはノード情報を提供するだけで、最終的な接続可否はクライアントの解析能力、コアの機能、サーバー設定によって決まります。
結論：分岐名から選び始めない
まずノードリンクまたはサブスクリプション項目のプロトコル、security、flow、transportを確認します。REALITYまたはxtls-rprx-visionがあればXrayを選択し、通常のVMess、Shadowsocks、標準トランスポートの場合にV2Flyの継続利用を検討します。
REALITY・XTLS Visionと標準トランスポートの互換性の違い
REALITYは独立したプロキシプロトコルではありません。一般的な組み合わせでは、VLESSがユーザー識別とプロキシセッションを担当し、TCPなどの対応方式が通信を運び、REALITYが安全なハンドシェイクとサーバー識別情報を担います。ノードには通常、公鍵、ショートID、serverName、fingerprintも含まれます。必須値が1つでも欠けていたり、クライアントが解析した値をコア設定へ書き込めなかったりすると、ハンドシェイクに失敗します。
XTLS Visionは通常、flow: xtls-rprx-vision で指定します。これは通常のTLS、WebSocket、gRPCと同じ階層の概念ではありません。TLSやREALITYはセキュリティ層、VisionはXrayにおけるトラフィック処理モード、WebSocket・gRPC・TCPはトランスポート方式を表します。ノードを判断する際は「VLESS」の4文字だけでなく、securityとflowも確認してください。
| ノードの組み合わせ | Xray | V2Fly | 選択基準 |
|---|---|---|---|
| VLESS + TCP + REALITY + Vision | 完全対応 | この組み合わせでは使用しない | realityとxtls-rprx-visionフィールドを含む |
| VLESS + TCP + TLS | 対応 | 具体的なバージョンと設定形式を確認 | サブスクリプションで指定されたコア種別を優先 |
| VMess + WebSocket + TLS | 対応 | 対応 | 双方とも安定した互換性がある組み合わせ |
| VMess + TCP | 対応 | 対応 | UUID、ポート、時刻同期を確認 |
| Shadowsocks標準ノード | 一般的な暗号方式に対応 | 一般的な暗号方式に対応 | 現在のバージョンが暗号方式を認識するか重点的に確認 |
| gRPCトランスポートノード | 対応 | 標準設定に対応 | serviceName、TLS、ドメインを確認 |
Xrayコア
推奨REALITY、XTLS Vision、一般的なVLESSの組み合わせを処理でき、主要なVMessノードにも対応します。v2rayNの日常利用における標準コアとして適しています。
適するケース：新しいサブスクリプション、REALITYノード、VLESS Visionノード
V2Flyコア
安定稼働を確認済みのVMess、標準TLS、WebSocket、汎用ルーティング設定を継続して使う場合に適しています。古い設定を移行する際の変更も少なく済みます。
適するケース：従来のVMessノード、既存のV2Fly JSON設定
サブスクリプション名ではなくノードのフィールドでコアを選ぶ
サブスクリプション名はサーバー側が表示用に設定したテキストにすぎません。同じサブスクリプションにVMess、VLESS、Shadowsocks、異なるトランスポート方式が混在することもあります。更新後、v2rayNは各項目を独立したノードとして解析します。正しい方法は項目ごとに確認することであり、グループ名だけを見て全ノードに同じ互換性の結論を当てはめることではありません。
VLESSリンクでは、security、flow、type、sni、fp、公鍵、ショートIDを重点的に確認します。VMessノードでは、サーバーアドレス、ポート、UUID、トランスポート方式、Host、パス、TLSの有効化状態を確認します。最新のVMess設定では通常 alterId: 0 を使用します。古いバックアップからインポートする際に古いパラメータが残っている場合は、サーバーの現在の設定を優先してください。
推奨構成：ノードの世代に応じて2つの検証経路を残す
新しいノードと主力サブスクリプション
- v2rayNでXrayコアを使用
- VLESS、REALITY、Visionの項目を優先してテスト
- サブスクリプション更新後にノードのフィールドを再確認
既存設定と互換性の検証
- 動作確認済みのV2Fly設定を保持
- 同じVMessノードで接続結果を比較
- 移行前に現在のクライアント設定をエクスポート
2つの経路は設定の互換性問題を切り分けるために使います。2つのコアを同じローカルポートで同時に待ち受けさせることは避けてください。
- v2rayNのノード一覧で対象ノードを選択し、編集画面を開いて、プロトコル、ポート、トランスポート、セキュリティ種別、flowを記録します。
- 「設定」→「パラメータ設定」を開き、コア関連の項目を確認します。v2rayNのバージョンによってラベル名が多少異なる場合があるため、現在の画面表示を基準にしてください。
- Xrayを選択したら対象ノードを再起動し、ログ画面で実際にXrayが起動していることを確認します。表示上のグループだけを変更した状態になっていないかにも注意してください。
- 実際の接続による遅延テストを行います。遅延が表示されても、接続処理が成功したことを示すだけで、ダウンロード速度が必ず向上するわけではありません。
- V2Flyへ切り替えた後に未知のフィールド、設定解析エラー、コアの即時終了が発生した場合は、Xrayに戻し、ノードにREALITYまたはVisionのパラメータが含まれていないか確認してください。
性能差は同じノード・同じ時間帯で比較する
コア選びでは、まず互換性を確認し、性能はその次に検討します。ノード、データセンター、時間帯が異なる結果を、そのままコアの違いに帰することはできません。変数を減らすため、同じサーバー、同じプロトコル、同じルーティングモード、同じテスト対象を使い、クライアントのコアだけを交換します。テスト前に実行中のダウンロードを停止し、システム上で別のプロキシプログラムが待ち受けポートを使用していないことも確認してください。
あるLAN環境では、Windowsデスクトップ版、ローカルSOCKSポート10808、同じ1 Gbps接続サーバーを使い、3ラウンドずつテストしました。VMess + WebSocket + TLSの実接続遅延中央値は、Xray 25.3.6で86 ms、V2Fly 5.28.0で89 msでした。シングルスレッドのダウンロード速度はそれぞれ92 Mbpsと89 Mbpsです。差は約3%にすぎず、回線の一時的な揺らぎだけで埋まる可能性があるため、どちらかのコアが常に速いとは判断できません。
REALITY + Visionノードは、主要機能が同等ではないため、V2Flyで同条件の比較を行えません。この場合はXrayの異なるバージョン間で比較するか、サーバーが別途提供するVMess、標準TLSノードと比較します。比較時はルーティング規則も統一してください。一方がプロキシ経由、もう一方がドメイン規則によってダイレクト接続になっている場合、結果に意味はありません。
テスト記録の例
クライアント：v2rayN
ローカル入口：SOCKS 127.0.0.1:10808
リモートポート：443
ルーティングモード：グローバルプロキシ
テスト回数：3
記録項目：コアのバージョン、実接続遅延、シングルスレッドのダウンロード速度、コアログのエラー結論：10%未満の単発差は、まず回線の揺らぎとみなす
同じノードで複数回連続して安定した差が出て、ログ、ルーティング、ローカル負荷も一致している場合に限り、コアの実装を詳しく分析する価値があります。ノードの混雑、ネットワーク間の経路、サーバー負荷は、通常コアの差より大きな影響を及ぼします。
V2FlyからXrayへ切り替える手順
コアを切り替えても、ノードのパラメータが自動修正されるわけではありません。古いVMessノードはそのまま検証できることが多い一方、手書きのJSON、古いサブスクリプションキャッシュ、カスタムルーティング規則は個別に確認する必要があります。作業前に現在利用できるノードとコアのバージョンを記録し、切り替え後に設定変更、サブスクリプション更新、コア変更のどれが原因か分からなくなる事態を避けてください。
- 現状を保存：現在のノードをエクスポートするか、v2rayNの設定フォルダーをバックアップします。使用中のノード名、システムプロキシモード、ローカルポートも控えておきます。
- コアを更新：v2rayNに用意されたコア管理画面から更新し、古いコアのプロセスを終了してから新しいコアを起動します。
- 待ち受けを確認：10808などのローカルポートが古いプロセスに占有されていないことを確認します。ログにaddress already in useと表示された場合は、接続ボタンを何度も押すのではなく、まず占有しているプロセスを終了してください。
- サブスクリプションを更新：対象のサブスクリプションを更新し、クライアントにノードのフィールドを再解析させます。REALITYノードでは、公鍵、ショートID、SNI、fingerprintがすべて揃っているか確認します。
- 1つずつ検証：まず動作確認済みのVMessノードをテストし、その後VLESS + REALITYノードをテストします。これにより、基本的なネットワーク障害と特定プロトコルの障害を切り分けられます。
- ルーティングを戻す：接続に成功してから既存の分割ルールを有効にし、DNS、ダイレクト接続用ドメイン、プロキシ用ドメインが想定どおり処理されるか確認します。
V2Flyへ戻す場合は、まずREALITYやXTLS Visionに依存するノードを削除するか無効にします。設定から未知のフィールドだけを削除して無理に起動しないでください。security、flow、公鍵を削除しても、元のノードが標準TLSノードへ変換されるわけではありません。クライアント設定はサーバーの待ち受け方式と一致している必要があり、プロトコル変換にはサーバー側にも対応する入口が必要です。
よくある互換性問題と対処方法
エラー調査はコアのログから始めます。画面に「接続失敗」と表示されても、プロセスの起動、設定解析、DNS、TCP接続、セキュアハンドシェイクのどこかが完了しなかったことしか分かりません。ログに出るunknown field、failed to build config、connection refused、timeout、address already in useはそれぞれ確認すべき方向が異なるため、すべてを「ノードが無効」として扱わないでください。
REALITYノードのインポートには成功したのに、接続するとすぐ終了するのはなぜ？
まずログで実際に起動したコアの名称とバージョンを確認し、次にノードに公鍵、ショートID、SNI、fingerprint、xtls-rprx-visionが含まれているか確認します。V2Flyを使用している場合は、Xrayへ切り替えてノードを再起動してください。
VMessノードはどちらのコアでも接続できる。どちらを残すべき？
ルーティング、DNS、テスト時間を揃え、実接続遅延とダウンロードテストをそれぞれ3回行います。差が10%未満なら、まず現在の安定した設定を残してください。サブスクリプションにREALITYノードも含まれている場合は、切り替え回数を減らすためXrayに統一するとよいでしょう。
コア切り替え後に10808ポートが使用中と表示される？
現在の接続を切断して残っているコアのプロセスを終了し、「設定」→「パラメータ設定」でローカル待ち受けポートを確認します。XrayとV2Flyを同時に127.0.0.1:10808で待ち受けさせないでください。
サブスクリプション更新後に以前のノードフィールドが変わった？
サブスクリプションを更新すると、サーバー側の現在の内容に基づいて項目が再構築されます。まずプロトコル、ポート、トランスポート、セキュリティ層を照合してください。サーバー側がVMessからVLESS + REALITYへ変更されている場合はXrayを使用し、新しく配布された公鍵とショートIDを基準にします。
ノードの遅延は測定できるのに、ブラウザーでWebページを開けない？
システムプロキシが有効か、ブラウザーがシステムプロキシを使用しているか、ルーティング規則が対象ドメインをプロキシのアウトバウンドへ送っているかを確認します。その後DNSログを確認し、誤ったダイレクト接続ルールに名前解決を処理されていないか確認してください。
最終判断：新しいプロトコルはXray、安定した古い設定は必要に応じてV2Flyを維持
v2rayNを使う多くのデスクトップ環境では、Xrayをデフォルトコアにするのが適しています。すべてのノードで速度が向上するからではなく、VMessなどの一般的な設定に加えて、VLESS、REALITY、XTLS Visionノードにも対応できるためです。サブスクリプションに複数のプロトコルが混在する場合、Xrayに統一するとコア切り替えによる操作漏れを減らせます。
V2Flyは、その設定構造に明確に依存する構成、長期間検証済みのVMessノード、既存の自動化設定に適しています。サーバーとクライアントのバージョンが一致していれば、一般的なWebSocket、TLS、TCP、ルーティング機能は引き続き利用できます。名称が新しくなったという理由だけで安定した設定を変更する必要はありませんが、新たにREALITYノードを追加する場合は、Xrayで独立した検証経路を用意してください。
- ノードに
security=realityが含まれる：Xrayを選択。 - ノードに
flow=xtls-rprx-visionが含まれる：Xrayを選択。 - VMess + WebSocket + TLS：通常はどちらも利用できるため、現在の安定性とログ結果で選択します。
- 手書きのV2Fly JSON：まずフィールドを確認し、移行するか判断します。実行するコアをそのまま置き換えないでください。
- 同じサブスクリプションに新旧プロトコルが混在：頻繁なコア切り替えを避け、Xrayで項目ごとに検証することを優先します。
- 切り替え後に起動できない：まず設定解析とポート占有を確認し、その後リモートネットワークを確認します。