ノードのプロトコル、トランスポート、セキュリティ層、flowを確認してからコアを選びましょう。REALITYやXTLS Visionが必要なら、対応するXrayを選択します。VMess、WebSocket、TLSのノードは、実際の設定を見て互換性を確認してください。この記事では、PC・Androidでの選び方、JSON移行時の注意点、切り替え後につながらない場合の確認手順を解説します。
クライアント・コア・ノードのプロトコルを区別する
v2rayN、v2rayNG、v2flyNGはクライアントで、サブスクリプションの管理や設定編集、ログ表示、接続の切り替えを行います。コアはプロキシ接続の確立、ルーティングルールの実行、通信の処理を担います。ノード一覧に表示されるVMessやVLESSはプロトコル名であり、クライアント名ではありません。クライアントの画面を別のものに変えても、サーバーが受け付けるプロトコルは自動では変わりません。
V2FlyコミュニティはV2Rayプロジェクトを保守しており、この記事ではその実装を「V2Flyコア」と呼びます。XrayはV2Rayプロジェクトから派生した、独立したコアです。両者には共通の歴史がありますが、現在は「同じプログラムの別名」として扱うことはできません。プロトコルの拡張、設定項目、バージョンの進化には違いが生じる場合があります。
- PC：v2rayNでノードを管理し、設定したコアを呼び出します。画面で項目を入力できても、実行中のコアがその項目を受け付けるとは限りません。
- Android：v2rayNGはXrayコアを、v2flyNGはV2Flyコアを使用します。ノードの要件に合わせてアプリを選び、同じアプリでコアだけを自由に切り替えられると考えないでください。
- サーバー：プロトコル、待ち受けポート、認証情報、トランスポート、セキュリティ層を決定します。クライアント側の設定はこれらに合わせる必要があります。
プロトコル対応：VLESSとREALITY、XTLSとTLSは別物
コアを比較するときに混同しやすいのが、プロトコルとセキュリティ層です。VLESSはプロキシのプロトコル層、TCPやWebSocketなどはトランスポートの選択肢です。TLSやREALITYは接続のセキュリティに関する設定で、xtls-rprx-visionは対応する実装が必要なflowの値です。ノード設定を正しく理解するには、これらの層を分けて確認する必要があります。
| 設定機能 | Xrayコア | V2Flyコア | 選び方のポイント |
|---|---|---|---|
| VMess | 一般的な設定の組み合わせに対応 | 一般的な設定の組み合わせに対応 | トランスポート、TLS、サーバー設定も確認 |
| 基本的なVLESS | 対応 | 該当する実装あり。バージョンと設定形式の確認が必要 | 「VLESS対応」だけで、すべての拡張機能に対応するとは限らない |
| XTLS Vision | 該当機能に対応したバージョンで使用 | XrayのVision設定をそのまま置き換えることはできない | xtls-rprx-visionが指定されている場合は、対応するXrayを選ぶ |
| REALITY | 該当機能に対応したバージョンで使用 | XrayのREALITYノード設定とは直接互換性がない | 公開鍵、serverName、shortIdなどの設定を一致させる |
| WebSocket + TLS | 一般的な組み合わせに対応 | 一般的な組み合わせに対応 | Host、パス、SNI、証明書検証を確認 |
基本的なVLESS自体には通信の暗号化機能がありません。VLESSと書かれているからといってセキュリティ層の設定を省略しないでください。また、互換性を確保するためにREALITYをTLSへ変更することもできません。サーバーがREALITYを要求する場合、クライアントは対応する実装を使い、サーバーから指定されたパラメーターを設定する必要があります。
XTLSの旧式設定と、現在のVision設定も混在させないでください。古い解説にあるflowの値、トランスポート名、セキュリティ項目は、現行バージョンでは使えない場合があります。移行時はノード提供元の最新の設定一式とコアのログを確認し、名前が似ているから置き換えられると判断しないでください。
クライアントの選び方：ノードに合わせてXrayかV2Flyを選択
以下の推奨は「REALITYまたはVisionが必要な場合」に限ったものです。すべての回線やハードウェアで、特定のコアが常に高速という意味ではありません。サーバー側ですでに動作確認済みのV2Fly設定があり、新機能も必要ないなら、コアをすぐに置き換えるより、現在の構成を維持するほうが変更点を管理しやすくなります。
Xrayコア
おすすめノードがREALITYやXTLS Visionなどの機能を明示的に要求する場合に使用します。PCではv2rayNで対象プロトコルのコア設定を確認します。Androidではv2rayNGを選び、内蔵コアのバージョンがノードのパラメーターに対応していることを確認してください。
適したノード：VLESS + REALITY、Visionの指定があるノード
V2Flyコア
V2Flyの設定形式で構築・検証済みの接続に使用します。一般的なVMess、WebSocket、TLSの組み合わせはサーバーの設定を確認すればよく、サブスクリプション名が変わっただけで移行する必要はありません。
適したケース：既存のV2Fly設定、一般的なプロトコルとトランスポートの組み合わせ
- 設定項目を確認：ノードの編集画面を開き、
security=realityまたはflow=xtls-rprx-visionが設定されているか確認します。該当する場合は、まずXrayの設定として扱ってください。 - PCの設定を確認：v2rayNの「設定」→「パラメーター設定」を開き、使用中のバージョンにあるコア関連の項目を確認します。プロトコルごとにコアを指定できる場合は、対象ノードのプロトコルに割り当てられたコアも確認してください。画面のバージョンによって項目の場所が異なる場合があります。
- 実行結果を確認：ノードを保存してアクティブサーバーに設定し、ログでコア名、バージョン、起動エラーを確認します。設定画面の選択結果だけで判断しないでください。
- Androidアプリを確認：v2rayNGまたはv2flyNGのノード一覧で対象ノードを長押しし、編集画面で設定を確認します。必要な項目をアプリで設定できない場合は、項目を削除せず、要件に合ったクライアントに切り替えてください。
設定の互換性：共有リンクを読み込めても、JSONをそのまま流用できるとは限らない
サブスクリプションのインポートと、設定全体の移行は別の作業です。共有リンクに含まれるのは通常、特定のアウトバウンドノードの情報だけです。クライアントはリンクを解析した後、ローカルのインバウンド、DNS、ルーティングなども設定します。一方、JSON全体には特定のコア向けの拡張項目が含まれる場合があります。同じVMessリンクを両方のクライアントで読み込めても、設定全体のJSONをそのまま置き換えて使えるとは限りません。
移行方法：ノード設定と実行設定全体を分けて考える
ノードリンク・サブスクリプション
- 元のアドレスと接続情報を保持する。
- 再インポート後、プロトコル、ポート、セキュリティ層を確認する。
- クライアントが未知の項目を無視していないか確認する。
- ローカルの待ち受け設定とルーティングは、新しいクライアントで個別に設定する。
JSON設定全体
- 元の設定をバックアップし、独立したテスト用コピーを作成する。
- inbounds、outbounds、routingを項目ごとに確認する。
- DNSの形式、タグの参照先、拡張項目を確認する。
- 対象のコアが設定形式に対応していることを確認してから起動する。
まず確認できるノード設定から移行します。設定全体は対象のコアで改めて検証し、プログラムのファイル名を変えるだけで済ませないでください。
たとえば、次の3項目はXrayのREALITYおよびVision設定で使われるものです。識別方法の例であり、実行可能な設定ではありません。これらを組み合わせてノード設定を作成しないでください。
"protocol": "vless"
"security": "reality"
"flow": "xtls-rprx-vision"移行に失敗したら、まず「設定の解析エラー」と「リモートとのハンドシェイク失敗」を切り分けます。未知の項目、未知のセキュリティタイプ、未対応のflowがログに出る場合、問題はまだローカルの設定段階にあります。起動できてもハンドシェイクに失敗する場合は、アドレス、ポート、認証情報、セキュリティ層、システム時刻を確認してください。証明書検証を無効にしてエラーの原因を回避しようとしないでください。
性能の考え方：同じ条件でテストし、コア名だけで順位を決めない
XrayのVisionは、特定のTLSトラフィック処理経路を最適化しています。ただし、すべてのプロトコルや負荷で同じ効果が得られるわけではありません。回線の混雑、サーバー負荷、トランスポートのカプセル化、端末のCPU、ネットワークの切り替えなどは、コアの違いより大きく影響する場合があります。異なるノード同士の遅延を比べても、コアの性能は判断できません。
まずテスト条件をそろえます。以下はトラブルシューティングに使えるポート番号の例であり、クライアントの初期値ではありません。実際の値は設定画面と起動ログで確認してください。接続先のポートが443でも、通常のTLSサービスとは限りません。
- 接続条件をそろえる：同じ端末、ネットワーク、サーバーを使い、双方が対応する同じプロトコル構成でコアを比較します。一方だけWebSocketを使うなど、トランスポートを変えないでください。
- 負荷をそろえる：各条件で3回テストし、同じテストデータを毎回30秒間ダウンロードして、スループットの中央値、CPU使用率、エラー回数を記録します。ここで示すのはテスト方法であり、本サイトの実測値ではありません。
- 指標を分ける：TCPハンドシェイクの遅延は接続先までの応答を示す指標です。実際の接続テストには接続先サイトやセキュリティハンドシェイクも影響します。継続的な転送性能を見るには、ダウンロードスループットがより参考になります。
- バックグラウンド処理を止める：サブスクリプションの自動更新やほかのダウンロードを一時停止します。Androidでは電源モードをそろえ、システムの周波数制限をコアの差と誤認しないようにしてください。
REALITYノードしか使えない場合、「同じプロトコルのままV2Flyに切り替える」という比較条件は成立しません。この場合はサーバー側のプロトコルを変えるのではなく、現在の端末でのXrayの接続安定性とリソース使用量を評価してください。
切り替え後の確認：まずコアの起動、次にルーティングとDNSを確認
コアが正常に起動しても、アプリの通信がプロキシを通っているとは限りません。PCのシステムプロキシが影響するのは、その設定に従うアプリだけです。AndroidではVPN接続と対象アプリの設定によって、プロキシ経由になるアプリが決まります。コアを切り替えると同時にルーティング、DNS、プロキシモードまで変えると、問題を再現しにくくなります。一度に変更する項目は一つにしましょう。
- 起動ログを確認：まず設定の解析エラーと
address already in useを確認します。例のポート10808が古いプロセスに使用されている場合は、古いプロセスを停止してから新しい設定を起動してください。 - 通信の入口を確認：PCではシステムプロキシまたはアプリの手動プロキシ設定を確認します。AndroidではVPNの使用が許可されていることと、テスト対象のアプリがアプリ別設定に含まれていることを確認してください。
- ルーティングタグを確認：カスタム設定で参照しているアウトバウンドタグが存在するか確認します。移行後もルールが古いタグを参照していると、起動に失敗したり、通信が意図しない経路に振り分けられたりする場合があります。
- DNSを確認：名前解決サーバーへの通信経路と、ドメインルールと名前解決方針の関係を確認します。DNSの問い合わせ失敗をVMessやVLESSの問題と決めつけないでください。
- 単一ノードで再テスト：自動選択や複雑なルーティングを一時的に無効にし、明示したプロキシ経由で固定の接続先にアクセスします。動作を確認してから、ルーティングルールを一つずつ戻してください。
ドメイン、IP、アウトバウンドルールの関係を確認するには、プロトコル解説のルーティング説明をご覧ください。プロキシの入口を設定し直す場合は、入門ガイドに沿ってクライアントを設定してください。実行設定全体をそのまま上書きしないでください。
よくある質問：サブスクリプション、ハンドシェイク、Androidアプリの選び方
同じサブスクリプションなのに、v2rayNGでは使えてv2flyNGでは使えないのはなぜ？
まずノードの編集画面でセキュリティ層とflowを確認します。REALITYまたはVisionのノードには、それらに対応するv2rayNGを使用してください。両方が対応するVMess構成の場合は、インポート後のトランスポート、Host、パス、TLSの設定を比較し、起動ログも確認します。ノード数が同じだからといって設定も同じとは限りません。
VLESSをVMessに変更すれば、古い設定で接続できますか？
クライアント側のプロトコルだけを変更しても接続できません。プロトコルはサーバーのインバウンドとクライアントのアウトバウンドの両方で決まり、認証情報の形式も異なる場合があります。元の設定に戻し、VMessに明確に対応した個別の設定をノード提供元に確認してから、サブスクリプションで読み込むかノードを手動で追加してください。
クライアントを更新しても「flowに対応していない」と表示される場合は？
まず接続を停止して再起動し、ログに表示される実際のコアのバージョンを確認します。PCでは、v2rayNが対象プロトコルで古いコアファイルを呼び出していないか確認してください。Androidでは、使用中のアプリがノードの要件に合っているか確認します。その後、サーバーから指定されたflowの値と照らし合わせ、古い解説の設定を新しいノードに流用していないか確認してください。
REALITYの公開鍵を設定したのに、ハンドシェイクに失敗するのはなぜ？
アドレス、ポート、UUID、serverName、shortId、フィンガープリントの設定を確認し、空白が混入していないことや別のサーバーの情報を使っていないことを確かめます。端末の時刻を合わせてからログを確認してください。shortIdをむやみに空欄にしたり、設定の不一致を回避するためにセキュリティ層をTLSへ変更したりしないでください。
選び方は2段階です。まずクライアントとコアがノードのプロトコル要件を満たすことを確認し、次に同じ条件で接続と性能を検証します。REALITYやVisionはコアを選ぶ明確な根拠になります。一般的なVMessや基本的なVLESS設定では、コア名だけで決めず、トランスポート、セキュリティ層、設定形式も確認してください。