V2Rayプロトコルガイド：プロトコル・通信方式・カーネルの選び方

1. プロトコル・通信方式・セキュリティ層・カーネルを分けて考える

クライアントの「プロトコル」は単一のスイッチではない

v2rayN、v2rayNG、v2flyNGのサーバー編集画面では、1つの接続に通常、プロトコルの種類、アドレス、ポート、ユーザー認証情報、通信方式、セキュリティ層、ルーティング先が含まれます。プロトコルの種類は、クライアントとサーバーがどのように認証し、データフレームを構成するかを決めます。通信方式は、TCP、WebSocket、gRPCなど、データフレームをどの経路で送るかを決めます。TLSやREALITYなどのセキュリティ層は、ハンドシェイク、サーバー認証、通信の暗号化を担います。カーネルは、これらの項目を実行可能な設定へ組み立てます。これらを混同すると、「特定のプロトコルなら必ず速い」「種類を変えるだけで接続できる」といった誤った結論につながります。

たとえばVLESSは通常のTCP、WebSocket、gRPC上で動作し、TLSやREALITYと組み合わせることもできます。同じVLESSと表示されたノードでも、通信層、混雑状況、証明書ハンドシェイク、サーバー実装が異なれば、実際の性能は大きく変わります。REALITYもVLESSと同列のプロキシプロトコルではなく、Xrayが実装する通信セキュリティ方式に近いものです。一般的にはVLESS、TCP、REALITY、XTLS Visionを組み合わせます。サーバーを選ぶ際は、共有リンクの先頭にある vless:// だけでなく、完全な組み合わせを1つの構成として確認してください。

選定時にまず確認すべき4つの条件

1つ目は、サーバー側で何が提供されているかです。クライアント側だけでVMessをVLESSに変更することはできません。サーバーでREALITYが設定されていない場合、クライアントでREALITYを選んでも接続できません。2つ目は、カーネルが対応する項目を認識できるかです。v2rayNGは主にXrayカーネルを実行環境とし、v2flyNGはV2Flyカーネルを対象とします。v2rayNはデスクトップ向けのGUIクライアントで、一般的な設定はXrayカーネルで実行されます。基本的なVMess、VLESS、Trojan、Shadowsocksの項目は幅広く対応していますが、XTLS VisionやREALITYなどの拡張機能は、対応するカーネルとの組み合わせが必要です。

3つ目は設定の入手元です。サブスクリプションリンクには、プロトコル、アドレス、ポート、通信パラメータがまとめて含まれるため、通常は完全な状態で取り込み、アドレスとポートだけをコピーして手入力しないでください。4つ目は利用環境です。デスクトップではTUN、複雑なルーティング、複数プロセスの接続を扱いやすい一方、モバイルでは常駐時の消費電力、ネットワーク切り替え後の再接続、バックグラウンド状態が重要になります。同じプロトコルでも、プラットフォームによる使用感の違いは、プロトコル名そのものより、システムのネットワークスタック、TUNの実装、接続維持方式に起因することが多いです。

1つのラベルだけで判断しない

プロトコルを選ぶ妥当な順序は、まずサーバー側の組み合わせとクライアントのカーネルが互換性を持つことを確認し、次に共有リンクまたはサブスクリプションが完全かを確認し、その後で性能とリソース使用量を比較することです。接続は確立するのにウェブページへアクセスできない場合は、システムプロキシ、TUN、DNS、ルーティングを確認してください。設定の取り込み時点で項目が失われている場合は、システムプロキシを何度も切り替えるのではなく、まずサブスクリプション形式を確認します。v2rayNのデスクトップ版、v2rayNGとv2flyNGのAndroid版はインストールパッケージページでプラットフォーム別に選択できます。インストール後の基本操作は、はじめにで案内しています。

2. VMess：完全なセッションプロトコルと互換性の基準

誕生の背景と設計上の重点

VMessはProject Vエコシステムの初期に形成された主要プロトコルの1つです。ユーザー認証、時刻情報、リクエスト先、データ転送を独自のプロトコル構造にまとめ、サーバーはユーザーIDによって接続を識別します。旧来の設定では alterId がよく使われていましたが、これは追加の認証機構として利用されていたものです。現在の実装では一般にAEAD方式が使われ、通常の設定で alterId はゼロです。古いサブスクリプションを取り込んだ際、クライアントに大きなalterIdが表示されても、新しいサーバーへそのまま設定せず、実際のサーバー設定を優先してください。

VMessの強みは、特定の性能項目が突出していることではなく、長年のエコシステム、成熟した項目定義、多くのクライアントやサブスクリプション変換ツールによる対応です。安定して動作しているVMess設定を、新しいプロトコル名が登場したという理由だけで急いで移行する必要はありません。クライアント間の移行における互換性の基準として、特にTCP、WebSocket、TLSなど一般的な機能だけを組み合わせる場合に適しています。V2FlyとXrayはいずれも、通常その基本設定を処理できます。

認証・時刻・暗号化項目

VMessのリクエストには時刻に関係する認証情報が含まれるため、クライアントとサーバーのシステム時刻に大きなずれがあると、アドレス、ポート、ユーザーIDがすべて正しくても認証に失敗することがあります。切り分けでは、まず端末で自動時刻と正しいタイムゾーンが有効になっていることを確認し、次にサーバーの時計を確認します。ここで問題になるのはシステム時刻のずれであり、ネットワーク遅延ではありません。同じリンクの再取り込み、グローバルプロキシの切り替え、クライアントの再インストールでは、明らかな時刻ずれは解消できません。

クライアント画面では、VMessのセキュリティ項目が auto、aes-128-gcm、chacha20-poly1305、none と表示されることがあります。これらはVMessのデータ層における処理方式を示すもので、外側のTLSの代わりにはなりません。auto を選ぶと、カーネルが実装と端末の性能に応じて適切な方式を決定します。暗号方式の手動固定は、サーバーが明示的に要求する場合や互換性を調査する場合にのみ意味があります。外側でTLSを有効にしても、サーバー名、証明書のドメイン、通信経路はそれぞれ一致させる必要があります。

VMessでよくある設定ミス

1つ目は、ユーザーIDを通常のパスワードとして編集してしまうことです。VMessのIDは通常UUID形式で、文字の欠落、前後の空白、誤ったユーザー項目への貼り付けが認証失敗の原因になります。2つ目はWebSocketのパスとHostの混同です。パスはHTTPリクエストのパス、HostはリクエストヘッダーまたはTLSのサーバー名に関係する項目で、同じ場合も異なる場合もあります。元の設定どおりに入力してください。3つ目は共有リンクの主要項目だけを残し、通信層のパラメータを欠落させることです。クライアントが vmess:// リンクを認識できても、現在の変換ツールがすべての項目を正しく解析できるとは限りません。

4つ目はTLSスイッチの扱いです。サーバーがTLSを要求している場合、クライアントでTLSを無効にすると正しいハンドシェイクを完了できません。サーバーでTLSが設定されていない場合、クライアント側だけで有効にしても安全な接続が自動的に得られるわけではありません。5つ目は、カーネルを更新した後も古い項目を使い続けることです。カーネルは廃止された項目に警告を出したり、読み込みを拒否したりします。GUIクライアントでは「起動失敗」としか表示されないこともあります。その場合はトレイの状態だけでなく、ログにあるoutbound、streamSettings、securityなどの項目パスを確認してください。

維持する場合と移行する場合

既存のVMess接続が安定し、サーバーの管理方針が明確で、サブスクリプションも正常に更新されているなら、目的のない移行より維持するほうが手間が少ないことが多いです。移行を検討する主なきっかけは、サーバー設定の変更、カーネル機能の要件、サブスクリプション提供元によるプロトコル変更です。REALITYやXTLS Visionを使いたい場合は、新しいVLESS設定を完全な状態で取り込みます。VMessノードのアドレスとIDをコピーして、プロトコルのプルダウンだけ変更する方法は避けてください。移行後もしばらく元のノードを残し、プロトコル設定の問題とローカルDNS・ルーティング規則の問題を切り分けられるようにします。

3. VLESSとREALITY：軽量認証と現代的なセキュリティ層の組み合わせ

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

VLESSは軽量な認証とリクエスト転送に重点を置き、プロトコル自体で内容暗号化の仕組みを重複して提供しません。クライアント画面でよく見られる encryption の値 none は、通信全体に暗号化がないことを意味するのではなく、TLSやREALITYなど外側の層がセキュリティ機能を担うことを示します。これにより、プロトコル層と通信セキュリティ層で同じ処理を重ねる機会が減り、VLESSをXTLS系のフロー制御と組み合わせやすくなります。VLESSにTCPを組み合わせ、どのセキュリティ層も有効にしていない場合と、VLESSにTLSまたはREALITYを組み合わせた場合では、通信の性質がまったく異なることを理解しておく必要があります。

VLESSのユーザー認証情報も通常はUUIDです。VMessと異なり、VMess固有の時刻認証構造に依存せず、alterIdもありません。サーバー側でflowなどの拡張項目を設定できるため、クライアントでも1つずつ一致させる必要があります。よく使われる xtls-rprx-vision はXTLS Visionのフロー制御値であり、Xrayエコシステムの実装機能です。VLESSに対応するすべてのカーネルがサポートしているわけではありません。取り込み後にflowが空で、元のリンクにVisionが明記されている場合は、まずクライアントのカーネルとサブスクリプションの解析過程を確認してください。

REALITYが解決する設定レイヤーの課題

REALITYはXrayの通信セキュリティ実装で、通常は接続先サイトに関する情報をハンドシェイクに利用し、サーバーの秘密鍵とクライアント側の公開鍵によって対応関係を構築します。クライアント側には、サーバー名、フィンガープリント、公開鍵、Short ID、SpiderXなどの項目があります。サーバー側には対応する秘密鍵や、許可するサーバー名などを保存します。クライアントに必要なのは公開鍵だけで、サーバーの秘密鍵をサブスクリプションや共有リンクに記載してはいけません。公開鍵、Short ID、サーバー名のいずれかが一致しないと、接続直後に切断されることがあります。

サーバー名はクライアント上でSNIまたはserverNameと表示されることが多く、ハンドシェイク時の選択と検証に使われます。フィンガープリントには chrome など、ブラウザーのフィンガープリントを示す値がよく使われます。これは端末のブラウザーのバージョンではなく、対応するブラウザー風のハンドシェイク特性を選ぶためのものです。Short IDはサーバーが許可する値の1つで、長さと内容はサーバー設定に従う必要があります。SpiderXの既定値はスラッシュであることが多く、サーバーから指定されていない限り、経験だけで複雑なパスを追加しないでください。

XTLS Visionと転送経路

XTLS Visionの目的の1つは、直接転送に適したデータ経路を識別し、不要な再カプセル化やメモリコピーを減らすことです。転送内容自体にセキュリティ層がある場合、適切なフロー制御によって追加処理のコストを抑えられます。特に継続的な大容量通信で効果が出やすい機能です。ただし、Visionの効果はカーネル、サーバー、通信方式の組み合わせ、実際のデータ形式に左右されます。短い接続によるページ読み込みは、主にハンドシェイク、DNS、往復時間の影響を受けるため、flowを有効にするだけですべての待ち時間がなくなるわけではありません。

Visionは通常TCPと組み合わせます。対応していない通信方式と無理に組み合わせると、設定を読み込めなかったり、サーバーに拒否されたりします。クライアントの編集画面にプロトコル、通信方式、セキュリティ、flowの4グループがある場合は、サーバーが指定した完全な組み合わせを入力してください。まず protocol = vless を確認し、次に通信方式、続いて security = reality を確認します。最後にflow、公開鍵、サーバー名、フィンガープリント、Short IDを照合します。

{
  "protocol": "vless",
  "user": {
    "id": "00000000-0000-4000-8000-000000000000",
    "encryption": "none",
    "flow": "xtls-rprx-vision"
  },
  "transport": {
    "network": "tcp",
    "security": "reality",
    "serverName": "www.example.com",
    "fingerprint": "chrome"
  }
}

上記の断片は項目の階層を示すためのもので、例示用ドメイン名とユーザーIDを使用しています。実際のサーバーへ直接接続することはできません。実際の設定には、サーバーアドレス、ポート、REALITY公開鍵、Short IDも必要です。目的は、サブスクリプション変換後に各項目が正しい位置へ入っているかを確認することです。VLESSのユーザー項目、TCPの通信項目、REALITYのセキュリティ項目は互いに置き換えられません。

取り込みに失敗した場合の確認順序

まず、使用中のクライアントがREALITYとVisionに対応するXrayカーネルを実際に使っていることを確認します。次に、リンクの security=reality と flow=xtls-rprx-vision がサブスクリプション変換時に失われていないか確認します。その後、pbk またはpublicKey、sid またはshortId、sni、fpなどを確認します。共有リンクの規格によって略称が異なる場合がありますが、取り込み後の画面では対応する設定項目として表示されるはずです。ノードを保存できるのに起動時に不明な項目が出る場合は、カーネルの対応範囲が一致していない可能性が高いです。カーネルは正常に起動するのにハンドシェイクに失敗する場合は、まず公開鍵、サーバー名、Short IDを確認してください。

4. TrojanとShadowsocks：異なる2つのシンプルな構成

TrojanにおけるTLSの前提

Trojanはパスワードでユーザー認証を行い、標準TLSを接続設計の重要な基盤として使用します。クライアント設定には通常、サーバーアドレス、ポート、パスワード、サーバー名、証明書検証に関する項目が含まれます。項目数は比較的少なく分かりやすいものの、「項目が少ない」からといってTLSを無視してよいわけではありません。サーバー名はサーバー側の設定と一致させる必要があり、証明書名の検証もこの項目に依存します。サーバー名をIPアドレスへ変更すると、証明書のホスト名が一致しないことがあります。明確な診断目的でない限り、証明書検証の無効化を恒久的な対策にしないでください。

TrojanとVLESSの主な違いは、認証情報だけではありません。Trojanはパスワードを使い、VLESSはUUIDを使うのが一般的です。Trojanの通常接続はTLSに強く依存しますが、VLESSはさまざまなセキュリティ層と組み合わせられます。どちらも一部の通信方式と組み合わせられますが、具体的な対応範囲はサーバーとカーネルによって決まります。trojan:// の共有リンクを受け取った場合は、パスワード、SNI、通信方式、Host、パスを完全な状態で保持し、目立つサーバーアドレスだけを抜き出さないでください。

Trojanでよくある障害の切り分け

TLSハンドシェイクの段階で失敗する場合は、まず端末の時刻、サーバー名、証明書の有効性、対象ポートへ到達できるかを確認します。TLS確立後に認証へ失敗する場合は、パスワードを確認します。パスワードは大文字と小文字を区別する文字列で、リンク内の特殊文字は正しくURLエンコードされている必要があります。手動コピーでは、プラス記号、パーセント記号、シャープ記号がリンク構造の文字として誤って扱われ、取り込み結果が元のパスワードと異なることがあります。最も確実なのは、完全な共有リンクをクライアントへ直接取り込み、編集画面で各項目を確認する方法です。

WebSocketやgRPCなどの通信方式を使う場合は、パス、サービス名、Hostなどの項目も加わります。このとき「Trojanで接続できる」とは、Trojan認証、TLSハンドシェイク、通信層のパラメータがすべて正しいことを意味します。ログにHTTPステータスエラーが出る場合は通信パスを、証明書名のエラーが出る場合はサーバー名を、認証拒否が出る場合はパスワードを確認します。複数のスイッチを何度も切り替えるより、段階ごとに調べるほうが原因を特定しやすくなります。

Shadowsocksの暗号方式とパスワード

Shadowsocksは比較的シンプルな暗号化プロキシ構造を採用しており、クライアントとサーバーで暗号方式とパスワードを完全に一致させる必要があります。代表的なAEAD方式には aes-128-gcm、aes-256-gcm、chacha20-poly1305 があります。ハードウェアアクセラレーションに対応するデスクトップCPUとモバイルCPUでは方式によって性能が異なる場合がありますが、現代の端末ではネットワーク品質、接続数、サーバー負荷の影響が差を上回ることも少なくありません。選択時はサーバー設定を優先し、クライアント側だけでアルゴリズムを変更しないでください。

Shadowsocks 2022系の方式では、鍵やセッションの処理が改善されていますが、パスワードまたは鍵の形式は従来のAEAD方式と異なり、すべてのカーネルやサブスクリプション解析器が完全に対応しているわけではありません。方式名に 2022 が含まれている場合は、まずクライアントのカーネルが対応方式をサポートしているか確認し、その後、取り込み後の鍵が完全かを確認します。2022方式を従来のAEAD名へ変更しても、サーバー側のプロトコル仕様が異なるため互換接続にはなりません。

この2種類のプロトコルを選ぶ場面

サーバーが標準的なTrojan設定を提供し、証明書とサーバー名が明確に管理されている場合、Trojanは設定モデルを理解しやすく、TLSと認証の2段階で切り分けやすい構成です。サーバーがシンプルなShadowsocks設定を提供し、クライアントが対応する暗号方式を明確にサポートしている場合、Shadowsocksは項目が少なく、複雑なフロー制御を必要としない用途に適しています。環境を離れてどちらかを絶対的に優先することはできません。実際には、サーバーの管理方式、クライアントのカーネル、サブスクリプションが項目を完全に表現できるか、端末でTUNや複雑なルーティングが必要かを考慮してください。

v2rayN、v2rayNG、v2flyNGでは、これらのプロトコル項目が画面に表示されることがあります。ただし、表示される項目が、現在のカーネルで利用可能なすべての拡張組み合わせを意味するわけではありません。特にShadowsocksのプラグイン項目、2022方式、Trojanの特殊な通信方式は、実行カーネルが生成した設定を基準にしてください。ノードがサブスクリプション由来の場合は、更新後の元の種類を優先して確認し、名前が似たノードを項目のテンプレートとして上書きしないでください。

5. 接続速度・リソース使用量・モバイル端末の電池消費

速度は複数の通信区間で決まる

ユーザーが感じる「速度」には、少なくともDNS検索、クライアントからサーバーへの接続確立、TLSまたはREALITYのハンドシェイク、サーバーから接続先サイトへの接続、最初の1バイトを待つ時間、継続転送のスループットが含まれます。プロトコルが左右するのはその一部だけです。短いウェブページのリクエストでは、DNS、ハンドシェイクの往復、接続の再利用が影響しやすく、大容量ファイルの転送では暗号実装、メモリコピー、輻輳制御、サーバーの出口帯域が表れやすくなります。1回のノード測定だけで、差をVMess、VLESS、Trojanのいずれかに正確に帰属させることはできません。

プロトコルを比較する際は、同じ端末、同じネットワーク入口、近い時間帯、同じサーバーと接続先コンテンツを使い、通信層もできるだけそろえてください。一方がWebSocketとTLS、もう一方がTCPとREALITYなら、結果は完全な組み合わせの差を示します。テストでは新規接続と確立済み接続も分けてください。新規接続にはDNSとハンドシェイクのコストが含まれ、繰り返しのリクエストでは接続が再利用されることがあります。両者は異なる問いに答えるテストです。

CPU・メモリ・接続の再利用

暗号アルゴリズムのハードウェアアクセラレーション対応、データのカプセル化層数、同時接続数、ログレベルはいずれもCPU使用率に影響します。AES-GCMはAESハードウェア命令を備えたデスクトップCPUで高い効率を示すことが多く、対応するAESアクセラレーションがない端末ではChaCha20-Poly1305が適する場合があります。ただし、端末の種類だけで断定することはできません。VLESSと適切なフロー制御の組み合わせで一部の重複処理を減らせますが、実際の効果にはサーバーと通信方式の両方の対応が必要です。

Muxの多重化は、複数の論理接続を少数の下位接続へまとめます。頻繁なハンドシェイクのコストを下げられる一方、1本の下位接続で混雑やパケットロスが起きると、複数のリクエストが互いに影響することもあります。短いリクエストが多いウェブページでは接続確立のコストを改善できる場合がありますが、継続的なダウンロード、リアルタイム接続、ネットワーク品質の大きな変動がある環境では、Muxを無効にしたほうが安定することもあります。クライアントの既定値を出発点とし、「接続数が少ないほど速い」と単純に考えないでください。

メモリ使用量は、ルーティング規則、ドメインデータベース、DNSキャッシュ、TUNバッファ、同時接続数にも左右されます。プロトコル自体のフレームヘッダーの差だけが、GUIクライアント全体のメモリ使用量を決めるわけではありません。使用量が高い場合は、詳細ログを無効にする、大きすぎるルールセットを減らす、重複した速度測定を停止する、不要な同時処理を閉じるといった変更を行い、その結果を比較してからプロトコルの変更を検討してください。

TUNモードでリソース消費が増える理由

システムプロキシは、システムプロキシ設定に従うアプリの通信を主に引き受けるため、処理経路が比較的直接的です。TUNモードは仮想ネットワークインターフェースを作り、システムプロキシを参照しないプログラムも広く対象にできますが、IPパケット、DNS、ルーティングの照合、プロトコルスタックの変換を処理する必要があります。モバイル端末でTUNを長時間有効にすると、ウェイクアップの頻度、バックグラウンド接続の維持、DNSリクエスト、ネットワーク切り替え時の再構築が電池消費に影響します。主なコストはシステムレベルで通信を引き受けることにあり、選択したプロキシプロトコルだけに原因を求めることはできません。

ブラウザーやシステムプロキシに従うデスクトップアプリだけを使う場合は、通常システムプロキシのほうがリソースを節約できます。プロセス単位またはアプリの通信全体を引き受ける必要がある場合にTUNを検討してください。有効化後は、仮想ネットワークインターフェースを占有する別のツールを同時に動かさないようにし、LANバイパス、DNSモード、ルーティング規則も確認します。TUNは対象範囲を広げる機能であり、「より強いプロトコル」ではありません。誤ったユーザーID、公開鍵、サーバー名を修正することもできません。

モバイル端末の電池消費を左右する項目

モバイル端末の電池消費は、ネットワーク状態とバックグラウンド動作の影響を受けやすいです。電波が弱いと無線接続の維持だけで多くの電力を使います。ノードが頻繁に切断されると、再接続、DNSの再試行、接続の再構築が発生します。自動速度測定や短すぎるサブスクリプション更新間隔もネットワークを起こす原因になります。安定したノードを選び、連続的な一括測定を避け、必要に応じて更新を設定し、通信全体を引き受ける必要がない場合はTUNの使用時間を減らすのが基本です。

プロトコル層では、クライアントのカーネルが標準で対応し、項目が完全で、接続が安定する組み合わせを優先してください。理論上の処理コストが低くても、ハンドシェイクに頻繁に失敗するノードは、安定した従来構成より実際の電池消費が大きくなることがあります。v2rayNGはXrayカーネルを使用するため、REALITYやVisionなどXrayの機能を必要とする設定に適しています。v2flyNGはV2Fly系統を使用し、対応するカーネル設定との整合性を重視する場合に適しています。アプリを選ぶ際は、プロトコル機能とバックグラウンドでの安定性を併せて考え、インストールパッケージ名だけを比較しないでください。

6. V2FlyとXrayのカーネルファミリーおよび設定互換性の範囲

共通する基盤と進化の方向性

V2FlyとXrayはいずれもProject Vエコシステムのモジュール型設定思想を受け継いでいます。インバウンドはローカル通信を受け付け、アウトバウンドは接続先またはプロキシサーバーへ接続し、ルーティングは通信をどのアウトバウンドへ渡すかを決めます。DNSモジュールは名前解決の方針を提供し、通信設定はTCP、WebSocket、gRPCなどの通信方式を記述します。VMess、一部のVLESS、Trojan、Shadowsocks、基本的なルーティング構造には共通する概念が多く、多くのサブスクリプションを異なるクライアントで認識できます。

似ているからといって、設定ファイルを完全に相互利用できるわけではありません。XrayはVLESS、XTLS Vision、REALITYなどの分野で独自の機能拡張を持ち、通信やルーティングに固有の項目を追加する場合があります。V2Flyも独自のバージョンとモジュール体系に沿って機能を維持しています。あるJSONを一方のカーネルが読み込めても、もう一方がすべての項目を受け入れるとは限りません。GUIクライアントで「取り込み成功」と表示されても、それはリンクがサーバー記録へ解析されたことを示すだけです。実際の互換性は、カーネルの起動結果と接続ログで確認してください。

3つのクライアントとカーネルの位置付け

v2rayNは本サイトがデスクトップ向けに推奨するクライアントで、Windows、macOS、Linuxに対応し、サーバー一覧、サブスクリプショングループ、システムプロキシ、TUN、ルーティング設定、カーネル管理などのGUIを提供します。複数のサブスクリプション、複雑なルーティング、プロトコルのテストをデスクトップで扱いたいユーザーに適しています。一般的な設定はXrayの機能を中心に構成されるため、REALITYやXTLS Visionを取り込む際は、クライアント名だけでなく実際に有効なカーネルを確認してください。

v2rayNGはAndroid向けで、主にXrayカーネルを使用し、VLESS、REALITY、Visionのほか、一般的なVMess、Trojan、Shadowsocks設定に適しています。v2flyNGもAndroid向けですが、カーネル系統が異なり、V2Flyの設定仕様を使う用途に適しています。2つのアプリは画面上の項目が似ている場合でも、実行結果はカーネルの対応能力によって決まります。サーバーがXray固有の拡張項目を要求する場合はv2rayNGを優先し、設定が明確にV2Fly向けならv2flyNGを選択できます。

設定互換性の3つのレベル

第1層は構文互換性です。JSONの項目名とデータ型を解析できるかを確認します。第2層は機能互換性で、カーネルがそのプロトコル、通信方式、セキュリティ層を実装しているかを確認します。第3層は動作互換性です。双方が項目を受け入れても、既定値、DNS方針、ルーティング照合の細部が同じとは限りません。移行時は「設定の読み込みに成功した」だけで判断せず、名前解決、直接接続ルール、プロキシルール、UDP通信が想定どおりかも確認してください。

共有リンクの互換性にも段階があります。クライアントが vless:// を認識できても、リンク内の新しいクエリパラメータまでは認識できない場合があります。ノード本体は保持されても、flow、fingerprint、Short IDが失われることもあります。サブスクリプション変換サービスが、カーネル固有の項目を独自の中間形式へ書き換える場合もあります。このようなときは、元の共有リンクと取り込み後の編集画面を比較し、クライアントが書き出した完全な設定も確認してください。問題を一括して「プロトコル非対応」と決めつけないことが大切です。

カーネル切り替え前後の確認

v2rayNで実行カーネルを切り替える前に、現在のノードのプロトコル、通信方式、セキュリティ層、ルーティング設定を記録してください。切り替え後はクライアントを再起動して設定を完全に読み込み、起動ログに不明な項目、無効な列挙値、リソースファイルの不足がないか確認します。基本的なVMess、TCP、TLSだけを使う設定なら移行は比較的スムーズです。REALITY、Vision、特殊なDNS、カーネル固有のルーティング機能を使う場合は、項目ごとに検証してください。

モバイル端末では、複雑なノードをテストするために複数のクライアント間で何度も手動再構築することはおすすめしません。元のサブスクリプションを残したまま、対象クライアントへ再度取り込み、ノードの種類と主要項目を確認するほうが確実です。サブスクリプションが特定のカーネル向けに生成されている場合は、対応するクライアントを選んでください。インストール入口はAndroidクライアント一覧で確認できます。仮想ネットワークインターフェースとシステムルーティングが競合しないよう、2つのクライアントで同時に接続を有効にしないでください。

7. サブスクリプション・共有リンク・ネイティブJSONの互換性

よく使われる3種類の設定形式

単一の共有リンクは通常 vmess://、vless://、trojan://、ss:// のいずれかで始まり、1つのサーバーを記述します。サブスクリプションリンクは更新可能なノード集合を指し、クライアントが取得すると複数の記録を解析します。ネイティブJSON設定には、インバウンド、アウトバウンド、DNS、ルーティング、ポリシーなどの完全な構造が含まれ、表現力は最も高い一方、サーバー記録だけを受け付けるサブスクリプション画面へ直接取り込めるとは限りません。3つは用途が異なり、どれもテキストに見えるからといって相互に代用することはできません。

Base64でまとめるサブスクリプションでは、複数の共有リンクを行単位で並べてからエンコードする方法がよく使われます。Base64はエンコード方式であり、プロトコル変換機能ではありません。VLESSリンクにREALITYの項目が含まれている場合、クライアントがそのクエリパラメータを認識する必要があります。ネイティブJSONのサブスクリプションはクライアント独自の構造を使うことがあり、カーネル設定と項目名が完全に一致するとは限りません。互換性を判断するには、レスポンスが共有リンクの集合なのか、クライアント専用JSONなのか、完全なカーネル設定なのかを先に確認してください。

各プロトコルリンクの主要項目

VMessリンクは、アドレス、ポート、ユーザーID、ネットワーク種別、Host、パス、TLS、サーバー名などを含む、エンコードされたJSONオブジェクトとして使われることが多いです。歴史的な形式には複数の項目規約があるため、変換ツールによって host、sni、パスの扱いが異なる場合があります。VLESSリンクは通常UUIDをユーザー情報の位置に置き、encryption、security、type、flow、sni、fp、pbk、sidなどをクエリパラメータで表します。REALITY設定では、クエリパラメータを完全に保持することが特に重要です。

Trojanリンクはパスワードをユーザー情報として使い、クエリパラメータにSNI、通信方式、Host、パスを含められます。パスワード内の特殊文字はURLエンコードが必要です。そうしないと、シャープ記号以降がノード名、疑問符以降がクエリパラメータとして解釈されることがあります。Shadowsocksリンクには、暗号方式とパスワード全体をエンコードする形式と、ユーザー情報を個別に表す形式があります。プラグイン項目を含むリンクもあります。クライアントが ss:// プレフィックスを認識できても、指定されたすべてのプラグインや2022方式をサポートするとは限りません。

サブスクリプション取り込み後にノードが空になる

最初にクライアントでサブスクリプショングループを手動更新し、更新通知がリクエスト失敗、内容が空、解析結果がゼロのどれなのかを確認します。リクエスト失敗は、サブスクリプションアドレス、ネットワーク経路、アドレスの有効性に関係することが多く、レスポンスはあるのにノードがゼロの場合は、形式が対応していない可能性が高いです。次に、コピーしたものがサブスクリプションアドレスであり、ウェブページのアドレスや単一ノードのメモではないことを確認します。最後に、アドレスの前後へ空白、改行、中国語の句読点が混入していないか確認してください。

一部のノードだけが欠落する場合は、プロトコル別に確認します。従来のVMessは取り込めるのにREALITYノードが消える場合、解析器が新しい項目を保持していないか、カーネルの対応が不足している可能性があります。通常のShadowsocksは取り込めるのに2022方式だけが欠落する場合は、方式の対応範囲が異なる可能性があります。Trojanノードは存在するのに接続できない場合は、パスワード、SNI、通信パラメータを確認します。形式の詳細と変換の考え方については、Base64・ネイティブJSON・共有リンクの解説も参照してください。

サブスクリプション更新とローカル変更の競合

サブスクリプションのノードは通常、リモート側の記録で管理されます。クライアントでサブスクリプションノードを手動変更しても、次回の更新でローカルの項目が上書きされることがあります。ルーティング、DNS、システムプロキシを長期的に調整したい場合は、ノードを個別に編集するのではなく、クライアントの全体設定やルーティング設定を変更してください。ノードのコピーを長期保存する必要がある場合は、ローカルグループへ複製し、更新可能なサブスクリプションとの関係を明確に区別します。

サブスクリプショングループは、異なる設定元を分け、それぞれに更新間隔を設定する用途にも使えます。サーバー一覧は通常、数分ごとに更新する必要がないため、更新頻度を上げすぎないでください。モバイル端末では頻繁な更新がバックグラウンドのネットワーク活動を増やします。ノードのメモは用途の識別に役立ちますが、プロトコル認証には関係しません。ノード名を変更しても、サーバーアドレス、公開鍵、パスワードは変わらず、下位項目の欠落も修正できません。

QRコード・クリップボード・手入力

QRコードは共有リンクを図形化したものに過ぎません。スキャンに成功しても、クライアントは元のURIを解析します。そのため、QRコードの鮮明さは読み取りに影響しますが、項目の互換性を解決することはできません。クリップボードからの取り込みは、完全なリンクを1件または複数件処理するのに適しています。手入力は少数の項目を確認する場合に向いています。REALITY、WebSocket、gRPCは項目が多いため、まず完全な状態で取り込み、その後編集画面で確認するほうが、最初から手入力するより確実です。

v2rayNとv2rayNGでサブスクリプションを取り込む具体的な入口、手動更新のタイミング、ノード一覧の確認順序については、サブスクリプションリンクの取り込みガイドを参照してください。vmess://またはvless://の単一リンクを受け取っただけの場合は、共有リンクとサブスクリプションの違いを確認し、単一リンクをサブスクリプション欄へ誤って入力しないようにしてください。

8. 利用シーンに応じたプロトコル選択と移行後の検証

デスクトップでの通常利用

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを使うのがおすすめです。安定したサブスクリプションがある場合は、完全な状態で取り込み、サブスクリプションが提供するプロトコルの組み合わせを使ってください。すべてのノードをあらかじめ同じ種類へ変更する必要はありません。通常の閲覧やシステムプロキシに従うアプリでは、まずシステムプロキシを有効にします。システムプロキシを使わないプログラムまで対象にする必要がある場合に、TUNを検討してください。ノードはまず接続が安定するかを見て、その後、継続アクセス時の状態を比較します。1回の速度測定結果だけで長期的な順位を決めないでください。

サブスクリプションにVMess、VLESS REALITY、Trojan、Shadowsocksが同時に含まれている場合は、比較用に複数の種類を残せます。Xrayカーネルを使う場合、サーバーが提供するVLESS、REALITY、Visionの組み合わせは、機能面で適合しやすいことが多いです。すでに安定しているVMessやTrojan接続はそのまま使えます。Shadowsocksでは暗号方式を重点的に確認してください。プロトコル名は品質の等級ではありません。名称の新旧より、サーバーの管理状況と設定の完全性が重要です。

モバイル端末での常時接続

AndroidでXrayの拡張機能が必要ならv2rayNG、V2Flyカーネルの設定仕様が必要ならv2flyNGを選んでください。モバイルでは、できるだけ多くの機能を有効にするより、安定性、バックグラウンドでの再接続、電池消費を優先します。安定したノードを1つ選び、不要な一括速度測定を停止し、サブスクリプション更新を適切に設定してください。アプリの通信をシステムプロキシで処理できるなら、常に負荷の大きいTUNを使う必要はありません。TUNが必要な場合は、ルーティング規則を簡素化し、DNSが重複して処理されていないか確認してください。

モバイルネットワークと無線LANを切り替えると、既存のTCP接続は通常再構築が必要になります。一時的な切断は、必ずしもプロトコルの障害ではありません。切り替え後も毎回長時間復旧しない場合は、クライアントのバックグラウンド権限、システムのネットワーク状態、ノードの再接続ログを確認してください。プロトコルの変更で解決できるのはプロトコル層やハンドシェイク層の問題だけで、システムによるバックグラウンド通信の停止、サブスクリプション項目の欠落、サーバーへの到達不能は修復できません。

古い設定を現代的な組み合わせへ移行する

VMessからVLESS REALITYへ移行する場合は、サーバー側で完全な新設定を生成し、クライアントでは新しいノードとして取り込んでください。古いVMessノードのプロトコル欄だけを変更し、TLS、WebSocket、ユーザー項目をそのまま使い続けないでください。移行時はUUID、通信方式、REALITY公開鍵、Short ID、サーバー名、フィンガープリント、flowをすべて確認します。旧ノードは同じネットワークで比較できるよう、しばらく残しておきます。

従来のShadowsocks方式から2022方式へ移行する場合も、サーバーとクライアントの両方を変更する必要があり、古いパスワード形式をそのまま再利用することはできません。Trojanで証明書やドメインを変更した場合は、サーバー名と、それに関連する通信Hostを更新する必要があります。どの移行でも、まず基本接続を確認し、その後で複雑なルーティング、TUN、カスタムDNSを戻してください。一度に多くを変更すると、ログから原因を特定しにくくなります。

障害の症状ごとの優先確認項目

繰り返し実行できる検証手順

1つ目に、元の設定のプロトコル、通信方式、セキュリティ層、実行カーネルを記録します。2つ目に、新しい設定を取り込みますが、元のノードはまだ削除しません。3つ目に、複雑なルーティングと追加のDNS書き換えを無効にし、カーネルが起動するか、サーバーへ接続できるか、基本的なドメインへアクセスできるかだけを確認します。4つ目に、システムプロキシ、ルーティング、DNS、TUNを順番に戻し、項目を1つ戻すごとに簡単なアクセスをテストします。5つ目に、ネットワーク切り替えや端末のスリープ後に復旧するか観察します。6つ目に、実際の利用状況で新規接続、連続アクセス、継続転送を比較します。

ログの読み取りも階層に沿って行います。設定解析エラーが起動段階で出る場合は、項目とカーネルを確認します。ハンドシェイクエラーが接続段階で出る場合は、認証情報とセキュリティ層を確認します。名前解決エラーはDNSを確認します。特定のアプリだけがアクセスできない場合は、システムプロキシ、TUN、ルーティングを確認します。ログの段階と設定レイヤーを対応させることで、すべての問題を「ノードが使えない」と一括りにせずに済みます。

初回接続を早く完了したい場合は、はじめにの基本手順に沿って進めてください。対応するクライアントをまだインストールしていない場合は、インストールパッケージページでv2rayN、v2rayNG、v2flyNGを選択できます。Windows版のインストールやデスクトップ版とWPF版の違いについては、v2rayN Windowsインストール・設定完全ガイドを参照してください。接続が完了してから本ガイドへ戻ってプロトコル項目を確認するほうが、最初からカーネル、ルーティング、通信パラメータを同時に変更するより、原因を説明しやすい結果になります。