V2Rayプロトコルマニュアルとクライアントの選び方

判断の基本を作る

まずプロキシプロトコル、トランスポート、安全層を区別する

クライアントの1つのノードは、実際には複数の層で構成される

v2rayN、v2rayNG、v2flyNGでノードを確認すると、画面上ではプロトコル、アドレス、ポート、トランスポート、安全設定が1つの編集フォームにまとめられていることが多くあります。これらが一体となって1本の接続を構成しますが、役割は同じではありません。VMess、VLESS、Trojan、Shadowsocksは主に、クライアントの認証方法、アプリケーション通信のカプセル化、サーバーによる接続識別方法を定義します。TCP、WebSocket、gRPCなどのトランスポート項目は、データをどのような形式で運ぶかを決めます。TLSとREALITYは、安全性やハンドシェイクに関わる層です。これらをすべて相互に置き換えられる「プロトコルの種類」と考えると、比較を誤りやすくなります。たとえばVLESSはTCPやgRPCなどと組み合わせられ、異なる安全設定にも対応できます。REALITYも、アドレスだけを単独で入力すれば動作するプロキシプロトコルではなく、VLESSなどのインバウンド／アウトバウンド構成とともに使う安全層の方式です。

設定は外側から内側へ読むと判断しやすくなります。まずサーバーアドレスとポートを確認し、「どこへ接続するか」を把握します。次にトランスポートを見て、「データがどう到達するか」を確認します。その後、安全層とハンドシェイクパラメータで「保護されたセッションをどう確立するか」を確認します。最後にユーザー識別子、パスワード、暗号化方式を確認し、「サーバーがこのユーザーのデータをどう識別・処理するか」を見ます。サブスクリプションをインポートすると、通常はこれらの項目が自動入力されるため、普段は1項目ずつ変更する必要はありません。ただし階層を理解していれば、インポート漏れ、プロトコルの選択ミス、パラメータの不整合を見つけやすくなります。

同じ名前でも、組み合わせが同じとは限らない

VLESSと表示された2つのノードでも、実際の動作は大きく異なる場合があります。一方は通常のTCPとTLS、もう一方はgRPCとREALITYを使っているかもしれません。ハンドシェイク回数、接続の多重化方法、証明書の要件、利用できるコアはいずれも異なります。反対に、VMessとVLESSは認証構造が異なっていても、同じ基盤のTCPやWebSocketを使えるため、ネットワーク経路上の一部の挙動は似ることがあります。速度を比較するときにプロトコル名だけを見ると、回線品質、サーバー負荷、トランスポートのカプセル化、安全層の違いをプロトコルそのものの差として誤って評価しがちです。

プロトコルの選択は、すべてのオプションを有効にすればよいというものでもありません。カプセル化を1層追加するたびに、通常は追加ヘッダー、バッファー、状態管理が発生します。一方で層を減らすと、現在の構成に必要なハンドシェイク機能や互換性を失う可能性があります。正しい進め方は、まずサーバー設定から利用可能な組み合わせを確認し、その中からクライアントのコアが完全に解析でき、端末への負担も適切なものを選ぶことです。クライアントのプロトコル項目はサーバーと一致させる必要があり、VMessノードの名前だけをVLESSに変更しても動作しません。また、REALITYだけを有効にして既存のTLSパラメータを残すこともできません。

遅延、帯域幅、安定性は別々の指標

クライアントの遅延テストは通常、特定の検査用接続を確立するまでの時間だけを示し、継続的なダウンロード速度を意味しません。帯域幅はサーバーの出口回線、ネットワーク経路、輻輳制御、端末性能に左右されます。安定性は、一定時間内のパケットロス、再接続、速度の大きな変動を観察して判断します。あるプロトコルが1回の遅延テストで数ミリ秒短かったとしても、長時間接続、動画通信、大量の同時リクエストに適しているとは限りません。選択時はまず設定が正しいことを確認し、同じ端末、同じ時間帯のネットワーク、同じ経路で比較してください。環境の変化をプロトコルの差と取り違えないことが重要です。

このマニュアルでは、異なる役割を表す言葉として「プロキシプロトコル」「トランスポート」「安全層」「コア」の4つを使います。この階層を保てば、クライアント内の複雑に見えるオプションも、追跡可能な接続チェーンとして理解できます。新しい名称に出会ったときも、別の名称より速いかを先に問うのではなく、どの層に属し、何を置き換え、何に依存するのかを確認するとよいでしょう。

プロトコルの背景と範囲

VMess、VLESS、Trojan、Shadowsocks、REALITYの設計上のトレードオフ

VMess：包括的な認証構造と豊富な互換性

VMessは、Project Vエコシステムで早期に確立された、クライアントとサーバーが連携する方式の1つです。ユーザー識別子と時刻に関する情報を認証に用い、データをプロトコル層でカプセル化します。過去の設定資料が多く、V2FlyとXrayの両ファミリーで広くサポートされている点が強みです。古いサブスクリプションや既存の構成では、現在もVMessが中心になっていることがあります。既存サーバーを維持しながら複数の古いクライアントを接続する環境では、最小限のカプセル化よりVMessの互換性が重視されることが多いでしょう。

この包括的な構造は、クライアントがより多くのプロトコル処理を担うことも意味します。システム時刻が大きくずれていると認証に失敗することがあり、WebSocketなどを使う場合はパス、Host、安全層のパラメータも一致させる必要があります。VMessは「有効にするだけで自動適応する」汎用形式ではなく、サブスクリプションにトランスポート項目が欠けていれば接続に失敗します。新規構成で古いクライアントとの互換性が不要なら、より簡素な構造のVLESSも同時に検討できます。ただし、既存のVMessノードを必ず移行すべきという意味ではありません。安定稼働中の設定を変更するかどうかは、実際の負荷、保守コスト、対応クライアントの範囲で判断してください。

VLESS：認証と暗号化の役割を分離

VLESSはユーザー認証とトランスポートの安全性を分けて扱います。プロトコル自体が内容の暗号化を重ねて担うのではなく、安全機能をTLSやREALITYなどの外側の層に委ねます。この設計により転送チェーンが明確になり、Xrayエコシステムで異なるフロー制御や安全方式を組み合わせやすくなります。VLESSではUUID形式の識別子をユーザー認証に使うことが多いものの、識別子だけでは完全なノードにはなりません。トランスポート、安全層、サーバー名、任意のフロー制御を、サーバー側と項目ごとに一致させる必要があります。

役割を分離することで、不要な重複処理を減らし、各層を独立して発展させられます。一方で、正確な設定の重要性は高まります。クライアント画面でVLESSを選べても、現在のコアがサブスクリプションに含まれるすべての拡張フィールドをサポートするとは限りません。特にREALITY、公​​開鍵、短いID、特定のフロー制御を含むノードでは、それらを完全に認識できるXray系コアを優先してください。理解できないパラメータを手動で削除しても「互換モード」にはならず、ハンドシェイクを壊すことがあります。

Trojan：パスワード認証を中心とした簡潔な構造

Trojanはパスワードでユーザー認証を行い、通常はTLSと組み合わせて使います。パラメータモデルは比較的わかりやすく、サーバー、ポート、パスワード、サーバー名、証明書関連の設定が主要項目です。明確なTLS構成を必要とし、Trojanに対応する複数のクライアント間で移行したい場合に理解しやすい構造です。ただし、サーバー証明書、ドメイン、時刻環境が正常であることが前提です。証明書名の不一致、SNIの入力ミス、システム時刻の異常があると、プロキシ認証以前にTLSハンドシェイクが終了する可能性があります。

TrojanとVLESSは、単純に速いか遅いかで比較できるものではありません。似たネットワーク経路を通り、どちらもTLSを使う場合があります。実際の違いは、認証構造、組み合わせ可能な拡張、サーバー実装、クライアントのコアに大きく左右されます。サブスクリプション提供元が安定したTrojanノードを用意し、クライアントも完全にインポートできるなら、名前が違うという理由だけで変換する必要は通常ありません。プロトコルはクライアント側だけで変換できず、「別の種類に変更する」には対応するサーバー設定が必要です。

Shadowsocks：軽量なデータ暗号化プロキシ

ShadowsocksはSSと略されることが多く、サーバーアドレス、ポート、パスワード、暗号化方式を主要パラメータとします。構造が軽く、クライアントとサーバーの実装も広く普及しているため、設定チェーンを短くしたい場合、端末リソースが限られる場合、従来の互換性が必要な場合に適しています。重要なのは「軽量」と覚えることだけではなく、双方がまったく同じ暗号化方式をサポートしているか確認することです。旧方式と現代的なAEAD方式では互換性と実装要件が異なり、クライアントの一覧に項目があっても、サーバーが同じ方式を使っているとは限りません。

Shadowsocksの共有リンクには通常、主要パラメータを収められますが、プラグインや追加のトランスポート情報は異なる拡張形式で記述されることがあります。サブスクリプション変換時にアドレス、ポート、パスワードだけが残ると、追加パラメータが失われる可能性があります。インポート後は、ノード名が表示されたからといって設定完了と判断せず、暗号化方式とプラグイン項目を確認してください。VMessやVLESSと同じく、性能はネットワーク経路とサーバー実装に左右されます。構造が軽いからといって、どの環境でも高いスループットになるわけではありません。

REALITY：安全なハンドシェイク方式であり、単独のノード種別ではない

REALITYは主にXrayエコシステムで使われ、安全なハンドシェイクと認証に関する処理を担います。実際の設定ではVLESSとREALITYの組み合わせが一般的なため、クライアントの一覧でREALITYが目立っていても、基盤となるプロキシプロトコルは別途確認する必要があります。代表的なパラメータにはサーバー名、公開鍵、短いID、任意のフィンガープリントなどがあり、いずれもサーバー側で生成・配布される組み合わせ情報です。公開鍵や短いIDが1文字でも欠けたり、サーバー名の選択が一致しなかったりすると、ハンドシェイクに直接失敗する可能性があります。

REALITYの価値は特定のハンドシェイクとデプロイモデルにあり、あらゆるTLS方式を置き換えるものではありません。対応するXrayコアと正確なサブスクリプション項目が必要です。ノード名にREALITYが含まれているだけで、V2Fly系コアが同じ機能を自動的に得るわけではありません。利用前にクライアントが実際に使うコアを確認し、次にサブスクリプションが必要なパラメータを完全に提供しているか確認してください。ハンドシェイクの負荷やXTLS Visionの転送経路をさらに理解したい場合は、REALITYとXTLS Visionの技術解説をご覧ください。

性能を判断する

接続速度、スループット、転送経路を比較する方法

ハンドシェイクの負荷は初回接続に影響するが、継続速度を完全には決めない

新しいウェブページを開くとき、端末ではまず名前解決、サーバーへのTCPなどのトランスポート接続、安全なハンドシェイク、プロキシ認証が順に行われ、その後に目的のリクエストが送信されます。プロトコルと安全層が影響するのは、このチェーンの一部です。VMessは独自の認証とカプセル化を処理します。VLESSはプロトコル構造が簡素ですが、外側でTLSやREALITYを使う場合は、それぞれのハンドシェイクが必要です。Trojanは通常TLSに依存し、Shadowsocksは選択した暗号化方式に応じてデータ処理状態を構築します。初回接続の差は多くの場合ミリ秒単位で、ネットワーク間の往復距離が大きいと、ローカルのプロトコル処理より経路遅延のほうが目立ちます。

継続的な転送では、各データブロックが何回コピー、暗号化、カプセル化、バッファリングされるかが重要になります。コアの実装、OSのネットワークスタック、トランスポートの組み合わせも関係します。一部のフロー制御方式は、特定条件下で重複した暗号化やデータコピーを減らそうとしますが、クライアント、サーバー、外側の条件がすべて一致して初めて機能します。クライアントでフロー制御名を選ぶだけで、サーバー側に同じ機能が設定されていなければ、通常は接続に失敗し、通常接続へ自動的に戻ることもありません。

トランスポートはプロキシプロトコル名より動作を大きく変えることがある

通常のTCPはカプセル化の層が少なく、直接転送を重視する構成に適しています。WebSocketはフレームやパスなどの項目を追加します。対応するWebサービスの構成と組み合わせられる点が利点ですが、追加のカプセル化や中間層がスループットと遅延に影響することがあります。gRPCはHTTP/2を基盤とし、ストリームと接続を管理できます。適切なサーバー構成では長時間接続を扱いやすい一方、正しいサービス名とHTTP/2のサポートが必要です。ノードを比較するとき、一方がTCP、もう一方がWebSocketなら、どちらもVLESSと表示されていても、テスト結果をVLESS自体の差とは判断できません。

接続の多重化も慎重に理解する必要があります。多重化によって複数の論理リクエストが少数の基盤接続を共有でき、頻繁なハンドシェイクを減らせます。しかし基盤接続で輻輳やパケットロスが発生すると、複数のリクエストが同時に影響を受けることがあります。ブラウザーや最新のアプリケーション自体が接続プールやHTTP/2を使っているため、プロキシ層でさらに多重化しても常に効果があるとは限りません。まずは初期設定から始め、大量の短時間接続がありハンドシェイクコストが明らかな場合に多重化をテストしてください。ページの初回表示、継続的なダウンロード、複数タスクの同時実行を分けて観察し、1回の遅延値だけで判断しないことが大切です。

再現性のある比較方法を作る

有効なテストでは変数を管理する必要があります。まず同じ端末、同じネットワーク、近い時間帯で複数のノードをテストします。プロトコルを比較する場合は、できるだけ同じサーバー所在地、近い負荷、同じトランスポートを選んでください。各項目で、初回表示、継続転送、ネットワーク切り替え後の復旧を最低限観察します。遅延テストは、完全に到達不能なノードや往復遅延が過大なノードを除外するのに役立ちますが、最終的には実際のアプリケーションで判断します。結果の変動が大きい場合は、まずテストを繰り返して回線の時間帯を確認してください。Mux、ルーティング、DNS、プロトコルなど複数の項目をすぐに変更すると、どの変更が影響したのか判断できません。

v2rayNはデスクトップ環境で通常、より余裕のあるCPUとメモリを利用でき、複雑なルールや同時接続にも対応しやすくなります。一方、Androidのv2rayNG、v2flyNGは、バッテリー設定、バックグラウンド制限、ネットワーク切り替えの影響も受けます。デスクトップでのテスト結果をそのままモバイル端末に適用することはできません。全体の速度が低下した場合は、ノード、回線、ローカル設定の3層に分けて確認してください。手順はV2Rayの速度低下を層別に確認するチェックリストで解説しています。問題が接続確立、継続スループット、ルーティングのどこにあるかを特定してから、プロトコルの組み合わせを変更します。

端末への負荷

リソース使用量、モバイル端末のバッテリー、バックグラウンド接続

CPU負荷はデータチェーン全体から生じる

プロトコル自体が占めるリソース消費は一部にすぎません。暗号化アルゴリズム、安全なハンドシェイク、トランスポートのカプセル化、DNSクエリ、ルールの照合、接続ログ、グラフィカルインターフェースもCPUとメモリを使います。Shadowsocksは構造が簡潔なため軽量と見なされることが多いものの、実際の負荷は暗号化方式や、端末のハードウェア機能を実装が活用できるかによって変わります。VLESSでプロトコル層の重複処理が減っても、外側のTLS、REALITY、トランスポートには計算処理が必要です。VMessはプロトコル処理が1層多くても、現代のデスクトップ端末で必ず体感できるボトルネックになるわけではありません。高スループット、低消費電力の端末、大量の同時接続で初めて差が表れやすくなります。

メモリ使用量は、接続数、バッファー、ルーティングルールの規模、ログレベルに大きく左右されます。大量のドメインルールや複数のアウトバウンドを含む設定は、単一ノードの直接接続より多くのメモリを必要とすることが一般的です。詳細ログを有効にすると接続イベントの記録が増え、書き込み処理も増える可能性があります。トラブル対処が終わったら、日常利用に必要なレベルまでログを戻し、過密な記録を長期間残さないようにしてください。クライアントウィンドウの使用量とコアプロセスの使用量は分けて考える必要があります。v2rayNのグラフィカルインターフェースと実際のプロキシコアは別の役割を持つため、画面をトレイに格納しても、コアがシステムプロキシの通信を処理し続けることがあります。

モバイル端末のバッテリー消費は、主にウェイクアップ頻度とネットワーク状態に左右される

Android端末の消費電力は「暗号化しているか」だけでは決まりません。長時間接続を維持するとネットワークモジュールが周期的に動作し、短時間接続を頻繁に作るとハンドシェイクとウェイクアップの回数が増えます。電波状態が弱い場合は、無線モジュールが送信出力を上げることもあります。Wi-Fiとモバイルネットワークを切り替えると古い接続が無効になって再確立され、追加の消費が発生します。システムがv2rayNGやv2flyNGのバックグラウンド動作を制限すると、接続が一時停止することがあります。アプリを再び開いた際に再接続が集中すると、体感上の安定性が下がり、短時間のリソースピークが発生する場合もあります。

プロトコル選択がバッテリーに与える影響は、同じ通信量で観察する必要があります。軽量なカプセル化で一部の計算を減らせても、ノードが不安定で再接続を繰り返せば、節約分はネットワークのウェイクアップで相殺されます。理論上の処理手順が少なくても頻繁に切断される方式より、安定した接続を長時間維持できる方式のほうが省電力になることがよくあります。多重化で基盤接続の数を減らせる場合がありますが、モバイルネットワーク切り替え後の共有接続の復旧がうまくいかないと、複数のリクエストが一斉に再試行されることもあります。モバイル端末では、ルールセットを適度な規模に保ち、サーバーが明確にサポートするデフォルトのトランスポートを使うことをおすすめします。まず安定稼働させ、その後に項目を1つずつ調整してください。

v2rayNGとv2flyNGのリソース差は、コアの能力と合わせて判断する

v2rayNGはXrayコアを使用するため、VLESS、REALITY、Xray拡張機能を含むサブスクリプションに適しています。v2flyNGはv2flyコアを使用し、VMess、ShadowsocksなどV2Fly互換の設定が中心の環境に向いています。両者の優劣を、インストールパッケージのサイズや一度のバックグラウンド使用量だけで判断することはできません。v2flyNGがノードに必要なREALITYフィールドを解析できなければ、アイドル時の使用量が少なくても目的の接続は確立できません。反対に、サブスクリプションが基本的なVMessだけなら、複雑な拡張機能が速度を自動的に改善することもありません。

モバイル端末のリソースを確認するときは、画面点灯、画面消灯、ネットワーク切り替え、継続転送の4状態を最低限含めてください。システムのバッテリー統計は一定期間の傾向を見るのに適していますが、数分間のサンプルで結論を出す用途には向きません。また、プロキシが発生させた通信量と、各アプリ自身が発生させた通信量を区別してください。動画再生、クラウド同期、大容量ファイルの更新はもともとネットワークを大きく使用し、クライアントはそれらを転送しているだけです。待機中の消費電力が異常な場合は、アプリが継続的にリクエストしていないか、ノードが再接続ループに入っていないか、サブスクリプションの更新頻度が高すぎないかを先に確認し、その後でプロトコルとコアを確認します。

リソース使用量を抑える調整順序

まず不要な詳細ログと重複した速度測定を止め、次に無効なノード、過度に頻繁なサブスクリプション更新、大きすぎるルーティングルールを減らします。その後、頻繁な再接続がないかを観察し、最後にトランスポートとプロトコルの組み合わせを比較します。変更は一度に1項目だけ行い、十分な観察期間を確保してください。端末がアイドル時にメモリを多く使っていても、システムにメモリ回収の圧力がなく、接続も安定しているなら、数値をよく見せるためにコアを頻繁に再起動する必要はありません。現代のシステムは利用可能なメモリをキャッシュに使います。注目すべきなのは、使用量の継続的な増加、動作の引っかかり、異常な発熱、接続ループです。

コアファミリー

V2FlyとXrayの関係、機能範囲、設定互換性

共通の起源があっても、機能が同期しているとは限らない

V2FlyとXrayは、どちらもProject Vエコシステムの設定モデルとマルチプロトコル転送の考え方を受け継いでいます。そのため、基本概念には共通点があります。インバウンドはローカルまたは外部からの接続を受け付け、アウトバウンドは通信を目的地へ送り、ルーティングはドメイン、アドレス、ポートなどの条件でアウトバウンドを選択します。VMess、Shadowsocks、SOCKS、HTTPなどの一般的な構造は、両者で大きく共通しています。コアを一方から他方へ移行する際も、通常は「インバウンド—ルーティング—アウトバウンド」という枠組みを学び直す必要はありません。

ただし、両者はすでに独立して進化するコアファミリーです。新機能の追加時期、フィールド名、デフォルト値、拡張プロトコルが一致する保証はありません。XrayではVLESS、REALITY、XTLS Visionなどの組み合わせが一般的ですが、V2Flyは独自の方針でプロトコル、トランスポート、設定機能を維持しています。JSONの見た目が似ていても、すべてのフィールドを相互利用できるとは限りません。クライアントにノードが表示されても、選択中のコアがそのノードを起動できるとは限りません。未知のフィールドをいったん保存し、コアの起動時になって初めて未対応または解析失敗を返すクライアントもあります。

3つのクライアントとコアの対応関係

v2rayNはWindows、macOS、Linux向けのデスクトップクライアントで、サブスクリプション管理、システムプロキシ、ルーティング編集、コアの呼び出しなどを担います。デスクトップ環境ではまずv2rayNから検討するとよいでしょう。異なるコアの能力に合わせて設定を構成できますが、個々のノードが利用できるかは、実際に同梱・選択されているコアに左右されます。v2rayNGはAndroidでXrayコアを主に利用するクライアントで、VLESS、REALITY、関連するXray設定に適しています。v2flyNGはv2flyコア向けで、AndroidでV2Flyの対応機能が必要な場合の選択肢です。

グラフィカルクライアントはプロトコルそのものではありません。クライアントはサブスクリプションやフォームをコア設定に変換し、プロセスを起動し、システムのネットワーク入口を調整します。プロトコルの解析とデータ転送を実際に行うのはコアです。「同じノードが一方のクライアントでは使えるのに、別のクライアントでは使えない」場合は、画面の名称だけでなく、両者が使うコアファミリーと設定フィールドをまず比較してください。同じファミリーを使っているのに結果が異なる場合は、インポート処理、バージョンが対応するフィールド、システムのネットワーク権限を確認します。

設定互換性は構文、フィールド、動作の3層に分けられる

第1層は構文互換性、つまりJSONを解析できるかどうかです。ファイルの構文が正しいことは、括弧、引用符、データ型が基本的に合法だと示すだけです。第2層はフィールド互換性で、コアがプロトコル名と具体的なキーや値を認識できるかを確認します。第3層は動作互換性で、同名フィールドのデフォルト値、境界条件、組み合わせ制限が2つの実装で一致するかを見ます。移行時に第1層だけ確認しても十分ではありません。最も確実なのは、古いコアの完全な実行設定を直接コピーするのではなく、移行先のクライアントにサブスクリプションから設定を再生成させる方法です。

以下の断片は、VLESSアウトバウンドの基本的な階層構造を、フィールドの位置を理解するためだけに示したものです。例のアドレスとユーザー識別子はドキュメント用であり、直接接続することはできません。実際のノードでは、サーバーの要件に応じてトランスポートと安全設定を補う必要があります。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-1111-1111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    }
  ]
}

ここでのprotocolはアウトバウンドのプロトコルだけを決めるもので、トランスポートや安全層の代わりにはなりません。REALITYノードをインポートすると、サーバー名、公開鍵、短いID、フィンガープリント、フロー制御などの情報も現れます。移行先のコアがこれらのフィールドに対応していない場合、フィールドを削除して無理に起動しないでください。正しい方法は、その組み合わせをサポートするXrayコアのクライアントへ変更するか、サーバーが別途提供する互換ノードを使うことです。デスクトップクライアントの形態を比較する場合は、v2rayNデスクトップ版とWPF版の違いもご覧ください。

データ交換

サブスクリプション形式、共有リンク、設定フィールドの互換性

サブスクリプションはノード一覧であり、統一プロトコル規格ではない

クライアントのサブスクリプションは通常、1つのアドレスからノード一覧を取得します。内容はエンコードされた複数行の共有リンクの場合もあれば、構造化された設定の場合もあります。サブスクリプションが解決するのは一括配布と更新の問題であり、コア間の機能差をなくすものではありません。同じサブスクリプションアドレスにVMess、VLESS、Trojan、Shadowsocksのノードが同時に含まれることもあります。クライアントは各項目を認識し、自身のデータモデルへ変換します。認識できないプロトコルはスキップされ、部分的にしか認識できないノードは名前だけ残って拡張フィールドが失われることがあります。

したがって、「サブスクリプションの更新に成功した」とは、クライアントがレスポンスを取得して処理したことを示すだけで、一覧内のすべてのノードが現在のコアに適合することを意味しません。更新後は、ノード数が妥当か、プロトコルの種類が表示されているか、重要なパラメータが存在するかを確認してください。サブスクリプションにREALITYノードが含まれていたのにv2flyNGで対応機能がない場合、それはコアの範囲によるもので、更新を繰り返しても解決しません。同じサブスクリプションをv2rayNGにインポートすると認識できるなら、差異がコアの機能または変換層にあることがわかります。

共有リンクに含められる情報は、プロトコルと拡張仕様によって決まる

一般的なリンクは、たとえばvmess://、vless://、trojan://、ss://のように、プロトコル名から始まります。リンク本文には、サーバー、ポート、認証情報、一部のトランスポートパラメータが含まれます。VLESSとTrojanでは追加パラメータをクエリ文字列に置き、ノードの備考を末尾に置くことがよくあります。VMessの従来の共有形式では、構造化されたフィールド群をエンコードしてリンクに格納します。Shadowsocksのリンクは、暗号化方式、パスワード、アドレス、ポートを中心に構成されます。クライアントによって拡張パラメータの名称やデコード時の許容範囲が異なる場合があります。

リンクを手動でコピーするときは、プロトコルの先頭から末尾まで完全にコピーし、アドレスとユーザー識別子だけを残さないでください。リンク内の疑問符、シャープ記号、スラッシュ、パーセント記号には構造上の意味があり、チャットツールやテキストエディターによって切り捨てられたり置換されたりすることがあります。QRコードもリンクを図形化したものにすぎず、スキャンに成功しても内容が完全とは限りません。インポート後はノードの詳細を開き、サーバーから提供された情報と照合して、トランスポート、安全層、SNI、パス、サービス名、公開鍵、短いID、フロー制御を確認してください。

一般的なフィールドを接続の階層に対応させる方法

サブスクリプション更新とローカル編集の関係

多くのクライアントは、サブスクリプションを更新すると同じサブスクリプショングループのノードをリモートの内容で上書きします。サブスクリプションのノードを直接編集すると、次回の更新で変更が消える可能性があります。ローカルの調整を長期的に残したい場合は、クライアントがローカルノードへの複製、サブスクリプション専用ルールの設定に対応しているか、またはサーバー側で元データを修正できるかを確認してください。重要な修正をサブスクリプションノードの一時編集だけに残さないでください。ルーティングルール、システムプロキシ設定、クライアントの環境設定は通常ローカル設定であり、ノード更新で上書きされるとは限りませんが、実際の挙動はクライアントの説明に従って判断してください。

サブスクリプションを更新できない場合は、まずシステム時刻、ネットワーク、サブスクリプションアドレスが正常か確認し、次にクライアントログのHTTPステータスと解析メッセージを確認します。更新後にノードが突然すべて使えなくなった場合は、すぐにクライアントを再インストールするのではなく、更新前後でプロトコル、アドレス、ポート、安全関連フィールドを比較してください。一部のノードだけが失敗するなら、問題はそれらのノードのパラメータまたはサーバー状態に集中している可能性が高いです。具体的な確認順序はノードのタイムアウトと接続不能を順番に確認する方法を参照してください。

クライアント間の移行では元のサブスクリプションを優先する

v2rayNからv2rayNGへ移行する場合や、v2rayNGとv2flyNGを切り替える場合は、元のサブスクリプションまたは完全な共有リンクを優先的にインポートし、移行先のクライアントに自身のコア用設定を生成させてください。特定クライアントが出力した実行用JSONを直接コピーすると、ローカルポート、プラットフォーム固有のパス、専用ルーティング、未対応フィールドまで持ち込む可能性があります。移行後はまず基本的なノードを1つテストしてから、複雑なルールをインポートします。これにより「ノードの互換性」と「ローカルルーティングの互換性」を分けて検証でき、一度に複数の変数を持ち込まずに済みます。

選択の道筋

端末、サブスクリプションの対応範囲、用途に応じてプロトコルを選ぶ

まずサーバーの機能で選択範囲を決める

プロトコルはクライアント側だけで決められません。サーバーがVMessしか提供していない場合、クライアントで種類をVLESSに変更しても接続は成立しません。サブスクリプションにREALITYの公開鍵と短いIDがない場合も、オプションを有効にするだけでは補えません。したがって最初に行うべきは、すべての名称から理論上の最適解を選ぶことではなく、サーバーが実際に提供し、現在のクライアントコアが完全にサポートする組み合わせを列挙することです。その共通範囲にあるノードだけを、速度、リソース、保守コストの観点で比較する価値があります。

次に、古い端末や複数のクライアントを共用する必要があるかを確認します。既存のV2Fly環境との互換性が必要なら、VMessまたは双方がサポートするShadowsocks設定のほうが整合性を保ちやすいでしょう。すべての端末がXrayコアを使い、サーバーもVLESSとREALITYを明確に提供しているなら、その組み合わせを優先的にテストできます。Trojanは、サーバーに完全なTLS設定があり、クライアントが証明書とサーバー名を正しく処理できる場合に適しています。選択は既存の条件を中心に行い、プロトコル名を上下関係として扱わないでください。

デスクトップでは管理性と長期安定性を優先する

Windows、macOS、Linuxではv2rayNを優先します。デスクトップ環境ではブラウザー、開発ツール、通信ソフト、システム更新などを同時に動かすことが多いため、システムプロキシ、ルーティングルール、ログの入口を明確に管理できることが重要です。プロトコルについては、サブスクリプションがVLESSとREALITYを提供し、現在のXrayコアが完全に対応しているなら、現代的な組み合わせとしてテストできます。VMess、Trojan、Shadowsocksのノードがすでに安定稼働しているなら、そのまま使い続けても問題ありません。名前だけを追って移行する必要はありません。

デスクトップではTUNとシステムプロキシの違いも考慮します。システムプロキシはシステム設定に従うアプリに主に影響し、TUNモードは仮想ネットワークインターフェースを通じてより広い通信を扱います。どちらもローカルの通信入口であり、リモートノードのプロトコルを変更するものではありません。特定のアプリがプロキシを通らない場合は、VMessやVLESSを変更する前に入口とルーティングを確認してください。複雑なルーティングによるルール照合やDNSの挙動が、プロトコル差より使用結果に大きく影響することもあります。

Androidではまずコアを合わせ、バックグラウンドの安定性を観察する

サブスクリプションがXrayの機能を中心とし、VLESS、REALITY、特定のflowフィールドを含む場合はv2rayNGを優先します。サブスクリプションが主にV2Flyのサポート範囲にあるVMess、Shadowsocksなどのノードで構成され、v2flyコアを使いたい場合はv2flyNGを選べます。選択後は、画面消灯後やネットワーク切り替え後に接続が復旧するかを確認してください。前景では正常なのにバックグラウンドで頻繁に切断される場合は、プロトコルが不安定だと判断する前に、システムのバックグラウンド設定とバッテリー制限を確認します。

モバイル端末では、使えないノードや複雑なテストルールを大量に長期間残すのは適していません。ノード一覧が長すぎると管理コストが増え、自動選択や速度測定がネットワークを頻繁に起動することもあります。検証済みの少数のノードを用途別にサブスクリプショングループへ整理するほうが、プロトコルの種類を増やし続けるより効果的です。クライアントをダウンロードする際、近年の主流Android端末では通常arm64アーキテクチャを選びます。アーキテクチャを確認できない場合は汎用版を利用できます。具体的なファイルはダウンロードセンターのAndroidセクションから取得してください。

目的別の推奨確認順序

環境から切り離した唯一の最適プロトコルは存在しない

VLESSは認証と安全性の役割を分けた現代的なXray構成に適しています。VMessは成熟した歴史的互換性を備え、TrojanはパスワードとTLSの構造がわかりやすく、Shadowsocksは軽量な構成に向き、REALITYは特定の安全なハンドシェイクモデルに対応します。それぞれ異なる制約を解決する方式です。選択時は次の5点を順番に確認してください。サーバーは何を提供しているか、クライアントのコアは何をサポートするか、サブスクリプションのフィールドは完全か、端末のリソースとバックグラウンド条件はどうか、実際の経路は安定しているか。この5点が明確になれば、プロトコル名そのものに惑わされることはありません。

まだ判断が難しい場合は、用途の異なる2つのノードを残してください。1つは安定性と互換性を重視し、もう1つは新しい組み合わせのテスト用にします。テストノードを十分な時間検証してから、メインノードを置き換えます。プロトコル、トランスポート、DNS、ルーティング、システム入口を同時に変更しないでください。一度に1つの層だけを変更し、変更前後の接続確立、継続転送、再接続の挙動を記録してこそ、再利用できる結論になります。

実地確認

プロトコル移行、パラメータ確認、トラブルの切り分け

移行前に動作する基準を保存する

プロトコル移行で最も起こりやすい問題は、古いノードを十分に検証する前に新しい設定で上書きしてしまうことです。開始前に、現在動作しているノードのクライアント、コアファミリー、プロトコル、トランスポート、安全層を記録し、元のサブスクリプションアドレスも保存してください。移行の目的も明確にします。古いVMessからサーバーが新たに提供したVLESSへ変更するのか、REALITYを使うためにv2flyNGからv2rayNGへ切り替えるのか、デスクトップ設定を別の端末へ移すだけなのかで、確認範囲は異なります。

サーバーが古いノードと新しいノードを同時に提供している場合は、新しいノードを独立した項目としてインポートし、古い項目を直接編集しないでください。接続に成功したら、ドメインへのアクセス、継続転送、ネットワーク切り替え、よく使うアプリを順番にテストし、置き換えるか判断します。新しいパラメータに誤りがあっても、既知の動作基準へ戻せます。サーバーが古い設定を提供しなくなった場合は、複数のクライアント間で何度も保存し直してフィールドを失わないよう、新しいサブスクリプションの原文を完全に保存してください。

接続に失敗したら、接続確立の流れを逆向きに確認する

最初にネットワークの接続先を確認します。アドレスに余分な空白がないか、ポートが数字か、ドメインを解決できるか、端末から対象ポートへ基本的な接続性があるかを確認してください。WindowsではPowerShellで次のコマンドを使い、TCPポートへの接続を確認できます。例のドメインは実際のサーバーアドレスに置き換えてください。

Test-NetConnection example.com -Port 443

macOSとLinuxでは、システムに付属するツールで同様の確認ができます。

nc -vz example.com 443

ポートに到達できない場合、プロトコル認証はまだ始まっていません。まずアドレス、ネットワーク経路、サーバーの待受を確認します。ポートには到達できるもののコアがハンドシェイク失敗を報告する場合は、システム時刻、安全層、SNI、証明書、REALITYパラメータを確認してください。ハンドシェイク後に認証が失敗するなら、UUID、パスワード、暗号化方式、ユーザー設定を重点的に確認します。接続はできるのに目的のサイトへアクセスできない場合は、DNS、ルーティング、ローカルのプロキシ入口を確認します。階層ごとに調べれば、いきなりクライアントを再インストールしたり、プロトコルを無作為に切り替えたりせずに済みます。

各プロトコルで頻発する確認ポイント

VMessでは、システム時刻、ユーザー識別子、alterIdなどの過去のフィールド、トランスポートパラメータが同じ設定に由来するかを特に確認します。VLESSでは、UUIDが正しくても安全層、flow、トランスポートが一致していないことがよくあります。Trojanでは、パスワード、SNI、証明書関連の条件を確認してください。Shadowsocksでは、パスワードと暗号化方式を完全に一致させ、追加プラグインのパラメータも漏らさないようにします。REALITYの組み合わせでは、公開鍵、短いID、サーバー名、フィンガープリント、flowをすべて確認し、推測で入力しないでください。

ログに表示される「解析失敗」と「接続タイムアウト」は意味が異なります。解析失敗は通常、設定の構文またはフィールドをコアが受け付けていないことを示します。認証失敗は、該当するプロトコル処理段階まで到達したことを示します。接続タイムアウトはアドレス、ポート、ネットワーク経路で発生する可能性があります。ハンドシェイクエラーはTLS、REALITY、トランスポートのネゴシエーションに関係することが多いです。エラーを見たらまず発生段階を特定し、その後でパラメータを確認してください。ログの最後の1行だけでは前後関係が不足することがあるため、同じ接続の開始時までさかのぼって確認します。ただし、常に最詳細ログを有効にしておく必要はありません。

接続成功後もアプリが通信できない場合はローカルの入口を確認する

ノードが接続済みと表示されても、コアが起動した、または検査接続が一度成功したことを示すだけです。ブラウザー、コマンドラインツール、その他のアプリがプロキシを通るかどうかは、システムプロキシ、TUN、アプリ自身のプロキシ設定、ルーティングルールにも左右されます。あるブラウザーは使えるのに別のプログラムが使えない場合、問題はローカルの入口に近いと考えられます。すべてのドメインに失敗してアドレスへの直接アクセスだけが成功する場合はDNSを確認してください。一部のサイトだけ誤った出口を通る場合は、ドメインルールとアドレスルールの照合順序を確認します。

ルーティングルールは、コア設定の順序またはクライアントが生成したロジックに従って処理されます。範囲の広いルールを前に置くと、後続の細かなルールが隠れることがあります。トラブル対処では、いったんクライアントの簡易プロキシモードへ切り替え、ノード自体が動作するか確認してから、カスタムルーティングを段階的に戻してください。ルーティングの問題をVLESS、VMess、Trojanのプロトコル問題と取り違えないようにします。ローカルのSOCKSまたはHTTPポートを変更した場合は、それらのポートを使うアプリ側の設定も変更してください。

再利用できる確認記録を作る

完全な記録には、端末のプラットフォーム、クライアント、コアファミリー、ノードのプロトコル、トランスポート、安全層、テストした時間帯、エラーが発生した段階を含めます。実際のパスワードやユーザー認証情報を保存する必要はありません。「ポートには到達できるがハンドシェイクに失敗」と記録するほうが、「ノードが使えない」とだけ書くより価値があります。「Wi-Fiでは正常だが、ネットワーク切り替え後に自動復旧しない」という記録も、単一の遅延値よりモバイル端末の問題を特定しやすくします。何度か対処を行えば、自分の環境に合った固定の確認順序を作れます。

初めて設定する場合は、まずクイックスタートの基本手順に戻り、サブスクリプションのインポートとデフォルト設定で基準を作ることをおすすめします。問題が初回インストールやシステムプロキシに限られる場合は、v2rayNの初回インストールと初期設定を参照してください。クライアントを選び直す場合は、デスクトップではv2rayNから始め、AndroidではXrayまたはV2Flyコアの要件に応じてv2rayNG、v2flyNGを選び、ダウンロードセンターから対応プラットフォームへ進んでください。