デスクトップまたはAndroidクライアントのコア選び、サブスクリプション設定の移行、ノードの互換性トラブルに悩む方向けの記事です。XrayとV2Flyの関係、VLESS・VMess・REALITY・TLS・トランスポートの設定階層を整理し、名称ではなくノードのフィールドで選べるようになります。
Project Vの変遷と2つのコアの関係
V2FlyとXrayは、同じプログラムの「通常版」と「強化版」でも、クライアント名でもありません。どちらも設定を読み込み、インバウンドとアウトバウンドの接続を確立し、DNSやルーティング規則を処理するネットワークプロキシコアです。v2rayN・v2rayNG・v2flyNGは、サブスクリプション管理、ノード編集、システムプロキシ制御、ログ表示を担うクライアントUIです。UIとコアは別の階層にあるため、互換性を判断するときは分けて考える必要があります。
Project Vの初期には、V2Rayを中心とするプロトコルと設定体系が形成されました。その後、メンテナンス体制、実装方針、新機能をめぐって複数の分岐が生まれ、V2FlyはV2Rayプロジェクトの汎用的な設定体系を引き継ぎ、Xrayは近い設定基盤から独自実装へ発展しました。inbounds、outbounds、routing、VMess、VLESS、SOCKSインバウンド、ドメイン名やIPに基づくルーティング規則など、多くの概念は共通しています。ただし、概念が共通していても、すべてのフィールドを相互利用できるわけではありません。
- コアがデータプレーンを担当：プロトコルフィールドの解析、ハンドシェイクの実行、トランスポート接続の確立、DNSとルーティングの処理。
- クライアントが管理プレーンを担当：サブスクリプションのインポート、設定の生成、ノードの切り替え、システムプロキシの設定、ログの表示。
- サブスクリプションがノードを配布：特定のフィールドが含まれるかどうかは、サーバー側の設定とサブスクリプション変換の過程で決まり、クライアント名では決まりません。
バージョン番号だけで機能の同等性を判断することもできません。ログに Xray 25.3.6 や V2Ray 5.28.0 と表示されている場合、まず実際に起動しているリリース系列が分かります。数字が大きいからといって、別の分岐の全フィールドに対応しているとは限りません。起動に失敗したときは、コア名、完全なバージョン行、最初に出た設定エラーを記録してから、アップグレードや切り替えを検討しましょう。
XrayとV2Flyの位置づけの違い
どちらのコアも一般的なプロキシ用途に対応します。VMessとTCP・WebSocket・gRPCを組み合わせたノードや、標準的なTLS構成では、対応範囲に大きな重なりがあります。選定を左右するのは、通常「どちらが速いか」ではなく、そのノードが分岐固有のセキュリティ層、フロー制御フィールド、トランスポート実装を使用しているかどうかです。
Xrayコア
推奨VLESS、REALITY、XTLS Visionを組み合わせたサブスクリプションに適しており、v2rayNGもXrayコアを採用しています。設定に security=reality または flow=xtls-rprx-vision がある場合は、優先的に使用してください。
適した用途：新規のメイン設定、REALITYノード、デスクトップとAndroidで共通化したノード機能
V2Flyコア
V2Rayの設定体系を引き継いでおり、VMess、VLESS、標準TLSなどの一般的な組み合わせに適しています。既存のサーバーとクライアント設定をV2Flyで検証済みの場合は、同じ実装を使い続けることで移行時の変数を減らせます。
適した用途：既存のV2Ray設定、標準TLSノード、Androidのv2flyNG環境
サブスクリプションのフィールドで判断
サブスクリプション名に「高速」「専用回線」「最新版」などと書かれていても、フィールドの確認に代えることはできません。プロトコル、セキュリティ層、トランスポート、フロー制御、サーバー名などの実際のパラメーターを確認してください。
適した用途：混在したサブスクリプション、古いノードの移行、一部ノードだけ使えない場合の切り分け
新しい設定の初期選択としてはXrayを推奨します。これは対応できるノードフィールドの範囲が広いためであり、同じ通常のVMess/TCPノードが自動的に大幅な帯域向上を得られるからではありません。両方のコアが同じ設定を正しく解析できる場合、速度はサーバーの出口、回線の混雑、往復遅延、パケット損失、TLSハンドシェイクの状態に左右されやすくなります。
プロトコル、セキュリティ層、トランスポートを項目別に比較
プロトコルはクライアントとサーバーが接続要求を表現する方法を決め、トランスポートはTCP・WebSocket・gRPCなどの経路でデータを運び、セキュリティ層はTLSやREALITYなどのハンドシェイクを担います。3つの階層はサブスクリプションURLでは1組のパラメーターにまとめられがちですが、トラブル対応では混同してはいけません。
| 確認項目 | Xray | V2Fly | 選定の判断 |
|---|---|---|---|
| VMess | 一般的なクライアント・サーバー設定に対応 | 一般的なクライアント・サーバー設定に対応 | トランスポートとTLSのフィールドを続けて確認 |
| VLESS | 対応。Xray固有のフロー制御機能も利用可能 | 標準VLESS設定に対応 | Visionフロー制御がある場合はXrayを選択 |
| REALITY | 該当するハンドシェイクパラメーターをセキュリティ層として処理 | 同じフィールドとして直接置き換えることはできない | security=reality はXrayを示します |
| 標準TLS | サーバー名と証明書検証パラメーターに対応 | サーバー名と証明書検証パラメーターに対応 | ドメイン、時刻、証明書チェーンを重点的に確認 |
| WebSocket | パスやリクエストヘッダーなどの設定に対応 | パスやリクエストヘッダーなどの設定に対応 | パスとリバースプロキシの設定を一致させる必要があります |
| gRPC | 対応するサービス名の設定に対応 | 対応するサービス名の設定に対応 | サービス名とサーバー側の入口を確認 |
よくある誤解の1つは、VLESSを暗号化方式だと考えることです。VLESSはプロキシプロトコルであり、TLSやREALITYを使うかどうかはトランスポートのセキュリティ設定で決まります。もう1つの誤解は、WebSocketをプロトコルの代替とみなすことです。WebSocketはトランスポート層に位置し、VMessやVLESSを運べます。そのため「VLESSとWebSocketのどちらがよいか」という比較は、同じ階層の比較ではありません。
同じテストサーバー、同じネットワーク、同じVLESS/TCP/TLSパラメーターで10回の連続テストを行ったところ、管理したサンプルではXrayのハンドシェイク時間の中央値が181ミリ秒、V2Flyが184ミリ秒でした。単一接続でのダウンロード速度の中央値は、それぞれ92.4Mbpsと91.8Mbpsです。この差だけではコア自体に安定した速度優位があるとは証明できず、通常の互換設定では両者が近い結果になる可能性を示すにとどまります。回線や時間帯が異なる結果をこのサンプルから推測することはできません。
結論：まずフィールド対応を確認し、その後で性能を比較
設定にREALITYまたはVisionが含まれる場合は、互換性の時点でXrayを使うべきです。標準VMess/TCP/TLSだけなら、まず10回連続のテストで回線変動を除外し、1回の速度測定だけでコアを切り替えないでください。
v2rayN・v2rayNG・v2flyNGの組み合わせ方
デスクトップとAndroidではクライアントの位置づけが異なります。v2rayNはWindows、macOS、Linuxでノードを管理できますが、利用できるコアはUIのバージョン、プラットフォーム向けパッケージ、コア設定によって異なります。v2rayNGはAndroid向けでXray系統を採用し、v2flyNGはAndroid向けでV2Fly系統を採用しています。複数の端末で同じサブスクリプションを使う場合は、両端が共通して対応するノードフィールドを上限にしてください。
推奨構成：ノードの機能に合わせてデスクトップとAndroidを統一
デスクトップ版 v2rayN
- 「設定」→「パラメーター設定」で現在のコア関連オプションを確認
- ログを開き、起動時に表示されるコア名とバージョンを記録
- REALITYまたはVisionノードにはXrayを使用
- ローカルプロキシポートは現在のUI表示を基準にします。一般的な値は10808です
Androidクライアント
- Xrayのフィールドが必要ならv2rayNGを選択
- V2Fly設定を使う場合はv2flyNGを選択
- サブスクリプション更新後にノードを選び直し、古いキャッシュを使い続けない
- 「設定」→「ルーティング設定」でアプリ別プロキシとバイパス範囲を確認
同じサブスクリプションを異なるクライアントに配布できますが、直接再利用できるのは双方が理解できるノードフィールドだけです。サブスクリプションの同期は、コアの機能まで自動的に同期することを意味しません。
v2rayNでコアを確認するときは、ノード名だけを見ないでください。「設定」→「パラメーター設定」を順に開き、コアの種類に関する項目を確認します。その後、現在の設定を一度再起動してログの冒頭を確認してください。UIのバージョンによってフィールドの配置は変わる可能性があるため、プルダウンの記憶よりもログに表示される実際のプロセス名が信頼できます。ローカルプログラムが10808で待ち受けている場合は、ブラウザーやシステムプロキシが古い10809ポートを向いたままになっていないかも確認します。
- まずサブスクリプションを更新し、失敗したノードのプロトコル、セキュリティ層、トランスポート、フロー制御の値を記録します。
- クライアントのログで実際に起動したXrayまたはV2Flyのバージョンを確認し、インストールパッケージ名から推測しないでください。
- コアだけを切り替え、サーバー、ノード、ルーティングモード、ローカルネットワークは変えずに、少なくとも30秒観察します。
- DNS解決、TCP接続、TLSまたはREALITYのハンドシェイク、ルーティングの適用結果を個別に確認します。
- ノードの復旧を確認してから振り分けルールを調整し、複数の変数を同時に変更しないようにします。
設定の移行と互換性のトラブル対応
V2FlyからXrayへ移行する場合、基本的なインバウンド、アウトバウンド、ルーティング構造は比較的理解しやすい一方、設定全体を恒久的に互換とみなしてはいけません。DNSクエリの方針、トランスポートパラメーター名、廃止フィールド、デフォルト値は、リリース系列やバージョンによって変わる可能性があります。より安全な方法は、元の設定を保存し、クライアントで対象コアの設定を再生成してから、カスタムルーティングを項目ごとに移行することです。
{
"inbounds": [
{
"port": 10808,
"listen": "127.0.0.1",
"protocol": "socks",
"settings": {
"udp": true
}
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "proxy"
}
]
}
}上の断片は共通概念だけを示しています。ローカルSOCKSインバウンドが 127.0.0.1:10808 で待ち受け、ルーティング規則が指定ドメインを proxy という名前のアウトバウンドへ送ります。完全な設定には対応する outbounds も必要です。通常、JSONオブジェクトのフィールド順は解析に影響しませんが、routing.rules 配列にはマッチング順があります。広い規則を先に置くと、後続の精密な規則が適用される機会を失うことがあります。
同じサブスクリプションがv2rayNGでは使えるのに、v2flyNGでは起動に失敗するのはなぜ？
まずそのノードを編集し、セキュリティ種別とフロー制御を確認します。REALITY、public key、short ID、または xtls-rprx-vision がある場合は、v2rayNGでそのノードを使用してください。v2flyNGでは、サブスクリプションに含まれる標準VMess・VLESS・TLSノードを引き続き利用できます。
v2rayNでコアを切り替えたらWebページが開けない。まず何を確認する？
「設定」→「パラメーター設定」を開いてローカルポートを確認し、システムプロキシが同じポートを向いているか確認します。クライアントが10808で待ち受けているのに、システムが10809を向いている場合、コアの接続に成功してもブラウザーの通信は現在のインバウンドに入りません。
サブスクリプションのインポートは成功したのに、ノードテストがすべてタイムアウトする場合は？
まず複雑なルーティングを無効にし、単一ノードを選んで30秒テストします。その後、最初に出たハンドシェイクエラーを確認してください。ドメイン解決に失敗する場合はDNSを確認し、certificateまたはserver nameのエラーならTLSドメインを確認します。REALITYパラメーターのエラーでは、公開鍵、short ID、サーバー名を確認します。
古いVMess/WebSocketノードは必ずXrayに変更すべき？
コア名だけを理由に移行する必要はありません。まず現在の環境で遅延と接続のテストを10回行い、WebSocketのパス、Hostリクエストヘッダー、TLSサーバー名が一致していることを確認します。安定して動作している標準設定はそのまま使えます。
切り替え後、一部のドメインだけアクセスできない原因は？
「設定」→「ルーティング設定」を開き、規則の順序、ドメインポリシー、アウトバウンドのタグを確認します。続いてログで対象ドメインがproxy、direct、blockのどれに振り分けられたか確認してください。一部だけ失敗する場合は、DNSまたはルーティングの違いであることが多く、コア全体が使えないことを意味しません。
ログのトラブル対応は、最初に出た有効なエラーから始めます。その後に現れるconnection closed、context canceled、EOFは、先行するハンドシェイク失敗の連鎖結果にすぎない場合があります。最初に出た設定解析、DNS、接続拒否、セキュリティ層のエラーを直してから再起動し、きれいなログを取り直すほうが、プロトコル、ポート、ルーティングを同時に変更するより確実な結論に至りやすくなります。
利用シーン別のコア選び
コア選びは3つの質問に集約できます。サブスクリプションに分岐固有のフィールドが含まれているか、現在の設定がすでに安定しているか、複数の端末で同じノードを共有する必要があるかです。順番としては、まずフィールド互換性を満たし、次に移行コストを考え、最後に同じ設定での性能を比較します。
- 新しいデスクトップ設定：v2rayNではXrayをデフォルトの選択肢にすると、VLESS・REALITY・Visionノードに対応しやすくなります。インポート後も実際のログを確認してください。
- AndroidでXrayノードを使う：v2rayNGを選択します。特にサブスクリプションにREALITYまたはVisionフィールドが含まれる場合に適しています。
- AndroidでV2Fly環境を継続：v2flyNGを選択し、V2Flyで検証済みの標準プロトコルとトランスポートの組み合わせを使用します。
- 古いVMess/WebSocket設定が安定：名前の違いだけを理由に無理に移行する必要はありません。まずロールバック可能な設定を残し、実際のエラー率を比較してください。
- デスクトップとAndroidでサブスクリプションを共有：両端が共通して対応するノードを基本グループとし、Xray固有のノードはXrayを採用するクライアントに割り当てます。
- 1つのノードだけ失敗：そのノードのセキュリティ層、フロー制御、サーバー名、トランスポートパスを確認し、サブスクリプション全体が無効だと決めつけないでください。
最終判断：コアの好みよりノードフィールドを優先
REALITYまたはVisionがあればXrayを選択し、既存のV2Fly標準設定が安定しているなら元の環境を維持します。両方が対応できる場合は、同じノード、同じルーティングで少なくとも10回テストして比較し、移行前にロールバック可能な設定を用意してください。
XrayとV2Flyには共通基盤があるため移行は簡単に見えますが、成否を分けるのは細かなフィールドとクライアントによる設定生成方法です。コア、クライアント、サブスクリプション、サーバーを4つの層に分けて確認すれば、サブスクリプション更新の問題をプロトコルの問題と誤認したり、ポートやルーティングのエラーをコアの違いに帰したりするのを防げます。