V2Rayプロトコルとカーネル選びのリファレンス

クライアント上の1つのノードは、通常1つのプロトコルだけで構成されるものではなく、複数のパラメータ層を組み合わせたものです。一般的なVLESSノードを例にすると、基盤の接続にはTCP、外側のセキュリティにはTLSやREALITY、データの搬送にはWebSocket、gRPC、HTTP Upgrade、XHTTPなどが使われます。ノード一覧では読みやすさを優先して地域、プロトコル略称、回線情報だけを表示し、完全なパラメータはサブスクリプションに格納されていることが多いものです。そのため、ノードを比較する際に「VLESS」と「VLESS + TCP + REALITY」を同じ粒度で扱うことはできません。VMessと表示された2つのノードを見て、接続特性が完全に同じだと判断するのも誤りです。

正しい確認順序は、まずクライアントが使用するカーネルを確認し、次にアプリケーション層のプロトコル、トランスポート方式、セキュリティ層を確認し、最後にアドレス、ポート、ユーザー識別子、サービス名などの接続パラメータを確認することです。カーネルは機能を認識できるかどうかを決め、プロトコルは認証とデータのカプセル化方式を決めます。トランスポート層はデータの運搬方法を決め、セキュリティ層は暗号化ハンドシェイクとサーバー認証に関わる処理を担います。具体的なパラメータは、対象サービスへ到達できるかどうかを左右します。どこか1層でも一致しないと、タイムアウト、ハンドシェイク失敗、設定の起動不能、サブスクリプションのインポート後にフィールドが消えるといった症状につながります。

5種類の用語は同じ階層ではない

VMess、VLESS、Trojan、Shadowsocksは、通常ノードの主要プロトコルとして扱われます。一方、REALITYはXrayが提供するトランスポートセキュリティ機能に近く、実際の設定ではVLESS、TCP、フロー制御などと組み合わせて使われます。REALITYをVLESSと同じ階層のプロトコルだと単純に考えると、選定時に重要な条件を見落とします。たとえば、クライアントがVLESSを認識できても、現在のカーネルがサブスクリプション内のREALITYパラメータに対応しているとは限りません。ノード名にREALITYとあっても、主体プロトコル、トランスポート方式、サーバー名などのフィールドを確認する必要があります。

非互換を除外してから性能を比較する

選定の第一原則は、使えることを最優先にすることです。サブスクリプションがXray拡張に依存しているのに、クライアントがV2Flyカーネルで動作しているなら、遅延やスループットを比較しても意味がありません。まずカーネルが設定を完全に読み込めることを確認し、その後に実際の接続テストで回線品質を判断します。遅延はローカルからサーバーまでの1回のテスト時間にすぎず、ダウンロード速度を意味しません。同じプロトコルでも、ネットワーク経路、サーバー負荷、トランスポート構成によって結果は大きく変わります。プロトコル名は技術的な特徴を判断する手がかりですが、実際の回線テストの代わりにはなりません。

第二の原則は、不要な階層を増やさないことです。2つのノードの回線品質が近いなら、通常はクライアントが標準対応し、パラメータが少なく、追加変換を必要としない構成を優先します。トランスポートのカプセル化を1層追加するごとに、ヘッダー、状態管理、トラブルシューティングの箇所が増えます。ただし、その負荷が明確に現れるかは、パケットサイズ、接続数、端末性能によって異なります。「階層が少ない」から必ず速いとは限らず、設定項目が多いから高機能とも限りません。現在のカーネル、端末、サーバー設定に合う最短経路を見つけることが選定の目的です。

第三の原則は、切り戻し用の構成を残すことです。サブスクリプションにVLESS、Trojan、VMess、Shadowsocksのノードが同時にある場合は、現在のカーネルに最も適した種類を先に選び、比較用として構成がシンプルなノードも残しておきます。接続に問題が起きたとき、同じ地域・同じ回線で異なるプロトコルのノードを交差テストすれば、回線、プロトコルパラメータ、クライアントカーネルのどこに問題があるかを切り分けられます。インポート、更新、ノード切り替えを復習する場合はv2rayN設定ガイドへ、インストールパッケージを選び直す場合はダウンロードセンターからOSを選択してください。

各プロトコルの違いは、まず設計目標に由来します。VMessはProject Vの初期に形成された主要プロトコルの1つで、ユーザー認証、時刻検証、データ暗号化、トランスポートを1つの構造にまとめています。エコシステムが成熟しており、旧来のサブスクリプションで広く使われ、V2FlyとXrayの双方が基礎機能を比較的完全にサポートしている点が長所です。その一方で、プロトコル内部が担う処理が多く、設定時にはユーザー識別子、暗号化方式、時刻の正確性、サーバーとクライアントのパラメータ一致を確認する必要があります。安定して動作しているVMessノードなら、新しいプロトコル名が登場しただけで移行する必要はありません。新規設定では、サーバーの機能とクライアントのカーネルを踏まえて判断してください。

VMess：包括的な仕組みと過去との互換性

VMessはユーザー識別子で認証し、時刻に関係する検証ロジックも備えています。端末のシステム時刻が大きくずれていると接続に失敗することがあるため、VMessの問題を調べる際は時刻同期を基本確認項目に含めてください。VMessには複数の暗号化方式や互換設定の表現が存在し、サブスクリプションパーサーは一般的なフィールドをクライアント内部形式へ変換します。既存サーバー、既存サブスクリプション、複数のProject V系カーネルとの互換性が必要な用途に向いています。弱点は単純に「遅い」ことではなく、VLESSよりプロトコル内部の処理経路が完全で、理論上は計算とカプセル化の負担がやや増えることです。現代のデスクトップ端末では、その差は多くの場合、回線差の影響より小さいものです。

VLESS：暗号化をセキュリティ層に委ねる設計

VLESSはより軽量な設計で、主体プロトコルは主にID管理とデータ転送を担い、プロトコル内部で独自の暗号化機構を重ねて構築しません。実際の運用では、TLSやREALITYなどのセキュリティ機能と組み合わせるのが一般的です。役割が明確で、VLESSが接続IDを管理し、セキュリティ層がハンドシェイクと暗号化を処理し、トランスポート層がデータを運びます。そのため、構成が完全に組み合わされているかどうかが重要です。アドレス、ポート、ユーザー識別子だけでは十分とは限らず、サーバー名、フロー制御、トランスポート種別、パス、公開鍵、短い識別子などが欠けると接続できないことがあります。

VLESSはXrayエコシステムの重要なプロトコルと見なされがちですが、基本的なVLESS機能を扱えるクライアントが1つだけというわけではありません。見分けるべきなのは拡張項目です。ノードにREALITY、Visionフロー制御、新しいトランスポートフィールドなどが含まれる場合は、それらを明確にサポートするXrayカーネルを優先してください。通常のVLESSとTLSの組み合わせなら、互換範囲は一般に広くなります。「VLESS」という4文字だけで判断せず、ノード詳細を開いてflow、security、network、serverNameなどの値を確認しましょう。

Trojan：TLS接続を中核とする構造

TrojanはTLSに依存した接続構造を持ち、パスワードを認証情報として使用します。設定は分かりやすく、一般的なフィールドにはサーバーアドレス、ポート、パスワード、サーバー名、証明書関連のオプションがあります。TLSが構成上必須であるため、サーバー名の入力ミス、端末時刻の異常、サーバー証明書の変更はハンドシェイクに直接影響します。クライアントに「安全でない接続を許可」のような項目があっても、通常の修復スイッチとして扱うべきではありません。まずサーバー名とサーバー側のパラメータを照合し、認証経路をサーバー設定と一致させるのが適切です。

Trojanの運用コストは、複雑なプロトコル内部の暗号化よりも、標準TLS処理とネットワーク経路から主に発生します。サーバーがTrojan方式で接続を提供し、サブスクリプションのフィールドが完全で、クライアントカーネルが安定して対応している場合に適しています。VLESS + TLSと比べると、どちらもTLSを使う可能性がありますが、認証構造とフィールドの意味は異なります。プルダウンのプロトコル名を変えるだけで相互変換することはできません。移行にはサーバー側の対応入口と、クライアント側での完全なパラメータ再インポートが必要です。

Shadowsocks：シンプルな構造だが暗号化方式の一致が必須

ShadowsocksはSSとも略され、シンプルな暗号化プロキシ構造を重視しています。基本設定は通常、サーバー、ポート、パスワード、暗号化方式です。項目が少なく見えても、暗号化方式は厳密な一致が必要で、クライアントとサーバーが異なると接続できません。現代の実装では対応する暗号化方式の範囲が異なる場合もあり、古いクライアントがSSリンクを認識できても、指定された方式を実行できるとは限りません。インポートは成功したのに起動できない場合は、カーネルログに未対応のcipherやmethodが出ていないか確認し、クライアント更新、カーネル切り替え、別ノードの選択を判断します。

この4種類のプロトコルに、環境を離れて適用できる固定ランキングはありません。既存のVMessサーバーが安定しているなら、互換性そのものに価値があります。サブスクリプションにVLESS + REALITYの完全なパラメータがあり、クライアントがXrayカーネルなら、その組み合わせを優先してテストできます。TrojanはサーバーがTrojan構成で接続を提供する場合に適し、Shadowsocksは項目が明確で実装範囲の広いシンプルな選択肢です。最終的な基準は、サーバーが何を提供しているか、現在のカーネルが完全に実装できるか、回線が安定しているか、端末の接続・バッテリーコストを抑える必要があるかです。

主体プロトコルを決めたら、次はトランスポートとセキュリティ設定です。接続問題の多くはプロトコルそのものではなく、パス、サービス名、サーバー名、フィンガープリント、フロー制御のフィールドが正しくインポートされていないことが原因です。クライアントの「トランスポートプロトコル」は通常、TCP、WebSocket、gRPC、HTTP Upgrade、XHTTPなどの搬送方式を指します。「トランスポート層のセキュリティ」にはTLSやREALITYがよく使われます。両方のフィールドは組み合わせられますが、任意の組み合わせが有効とは限らず、サーバーが開放している入口と1項目ずつ一致させる必要があります。

TCPと追加トランスポートのカプセル化

TCPの直接接続は最も理解しやすい構造です。主体プロトコルのデータをTCP接続上に直接載せるため、追加フィールドは通常少なくなります。項目が少ないほど確認経路は短くなりますが、実際の性能はネットワーク品質、輻輳制御、サーバー設定にも左右されます。WebSocketは接続にHTTP Upgrade処理を加え、パスなどのパラメータを使用します。パスが1文字違うだけでも失敗します。gRPCでは通常サービス名が必要で、長時間接続や多重化の特性を持つ場合があります。クライアントとサーバーでサービス名、モード、TLS設定を一致させてください。HTTP Upgradeもアップグレード要求の関連パラメータに依存します。XHTTPは比較的新しいトランスポート機能なので、使用前に現在のXrayカーネルとサブスクリプションパーサーの双方が関連フィールドを認識できることを確認してください。

「追加のカプセル化が多いから必ず遅い」と判断してはいけません。短時間の接続、小さなパケット、頻繁なリクエストでは、ハンドシェイク回数や接続多重化方式の差が大きく現れます。継続的な大容量通信では、回線帯域、パケットロス、輻輳のほうが重要です。クライアントの多重化も高ければよいとは限りません。少数の基盤接続に複数の論理接続を載せられますが、不安定なネットワークでは1本の基盤接続のブロックが複数のリクエストに同時に影響することがあります。デフォルト設定で正常に動作する場合は、まず変更せず、ログと実際のアプリ動作を見ながら調整してください。

TLSに必要な情報

TLS構成では通常、少なくともサーバー名が必要です。接続アドレスはドメイン名でもネットワークアドレスでも構いませんが、ハンドシェイクで使用するサーバー名はサーバー側の指定どおりに入力する必要があります。クライアントのフィンガープリントはハンドシェイク特性を示す項目なので、サブスクリプションの値またはクライアントの互換性のあるデフォルト値に従い、サーバー設定が不明なまま無作為に変更しないでください。ALPNやallowInsecureにも明確な意味があります。ALPNはアプリケーションプロトコルのネゴシエーションに関わり、認証確認をスキップするオプションは本人確認の流れを変えるため、一般的なネットワーク障害への恒久的な対処には適しません。

REALITYはセキュリティ構成であり、単独の置き換え項目ではない

REALITYは通常Xrayカーネルで実装され、VLESS、TCP、Visionなどの機能と組み合わせて使われます。一般的なクライアント項目には、サーバー名、公開鍵、短い識別子、フィンガープリント、flowがあります。公開鍵はサーバー設定から取得し、短い識別子はサーバーが許可した値を使い、サーバー名もサーバー側の指定を満たす必要があります。どれかの項目が空、サブスクリプション変換時に切り詰められている、コピー時に余計な文字が混入していると、ハンドシェイクに失敗することがあります。REALITYノードに接続できない場合は、まず詳細を開いてこれらの値を照合し、次にカーネルログを確認してください。TCP、WebSocket、TLSを闇雲に切り替えるだけでは解決しません。

共有リンクから組み合わせフィールドを確認する

一般的な共有リンクでは、URIの先頭にプロトコル、ホスト部分に主体パラメータ、クエリパラメータにトランスポートとセキュリティのフィールドが記載されています。サブスクリプションツールによって、フィールド名、大文字・小文字、エンコードの扱いが異なる場合があります。インポート後は、ノードが一覧に表示されたかだけでなく、クライアントのノード編集画面で確認してください。以下の例は構造のみを示したもので、接続情報は含みません。各値はフィールド間の関係を説明するためのものです。

vless://[email protected]:443?type=tcp&security=reality&flow=xtls-rprx-vision&sni=example.invalid&fp=chrome&pbk=PUBLIC_KEY&sid=SHORT_ID#VLESS-REALITY

この構造では、vlessが主体プロトコル、type=tcpがトランスポート方式、security=realityがセキュリティ層、flowがフロー制御を示します。sni、fp、pbk、sidはそれぞれサーバー名、フィンガープリント、公開鍵、短い識別子に対応します。アドレス、ポート、ユーザー識別子だけを残すと、一見完全でも実際にはハンドシェイクを完了できないノードになります。サブスクリプション変換後にこれらのフィールドが消えていたら、元のサブスクリプションから再インポートするか、該当フィールドを保持できる形式を使ってください。

構成が正しいかどうかは3段階で判断できます。第一に、カーネルが設定を読み込めるかを確認します。起動時に未知のフィールドが報告されるなら、通常はカーネルまたは形式の互換性が問題です。第二に、ネットワーク接続を確立できるかを確認します。すぐにタイムアウトする場合は、アドレス、ポート、ローカルネットワークを調べます。第三に、ハンドシェイク段階のログを確認します。サーバー名、公開鍵、認証、サービス名に関するエラーがあれば、セキュリティ層とトランスポートフィールドを順に照合します。この層別の調査は、ノード名を何度も変更するより速く、クライアント更新、カーネル切り替え、サブスクリプション再取得のどれが必要かも明確にできます。

プロトコル性能は、接続確立時間、持続スループット、CPU使用率、メモリ使用量、接続安定性、端末のスリープ解除頻度に分けて考える必要があります。クライアントに表示される遅延は通常1回のテストだけを示し、大容量ファイルのダウンロード速度やバッテリー消費を直接表すものではありません。同じVLESSノードでも、デスクトップの有線ネットワークとモバイルネットワークでは結果が大きく異なることがあります。同じプロトコルでも、トランスポート方式、回線、サーバー負荷が違えば、プロトコル自体の差より大きく変動する場合があります。

接続確立時間を構成する手順

新しい接続では、DNS名前解決、TCP接続、セキュリティハンドシェイク、プロトコル認証、上位リクエストを順に行うことがあります。TLSやREALITYを使うと対応するハンドシェイクが増えますが、接続の再利用、セッション再開、安定した長時間接続によって重複コストを減らせます。WebSocketやgRPCなどのトランスポートにも、それぞれ確立処理があります。短時間に大量の小さなリクエストを開く場合は接続確立コストが目立ち、継続通信ではネットワーク経路、輻輳、パケットロスからの復旧が重要です。テストでは少なくとも初回表示、再訪問、継続通信を分けて確認してください。

VMessは内部処理が包括的で、理論上は軽量なVLESSより計算経路が長くなります。VLESSはセキュリティの役割を外側に委ねるため主体プロトコルが簡潔です。Trojanの主なコストはTLSとデータ転送に集中し、Shadowsocksは選択した暗号化方式と実装に左右されます。これらの差は、低性能端末、多数の同時接続、小さなパケットが集中する環境ほど現れやすくなります。現代のデスクトップCPUや一般的なWeb閲覧では、回線品質が依然として主な要因です。数ミリ秒の単発差をプロトコルの恒久的な順位とみなすのは適切ではありません。

メモリとCPU使用率は接続モデルで変わる

メモリ使用量はプロトコルだけで決まりません。クライアントのGUI、カーネルプロセス、ルールセット、DNSキャッシュ、ルーティングデータ、接続状態もメモリを使用します。デスクトップクライアントのv2rayNでは、UIプロセスとカーネルプロセスが別々に処理を担うことが一般的です。v2rayNGとv2flyNGはAndroid上でシステムのネットワークサービスとも連携します。TUNを有効にしたり、大きなルーティングデータを読み込んだり、多数の接続を維持したりすると、プロトコル変更より使用量が大きく変わることがあります。調査時はまずルーティングとDNSを同じ条件に保ち、同じ回線の異なるプロトコルノードを比較してください。

CPU使用率は、暗号化、ハンドシェイク、データコピー、圧縮、ログレベル、接続数に左右されます。ログを詳細にしすぎると、継続的な書き込み自体がリソース消費を増やします。速度測定中にCPU使用率が一時的に上がるのは正常です。注目すべきなのは、アイドル時にも高負荷が続くか、アプリがアクセスを停止した後も接続が頻繁に動作するか、カーネルログが再試行を繰り返していないかです。再試行が続く場合、バッテリーとCPUの消費はプロトコル効率ではなく、設定ミスやネットワーク到達不能による接続ループが原因であることが多いものです。

モバイルのバッテリー消費はスリープ解除と再接続が左右する

モバイル端末のバッテリー消費を「このプロトコルのほうが省電力」と単純化するのは誤りです。ネットワーク切り替えの頻度、バックグラウンド接続維持、接続の安定性、DNSリクエスト数、TUNの適用範囲、ルーティングルールの複雑さ、失敗時の再試行が大きく影響します。安定した長時間接続は、タイムアウトと再接続を繰り返す状態より省電力になりやすいものです。Wi-Fiからモバイルネットワークへ切り替えると既存接続の再構築が必要になる場合があります。ノードのハンドシェイクが失敗して短時間に再試行されると、システムが頻繁に起動され、バッテリー消費が急増します。

v2rayNGまたはv2flyNGでバッテリー消費を抑えるには、まず安定したノードを選び、不要な全体接続や高頻度の速度測定を減らします。一部のアプリだけで接続を使う場合は、クライアントのアプリ別設定やルーティング機能で処理範囲を絞ります。すべての通信をTUNへ通す場合は、ループ転送を避けるためDNSとルーティングを確認してください。ノードは最低遅延ではなく、ハンドシェイクが安定しパケットロスが少ない構成を優先します。プロトコル間に明確な機能差がないなら、わずかなカプセル化コストより安定性を重視するほうが実用的です。

最終的には3段階で判断できます。まず遅延テストで明らかに到達できないノードを除外し、次に実際のアプリで初回接続と継続通信を確認し、最後にアイドル時の再接続とリソース使用量を観察します。デスクトップではv2rayNのログで接続失敗の頻度を確認できます。モバイルではネットワーク切り替え後に復旧するか、タイムアウトが続くかを重点的に見ます。サイト内のノード選びの記事では、遅延、倍率、地域、プロトコルの4つの観点を詳しく解説しています。本章と併せてご利用ください。

V2FlyとXrayはいずれもProject Vに関連する技術エコシステムに由来し、複数の共通する基礎プロトコルやルーティング概念を扱えます。しかし、名前を自由に置き換えられる同一プログラムではありません。それぞれが機能、設定フィールド、拡張機能を個別に維持しています。VMess、通常のVLESS、Trojan、Shadowsocks、ルーティングルール、DNSなどの基礎機能には多くの共通点がありますが、REALITY、Vision、特定のトランスポート方式、新しい拡張フィールドについては、各カーネルの実装状況で判断する必要があります。

共通基盤と設定の類似性

両方のカーネルは、インバウンド、アウトバウンド、ルーティング、DNSを中心とした設定モデルを採用しています。インバウンドはローカルアプリがカーネルへ通信を渡す方法、アウトバウンドはカーネルが宛先やリモートサービスへ接続する方法、ルーティングルールはどのアウトバウンドへ渡すか、DNSは名前解決の方針を示します。クライアントは通常、GUIのノードと設定から完全な構成を生成するため、一般ユーザーがすべてを手書きする必要はありません。共通概念を理解しておけば、クライアントやカーネルを切り替えた際に、問題がノードプロトコル、ルーティング、DNS、GUIによる設定生成のどこにあるか判断できます。

基礎フィールドの名前が同じでも、すべての値をそのままコピーできるとは限りません。あるカーネルでは拡張機能であるフィールドが、別のカーネルでは認識されない、無視される、異なる構造を取る場合があります。典型的なのは、サブスクリプションにXray固有の機能が含まれているのに、変換ツールが汎用的なV2Rayフィールドだけを出力するケースです。その結果、ノードはインポートできても、flow、REALITY公開鍵、新しいトランスポートパラメータが失われます。ノード名とアドレスは残っていても、ハンドシェイクに必要なフィールドが不完全になります。

Xrayが得意とする機能

XrayはVLESS拡張、REALITY、Vision、一部のトランスポート機能で明確な方向性を持っています。サブスクリプションにこれらのキーワードがある場合は、Xrayカーネルを優先すると変換を減らせます。v2rayNとv2rayNGはこの種のノードを扱うためによく使われます。v2rayNはWindows、macOS、Linuxのデスクトップ環境向け、v2rayNGはAndroid向けです。クライアント名とカーネル名は同じではないため、実際に動作しているカーネルは設定、ログ、概要画面で確認してください。

Xrayを使うからといって、すべてのノードをVLESSに変更する必要はありません。Xrayは複数のプロトコルを扱えるため、互換性や比較用にVMess、Trojan、Shadowsocksを残すのも合理的です。カーネル選択は機能セットの選択であり、プロトコル選択は具体的な接続入口の選択です。両者には関係がありますが同じものではありません。サーバーがVMessしか提供していない場合、XrayカーネルでもVMessパラメータで接続する必要があり、ローカルでVLESSへ変更することはできません。

V2Flyが得意とする機能

V2FlyはProject Vのオープンな設定体系を引き継ぎ、VMess、VLESSの基礎機能、Trojan、Shadowsocks、ルーティング、DNSなどを独自に進化させています。v2flyNGはAndroidでV2Flyカーネルを使う代替クライアントで、サブスクリプションが主に汎用プロトコルで構成され、V2Fly実装を明確に使いたい場合に適しています。サブスクリプションにXray側だけが実装するパラメータが含まれる場合、v2flyNGでは完全に読み込めない可能性があります。その場合はv2rayNGを選ぶか、サーバーが提供する互換ノードを使用してください。

カーネル切り替え前に保存するもの

カーネルを切り替える前に、現在のクライアント、ノード名、主体プロトコル、トランスポート方式、セキュリティ種別、ルーティングモード、DNS設定を記録してください。クライアントが設定のエクスポートに対応している場合は、比較用に保存します。切り替え後すぐに元のサブスクリプションを上書きせず、まず少数のノードをインポートして基本接続を確認し、その後にルーティングやTUNなどの高度な設定を戻します。こうすれば、カーネル互換性の問題と高度な設定の問題を切り分けられます。切り替え後にすべてのノードが起動できない場合は設定読み込みログを確認し、REALITYだけ失敗するなら拡張フィールドを重点的に確認します。ノードは接続できても一部のドメインだけ異常なら、DNSとルーティングを確認してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.invalid"],
        "outboundTag": "direct"
      }
    ]
  }
}

上の断片は、両方のカーネルで理解しやすいルーティング構造を示しています。ドメインが指定ルールに一致した場合、directという名前のアウトバウンドへ渡します。これは完全な設定ではなく、クライアントにはインバウンド、リモートアウトバウンド、DNSなどの生成も必要です。手動編集では、outboundTagが実在するアウトバウンドのタグと一致していなければなりません。GUIクライアントは通常、この関連付けを自動処理します。プロトコルの選択とサブスクリプションのインポートだけなら、この断片をクライアントへ直接貼り付ける必要はありません。

カーネル更新の主な目的は、プロトコル修正、互換性、動作改善を得ることです。「最新だからすべての古い設定を作り直す必要がある」と考えてはいけません。クライアント更新後は元の設定を残してテストし、ログで古いフィールドが使えない、またはサーバーの入口が変更されたと明確に示された場合だけノードを修正します。インストールパッケージとクライアントの対応はダウンロードセンターを基準にしてください。ページでは4つのプラットフォーム別にv2rayN、v2rayNG、v2flyNGへの固定入口を案内しています。

サブスクリプションは、複数のノードパラメータをクライアントへ渡すためのものです。複数の共有リンクを含む場合もあれば、構造化設定やサーバー専用形式を使う場合もあります。クライアントがサブスクリプションをインポートすると、まずテキストをダウンロードし、各レコードを解析し、最後に内部ノードモデルへ変換します。互換性の問題はどの段階でも起こり得ます。アドレスにアクセスできない、文字コードが異常、共有リンクのフィールドが欠けている、パーサーが新しいパラメータを認識しない、クライアント内部モデルに対応フィールドがない、といった原因です。「サブスクリプション更新成功」はリクエストが完了したことを示すだけで、すべてのノードが完全に解析されたことを意味しません。

共有リンクは単一ノードの受け渡しに向いている

VMess、VLESS、Trojan、Shadowsocksには、それぞれ一般的な共有リンク形式があります。リンクには主体の認証情報、サーバー、ポート、トランスポート、セキュリティパラメータが1行のテキストとしてエンコードされています。コピーやインポートが簡単な一方、プロトコル拡張に伴ってフィールド名が増え、新しいフィールドへの対応速度はパーサーごとに異なります。特にVLESS + REALITYでは、公開鍵、短い識別子、フィンガープリント、サーバー名、flowをすべて保持する必要があります。サブスクリプション変換サービスが古いVLESSフィールドしか認識しない場合、セキュリティパラメータのない通常ノードへ変換されてしまいます。

VMessの共有情報は、アドレス、ポート、ユーザー識別子、ネットワーク種別、ホスト、パス、TLSなどを含むエンコード済みJSONで表現されることがあります。生成ツールによってフィールドの略称やデフォルト値の扱いは完全には一致しません。TrojanとShadowsocksのリンク構造は比較的直接的ですが、パスワード、暗号化方式、サーバー名なども正しくエンコードする必要があります。リンクに特殊文字がある場合はURIエンコードが必要です。手動コピーで末尾のクエリパラメータを落としたり、改行をフィールドへ混入させたりすると解析エラーになります。

完全設定とクライアント用サブスクリプションは用途が異なる

完全なカーネル設定には通常、インバウンド、アウトバウンド、ルーティング、DNS、ログなどの全体設定が含まれ、カーネルを直接動かすために使われます。クライアント用サブスクリプションは主にリモートノードを記述し、クライアントがローカルのシステムプロキシ、TUN、ポート、ルーティング設定と組み合わせて最終設定を生成します。完全設定を通常のノードサブスクリプションとしてインポートしても、全体ルールが保持されるとは限りません。ノード共有リンクを完全設定として使う場合も、ローカルのインバウンドとルーティングが不足します。拡張子よりもファイルの用途を確認することが重要です。

v2rayNのサブスクリプショングループは複数のリモートノードの管理に適しており、インポート後はノード編集画面でプロトコル、トランスポート、セキュリティフィールドを確認できます。v2rayNGとv2flyNGもサブスクリプションをインポートできますが、使用するカーネルの方針は異なります。汎用的なVMessやShadowsocksノードは通常移行しやすい一方、Xray拡張を含むVLESSノードはv2rayNGで優先的に確認してください。すべてのクライアントでインポートできるようにするために重要なフィールドを削除してはいけません。互換範囲が広がっても、正しい設定を失えば意味がありません。

サブスクリプション変換で変わる可能性があるもの

サブスクリプション変換は、名前の統一、ノードの絞り込み、別クライアント形式への出力に使われます。変換中にノード名が書き換えられたり、未知のクエリパラメータが削除されたり、トランスポート名が変換されたり、デフォルトのフィンガープリントが設定されたり、空の値が省略されたりすることがあります。通常のプロトコルでは問題にならない処理でも、拡張フィールドに依存する構成では、未知のフィールドを削除すると接続の意味が変わります。変換結果を使う場合は、1つのノードを元のパラメータと照合し、protocol、network、security、flow、serverName、publicKey、shortId、path、serviceNameを重点的に確認してください。

サブスクリプション更新の安全な手順

更新前に、現在使えるノードとルーティングモードを記録します。更新後は追加、削除、プロトコルの変化を確認し、手動設定をすぐに一括上書きしないでください。構造が明確なノードを1つ選び、カーネルが起動できることを確認してから実際の接続をテストします。最後に自動選択、負荷分散、TUNを戻します。新しいサブスクリプションですべてのノードが使えなくなった場合は、以前のグループと比較してください。問題がダウンロード段階に集中していればアドレスを、ノード解析段階なら形式を、ハンドシェイク段階ならプロトコルパラメータを確認します。

サブスクリプションアドレスは設定用の認証情報です。管理下にある端末と信頼できるクライアントだけで使用し、公開ページやスクリーンショットに貼り付けないでください。端末を移行する場合は、新しいクライアントで元のサブスクリプションを再登録し、グループとルーティングを確認するのが安全です。何度もコピーした単一ノードのテキストに頼らないでください。解析エラーが出た場合はV2Ray実行ログの読み解き方を参照し、rejected、timeout、DNS、フィールドエラーで障害段階を切り分けます。

プロトコル選びは最終的にクライアント画面で行います。本サイトでは3つのクライアントを扱います。デスクトップはv2rayN、Androidはv2rayNG、V2Flyカーネルが必要な場合はv2flyNGを優先します。いずれもGUIでノードを管理しますが、フィールドの配置や表示項目は異なります。サブスクリプションをインポートしたら、まず現在のカーネルでノードを読み込めることを確認し、その後に手動編集を行います。手動編集は既知のフィールドの修正に適しており、サーバーが提供していない情報を推測で補うためのものではありません。

v2rayN：デスクトップの主要入口

v2rayNはWindows、macOS、Linuxに対応し、複数のサブスクリプション、デスクトップのシステムプロキシ、TUN、ルーティング、複数のカーネルを管理できます。ノード一覧から編集を選ぶと、通常はアドレス、ポート、ユーザー識別子またはパスワード、トランスポートプロトコル、トランスポート層のセキュリティ、サーバー名などを確認できます。VLESSノードがREALITYを使う場合は、flow、公開鍵、短い識別子、フィンガープリントも確認してください。画面のバージョンによってフィールドの分類は変わることがありますが、配置が変わってもフィールドの意味は変わりません。

デスクトップでv2rayNを優先する理由は、ノード管理、カーネル実行、システムプロキシの入口を1つの画面に集約し、本サイトで扱う複数のプロトコルに対応できるためです。ノードを選択したら、まず実際の接続をテストし、その後にシステムプロキシやTUNを有効にします。ノードテストに失敗しても、システムプロキシのモードを連続して変更しないでください。システムプロキシはアプリの通信をクライアントへ渡す方法を決めるだけで、リモートノードのハンドシェイクパラメータは修正できません。設定読み込み失敗がログに出る場合はプロトコルとカーネルを、接続確立後もアプリが利用できない場合はシステムプロキシ、ルーティング、DNSを確認します。

v2rayNG：Androidで選ぶXrayクライアント

v2rayNGは、Xrayのプロトコル拡張を必要とするAndroid設定に適しています。サブスクリプションをインポートしたら、ノード詳細でプロトコル、トランスポート、TLSまたはREALITY関連のフィールドを確認できます。接続を開始すると、クライアントはシステムが提供するネットワークインターフェースを通じて対象の通信を引き受けます。一部のアプリだけで接続を使う場合は、アプリ別設定で範囲を制御できます。全体接続を使う場合はDNS、ルーティング、バッテリー消費に注意してください。REALITYやVisionなどの構成は、サブスクリプションのフィールドが完全であることを前提に、まずv2rayNGでテストするのが適切です。

モバイルネットワークではアドレス変更や回線切り替えが頻繁に起きるため、Wi-Fiでは正常でも切り替え後に一時中断することは、必ずしもプロトコル非互換を意味しません。いったん停止して再接続し、ログでセッションが再確立されるかを確認してください。タイムアウトが続く場合は、同じサブスクリプションの安定したノードへ切り替えます。高頻度の速度測定をバックグラウンドで常時実行しないでください。測定は接続を積極的に作成し、リソースを消費します。普段は安定したノードと、異なるプロトコルの予備ノードを1つずつ残しておくと、障害範囲を素早く判断できます。

v2flyNG：V2Flyカーネルの選択肢

v2flyNGの使い方は一般的なAndroid GUIクライアントに近いものの、カーネルはV2Fly系です。サブスクリプションがVMess、通常のVLESS、Trojan、Shadowsocksを中心としている場合、V2Fly実装での動作確認に使えます。ノードにREALITY、Vision、その他のXray拡張が含まれる場合、インポートには成功しても実行時に失敗することがあります。これは機能範囲の問題であり、フィールドを削除して無理に動かすべきではありません。v2rayNGへ切り替えるか、サブスクリプションが提供する汎用プロトコルのノードを選んでください。

画面上のフィールドを統一的に読む方法

アドレスとポートは接続先を決めます。ユーザー識別子はVMessまたはVLESSの認証に使われ、パスワードはTrojanとShadowsocksでよく使われます。暗号化方式は主にShadowsocksで使用します。トランスポート種別はTCP、WebSocket、gRPCなどの搬送方式を決めます。Host、path、serviceNameは各トランスポートのパラメータです。securityはTLSまたはREALITYを示し、serverNameはセキュリティハンドシェイクに使われます。flowは特定のVLESS構成でよく登場します。クライアントによって表示名が異なる場合は、画面上の位置ではなくフィールドの役割で照合してください。

ノードを変更するときは一度に1つのフィールドだけを変え、変更前にノードをコピーしてバックアップしてください。アドレス、トランスポート、セキュリティ層を同時に変更すると、テストに失敗しても原因を特定できません。サブスクリプションノードは通常サーバー側で一元管理され、手動変更は次回更新時に上書きされます。長期的に残したいローカル調整は、ノードをコピーして別名を付けた独立ノードとして保存します。元のサブスクリプションノードは変更せず、サーバー側の変化と比較できるようにしてください。

クライアントを選んだら、チュートリアルの基本手順に沿ってサブスクリプションをインポートし、ノードを選択して接続を開始・確認します。OSとCPUに合うインストールパッケージを確認する場合は、V2Rayクライアントのダウンロードページへ進んでください。ページ下部のダウンロードに関するよくある質問では、パッケージの選び方、システム要件、更新方法をまとめています。本ページでは引き続き、プロトコルとカーネルの判断を扱います。

ここまでの層別確認を踏まえると、選定は固定の手順にまとめられます。端末とクライアントを確認し、カーネルを確認し、サブスクリプションが実際に提供するプロトコル構成を調べ、フィールド不足やカーネル非対応のノードを除外し、残ったノードの安定性をテストします。新しいプロトコルだから適している、項目が少ないから適しているとは限りません。最適なノードは、サーバーが提供していること、クライアントが完全に解析できること、カーネルで実行できること、現在の回線が安定していること、端末のリソースに無理がないことの5条件を満たすものです。

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

Windows、macOS、Linuxのデスクトップ環境では、まずv2rayNを使用します。サブスクリプションにVLESS + REALITYがあり、フィールドが完全なら、Xrayカーネルで優先的にテストできます。VMess、Trojan、Shadowsocksのノードがすでに長期間安定しているなら、そのまま残して構いません。デスクトップ端末は一般にCPUとメモリに余裕があるため、プロトコル間のわずかな計算差を最優先にする必要はありません。接続の安定性、回線品質、アプリ互換性、ルーティング要件を重視してください。すべての通信をTUNで引き受ける場合は、権限、DNS、ルーティングを追加確認し、TUNの問題をリモートプロトコルのせいにしないでください。

Androidでの日常利用

AndroidでサブスクリプションにREALITY、Vision、その他のXray拡張が含まれる場合はv2rayNGを選びます。汎用VMess、Trojan、Shadowsocks、通常のVLESSが中心で、V2Flyカーネルを使いたい場合はv2flyNGを選択できます。モバイルでは接続の安定性と再接続の挙動を優先してください。最低遅延のノードでも頻繁に切断されるなら、遅延が少し高くても安定したノードのほうが、実際のバッテリー消費と使い心地で優れることがあります。異なるプロトコルのノードを2つ残しておけば、ネットワーク切り替え後に素早く比較できます。

古い設定を新しいクライアントへ移行する

移行時はノードを1つずつ書き写すのではなく、元のサブスクリプションを再インポートしてください。インポート後にノード数、プロトコル、トランスポート、セキュリティフィールドを確認し、通常のノードと拡張機能を含むノードを1つずつテストします。リモート接続が正常だと確認してから、ルーティング、DNS、システムプロキシ、TUNを移行します。古いクライアントがV2Fly、新しいクライアントがXrayの場合、汎用プロトコルは移行しやすいものの、デフォルト値を確認してください。逆方向では、REALITY、Vision、新しいトランスポート機能を先に除外します。

プロトコル移行をクライアントの種類変更だと考えてはいけません。たとえばVMessのプルダウンをVLESSへ変えても、サーバーに対応する入口が現れるわけではありません。TLSをREALITYへ変更しても、公開鍵や短い識別子などのサーバーパラメータが不足します。本当のプロトコル移行には、サーバーが新しいノードを提供するか、サブスクリプションを更新する必要があります。クライアント側の役割は、パラメータを完全に受け取り、対応するカーネルを選び、接続を検証することです。

ログに応じてトラブルシューティングの分岐を選ぶ

設定が起動しない場合は、まずフィールド構造、カーネル対応、ローカルポートを疑います。接続直後に失敗する場合は、アドレス、ポート、認証値、セキュリティフィールドを確認します。長時間タイムアウトする場合は、ネットワーク到達性、サーバー状態、回線を確認します。特定のドメインだけ異常ならDNSとルーティングを調べます。ブラウザーは正常でも他のアプリが動かない場合は、システムプロキシの適用範囲やTUNを確認します。モバイルでネットワーク切り替え後に異常が出た場合は、まず接続を再構築し、失敗が続くかを観察してください。

5分で確認する選定チェックリスト

1. クライアントを決める：デスクトップはv2rayN、AndroidはXrayまたはV2Flyの要件に応じてv2rayNG、v2flyNGを選びます。
2. ノード詳細を開く：主体プロトコル、トランスポート方式、セキュリティ層、主要な拡張フィールドを記録します。
3. 機能の衝突を除外する：REALITY、Vision、新しいトランスポートフィールドは、明確に対応するXrayカーネルへ割り当てます。
4. 実際の接続をテストする：まず設定の読み込み、次にハンドシェイク、最後に実際のアプリと継続通信を確認します。
5. 端末への負荷を確認する：モバイルでは再接続、バッテリー、ネットワーク切り替えを、デスクトップではルーティング、DNS、TUNを確認します。
6. 切り戻し用ノードを残す：パラメータが明確で、異なるプロトコルを使い、接続確認済みのノードを少なくとも1つ残します。

さらに詳しく調べる場合は、ノードの遅延と地域の判断をノード選びの方法で、ルーティング構文をdomain、ip、geositeルールの解説で確認できます。実行に失敗した場合はログエラーの対照表で原因を特定してください。これらの概念に初めて触れる場合は、先にV2Ray初心者向け10問を読み、その後に本ページの該当章へ戻ると理解しやすくなります。

プロトコル選定ですべての高度な設定を一度に完了させる必要はありません。まずサブスクリプションの元のパラメータで安定した接続を確立し、そこへシステムプロキシ、ルーティング、DNS、TUNを段階的に追加します。項目を1つ追加するごとに検証し、問題が起きたら直前の変更を戻してください。こうすれば、リモートプロトコル、クライアントカーネル、ローカルネットワーク設定を分けて扱え、複数の変数が重なるのを防げます。インストールパッケージを取り直す場合はダウンロードセンターへ、インポートから検証までやり直す場合は設定ガイドへ戻ってください。