V2Rayプロトコルとコア技術リファレンス

1. まずプロトコル選定の枠組みを作る

プロトコル、トランスポート層、セキュリティ層は別の概念

クライアントのノード名には、VLESS、TCP、WebSocket、TLS、REALITYなどの語が同時に表示されることが多く、互いに競合する複数のプロトコルだと誤解しがちです。実際には、これらは異なるレイヤーに属します。VMess、VLESS、Trojan、Shadowsocksは主に、クライアントとサーバーがユーザーを識別し、データをカプセル化してプロキシセッションを確立する方法を定めます。TCP、WebSocket、gRPCなどはデータの運搬方法を示し、TLSとREALITYは接続の安全性やハンドシェイクの特徴を扱います。1つのノードは複数レイヤーの組み合わせで構成されるため、すべての用語から1つだけを選ぶものではありません。

たとえば「VLESS + TCP + REALITY」は、アプリケーション層にVLESSを使い、下位層でTCPを転送し、REALITY関連のハンドシェイクパラメーターでセキュリティ層を処理する構成です。「VMess + WebSocket + TLS」は別の組み合わせです。ノードを比較するときは層ごとに分けて確認します。まずクライアントのコアがプロトコルに対応しているかを確認し、次にトランスポート方式とセキュリティ方式を同時に有効化できるかを調べ、最後にアドレス、ポート、ユーザー識別子、サーバー名、公 ключなどの具体的な項目を確認します。ノード名の最初の単語だけでは、その設定が現在の端末に適しているか判断できません。

理論上の性能より互換性を優先

プロトコル選定で最初に考えるべきなのは、抽象的な意味で最速の方式を探すことではありません。サーバー、サブスクリプション変換側、クライアントのコア、グラフィカルインターフェースが、同じ設定を完全に表現できることが重要です。カプセル化が簡素な組み合わせでも、クライアントが重要な項目を1つ無視すれば、ハンドシェイク失敗、接続後の通信不能、読み込み時のノード欠落につながります。まず対応表を確認し、その後で接続速度、スループット、リソース使用量を比較してください。

デスクトップではv2rayNを第一候補にできます。Windows、macOS、Linuxで比較的充実したグラフィカルな設定画面を利用でき、一般的なXray関連プロトコルの項目にも対応します。Androidではv2rayNGがXrayコアを採用しており、VLESSやREALITYなどを必要とする設定に向いています。v2flyNGはv2flyコアを採用しているため、VMess、Shadowsocks、V2Fly互換設定を中心に使う環境に適しています。2つのAndroidクライアントは画面が似ていますが、コアの対応機能まで完全に同じとは限りません。

ノード品質をプロトコル名だけで判断しない

実際の接続結果は、サーバー負荷、回線品質、出口帯域、距離、ドメイン名前解決、OSのネットワークスタック、サーバー側パラメーターにも左右されます。同じプロトコルでもノードによって結果は大きく異なり、異なるプロトコルでも回線条件によって逆の結果になることがあります。プロトコルが決めるのはカプセル化方式と機能の範囲であり、ノードの帯域、安定性、利用可能期間を直接保証するものではありません。

したがって、まず完全に読み込めない組み合わせを互換性で除外し、そのうえで同じ端末、同じネットワーク、近い時間帯に実際の接続遅延、ページ応答、継続ダウンロードを比較するのが合理的です。クライアントのICMP Ping、TCP実接続遅延、ダウンロード速度測定は異なる経路の段階を測るため、最小の数値だけで順位付けはできません。3種類のテストの違いは、Ping・実接続遅延・ダウンロード速度測定の違いで確認できます。

2. VMessとVLESS：完全なセッションから簡素な認証へ

VMessの設計背景とセッションの特徴

VMessは、Project Vの初期エコシステムを代表するプロトコルの1つです。ユーザー識別子、時刻に関する検証、セッション確立、データのカプセル化をプロトコル設計に組み込み、クライアントとサーバーが共通の構造で認証と通信を行えるようにしています。初期のV2Ray設定ではVMessが多くの役割を担っていたため、古いサブスクリプション、長期運用されているサーバー、V2Flyエコシステムで現在もよく使われています。長年の互換性が広く、多くのサブスクリプション生成システムやグラフィカルクライアントが基本項目を認識できる点が利点です。

VMessの設定には通常、サーバーアドレス、ポート、ユーザー識別子、暗号化またはセキュリティ項目、トランスポート方式、TLSなどの外側のオプションが含まれます。ユーザー識別子はサーバー側と一致している必要があり、クライアント端末の時刻も正確に保つべきです。時刻のずれが認証に影響する場合があります。VMessの接続失敗を調べる際は、アドレスとポートだけでなく、端末時刻、ユーザー識別子、転送パス、Host、TLSサーバー名、サブスクリプションの有効期限も確認してください。再測定だけを繰り返しても、設定上の問題は通常特定できません。

VMessは自身が担うセッションロジックが多いため、プロトコル処理はVLESSよりやや複雑です。ただし一般的なデスクトップ端末では、この差はネットワーク品質による変動より小さいことがほとんどです。低消費電力のAndroid端末、高並列接続、継続的な大容量通信では、カプセル化の複雑さがCPUのウェイクアップ、メモリ割り当て、消費電力の変化として現れやすくなります。それでも、トランスポート方式とアプリの動作がプロトコル自体より大きな影響を与える場合があります。

VLESSが簡素な設計を採用する理由

VLESSは、プロトコル内部が担う暗号化と状態管理の責務を減らし、安全性をTLSやREALITYなどの外側の仕組みに委ねることを重視しています。ユーザー識別子と必要なプロキシセッション項目は保持しますが、完全なデータ暗号化層を重複して実装しません。これによりプロトコル処理の経路が短くなり、セキュリティ層とトランスポート層の役割も明確になります。VLESSだけで自動的に安全になるわけではなく、安全性はVLESSという名称ではなく、設定全体の組み合わせで決まります。

このレイヤー構造により、VLESSノードにTLSやREALITYが組み合わされる理由も説明できます。読み込み時には、サーバー名、フィンガープリント、公 開鍵、ショートID、フロー制御パラメーターなどの組み合わせを完全に保持する必要があります。項目によっては特定のトランスポート方式、セキュリティ方式、コア実装でのみ有効です。別の組み合わせへそのままコピーすると、ハンドシェイクに失敗することがあります。特にフロー制御は汎用的な速度スイッチではなく、サーバーとクライアントが同じ方式で設定されている場合にだけ有効にしてください。

利用者の視点では、VLESSの価値は画面上の項目が少ないことではなく、プロトコルの責務が明確で、現代的なトランスポートやセキュリティ機構と組み合わせやすい点にあります。新しい設定で、サーバーがVLESSを明示的に提供し、現在のクライアントがすべての項目を完全に認識できるなら、優先的なテスト対象にできます。既存のVMessノードが安定し、サブスクリプション更新にも問題がないなら、プロトコル名が古いという理由だけで移行する必要はありません。項目が欠けた新しい組み合わせより、安定稼働する完全な設定のほうが信頼できます。

互換性と移行の境界

VMessとVLESSは、ノード種類のプルダウンを変更するだけで相互変換できる形式ではありません。サーバー側で対応するインバウンドプロトコルを設定し、クライアントのユーザー識別子、トランスポート層、セキュリティ層も一致させる必要があります。VMess共有リンクのプロトコルヘッダーだけをVLESSに書き換えたり、グラフィカルインターフェースで種類だけを変更したりしても、利用可能なノードは自動生成されません。移行にはサーバー設定とサブスクリプション内容の両方が必要です。

サブスクリプション変換の過程で、古い項目が新しい項目へ変換されることもあります。たとえば、過去のVMessデータにあるセキュリティ項目、偽装タイプ、パスの表現は、サブスクリプション形式によって名称が異なります。読み込み後は、ノードが一覧に表示されたかだけでなく、編集画面で項目を1つずつ確認してください。ノードが表示されるのは、パーサーが基本レコードを認識したことを示すだけで、高度な項目がすべて保持されたことを意味しません。

3. Trojan、Shadowsocks、REALITYの境界

Trojan：認証は簡潔だが、TLS設定の完全性に依存

Trojanは比較的わかりやすいパスワード認証を採用し、通常はTLS接続上で動作します。安全な通信は成熟したTLS実装に任せ、自身はプロキシ要求と本人確認を担当します。ノード項目は複雑なVMess構成より短く見えることが多いものの、接続成立を左右するのはアドレス、ポート、パスワード、サーバー名、証明書関連設定、トランスポート項目です。パスワードが正しくてもサーバー名が間違っていれば、TLSハンドシェイクで接続が中断することがあります。

Trojanは、サーバー側でTLSが適切に設定され、クライアントがサーバー名を正しく送信できる環境に適しています。基本モデルが理解しやすく、サブスクリプション形式でも一般的です。ただし実装によってはWebSocketやgRPCなどのトランスポート方式が追加されます。その場合、Trojanは単なる「アドレス、ポート、パスワード」の3項目ではありません。パス、サービス名、Host、ALPNなども互換性の条件になります。読み込み後にノードが存在するのに接続できない場合は、元のサブスクリプション項目と1つずつ比較してください。

性能面ではTrojanのプロトコルカプセル化は比較的直接的ですが、最初のTLSハンドシェイクには計算コストと通信往復が発生します。長時間の接続では後続のデータ転送に分散されますが、短い接続を頻繁に作る場合はハンドシェイク回数が応答速度や消費電力に影響しやすくなります。したがって、1回の速度測定だけでVMessやVLESSより必ず速いと判断することはできません。接続の再利用やネットワーク切り替えの頻度も結果を変えます。

Shadowsocks：軽量なデータ転送と方式の互換性

ShadowsocksはSSとも略され、軽量な転送を目的としています。設定の中心は通常、サーバー、ポート、パスワード、暗号化方式です。複数レイヤーの項目を含むノードより、さまざまなクライアントやサブスクリプション形式で表現しやすく、リソースが限られた端末にも適しています。ただし「項目が少ない」ことは互換性を無視できるという意味ではありません。クライアントとサーバーが同じ暗号化方式に対応している必要があり、古い実装と新しい実装では対応方式の範囲が異なる場合があります。

サブスクリプションの読み込み後に暗号化方式が置き換わったり、空欄になったり、未対応と表示されたりした場合、ノードは再測定だけでは通常復旧しません。現在のコアがその方式を実装しているか、サブスクリプション変換で方式名が別の表記に書き換えられていないかを確認してください。プラグイン型の拡張には追加パラメーターも必要です。基本的なSS項目だけを残してはいけません。v2rayN、v2rayNG、v2flyNGはいずれも一般的なSSノードを処理できますが、対応方式や拡張機能はクライアントとともに動作するコアによって異なります。

SSのプロトコル処理による負荷は通常低く、接続数が多くなく、設定構造が明確な日常用途に適しています。実際のスループットは、回線、暗号化方式、端末のプロセッサー、サーバー負荷によって決まります。性能の低いAndroid端末では、コアがネイティブ対応し、計算コストも適切な方式を選ぶほうが、ノード名を変更するより効果的な場合があります。暗号化方式はサーバーとの取り決めなので、クライアントで勝手に変更しないでください。

REALITYはセキュリティ層の組み合わせであり、独立したプロキシプロトコルではない

REALITYはVLESSと組み合わせて使われることが多く、VMessやTrojanと並ぶプロトコルだと誤解されがちです。より正確には、特定のハンドシェイクとセキュリティ層の処理を担い、VLESSなどのプロトコルがプロキシセッションを担当します。REALITYノードには通常、サーバー名、公 開鍵、ショートID、フィンガープリント、場合によってはフロー制御パラメーターも必要です。これらは組み合わせて使う項目であり、1つでも欠けるとハンドシェイクを完了できないことがあります。

REALITY関連機能は主にXrayコアが提供するため、v2rayNGやXrayを中心に動作させるv2rayNがこの種のノードに適しています。v2flyコアを採用するv2flyNGに同じ項目対応があると想定してはいけません。サブスクリプションパーサーがノード名を読み取れても、保存時にコアが認識しない項目を破棄することがあります。互換性は一覧に「REALITY」と表示されるかではなく、ノード編集画面に対応するセキュリティ方式とパラメーターがあるかで判断してください。

サーバー名と接続先アドレスの意味も混同してはいけません。ノードの接続アドレスはクライアントがネットワーク接続を確立する先を決め、サーバー名はハンドシェイクのパラメーターに使われます。両者は異なる項目です。公開鍵はユーザー識別子ではなく、ショートIDもポートの追加値ではありません。設定をコピーするときは項目の位置を維持し、アドレスやメモに連結しないでください。フィンガープリントはサーバー設定が対応する値を使う必要があり、クライアントのデフォルト値をすべてのノードで置き換えられるわけではありません。

4. 接続速度、スループット、リソース使用量の比較方法

接続速度は複数の段階で構成される

ユーザーが感じる「表示速度」には通常、名前解決、サーバーまでのネットワーク往復、TCP接続、セキュリティハンドシェイク、プロトコル認証、サーバーから接続先への接続、最初のバイトの返却などが含まれます。VMess、VLESS、Trojan、SSのプロトコル処理が占めるのはその一部にすぎません。ノードとの距離が遠い、または回線が混雑している場合、カプセル化処理を少し短縮しても全体の応答は大きく変わりません。回線条件が近い場合は、ハンドシェイク方式と接続再利用の違いが現れやすくなります。

クライアントの遅延テストがすべての段階を測るとは限りません。通常のPingはアドレスまでのネットワーク往復だけを測ることがあり、実接続遅延は実際にプロキシ接続を確立します。ダウンロード速度測定は出口帯域、測定先、継続転送能力にも左右されます。そのため「Pingは低いがページ応答は普通」や「実接続遅延は高いがダウンロードは安定」という結果も矛盾ではありません。用途に応じて指標を選び、閲覧では初回接続と応答、継続転送では安定したスループット、リアルタイム用途では揺らぎとパケット損失を重視してください。

プロトコルを比較するときは変数をそろえます。同じクライアント、同じ端末、同じネットワーク、近い地域とサーバー負荷で短時間に複数回テストすれば、偶然の変動を抑えられます。2つのノードでプロトコル、サーバー地域、トランスポート方式を同時に変更した場合、結果をプロトコルの差に帰属できません。実際の選定に実験室レベルの精度は不要ですが、回線差をVLESSやTrojan固有の利点と誤認しないことが重要です。

トランスポートのカプセル化がアプリケーションプロトコルよりスループットに影響することがある

TCPの直接的な転送は構造が比較的単純です。WebSocketはフレームのカプセル化とHTTPアップグレード処理を追加し、gRPCはHTTP/2を基盤として独自のストリームと接続管理を行います。各トランスポート方式には、サーバー構築、接続再利用、ヘッダーのオーバーヘッド、中間ネットワーク機器との互換性に関する利点と妥協点があります。大容量ファイルの継続転送では少量のヘッダー負荷だけがボトルネックとは限らず、短い要求が多い場合はハンドシェイクと再利用戦略がより重要になります。

トランスポート方式はメモリとプロセッサーの負荷にも影響します。接続数が増えると、各接続のバッファー、プロトコル状態、暗号化コンテキストがリソースを消費します。WebSocketやgRPCが必ず遅いわけではありませんが、単純なTCPより処理経路が長く、性能はクライアントとサーバーの実装品質に左右されます。リソースが限られた端末では、不要な多層カプセル化を減らすほうが安定した結果を得やすいでしょう。

UDPを使う用途は別途確認が必要です。プロトコルとトランスポートの組み合わせによってはUDPを転送できますが、ネイティブなデータグラム処理の場合もあれば、別の接続に載せる場合もあります。ゲーム、音声、DNS問い合わせはパケット損失、揺らぎ、ヘッドオブラインブロッキングの影響を受けやすく、TCPのダウンロード速度だけではUDPの体感を予測できません。クライアントでTUNモードを有効にするとシステムトラフィックの流入方法も変わり、ルーティング規則、DNSポリシー、コアの処理経路が測定結果に加わります。

リソース使用量は起動直後ではなく安定した状態で見る

コアの起動時には、設定の読み込み、ルーティング規則の作成、DNS、ログ、接続管理モジュールの初期化が行われるため、一時的なCPU使用率には代表性がありません。同じ設定と近いアプリ活動のもとで一定時間の安定区間を観察し、アイドル、ウェブ閲覧、継続転送の3状態を記録するほうが有効です。メモリ使用量も常駐メモリ、接続バッファー、システムキャッシュを分けて考える必要があり、瞬間的な1つの数値だけではプロトコル効率を説明できません。

ログレベルはリソース消費に影響します。トラブルシューティングでは詳細ログがハンドシェイク、DNS、ルーティングの問題特定に役立ちますが、高い詳細度を長時間維持すると書き込みと整形処理が増えます。日常利用ではwarningやerrorなど控えめなレベルを選び、調査時だけ引き上げ、確認後に戻してください。ノード数が多い場合は、一括速度測定やサブスクリプション更新も一時的なピークを生みます。これは現在の接続プロトコルが安定して使用するリソースとは別のものです。

5. Androidの消費電力とバックグラウンド接続

消費電力は暗号化計算だけでなく、継続的なウェイクアップから生じる

Androidでv2rayNGやv2flyNGを動かす場合、消費電力は複数の要因で決まります。コアによるデータ処理、仮想ネットワークインターフェースの転送、フォアグラウンドサービスの維持、ネットワーク切り替え、DNS問い合わせ、ログ書き込み、他アプリのバックグラウンド要求がCPUや無線モジュールを起こします。プロトコル暗号化はその一項目にすぎません。ノードが「接続済み」でもアプリが通信していなければ、動画の連続再生、ファイル同期、大量の通知がある状態とは消費電力が異なります。

モバイルネットワークと無線LANでは消費電力の特性も異なります。電波が弱いと無線モジュールの送信電力が上がり、ネットワーク状態の変化後に接続を何度も再構築することがあります。このとき頻繁なハンドシェイクのコストが大きくなります。移動中はネットワークアドレスの切り替え、スリープからの復帰、接続切断によってクライアントがトンネルを再確立することがあります。固定した無線LANで安定する組み合わせが、ネットワークを頻繁に切り替える環境でも同じ消費電力になるとは限りません。

長時間接続はハンドシェイクの繰り返しを減らすのに役立ちますが、維持にはハートビートやシステムのキープアライブ機構が必要です。ハートビートが頻繁すぎるとウェイクアップ回数が増え、間隔が長すぎるとネットワーク機器に接続を削除され、再接続が発生します。通常、ユーザーが低レベルのハートビートを手動調整する必要はありません。安定したノードを選び、頻繁な切り替えとバックグラウンドの一括速度測定を避け、クライアントとシステムが推奨するデフォルト接続パラメーターを使うほうが現実的です。

プロトコルとトランスポート方式が消費電力に与える相対的な影響

同じ回線条件なら、処理経路が短く、接続の再確立が少ない組み合わせは消費電力を抑えやすい傾向があります。VLESSはセキュリティの役割を外側の機構に委ね、SSの基本構造も軽量ですが、最終的な消費電力はTLSまたはREALITYのハンドシェイク、トランスポートのカプセル化、アプリの接続数、ネットワークの安定性で決まります。VMessのセッション処理が比較的完全だからといって、すべての端末で明らかに電力を多く消費するとは限りません。VMessノードが安定し、軽量な別プロトコルのノードが再接続を繰り返すなら、前者のほうが省電力になることもあります。

WebSocketとgRPCには、それぞれ独自のプロトコル処理と接続管理が加わります。現代的な端末では通常の通信時の差は小さいことがありますが、性能の低い端末、大量の並列短接続、長時間のバックグラウンド動作では、追加のカプセル化による変化が現れやすくなります。TUNモードでは、手動プロキシポートを通らなかったアプリ要求を含む、より多くのシステムトラフィックがクライアントに入ります。TUNに切り替えて消費電力が増えた場合は、まずバックグラウンドアプリが継続的に通信していないか確認し、その後でプロトコルとの関係を判断してください。

DNS設定も重要です。名前解決の失敗、到達不能な結果、規則による重複問い合わせがあると、クライアントやアプリが接続を何度も試みることがあります。見た目はプロキシクライアントが常に動作しているようでも、原因はDNSやルーティング規則かもしれません。調査時は複雑な規則を一時的に減らし、安定したノードを使い、システムのバッテリー画面で継続的に通信しているアプリを確認してください。バッテリー一覧でクライアントの割合だけを見て結論を出してはいけません。仮想ネットワークサービスは、転送活動を多く計上される場合があります。

再現性のある消費電力比較を行う

v2rayNGとv2flyNG、または2種類のプロトコルを比較する場合は、画面輝度、ネットワーク種別、バックグラウンドアプリ、使用時間をできるだけそろえてください。まず端末の充電状態を安定させ、一括更新と速度測定を停止し、待機、軽い閲覧、継続転送をそれぞれ観察します。数分間のバッテリー残量の変化は精度が限られるため、システムのバッテリー曲線、フォアグラウンド活動、発熱を合わせて判断するのが適切です。

ロック画面にすると特定のノードが頻繁に切断される場合は、まずAndroidのバックグラウンド実行制限、フォアグラウンドサービスの状態、ネットワーク切り替えを確認します。次にクライアントログで、接続タイムアウト、DNSエラー、ハンドシェイク失敗が繰り返されていないかを確認してください。ネットワーク復旧後に失敗が集中するなら接続再確立の問題かもしれません。固定したネットワークでも続くなら、ノード項目とサーバーの利用可能性を確認します。一般的な手順はよくある質問でも確認できます。

日常的な最適化は、不要な処理を減らすことから始められます。サブスクリプション更新は必要なときだけ行い、クライアントで速度測定を連続実行しないようにします。ノード一覧が大きい場合はグループ化やフィルターを使い、調査後は通常のログレベルに戻し、全体的なトラフィック取り込みが必要な場合だけTUNを有効にしてください。再接続が少なく、実接続テストが安定するノードを選ぶことも重要です。プロトコル名自体が消費電力を切り替えるわけではなく、安定した経路と適切な通信量のほうが重要です。

6. V2FlyとXrayのコアファミリーおよび設定互換性

Project Vエコシステムと2つのコアの方向性

Project Vは、プロキシプロトコル、コアプログラム、設定体系、クライアントツールで構成されるオープンソースのエコシステムです。V2Rayという語は技術体系全体を指す場合も、特定のコア実装を指す場合もあるため、互換性を議論するときはプロトコル、設定形式、具体的なコアのどれを指すのかを明確にする必要があります。V2FlyはV2Rayのコミュニティ保守の方向性を引き継ぎ、既存プロトコルと設定エコシステムを重視します。Xrayは近い設定モデルを基盤に機能を拡張し、VLESSやREALITYなどに関連する機能を提供します。

両者には共通の歴史と似た概念が数多くありますが、名前だけが違って機能も完全に同じ2つのプログラムと考えることはできません。インバウンド、アウトバウンド、ルーティング、DNS、ログの基本構造は共通点が多い一方、具体的なプロトコル項目、トランスポートオプション、セキュリティ設定、デフォルト動作は異なる場合があります。設定ファイルを別のコアが解析できても、すべての項目が同じように動くとは限りません。逆に解析に失敗しても、設定体系全体が非互換とは限らず、別のコア専用項目が含まれているだけの場合もあります。

グラフィカルクライアントはさらに1層の変換を加えます。v2rayNは画面、サブスクリプション、システムプロキシ操作をコア設定へ変換します。v2rayNGはXrayコアの機能を主な基盤とし、v2flyNGはv2flyコアに対応します。画面に表示されるのはノードとスイッチですが、実際の接続動作は生成された設定と基盤コアによって決まります。調査では「サブスクリプションが項目を解析していない」「画面に選択肢がない」「コアが機能に対応していない」を区別してください。

共通する設定の骨格と専用項目

両方のコアは通常JSON設定を採用し、ログ、インバウンド、アウトバウンド、DNS、ルーティングなどのセクションで構成します。次の最小例は、ローカルのSOCKSインバウンドを作成し、自由なアウトバウンドで直接アクセスするものです。設定ファイルの構造、待ち受けポート、コアの起動を確認するための例であり、リモートノードは含まれません。日常利用の設定として、クライアントが生成した設定の代わりに使うものでもありません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

Xrayを正しくインストールし、上記の内容をconfig.jsonとして保存したら、ターミナルから次のコマンドを実行して設定を起動できるか確認します。ポートが他のプログラムに使用されている場合は、競合するプログラムを終了するか、待ち受けポートを変更してください。グラフィカルクライアントを通常利用する場合、このコマンドを手動で実行する必要はありません。

xray run -config config.json
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

実際のVLESS、VMess、Trojan、SSアウトバウンドには、サーバー一覧、ユーザー識別子、パスワード、暗号化方式、フロー設定なども加わります。REALITY関連項目は特に注意して確認すべき拡張機能です。これらの項目を含むXray設定を非対応のコアにそのまま渡すと、起動時に未知の項目として報告されることもあれば、上位の変換ツールに先に削除されることもあります。コアをまたぐ設定では、JSONの構文だけでなく、プロトコルの意味を項目ごとに確認してください。

設定の互換性とサブスクリプションの互換性は別

コア設定ファイルとサブスクリプションファイルは異なる問題を解決します。コア設定はプログラムの待ち受け、ルーティング、接続方法を記述し、サブスクリプションは主にノード情報を渡して、クライアントが完全なコア設定を生成します。あるクライアントが特定の共有リンクに対応していても、コアJSON全体の読み込み機能を提供しているとは限りません。逆にコア設定を読み込めても、すべての項目を編集可能なノードへ変換できるとは限りません。「Xrayが動作する」ことから「任意のサブスクリプションクライアントに読み込める」とは導けません。

v2rayNはデスクトップでのノード管理、サブスクリプション更新、ルーティング選択、システムプロキシ切り替えに適しています。v2rayNGはAndroidでXray関連プロトコルを使う場合に向いています。v2flyNGはV2Fly系統の選択肢です。3つのクライアントはサブスクリプションリンクや単一ノードの共有情報で一般的な設定を同期できますが、複雑なルーティング、DNS規則、コア専用項目、クライアント固有の設定は完全には交換できません。複数端末の同期方法はサブスクリプションリンク、設定エクスポート、QRコード共有を参照してください。

コアの違いに直面したときの調査順序

まずノードの元のプロトコルと、すべてのセキュリティ・トランスポート項目を記録します。次に現在のクライアントが実際に使っているコアファミリーを確認し、ノード編集画面で項目が存在するかを調べます。最後に実行ログを確認し、エラーが解析、起動、ハンドシェイク、トランスポートのどの段階で発生したかを判断します。読み込み後に該当する入力欄自体がないなら、通常はクライアントまたはコアの対応範囲の問題であり、ネットワーク遅延の問題ではありません。対応するクライアントへ切り替え、推測で重要項目を削除しないでください。

7. サブスクリプション形式、共有リンク、項目の互換性

サブスクリプションはノードの入れ物であり、統一設定規格ではない

「サブスクリプションリンク」は、クライアントが複数のノードデータを取得する入口を指しますが、返される内容の構成はさまざまです。一般的には、複数行の共有リンク、エンコードされたテキスト、構造化されたノード一覧、クライアント専用形式などがあります。クライアントはまず外側の形式を識別し、各ノードレコードを解析して、最後に項目をコア設定へ割り当てます。どこか1層でも非互換だと、サブスクリプション更新の失敗、ノード数の異常、高度な項目の欠落が起こります。

VMessの共有データには比較的多くの構造化項目が含まれます。VLESS、Trojan、SSはURI形式が一般的で、クエリパラメーターでトランスポートやセキュリティの項目を表します。URIを認識できても、パラメーター名すべてに現在のクライアントが対応しているとは限りません。特にREALITYの公開鍵、ショートID、フィンガープリント、フロー制御、gRPCのサービス名、WebSocketのパス、Hostなどは、古いパーサーや形式変換で欠落しやすい項目です。

ノードのメモは通常表示専用で、接続には使われません。メモを変更してもプロトコルは変わりませんが、メモに基づく自動グループ化の規則には影響することがあります。一方、アドレス、ポート、ユーザー識別子、パスワード、暗号化方式、サーバー名、セキュリティ項目は接続項目であり、画面を整理するために削除してはいけません。読み込みに異常がある場合は、元のサブスクリプションを比較用に残し、複数項目を続けて手動変更しないでください。

読み込み成功と接続成功は別の確認段階

サブスクリプション更新後にノードが表示された場合、クライアントが基本的な解析を完了したことだけがわかります。次にノード種類、トランスポートとセキュリティ方式の一致、重要な入力項目の値を確認し、その後で実接続テストを行ってください。すべてのノードが読み込まれない場合は、まずサブスクリプションアドレスへのアクセス、内容が空でないか、サブスクリプション種類の選択ミスを確認します。特定のプロトコルだけが欠ける場合は、形式またはコアの対応範囲に原因がある可能性が高いでしょう。

ノードは存在するのにすべて接続できない場合、まず同じサーバー名、同じトランスポート方式、同じコア専用設定など、共通項目がないかを確認します。一部のノードだけが失敗する場合は、アドレス、ポート、ユーザー情報を調べます。すべての失敗をサブスクリプションアドレスのせいにすると、ノード単位の問題を見落とします。逆にサブスクリプション更新でエラーが出ているとき、ノードを切り替え続けても意味はありません。更新処理がノード接続の段階に達していないからです。

サブスクリプション更新には上書きルールも関係します。クライアントによってはサブスクリプショングループ単位で古いノードを置き換えるため、手動変更したノードが次回更新で元に戻ることがあります。別のケースではローカルノードを残して新しいレコードを追加し、重複が発生します。長期的に項目をカスタマイズするなら、まずクライアントの更新動作を確認し、独立した手動ノードを残すか、サブスクリプションの提供元を変更するか決めてください。v2rayNへの読み込み手順の基本はクイックスタートの手順をご覧ください。

クライアント間同期では対応機能の共通部分を受け入れる

v2rayNからv2rayNGへ同期する場合、一般的なノードプロトコルと基本項目は同じサブスクリプションでそろえられますが、デスクトップのシステムプロキシ設定、ルーティンググループ、プロセスマッチング、画面設定はAndroidに自然には引き継がれません。逆方向も同様で、Androidのアプリ単位の選択やバックグラウンドサービス設定はノードサブスクリプションには含まれません。サブスクリプションはサーバー接続情報の管理には適していますが、すべての端末設定のバックアップには向きません。

v2rayNGとv2flyNGの違いは主にコアの機能に由来します。REALITYを含むサブスクリプションはv2rayNGなら完全に認識できても、v2flyNGでは同等の設定を作れない場合があります。そのときREALITY項目を通常のTLSへ置き換えるべきではありません。両者は自由に交換できるスイッチではないからです。対応するノード種類をコアごとに用意するか、サブスクリプションの機能に合ったAndroidクライアントを選ぶのが適切です。

QRコード共有は通常、単一ノードのURIを画像として符号化したものです。1レコードの長さとクライアントの解析能力に制限されるため、少数ノードの一時的な受け渡しには適していますが、長期的なサブスクリプション更新の代わりにはなりません。設定ファイルのエクスポートにはより完全なルーティングやDNS情報を含められますが、クライアント間では専用構造が非互換になりやすくなります。同期方法を選ぶ前に目的を明確にしてください。ノードだけならサブスクリプション、単一ノードの一時共有ならQRコード、高度な設定まで保持するならクライアントが対応するエクスポートを使い、移行先で項目を確認します。

8. 用途に応じたプロトコルとクライアントの選び方

デスクトップの日常利用：まずクライアントを選び、完全なノードを確認する

Windows、macOS、Linuxのデスクトップ環境ではv2rayNを優先します。サブスクリプション管理、システムプロキシの切り替え、ノード編集、接続ログの確認に適しています。サブスクリプションにVLESS、VMess、Trojan、SSが同時にある場合は、項目が不完全なノードやコアが対応しないノードを除外し、残りを実接続と実際のアクセスでテストしてください。新しい設定では、明確なセキュリティ層を組み合わせたVLESSを優先的に試し、安定しているVMessやTrojanノードはそのまま使えます。

デスクトップ端末は通常、CPUとメモリに余裕があるため、プロトコル間の小さな処理負荷は最優先の問題ではありません。接続の安定性、サーバー負荷、トランスポート方式、ルーティング設定を重視してください。プロセス単位の分流や全体的なトラフィック取り込みが必要な場合、TUNモードはトラフィックの入口を変えるため、現在のシステムプロキシとルーティング設定を記録してから段階的に有効化します。TUN切り替え後に一部アプリだけ異常になるなら、まずDNSとルーティングを確認し、すぐにプロトコルを変更しないでください。

大容量ファイルのダウンロードや継続転送では、スループットが安定し、揺らぎの少ないノードを選び、1回だけの最低遅延を追い求めないでください。オフィスのウェブ閲覧や対話型アプリでは初回応答が重要なので、実接続遅延と実際の表示速度を優先して比較します。同じプロトコル名のノードでも、サーバー地域と回線の違いがカプセル化の差より大きいことが多いため、個別にテストしてください。

Androidの日常接続：バックグラウンドの安定性とコアの一致を重視

AndroidでVLESS、REALITY、その他のXray機能が必要ならv2rayNGを使います。VMess、SSなどV2Fly互換設定が中心ならv2flyNGを選べます。端末のリソースが限られている、または長時間バックグラウンドで動かす場合は、再接続が少なく、項目が簡潔で、コアがネイティブ対応する組み合わせを優先してください。理論上軽量なプロトコルでも、ハンドシェイクに失敗し続ければ消費電力の利点はありません。

モバイルネットワークを頻繁に切り替える場合は、ネットワーク復旧後にノードが正常に再接続できるかを確認します。特定のノードが無線LANでしか使えない、またはモバイルネットワークへの切り替え後に失敗し続ける場合は、名前解決、トランスポート方式、サーバーへの到達性を分けて確認してください。プロトコル、セキュリティ層、DNSの3組を一度に変更せず、毎回1つの変数だけを変え、ログに記録されたエラー段階を残します。

端末が発熱する、または待機中の消費電力が明らかに増えた場合は、一括速度測定と頻繁なサブスクリプション更新を停止し、バックグラウンドアプリの通信を確認してからプロトコルを比較します。TUNは取り込み範囲を広げ、より多くのアプリ要求をコア経由にすることがあります。少数のアプリだけを接続するなら、クライアントの機能に応じて対象アプリを絞り、不要な転送を最初から減らしてください。

古いサブスクリプションと長期運用設定：安定性を優先し、移行は一式で行う

古いサブスクリプションではVMessとSSがよく使われています。ノードを完全に読み込めて接続も安定しているなら、手動でVLESSへ変更するより、そのまま使うほうが信頼できます。プロトコル移行にはサーバー、サブスクリプション、クライアントのすべてが関係し、ローカルのノード種類だけを変更しても完了しません。移行する場合は、まず元のノードを比較用に残し、サーバーが提供する新しいノードを読み込んで個別にテストしてからグループを調整します。

サブスクリプション変換ツールが基本項目しか出力できない場合、複雑なWebSocket、gRPC、TLS、REALITYのパラメーターが失われることがあります。その場合は中間変換を減らし、目的の形式に対応するクライアントでサブスクリプションを直接読み込んでください。ノードのメモ、グループ名、並び順は後から整理できますが、接続項目は元のまま保持します。サブスクリプション更新失敗の詳しい確認方法はFAQの分類解説をご覧ください。

リソースの少ない端末と高並列環境

リソースの少ないAndroid端末では、構造が比較的単純で、コアが成熟して対応しているSS、VLESS、または現在安定しているプロトコルを優先的にテストできます。ただし、サーバー条件を無視して唯一の正解を決めることはできません。ノード総数を減らし、詳細ログの常時出力を止め、一括速度測定と大容量通信を同時に行わないでください。接続数に応じてメモリ使用量が明らかに増えるなら、大量の短接続を作っていないか、TUNが不要なバックグラウンド通信まで取り込んでいないかを確認します。

高並列環境では、接続の再利用、サーバーのファイルディスクリプター、バッファー、ルーティング規則の複雑さが、プロトコルのカプセル化より重要になる場合があります。WebSocket、gRPC、通常のTCPは接続管理の方法が異なるため、サーバー構成と合わせてテストしてください。1ユーザーの日常閲覧で得た結果を、大量の並列接続にそのまま適用することはできません。長期運用する端末では、瞬間的な最高速度より安定区間、エラー率、再接続回数を記録する価値があります。

最終判断表と検証サイクル

選択後は、簡単な検証サイクルを作ります。クライアントとコアファミリーを記録し、ノードのプロトコル、トランスポート、セキュリティ方式を保存します。実接続テストを複数回行い、実際のアプリで応答と継続転送を確認し、一定時間の安定稼働中にログとリソース使用量を観察します。その後でデフォルトノードにするか決めてください。問題が起きたら直近の変更から戻し、プロトコル、クライアント、ネットワーク環境を同時に変更しないでください。

複数のノードの結果が近いなら、設定が明確で、サブスクリプション更新が安定し、現在のクライアントが完全に対応しているものを1つ選べば十分です。すべてのプラットフォーム、ネットワーク、サーバー条件で常に優位なプロトコルはありません。プロトコル選定の目的は、環境から切り離した理論上の順位を追うことではなく、互換性のリスクを減らし、接続動作を説明・再現できるようにすることです。