まずノードの要件を確認してから、使うコアを選びましょう。VLESS、XTLS Vision、REALITYを組み合わせる場合は、該当機能に対応したバージョンのXrayを選びます。VMess、WebSocket、TLSなどの設定では、両端のパラメーターを一つずつ照合してください。サブスクリプションを読み込み済みで、コアの互換性を確認したい方向けに、プロトコルの階層、Androidクライアントの選び方、コア変更後の確認手順を解説します。
クライアント、コア、Project Vの系統を区別する
まず、画面を操作するクライアントと接続処理を担うコアを分けて考えましょう。v2rayN、v2rayNG、v2flyNGはクライアントで、ノードの保存、サブスクリプショングループの管理、設定の生成、ログの表示を行います。コアは設定を読み込み、プロキシプロトコルやDNSクエリ、ルーティングを処理します。サブスクリプションのリンクをクライアントが認識できても、使用するコアがリンク内のすべてのパラメーターに対応しているとは限りません。
Project Vは、関連ツールやプロトコルを含むプロジェクト群です。その中のV2RayコアはV2Flyコミュニティがメンテナンスしています。Xray-coreは2020年にV2Rayから分岐し、その後は独立して開発されています。共通するプロトコルや設定の概念もありますが、新機能、フィールド形式、リリース時期は異なります。同じプログラムの別スキンと捉えたり、プロジェクトをまたいでバージョン番号の大小だけで機能を比較したりしないでください。
- v2rayN：デスクトップ向けクライアントです。現在のリリースで選択できるコアを確認し、インストール先にある実行ファイルの種類だけでなく、ノードが実際にどのコアを呼び出しているかを調べてください。
- v2rayNG：Android向けクライアントで、Xrayコアを使用します。新機能への対応状況は、クライアントに同梱されているコアのバージョンも確認してください。
- v2flyNG：Android向けクライアントで、V2Flyコアを使用します。V2Flyの設定形式やプロトコル機能に沿って構築・トラブル対処する場合に適しています。
VLESS、Vision、REALITYの役割を整理する
「VLESS + TCP + REALITY + Vision」は、連携して動作する設定の組み合わせであり、自由に置き換えられる4種類のプロトコル名ではありません。VLESSはプロキシプロトコル層、TCPは下位の通信方式、REALITYはセキュリティ層の方式、VisionはXrayのフロー制御方式です。異なる階層の機能を一つのスイッチのように扱うと、サブスクリプションの読み込みは成功しても、実際のハンドシェイクに失敗しやすくなります。
| 名称 | 主な役割 | 確認する項目 |
|---|---|---|
| VMess | 認証とデータ保護機能を備えたプロキシプロトコル | UUID、通信設定、サーバーとの互換性。現在の一般的な設定ではalterIdを0にする |
| VLESS | 軽量なプロキシプロトコル。プロトコル自体に通信の暗号化機能はない | UUID、暗号化フィールド、セキュリティ層、flow設定 |
| WebSocket | プロキシ通信を運ぶトランスポート方式 | パス、Host、リバースプロキシの設定、TLSを併用するかどうか |
| TLS | 証明書の検証などを通じて安全な接続を確立する | SNI、証明書のドメイン名、システム時刻、証明書チェーン |
| XTLS Vision | Xrayのフロー制御方式。特定の接続構成で使用 | xtls-rprx-vision、対応する通信方式、クライアントとサーバー双方の対応状況 |
| REALITY | Xrayが提供するセキュリティ層の方式 | サーバーの公開鍵パラメーター、serverName、shortId、クライアントフィンガープリントの設定 |
VLESSのencryption=noneは、接続全体が必ず平文で通信するという意味ではありません。通信が保護されるかどうかは、外側の層にTLSとREALITYのどちらを使うかで決まります。逆に、VLESSを設定しただけで接続が暗号化済みだと判断することもできません。サーバー側から指定された一式の設定を使い、UUIDだけをコピーしないようにしてください。
Visionは汎用的な「高速化ボタン」ではありません。利用できる通信方式や接続内容に条件があり、WebSocketノードだからといってflow=xtls-rprx-visionを追加できるわけではありません。REALITYとVisionは併用されることがありますが、同じ機能ではありません。片方を有効にしても、もう片方の設定が済んだことにはなりません。
XrayとV2Flyの対応範囲を確認する
コアを選ぶ際は、ノードで実際に使う機能ごとに対応状況を確認しましょう。VMessや一般的なWebSocket、TLSの設定は両プロジェクトで実装されていますが、設定ファイル全体をそのまま流用できるわけではありません。特にV2Flyの設定形式の違い、Xrayの拡張フィールド、新しい通信オプションは、利用するリリースでの対応状況を確認してください。
| ノードの要件 | Xrayコア | V2Flyコア | 選び方 |
|---|---|---|---|
| VMess | 対応 | 対応 | 認証、通信方式、セキュリティ層、バージョンの互換性を確認 |
| WebSocket + TLS | 一般的な構成に対応 | 一般的な構成に対応 | パス、Host、SNIなどのパラメーターを一致させる |
| 基本的なVLESS設定 | 対応 | 利用するリリースのプロトコル実装と設定形式を確認 | VLESSという名称だけでは、VisionやREALITYへの対応は判断できない |
| XTLS Vision | 該当機能に対応したバージョンを使用 | XrayのVisionフロー制御には非対応 | ノードで該当flowが必要な場合は、対応するXrayのバージョンを使用 |
| REALITY | 該当機能に対応したバージョンを使用 | XrayのREALITY設定には非対応 | フィールド名の変更だけでは、通常のTLS設定に変換できない |
基本的なVLESSの過去の実装やリリース間の違いを、「V2Flyのすべてのバージョンが対応」または「両プロジェクトのVLESSは完全に同じ」と単純化することはできません。実際の選定では、ノードがREALITYまたはxtls-rprx-visionを必要とするなら、V2Flyに該当フィールドを無視させようとせず、Xrayの対応範囲に合わせてクライアントとコアを選んでください。
Xrayコア
おすすめこの記事では、VLESS、Vision、REALITYの組み合わせを優先して解説しています。サーバーから指定されたセキュリティ層とflowのパラメーターを維持し、クライアントに内蔵されたバージョンが認識できることを確認してください。
適した環境：ノードでREALITYまたはXTLS Visionが明示的に必要な場合。
V2Flyコア
V2Flyの設定体系に沿って、動作確認済みのプロトコルと通信方式を使用します。VMessなどをすでに運用している場合は、互換性を確認しながら継続でき、系統名が異なるという理由だけで移行する必要はありません。
適した環境：サーバーがV2Fly形式の設定を提供し、Xray固有の機能に依存しない場合。
サブスクリプションの設定と接続ポートを確認する
サブスクリプションの更新で取得できるのはノード情報です。互換性のないプロトコルが変換されるわけではありません。VLESSノードを確認するときは、まずアドレス、ポート、UUIDを照合し、その後に通信方式、セキュリティ層、SNI、flowを確認してください。REALITYノードでは、サーバー指定の公開鍵パラメーター、shortId、クライアントフィンガープリントも一つずつ照合します。バージョンによってフィールド名が変更される場合があるため、現在のクライアント画面とコアのドキュメントを確認してください。
この2つのポートは別のものです。リモートポートはサーバーへの接続に使い、ローカルの待ち受けポートはブラウザーなどのプログラムから端末上のプロキシへ接続するために使います。リモート側の443をローカル側の10808に変更しても、接続失敗は解決しません。また、複数のローカルプロセスが同じ待ち受けポートを使用すると、コアが起動できないことがあります。数値は設定例であり、現在の端末の実値ではありません。
- 元のノード情報を保存する。変更前にサブスクリプショングループとノードのパラメーターを控えてください。tokenやUUIDを含むリンク全体を公開しないでください。
- セキュリティ層を照合する。サーバーがREALITYを要求する場合、クライアント側でTLSに変更しないでください。サーバーがTLSを要求する場合も、REALITYの公開鍵を独自に入力しないでください。
- フロー制御を照合する。サーバー設定で要求され、構成全体が対応している場合に限り、
xtls-rprx-visionを設定してください。 - 通信フィールドを照合する。WebSocketのパス例である
/example-wsは、サーバーで実際に指定された値に置き換えてください。この例をもとに、TCPノードへパスを追加しないでください。 - 実接続の遅延を測定する。測定時刻とログを記録してください。TCPingで確認できるのは接続先ポートへの到達性であり、認証やセキュリティハンドシェイクの成功までは確認できません。
デスクトップとAndroidで構成を選ぶ
デスクトップでは、まずv2rayNの現在のノードが使用しているコアを確認してからテストします。ローカルの待ち受けやプロキシ関連の設定を確認するには、「設定」→「パラメーター設定」を開いてください。項目の配置はリリースによって異なる場合があるため、実際の画面に従ってください。サブスクリプショングループは配信元の管理、サブスクリプションの更新はノード情報の再取得に使います。どちらもコアの切り替え操作ではありません。
構成例：ノードの特性に応じてクライアントを使い分ける
デスクトップ：v2rayN
- REALITYまたはVision対応ノードでは、互換性のあるXrayコアが実際に呼び出されていることを確認してください。
- 元のサブスクリプショングループを残し、同じノードで切り替え前後をテストしてください。
- まずコアの起動ログを確認し、その後にシステムプロキシとルーティングを確認してください。
Android：コアに応じて選ぶ
- Xrayの機能が必要な場合は、内蔵バージョンが要件を満たすv2rayNGを選んでください。
- V2Flyの設定で運用する場合は、v2flyNGを使い、フィールドの互換性を確認してください。
- サブスクリプションは各端末で更新してください。アプリごとのプロキシ設定と端末側のルールは、それぞれ別途設定が必要です。
同じサブスクリプションURLを使っても、端末間でローカル設定が同期されるわけではありません。両端のノードが一致するかどうかは、サブスクリプションの内容、解析機能、更新時刻によって決まります。
移行時にコア、DNS、ルーティング、プロキシモードを一度に変更しないでください。まずノードを固定したまま、新しいコアが起動し、実接続の遅延テストが完了することを確認します。その後、ルーティングを一項目ずつ戻してください。システムプロキシとAndroidの通信制御方式は異なるため、同じノードを使っていても、すべてのアプリの動作を直接比較することはできません。
ログから互換性エラーとネットワークエラーを見分ける
まず、どの階層で失敗しているかを確認します。設定の読み込み時にエラーが出る場合は、フィールドとコアを優先して確認してください。リモート接続がタイムアウトする場合は、アドレス、ポート、ネットワークを確認します。ハンドシェイクエラーが出たら、セキュリティ層のパラメーターを照合してください。エラーが出るたびにサブスクリプションを更新すると、変更前との比較条件が失われるうえ、根本原因の解決にもつながらないことがあります。
REALITYノードを読み込めるのに接続できないのはなぜ？
読み込みはクライアントがリンクを解析する処理であり、接続はコアが行います。まず起動ログでXrayのバージョンと実際の呼び出し先を確認し、サーバー指定の公開鍵パラメーター、serverName、shortId、フィンガープリントの設定を照合してください。最後に実接続の遅延テストを行います。ノードが一覧に表示されるかどうかだけで判断しないでください。
ログにunknown fieldと表示されます。その行を削除してもよいですか？
まず、その設定がどのプロジェクトのどの形式に属するかを確認してください。エラーになったフィールドがREALITYやVisionに使われている場合、削除すると接続の意味が変わるため、互換性を確保する方法にはなりません。そのフィールドに対応するコアのバージョンを使うか、サーバー側から別の完全互換なノード設定を提供してもらってください。
REALITYをTLSに変更すれば、別のコアでも使えますか？
クライアント側だけでは変更できません。2つのセキュリティ層では、ハンドシェイクとサーバー側の設定が異なります。サーバー側にTLSのインバウンドが別途設定され、対応するポート、証明書のドメイン名、認証情報が提供されている場合に限り、その設定で接続できます。
TCPingは成功するのに、実接続の遅延テストがタイムアウトします。まず何を確認すればよいですか？
まずUUID、flow、セキュリティ層、SNIを確認し、認証失敗やハンドシェイク失敗を示すログがないか調べてください。ノードの実接続テストは成功するのにブラウザーで失敗する場合は、システムプロキシ、ローカルポート、ルーティングルールを確認します。テスト対象に実際にアクセスできることも確認してください。
Xrayに切り替えると必ず速くなりますか？
コアの名称だけでは判断できません。同じネットワーク、同じサーバー、同じテスト対象を使い、実接続の遅延と実際のリクエスト結果をそれぞれ記録してください。サーバーの負荷、回線、DNS、ルーティングも通信品質に影響します。互換性が確認できても、必ず通信速度が向上するとは限りません。
再現できる確認手順を最後まで実行しましょう。コアの起動、ノードでの実際のリクエスト、アプリの通信経路を順に確認します。操作手順は実接続の遅延テストとシステムプロキシの設定を参照してください。Androidの設定はAndroid向け利用ガイドをご覧ください。コアを選ぶ基準は、サーバー側の要件とクライアントの実際の対応状況です。プロトコル名だけで選ばないでください。