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

接続設定：プロトコル・通信方式・セキュリティ層

クライアントの接続項目は、単なるプロトコル名ではありません。接続先のアドレス、認証情報、プロキシプロトコル、データを運ぶ通信方式、接続を保護するセキュリティ層をまとめて表します。一覧に「VLESS」と表示されていても、それは構成要素の一つにすぎません。接続できるかどうかは、ほかの項目もサーバー設定と一致しているかで決まります。選ぶ前に、まず設定全体を理解しましょう。

プロキシプロトコルが定める接続の仕組み

プロキシプロトコルは、クライアントが接続先を指定し、アクセス認証を行い、その後のデータをどう扱うかを定めます。VMess、VLESS、Trojan、Shadowsocksはこの層に属しますが、認証と暗号化の役割分担はそれぞれ異なります。画面上で同じ「ユーザー」欄に表示される設定でも、実際の認証情報はUUIDとパスワードのように異なる場合があります。表示が似ているからといって置き換えることはできません。

接続先サーバーのアドレスは、最終的にアクセスするWebサイトのアドレスではありません。クライアントはまずプロキシサーバーに接続し、プロトコルを通じてアクセス先をサーバーに伝えます。トラブル時はこの2段階を分けて考えましょう。クライアントからサーバーへの接続に失敗する場合は、まずアドレス、ポート、ハンドシェイクを確認します。特定のアクセス先だけ失敗する場合は、ルーティング、名前解決、アクセス先自体も調べてください。2つの段階を混同すると、プロトコル全体が使えないと誤判断しやすくなります。

通信方式が決めるデータの運び方

TCP、WebSocket、gRPCなどの通信方式は、プロキシのデータを基盤となる接続でどう運ぶかを定めます。TCPは比較的シンプルにデータを運び、WebSocketではアップグレードのハンドシェイクとメッセージフレームが加わります。gRPCは対応するHTTP/2の通信機構を利用します。後者の2つは既存のリバースプロキシ環境で使われることがありますが、経路、サービス名、転送ルールなどの条件も増えます。直接接続より必ず速くなるわけではありません。

クライアントにある「パス」「Host」「サービス名」は、多くの場合ノード名ではなく通信方式の設定項目です。WebSocketのパスはサーバーや中継ルールと一致させる必要があり、gRPCのサービス名も任意に入力できるものではありません。入力欄を空にできる場合があるのは、特定の構成で既定値が使われるためで、すべてのサーバーが空欄を受け付けるわけではありません。判断に迷ったら、インポート時の値を維持し、設定の提供元に項目の意味を確認してください。

多重化も別途検討すべき設定です。複数の通信を一つの接続で共有し、接続の繰り返しによる負荷を抑える仕組みですが、混雑の影響を大きくしたり、通信方式と機能が重複したりすることがあります。「多重化を有効にすれば最適」とは限りません。まずサーバー推奨の基本設定で安定性を確認し、その後に多重化の有無を変えて、Webページの初回表示、長時間接続、同時リクエストへの影響を個別に比べましょう。

セキュリティ層とアプリ自体の暗号化は分けて考える

TLSはクライアントからプロキシサーバーまでの通信を暗号化し、サーバーの本人確認を行います。REALITYは、クライアントとサーバーの両方で設定が必要な別のセキュリティ機構です。どちらもVLESSと並ぶ、相互に置き換え可能なプロキシプロトコルではありません。WebサイトへのHTTPS通信はプロキシ経路の内側にあります。外側はクライアントとプロキシサーバー間を保護し、内側はブラウザーとWebサイト間のデータを保護します。それぞれ保護する範囲が異なります。

システムプロキシ、Tunモード、ルーティングルールは、ローカル接続と通信の振り分けに関する設定です。システムプロキシを有効にしても、すべてのアプリが従うとは限りません。Tunモードはより広い範囲の通信を扱えますが、ルーティングや権限の影響を受けます。プロトコルが正しくてもブラウザーがプロキシを使っていない場合と、ハンドシェイク設定が誤っている場合は別の問題です。このページの以降の比較は、通信がクライアントに届き、サーバー設定が分かっていることを前提とし、接続方式の違いをプロトコル性能に含めません。

VMessとVLESS：認証と暗号化の役割分担

VMessはProject Vの初期開発段階から使われ、認証、リクエストの記述、データ保護などを担ってきました。VLESSはよりシンプルなプロトコル構造を採用し、セキュリティの多くを組み合わせるセキュリティ層に委ねています。どちらもUUIDでユーザーを識別することが多く、GUIクライアントの追加メニューにも表示されますが、項目が似ていても接続設定を相互に使えるわけではありません。サーバーがVMessを受け付けている場合、クライアントのプルダウンを変えるだけでVLESSにはできません。

VMessの完全性と互換性の注意点

現在のVMess設定では、一般にAEAD認証方式が使われます。古い設定にはalterIdなど、以前の認証方式に関する項目が含まれることがあります。古い共有情報を使う場合は、サーバーが実際に採用している認証方式を確認してください。旧設定の値をすべてのノードに共通する値として使うことはできません。現在一般的なAEAD構成では、通常、クライアント側でユーザー番号を追加する必要はありません。具体的な項目はインポート結果とサーバーの説明を確認してください。

VMessのセキュリティ設定は、プロトコル自体のデータ暗号化方式に関するもので、通信設定のTLSスイッチとは別です。画面の「自動」は、通常、コアが対応状況に応じて適切な方式を選ぶことを示し、暗号化されないという意味ではありません。サーバー側で方式が制限されている場合は、その設定に従ってください。互換性の問題が起きたら、複数の暗号化方式を手当たり次第に切り替えず、まず提供元の設定値に戻しましょう。

システム時刻も確認してください。VMessの認証処理は時刻情報に関係するため、端末の時計が大きくずれていると認証に失敗し、ネットワークのタイムアウトのように見えることがあります。まずシステムの自動時刻設定を有効にして、再接続してみましょう。UUIDを何度も変更するより効果的な場合があります。同じ設定が別の端末で動作するなら、端末間の時刻、コアの選択、通信方式の項目を一つずつ比べてください。すべての接続項目を作り直す必要はありません。

VLESSは軽量でも、単独で安全性を確保するわけではない

VLESSの基本設計は、VMessのような一般的なペイロード暗号化を行いません。そのため、一般的な構成ではTLSまたはREALITYと組み合わせます。クライアントのencryptionに表示されるnoneは、このプロトコル項目の値であり、接続全体の安全性を示すものではありません。セキュリティ層が有効か、サーバーの本人確認がどのように行われるかも確認してください。一つの項目だけで接続の安全性を判断すると、重要な背景を見落とします。

VLESS設定のflowは、速度の段階を示す項目ではありません。たとえば xtls-rprx-vision は特定のフロー制御方式を表し、サーバー、コア、関連する接続設定が一体で対応している必要があります。サーバー側に該当する設定がなければ、クライアントに入力しても通信できないことがあります。逆にサーバー側でこの方式が必須なのに、インポート時に項目が失われた場合、通常のTLSスイッチでは補えません。

VLESSを選ぶ実際の理由は、多くの場合、既存サーバーがTLSまたはREALITYとの特定の組み合わせを使っていて、クライアントのコアがその設定を完全に表現できることです。「新しいプロトコル名だから速い」とは限りません。プロトコル処理の少なさが一部の負荷を減らす可能性はありますが、実際の経路、通信方式、端末の暗号化性能、同時接続数も影響します。安定しているVMess設定を移行するなら、互換性や保守性など明確な目的を持ちましょう。

クライアントで2種類の設定を確認する

v2rayNに接続設定をインポートしたら、編集画面を開き、プロトコル、サーバー、ポート、UUIDを確認してから通信方式、セキュリティ層、詳細項目を見直します。ノード名は自由に変更できますが、認証情報は書き換えないでください。v2rayNGでも同じ順序で確認し、特に詳細設定に折りたたまれているサーバー名とflowに注意しましょう。保存後に接続テストを行い、一覧に表示された古い設定が引き続き有効になっていないかも確認してください。

インポート直後に接続できない場合は、まずログで失敗した段階を確認します。サーバーへの接続が確立しない場合は、ネットワークとポートを優先して調べます。ハンドシェイクで拒否された場合は、認証、セキュリティ層、flowを確認します。接続後に一部のアクセス先だけ失敗する場合は、ルーティングと名前解決を調べましょう。項目の違いは4種類のプロトコルの用途別比較も参考にしてください。最初のトラブルシューティングで、すべての設定を同時に変更する必要はありません。

TrojanとShadowsocks：異なるセキュリティ設計

TrojanとShadowsocksは同じノード一覧に並ぶことがありますが、認証と暗号化の設計は異なります。一般的なTrojanの使い方では、TLSで安全な通信路を確立し、その中でプロキシリクエストとパスワード認証を行います。Shadowsocksは共有シークレットと選択した暗号スイートでプロキシ通信を保護します。どちらも画面上で「パスワード」を使うからといって、その表示だけで選ばず、構成全体を比べましょう。

TrojanではTLSとの組み合わせが重要

Trojanのパスワードはアクセス認証情報で、サーバー名と証明書の検証はサーバーの本人確認を担います。どちらも欠かせません。パスワードが正しくても証明書名が一致しなければ接続は失敗し、証明書が信頼できてもパスワードが誤っていれば有効なプロキシセッションは確立できません。提供元からドメイン名が指定されている場合は、その名前がセキュリティ層の設定にも使われているか確認してください。サーバーアドレスをIPアドレスに変えただけで、ほかの項目を放置しないようにしましょう。

Trojanの一般的な標準構成はTCPとTLSですが、コアやサーバーの実装によって別の通信方式が追加されることがあります。同じTrojanという表示でも、通信方式まで同じとは限りません。WebSocketのパスなど拡張項目がある場合は、使用中のコアが該当する実装に対応しているか確認してください。trojan://というプレフィックスを認識できても、インポーターが拡張情報をすべて保持したとは限りません。

TLSのハンドシェイクに失敗した場合は、まずシステム時刻、サーバー名、証明書の信頼チェーンを確認し、中継が接続を本来のサービスに転送しているかも調べます。テストを通すために証明書検証を無効にしたまま使わないでください。検証を無効にすると、信頼できるサーバーとほかの接続先を区別する仕組みが弱まり、テストに成功しても設定が正しいとは言えません。サーバー名と証明書の対応を修正するのが確実です。

Shadowsocksの暗号化方式名は正確に一致させる

Shadowsocksでは、開発の過程でさまざまな暗号化方式が使われてきました。現在はAEAD方式が一般的で、必要な鍵の形式が異なる新しい暗号スイートもあります。クライアントはサーバーの方式と、それに対応する認証情報の形式の両方をサポートしている必要があります。方式名、鍵のエンコード形式、パスワード文字列はいずれも接続設定です。名前が似ているからと置き換えないでください。同じサーバーアドレスでも、認証設定が大きく異なる場合があります。

従来のパスワードから鍵を導出する設定では、パスワード文字列を使って実際の鍵を生成します。一部の新しい暗号スイートでは、指定された長さのエンコード済み鍵が必要な場合があります。どちらもパスワード欄に表示されることがありますが、意味は異なります。コピー時は先頭や末尾の空白、改行、エンコード文字に注意してください。形式エラーが表示されたら、保存できるまで文字を削るのではなく、方式に応じた入力要件を確認しましょう。

ShadowsocksでUDPを使うには、接続の両端と経路が対応している必要があります。サーバーでUDPが有効か、通信経路が許可しているか、クライアントのローカル接続方式がUDPを転送するかによって結果が変わります。Webページが表示できても、TCP通信の一部が正常なことを示すにすぎず、リアルタイム通信などのUDP通信も使えるとは限りません。特定のアプリだけで問題が起きる場合は、通信の種類を確認してから関連する経路を調べましょう。暗号化方式を変更するより効果的です。

設定の簡潔さと保守コストを合わせて比較する

Shadowsocksは設定項目が少ない構成が多く、条件が分かっている環境では導入しやすい一方、追加プラグインや拡張機能によって互換性の範囲が変わります。共有リンクに拡張パラメーターがある場合は、使う3つのクライアントのコアと画面が対応しているか確認してください。プラグイン項目を単なるメモとして無視してはいけません。Trojanは証明書やドメイン名の管理が増える傾向がありますが、その分、実績のあるTLSの信頼機構を使って本人確認を行います。

選定表でShadowsocksを一律に「最速」、Trojanを一律に「低速」と評価するのは、比較条件が不十分です。ハードウェアアクセラレーションに対応するアルゴリズム、接続の再利用、サーバー負荷、実際のネットワーク経路によって結果は変わります。デスクトップで日常的に使うなら、設定がそろっていて、サーバーの管理方針が明確で、継続的に更新される構成を優先しましょう。モバイル端末では、同じ用途でバックグラウンド接続の維持とバッテリー消費を比べてください。

TrojanまたはShadowsocksの設定がすでに安定しているなら、一覧のプロトコル名をそろえるだけのために変更する必要はありません。移行が必要になるのは、旧方式がサポートされなくなった場合、サーバー設定が変更された場合、現在の構成では必要な機能を提供できない場合などです。移行時は比較用に旧設定を残し、新しい設定を追加して検証してから旧設定を無効にしましょう。認証情報とクライアント設定を同時に変更するのは避けてください。

TLSとREALITY：サーバーの本人確認とハンドシェイク設定

TLSとREALITYは、クライアントの「セキュリティ」などのメニューに表示されることがあります。最終的にアクセスするWebサイトを選ぶ機能ではなく、クライアントとプロキシサーバーの間に保護された接続を確立する仕組みです。一般的なVLESS設定ではどちらかと組み合わせることがあり、通常のTrojan構成もTLSに依存します。セキュリティ層はサーバー設定と一致させる必要があり、クライアント側だけで有効にできる追加機能ではありません。

TLSのサーバー名・証明書・アドレス

TLS接続では、混同しやすい名前がいくつかあります。実際に接続するアドレス、ハンドシェイクで使うサーバー名、証明書に記載された名前です。接続先アドレスはデータの送信先を決め、サーバー名は通常SNIとしてハンドシェイクに使われ、本人確認にも利用されます。それぞれ異なる値になることはありますが、サーバー側の設計に基づいている必要があります。接続先を別のサーバーに変え、元のサーバー名だけ残しても接続できるとは限りません。

証明書の検証では、信頼関係、有効期間、名前の一致などを確認します。システム時刻が誤っていると有効期間の判定に影響し、証明書チェーンが不完全だと一部の端末だけで問題が表面化することがあります。設定のコピーや接続先の手動変更後には、名前の不一致も起こりやすくなります。こうした問題を検証の無効化で覆い隠してはいけません。まず提供元が指定したドメイン名と端末の時刻を確認し、クライアントが実際に使っているサーバー名を調べると、順を追って切り分けられます。

ALPNはアプリケーション層のプロトコルをネゴシエートする仕組みです。入力が必要か、どの値を指定するかは、通信方式とサーバーの設計によって異なります。gRPCなどの構成はHTTP/2に明確に依存しますが、通常の接続では手動指定が不要なこともあります。別のノードのALPNリストをコピーすると、正常だったハンドシェイクに不整合が生じる場合があります。入力欄があるからといって、すべての項目を手動で設定する必要はありません。

REALITYでは関連するパラメーターを一式で設定する

REALITYは一般的な証明書による構成とは異なる検証方式を用い、Xray関連の接続構成でよく使われます。クライアントには通常、サーバー名、サーバーから提供された検証情報、short IDなどが必要です。項目名はクライアントやコアの画面によって異なることがあります。サーバーの秘密鍵は必ずサーバー側に保管してください。クライアントにインポートするのは検証用の情報であり、サーバー設定にあるすべての鍵をクライアントに移すわけではありません。

short IDはノード番号でも、自由に作るメモでもありません。サーバーで許可されている値と一致させ、形式上の制約も設定の提供元に確認してください。サーバー名もサーバー側の設定と一致させる必要があり、よく知られたドメイン名なら何でも使えるわけではありません。フィンガープリント設定はハンドシェイク特性の模擬方法を指定するもので、アクセス先Webサイトの本人確認とは異なります。フィンガープリント、サーバー名、接続先アドレスはそれぞれ役割が異なります。

一般的なVLESS、REALITY、Visionの組み合わせでは、flowとセキュリティ層の設定を合わせて確認します。ただし、すべてのREALITY接続に同じflowを入力すればよいとは限りません。クライアントの対応状況、通信方式との適合性、サーバー側の要件を個別に確認してください。インポーターがプロトコルを認識しても、セキュリティ層の項目を取りこぼすと、一覧上は設定がそろっているように見えてもハンドシェイクに失敗します。ノード名だけを見るより、編集画面で確認する方が確実です。

ハンドシェイクの段階から原因を特定する

ログに基盤となる接続の確立後すぐに切断されたと表示された場合は、通常のTLSにおける証明書検証エラーと、REALITYのパラメーター検証エラーを区別します。前者ではサーバー名、時刻、信頼チェーンを確認し、後者では検証情報、short ID、サーバー名、コアの対応状況を確認してください。どちらも画面上では単に接続失敗と表示されることがあります。ログの詳細を開けば、どのレイヤーを修正すべきか分かります。

REALITYはローカルDNS、システムプロキシ、アプリ自体の証明書問題を自動で解決するものではありません。特定のWebサイトだけでアプリケーション層の証明書エラーが出る場合は、ブラウザーとWebサイト間の内側のTLSか、クライアントとサーバー間の外側のハンドシェイクかを見極めてください。REALITYが有効だからといって、すべての証明書や名前解決の問題を同じ原因とみなさないようにしましょう。接続の段階ごとに切り分ければ、正しいセキュリティ層の設定を何度も変更せずに済みます。

Project V、V2Fly、Xray：コアとクライアントの役割

V2Rayは技術エコシステムを指す名称として使われるほか、具体的なプログラムや設定名に含まれることもあります。Project Vはこのエコシステムの背景を知る手がかりです。V2FlyはV2Rayのコミュニティ開発を引き継ぎ、Xrayは別のコアとして発展しました。歴史や設定概念の一部は共通していますが、機能の進化はそれぞれ異なります。設定が動作するか判断するには、名前にV2Rayが含まれているかではなく、使用するコアの対応状況を確認してください。

クライアントが操作を管理し、コアが接続を実行する

GUIクライアントはサブスクリプション管理、ノード編集、システムプロキシの切り替え、ログ表示などを行い、設定をコアに渡して実行します。コアはプロトコルの解析、接続、セキュリティ層、ルーティングなどを担当します。画面上で保存できても、それは入力内容がローカルのチェックを通過したことを示すだけで、コアがすべての設定項目を受け付けたとは限りません。リンクをインポートできても、使用中のコアがリンク内の拡張項目すべてに対応しているとは限りません。

デスクトップでは、Windows、macOS、Linux向けの導入窓口としてv2rayNをおすすめします。利用できるコアや機能は、インストールした配布パッケージとクライアントの対応状況によって異なります。別のプラットフォームの画面を見て、自分の環境にも同じメニューがあると判断しないでください。Windows版のデスクトップ版と従来のWPF版は、主に画面技術と操作手順が異なります。「クラシック」は旧プロトコルだけに対応するという意味でも、「デスクトップ版」はすべての機能が必ず使えるという意味でもありません。

AndroidではXrayコアを採用するv2rayNGを優先し、V2Flyコアを使うv2flyNGを代替候補として検討します。両方のクライアントで同じ設定を利用できる場合もありますが、アプリ名を置き換えるだけですべての設定に対応できるわけではありません。特にREALITY、特定のflow、コア拡張を使う場合は、どの機能に依存しているか確認してください。設定がXrayの特定の実装を明確に必要とするなら、似た入力画面があるだけで別のコアでも動作するとは限りません。

設定全体をそのまま相互に置き換えられるわけではない

V2FlyとXrayは、一般的なインバウンド、アウトバウンド、ルーティングなどの概念に共通点があり、簡単な設定なら移行できる場合もあります。ただし、セキュリティ層、通信方式の実装、項目の値、拡張機能には違いがあります。どちらもJSONを読み込めても、それはファイル構文が同じというだけで、設定の意味まで一致するとは限りません。GUIクライアントが生成する実行用設定には、ローカルパスや内部タグが含まれることもあるため、別のクライアントへのインポートファイルとしてそのまま使うのは避けましょう。

移行する場合は、まずプロトコル、通信方式、セキュリティ層、フロー制御、名前解決の各機能を整理し、移行先のコアが対応しているか一つずつ確認してください。一般的なサーバーアドレスやユーザー識別情報は移しやすい一方、コア固有の項目には新しい設定情報が必要です。動作ログから設定を組み立てるより、元の共有情報を保存しておく方が確実です。サーバー側も変更する場合は、クライアントだけでなく両端の設定をまとめて更新してください。

更新による機能変更と動作確認

クライアントの更新とコアの更新は関連しますが、同じ操作ではありません。新しい画面でサブスクリプションの解析が修正されることもあれば、コアの更新で項目の検証やプロトコルの実装が変わることもあり、既存設定に影響する可能性があります。更新前に現在の接続設定、接続方式、重要なルーティング設定を記録し、更新後はまず元の基本設定を確認してください。一度にコア、通信方式、ルーティングを変更すると、問題が起きたとき原因を特定しにくくなります。

ログに未知の項目、無効なflow、未対応のセキュリティ方式が表示されたら、詳細項目をすべて消す前に、コアの選択と設定元が現在のクライアントに合っているか確認してください。項目を消すとプログラムが起動することはあっても、接続設定の意味が変わる可能性があります。エコシステムの関係はProject Vとクライアントの系統に関する解説をご覧ください。インストール形式はダウンロードページで確認できるため、このプロトコルガイドでは別のクライアント種別を追加で紹介しません。

速度・リソース使用量・モバイル端末のバッテリー

プロトコル性能に、常に当てはまる速度ランキングはありません。同じプロトコルでも、通信方式、セキュリティ層、サーバー構成によって動作が異なり、平均的なプロトコル間の負荷差より大きな違いになることがあります。比較の前に用途を明確にしましょう。Webページの初回表示では接続確立と名前解決、継続的なダウンロードでは安定したスループット、リアルタイム通信では遅延の揺れやパケットロスが重要です。これらを一つの数値にまとめると、互いに矛盾する結論になりがちです。

初回表示と継続通信を分けて測定する

Webページを一度開くだけでも、ローカル接続、名前解決、サーバーへの接続、セキュリティハンドシェイク、その後のWebサイトへの接続とアプリケーション応答が発生します。WebSocket、gRPCなどの中継を加えると、それぞれのネゴシエーションや制御も必要になります。プロトコルの処理負荷が軽くても、不安定な回線や混雑した接続先は補えません。反対に、接続済みの通信を再利用できても、初回接続時のコスト全体を示すものではありません。

クライアントのTCPingは主にサーバーポートへの接続状況を調べるものです。実接続テストでは通常、プロキシ経由でテスト先にアクセスしますが、結果はテスト先や実装方法にも左右されます。どちらも継続的なダウンロード速度を測るものではありません。TCPingが正常でも実接続に失敗する場合、認証、セキュリティ層、アクセス先への接続段階に問題がある可能性があります。それだけで「プロトコルが遅い」とは判断できません。まず接続できることを確認してから、使い勝手を比べましょう。

公平に比較するには、できるだけ同じ端末、ネットワーク、アクセス先、接続方式を使い、テスト順を入れ替えながら複数の時間帯で繰り返します。サーバーの地域とプロトコルを同時に変えると、結果の違いをプロトコルの影響と判断できません。ページの初回表示、再訪問、長時間のデータ転送をそれぞれ記録する方が、最小値を追い求めるより役立ちます。詳しい確認手順は初回接続とプロキシの動作確認をご覧ください。

CPU・メモリ・接続数が与える影響

暗号化の処理負荷は、アルゴリズムとプロセッサーの性能によって異なります。特定の端末でハードウェアアクセラレーションに対応するアルゴリズムもあり、別のアーキテクチャでは結果が逆転することがあります。TLS、プロトコル自体の暗号化、データのコピー、通信方式のカプセル化はいずれも処理リソースを使う可能性がありますが、常に特定のレイヤーがボトルネックになるわけではありません。軽いブラウジングでは差が目立たず、高負荷や長時間の通信でCPU使用率の上昇が見えることがあります。

メモリ使用量は、接続数、バッファー、ルールセット、DNSキャッシュ、ログ量にも左右されます。大規模なルーティングルールによるリソースの変化を、すべてVMessやVLESSの影響と考えることはできません。クライアントの使用量を調べるときは、ルールとログの設定をそろえ、アイドル時、普段のブラウジング時、継続通信時を比べてください。同じ負荷を再現できれば、結果の理由を判断しやすくなります。

多重化は接続確立のコストを一部減らせますが、あらゆる用途でスループットが上がるとは限りません。共有接続でパケットロスや混雑が起きると、複数の通信が同時に影響を受けることがあります。通信方式自体がすでに多重化を備えている場合、さらに重ねると複雑になる可能性もあります。既定の設定で安定しているなら、まずその状態を基準にしましょう。試す場合は一度に一つの項目だけを変更し、Webページを一度開くだけでなく、短時間と長時間の接続を両方確認してください。

モバイル端末のバッテリー消費は接続以外の要因にも左右される

モバイル端末では、無線の電波状況、画面、バックグラウンドアプリ、システムのスケジューリングがバッテリー消費に影響します。頻繁な切断と再接続、短い間隔でのキープアライブ、ネットワーク切り替えにより、無線モジュールが長時間動作することがあります。プロトコルの処理が軽くても、再接続が頻繁なら省電力とは限りません。プロトコル名だけを見て「省電力モード」と判断せず、接続の安定性、バックグラウンドでの強制終了、再試行の頻度を確認しましょう。

v2rayNGまたはv2flyNGでバッテリー消費を比較する場合は、接続対象の範囲、ルール、画面の明るさ、バックグラウンドアプリをできるだけそろえてください。待機時と実際の利用時を分けて観察し、継続的なダウンロードとアイドル状態を同じ条件として比べないようにしましょう。システムのバッテリー最適化設定は、実際のバックグラウンド利用に合わせて調整してください。バックグラウンドで長く動作できるようにすると接続を維持しやすくなりますが、その分クライアントが通信を処理する時間も長くなります。用途に応じた判断が必要です。

モバイルネットワークでだけ消費が増える場合は、電波状況とネットワークの切り替えを確認します。特定のノードだけ頻繁に再接続する場合は、通信経路とサーバーを調べましょう。すべての設定がバックグラウンドで切断される場合は、システム側の制限を確認してください。不要な起動や再試行を減らすことが目的であり、省電力のためにセキュリティ層を削除するべきではありません。再現できない短時間のバッテリー変化は経過を観察し、プロトコル全般の結論に結び付けないようにしましょう。

共有リンクとサブスクリプション：形式の互換性と接続の互換性は別

共有リンクは通常、1つの接続設定を表します。サブスクリプションURLは、設定の一覧を取得して更新するためのものです。どちらもクリップボードからインポートできますが、クライアントが行う処理は異なります。共有リンクではパラメーターを解析し、サブスクリプションではまず内容を取得してから形式を判定します。インポート失敗は、取得、デコード、項目の変換、コアでの実行のどの段階でも起こります。まず失敗した場所を見極め、URL、形式、プロトコル対応のどれを確認するか決めましょう。

同じプレフィックスでも項目の違いに注意

一般的なVMess共有リンクはエンコードされた構造化データを使います。VLESSとTrojanではクエリパラメーター付きURI、Shadowsocksでは独自のユーザー情報エンコード方式がよく使われます。生成ツールによって、拡張項目や既定値の扱いは異なります。クライアントがプレフィックスを認識しても、入口の形式を判別できたことを示すだけです。flow、セキュリティ層、フィンガープリントなどの項目が正しく反映されたか、編集画面で確認してください。

URIの特殊文字は正しくエンコードする必要があります。ノード名の空白、パスワードに含まれる記号、パラメーター値の区切り文字は、コピーや転送で変わることがあります。ブラウザーが自動デコードした表示文字列は、そのまま再構成に使えるとは限りません。元の完全なリンクをコピーし、不要に見えるパーセント記号や等号を手動で削除しないでください。QRコードからインポートした場合も重要な項目を確認し、読み取りに成功しただけで設定が完全だと判断しないようにしましょう。

共有情報に含まれるremarksやフラグメントのノード名は表示用で、通常は変更できます。一方、クエリパラメーターは接続に使われる場合があります。見慣れないパラメーターがあっても、すぐにノード名とみなして削除せず、クライアントが対応しているか、サーバー側で必要かを確認してください。インポーターによっては、未知のパラメーターをエラーなしで無視することがあります。その場合、一覧に項目が表示されても詳細機能が失われている可能性があります。元の共有情報と項目ごとに照らし合わせましょう。

サブスクリプションの更新は独立したデータ通信

サブスクリプションから返される内容は、リンク一覧、エンコードされた一覧、構造化設定などさまざまで、3つのクライアントすべてがそのまま読み込めるとは限りません。拡張子だけで内容の種類を判断することもできません。通常のWebページに見えるURLがサブスクリプションを返す一方、別のURLはログインページを返すことがあります。更新後に項目が空になった場合は、まずリクエストが成功したか、設定データが返されたかを確認し、その後でプロトコルの互換性を調べてください。

サブスクリプションの取得には、直接接続するか、現在のプロキシを経由するかの設定が必要な場合があります。これはインポート後のノードの接続方法とは別の話です。使用中のプロキシが利用できないと、そのプロキシ経由の更新も失敗し、「接続するには更新が必要だが、更新には接続が必要」という状態になることがあります。提供元の案内に従って利用可能な更新経路を選び、動作確認済みの設定は残してください。取得の問題を直すために、端末上の設定をすべて削除しないでください。

サブスクリプションにはアクセス認証情報が含まれることが多く、URL自体が認証機能を持つ場合があります。トラブル相談用のスクリーンショットに完全なURLを載せず、クエリパラメーターを公開コメントに貼らないでください。形式を説明する場合は、返された内容の種類、エラーの分類、項目名だけで十分です。期限切れ、認証失効、サーバーからエラーページが返る問題は、設定の提供元に問い合わせてください。ローカルのプロトコルを変えても、取得時のアクセス権限は修復できません。

更新後に有効な設定とローカル変更を確認する

サブスクリプション更新でノードの置き換え、名前の変更、古いサーバーの削除が行われることがあります。有効なノードの選択や手動変更が維持されるかは、クライアントの実装によります。重要なローカル変更は事前に記録し、必要であれば分かりやすい名前を付けて別の項目として複製してください。ただし、更新されなくなった古い認証情報を長期間使い続けないようにしましょう。更新後は、現在の接続設定、プロトコル、セキュリティ層、ルーティング先を確認してから、実際に接続してください。

クライアント間で移行する場合は、提供元が明確にサポートするサブスクリプション形式を優先してください。設定が少なければ一つずつインポートして確認し、同じ拡張機能に依存する設定が多数ある場合は、まず1つで動作を検証してから全体を移行します。変換ツールは項目を失ったり、ローカルのルーティングの意味を変えたりすることがあります。変換に成功しただけで、動作も正常だと判断しないでください。認証情報を含むデータを扱う際は、どの処理を経由するのかも確認しましょう。

更新前は正常で更新後に問題が起きた場合は、すぐにクライアントを再インストールせず、追加された変更点を比べてください。サーバーアドレス、プロトコル、セキュリティ層、flowの変更が、必要なコアに影響している可能性があります。認証情報を含まないエラー概要を残しておくと、提供元に状況を正確に伝えやすくなります。インポート、認証、接続のトラブルはヘルプセンターの該当項目もご覧ください。

用途に合わせて選ぶ：まず設定を合わせ、実際の通信で検証

クライアントのプロトコル選択メニューは、自由に新しい方式へ切り替えるためのものではありません。選択肢は、まずサーバーが提供する有効な設定、次にローカルのコアが対応する機能、最後に性能や保守性の好みで決まります。用途を確認し、設定全体を照合し、安定した基準を作ってから代替案を比べるのが適切です。選定の成果は、サーバーの条件を無視したプロトコルランキングではなく、検証可能な接続設定であるべきです。

デスクトップの日常利用とモバイルのバックグラウンド利用

デスクトップで普段使いする場合は、v2rayNで提供元の設定を管理し、システムプロキシが必要なアプリをカバーしているかを先に確認してください。VMess、Trojan、Shadowsocksの接続が安定しているなら、VLESSを見かけただけで移行する必要はありません。サーバーがXrayに依存するREALITY設定を提供している場合は、対応するコアと項目を確認しましょう。デスクトップでは端末リソースより、接続の安定性と分かりやすいルーティングの方が使い勝手に直結します。

モバイルではv2rayNGと設定の互換性を優先し、バックグラウンドでの接続維持、ネットワーク切り替え、実際の用途を含めて確認してください。V2Flyの機能が必要な場合にv2flyNGを検討します。Webページが一度開くかだけでなく、待機後の復帰、Wi-Fiの切り替え、必要なUDP通信も確かめましょう。プロトコルのハンドシェイクが成功しても、システムのバックグラウンド制限やローカル接続範囲によって、特定のアプリが使い続けられないことがあります。

複数端末で共用する場合は、1台だけで複雑な拡張を追求するより、すべての端末で設定を完全に表現できる構成を選ぶ方が管理しやすくなります。各端末に分かりやすい名前を付け、設定の入手元も記録しておけば、更新時の混乱を防げます。サーバー側で認証情報を端末ごとに割り当てられるなら、個別管理によって失効やトラブル対応が容易になります。すべての端末の問題を同じノード名のせいにせず、実際に使われている設定を確認してください。

ローカルルーティングとプロトコル選択は分けて考える

ルーティングルールは通信をどのアウトバウンドに渡すかを決めるもので、リモート側のプロトコルは変更しません。Webサイトが開けない場合、テスト対象のプロキシ項目に通信が届いていない可能性もあります。切り分けの前に、適用されたルール、使用されたアウトバウンド、名前解決の経路を確認してください。以下は広告カテゴリをブロックする、コアのルーティングルールにおける単一ルールオブジェクトの例です。完全な設定ではありません。blockという名前のブロック用アウトバウンドと、対応するgeositeデータが必要です。

{
  "type": "field",
  "domain": ["geosite:category-ads-all"],
  "outboundTag": "block"
}

この例から分かるように、ルールが参照するタグとデータファイルも実行条件の一部です。プロトコルのハンドシェイクが正常でも、アウトバウンドやルール用データが不足していれば補えません。普段のトラブル対応では、まずクライアントのシンプルなルール設定を使い、問題がなければカスタムルールを段階的に戻してください。1つのノードを確認するために、実行設定全体を上書きしないようにしましょう。特定の種類のドメインだけ失敗するなら、プロトコルを変える前にルールと名前解決を確認してください。

システムプロキシとTunモードも個別に動作確認してください。アプリがシステムプロキシに従っていない場合、プロトコルを変えても通信が自動的にクライアントへ届くことはありません。Tunモードで権限やルーティングに問題がある場合も、ノードの接続テストが成功しただけでは接続方式全体が正常とは言えません。まずプロキシに確実に従うアプリで確認し、その後に対象範囲を広げましょう。初めて設定する場合はクイックスタートガイドに戻り、インポート、選択、接続、アクセス確認の順に進めてください。

確認手順を整理して選定を仕上げる

1回目はアドレス、ポート、プロトコル、認証情報を確認し、接続先と本人確認の設定を確かめます。2回目は通信方式、パス、サーバー名、セキュリティ層、flowを確認し、ハンドシェイクの組み合わせを検証します。3回目はコアの対応状況、ローカル接続、ルーティングを確認し、実際の通信が目的のアウトバウンドを通っているか確かめます。根拠のある不一致だけを各段階で一つずつ修正し、保存して再試行してください。原因と結果を把握しやすく、元の設定とも比較できます。

ログは原因の絞り込みに役立ちますが、最後の1行だけを切り取るのは避けてください。基盤接続のタイムアウト、認証拒否、証明書名の不一致、接続先の名前解決失敗は、それぞれ異なる段階で発生します。エラーの種類、発生した状況、直近の変更を記録し、認証情報を隠して相談しましょう。特定の端末だけで同じ設定が失敗する場合は、その端末のコア、時刻、接続設定を優先して比較してください。複数端末で同時に失敗するなら、サーバーの状態と設定の更新を確認します。

最終的に使う設定は、パラメーターの入手元が明確で、必要な用途で動作確認でき、更新とトラブル対応の手順が分かっていることが大切です。性能の比較は、この条件がそろってから行いましょう。インストーラーはOSとCPUアーキテクチャに合わせてダウンロードセンターから選べます。用語が分からない場合は用語集を、繰り返す問題はヘルプセンターの項目別ガイドをご覧ください。プロトコル名は出発点にすぎません。設定全体と再現可能な検証が、選定の根拠になります。