V2Rayのプロトコルとコア
技術ガイド

プロトコルの階層：まずクライアントの設定項目を整理

クライアント、コア、サーバーはそれぞれ別の役割

クライアントを選ぶ際は、新しい名称かどうかではなく、接続を構成する要素を把握することが大切です。v2rayNはサーバー、サブスクリプション、動作モードを管理するGUIクライアントです。コアは実際の接続確立やプロトコル処理、ルーティング、名前解決を担います。サーバー側にも、クライアントと一致する接続方式が必要です。画面で特定のプロトコルを選べても、それだけで現在のコア、サーバー設定、インポート形式のすべてが対応しているとは限りません。

接続は、ローカルの入口、プロキシプロトコル、トランスポート方式、セキュリティ層、リモート側の出口に分けて考えられます。ローカルの入口は、システムプロキシが指定するローカルポートや、仮想NICが受け取るデータなど、アプリから通信を受け取る方法を決めます。プロキシプロトコルは認証とリクエストの形式を、トランスポート方式はデータを下位の接続に載せる方法を担います。セキュリティ層は、対応する通信を保護します。リモート側の出口から接続先のサービスへ接続します。どこか一つでも不一致があると、ブラウザーが応答を待ち続けるなどの症状が起きますが、対処方法は階層ごとに異なります。

プロトコルとトランスポート方式は分けて確認

VMess、VLESS、Trojan、Shadowsocksは、プロキシプロトコルまたはプロキシ方式の名称です。一方、TCP、WebSocket、gRPCはトランスポート方式を表すため、同じ基準で比較して置き換えることはできません。VLESSは複数のトランスポート方式やセキュリティ設定と組み合わせられますが、実際に使える範囲はコアとサーバーの対応状況によります。サーバーがWebSocketを要求する場合、プロトコルだけVLESSにして通常のTCP設定を残しても同等の接続にはなりません。パス、ホスト名、セキュリティ層も合わせて設定してください。

TLSとREALITYも、別のサーバーアドレスやサブスクリプションではなく、接続のセキュリティ設定にあたります。通常のTLS接続では、サーバー証明書と名前を照合してサーバーの身元を確認します。REALITYは独自の認証パラメーターとハンドシェイク方式を使います。クライアントの同じプルダウンに表示されていても、設定項目を一つずつ置き換えられるわけではありません。TLSの証明書設定をそのままREALITYに流用したり、REALITYの公開鍵をユーザーID欄に入力したりしないでください。

階層を意識してインポート結果と速度測定を確認

サブスクリプションのインポートに成功した場合、通常はテキストを解析してクライアントのサーバー情報に変換できたことを示します。接続先ポートに到達できることや、認証パラメーターが正しいことまでは確認できません。また、ポートに到達してもプロトコルのハンドシェイクが成功するとは限りません。下位の接続を確立できても、サーバー名、パス、ユーザーID、セキュリティ設定の不一致で中断することがあります。接続確認では、インポートと解析、下位接続の確立、プロトコル認証、接続先へのアクセスの順に進めましょう。一つの成功表示だけで接続全体が完了したと判断しないでください。

ルーティングやDNSも、実際の症状に影響します。アプリの通信がクライアントに渡されていなかったり、ドメイン名が直接接続に振り分けられていたりすると、選択中のサーバーの性能を正しく測れません。まずは同じアプリ、同じ接続先、明確な通信制御モードで確認し、その後にルールを追加してください。テストごとに変更する階層を一つに絞れば、結果がプロトコル、名前解決、ローカルの入口のどこに由来するか判断できます。よく使う項目の簡単な説明は用語集で確認できます。名前が似た設定を同じパラメーターと混同しないようにしましょう。

プロキシプロトコル：開発の背景と設計上の違い

VMessとVLESS：異なる設計方針

VMessはProject Vのエコシステムを構成する重要なプロトコルで、ユーザー認証、リクエスト形式、データ保護を一つの体系にまとめています。長年にわたって幅広いクライアントやサブスクリプションで使われており、必要な設定一式がすでに導入されている環境に適しています。現在の設定では、古いチュートリアルの旧式項目をそのまま使うのではなく、利用する実装が対応する認証方式と暗号化方式を確認してください。古い共有設定を使う場合は、各項目が現在のコアでも受け付けられるか確認が必要です。クライアントに保存できても、コアが従来と同じ方法で処理するとは限りません。

VLESSはよりシンプルな設計を目指し、プロキシプロトコル自体の役割を減らして、通信の保護を対応するセキュリティ層や管理された環境に委ねます。シンプルだからといって自動的に安全になるわけではなく、常にVMessより高速になるわけでもありません。インターネット上で運用する場合は、明確な通信保護の設計が必要です。一般的なVLESS設定には、ユーザーID、トランスポート方式、セキュリティ層、任意のフロー制御が含まれます。どれか一つでも変更すると、サーバーとの互換性が失われる可能性があります。プロトコル名だけで選ばず、サーバーが実際に提供する組み合わせを使ってください。

どちらもクライアントにユーザーIDが表示されることがありますが、項目名が似ていても相互に置き換えられるわけではありません。VMessの設定をVLESSに変更しても、通常はクライアント側の設定生成方法が変わるだけで、サーバーの認証プロトコルは変わりません。プロトコルを移行するには、サーバー側に対応する接続口を用意し、新しい設定をクライアントに配布する必要があります。安定して接続できており、明確な機能要件や互換性の問題がないなら、プルダウン一つだけを変えるより、クライアントとサーバーの設定を一致させたまま使うほうが適切です。

TrojanとSS：セキュリティへの依存と暗号方式の制約

Trojanは一般に、通信の保護をTLSに任せ、パスワードでプロキシ認証を行います。成熟したTLS機能と比較的シンプルなプロキシリクエストを組み合わせていますが、パスワードだけ入力すればよいわけではありません。アドレス、ポート、サーバー名、証明書の信頼設定、実際のトランスポート設定を一致させてください。証明書の検証に失敗した場合は、名前、システム時刻、サーバー証明書のチェーンを確認します。検証を無効にすればエラーが変わることはありますが、重要なサーバー認証も無効になるため、通常の接続方法として使うべきではありません。

SSはShadowsocksの一般的な略称で、事前共有鍵と明示的な暗号化方式を使ってプロキシ接続を構成します。設定項目は少なく見えることがありますが、暗号方式の名称そのものが互換性を左右します。暗号方式の系統によって鍵の形式、認証方法、実装要件が異なるため、パスワードだけでなく方式の項目も確認してください。クライアントとコアの両方が、サーバーで使われている方式に対応している必要があります。既存のSSサーバーを使う場合、「SSに対応」とだけ判断するより、暗号方式と鍵の形式を先に確認しましょう。

単独の名称ではなく、設定一式で選ぶ

プロトコルの開発背景を知れば、なぜそのような設定項目があるか理解できますが、実環境での検証に代わるものではありません。プロトコルヘッダーが短ければ一部の処理負荷を減らせる場合はありますが、実際のアクセスには名前解決、ハンドシェイク、リモート側の出口、接続先からの応答も関わります。ユーザーが感じる差は、サーバーの設置場所やネットワーク品質に大きく左右されることがあります。異なるサーバーで一度ダウンロード速度を測り、その差をVMessとVLESSの違いだと結論づけても、条件を揃えた比較にならず、ほかの端末にも当てはめられません。

クライアントを選ぶ際は、まずサーバーが必要な設定一式を提供しているか、現在のコアがそのパラメーターに対応しているか、サブスクリプションで全項目を表現できるか、利用するアプリが特定の通信機能を必要とするかを確認します。最初の3項目のうち一つでも満たされなければ、理論上の性能上の利点は得られません。フロー制御、セキュリティ層、暗号方式を推測で補わず、設定の提供元に元のパラメーターを確認してから、クライアントで一つずつ照合してください。プロトコル選びは、まず互換性の判断であり、その次に性能を調整するための判断です。

REALITYとXTLS Vision：セキュリティ層とフロー制御の違い

REALITYはVLESSと並ぶプロキシプロトコルではない

REALITYはXrayのエコシステムにおける通信セキュリティ機構で、VLESSと組み合わせて使われることが多いため、共有設定では一式が一つの名称で呼ばれる場合があります。設定は階層に分けて理解してください。VLESSはプロキシリクエストと認証を担い、REALITYは対応するハンドシェイクとサーバー認証を処理します。Visionは別のフロー制御方式です。連携して使われることはあっても、常に三つが一体となる同義語ではありません。クライアントにREALITYの選択肢があっても、どのプロトコルやトランスポート方式とも自由に組み合わせられるわけではありません。

一般的なクライアント設定には、サーバーアドレス、ポート、ユーザーID、サーバー名、フィンガープリント、公開鍵、ShortIdが含まれます。アドレスは実際の接続先を示します。サーバー名はハンドシェイク設定に使われ、アドレスの文字列と同じとは限りません。公開鍵はサーバー認証に使い、ShortIdはサーバーが許可する値と一致させます。項目名から値を推測したり、解決できるドメイン名をサーバー名欄に適当に入力したりしないでください。複数のチュートリアルから寄せ集めるのではなく、有効な設定一式からパラメーターを取得しましょう。

PublicKey、ShortId、Fingerprintの役割

PublicKeyはクライアントが使う公開の認証情報で、サーバー側の対応する秘密鍵と関係します。ユーザーIDではなく、任意のメモに置き換えられる値でもありません。クライアントには接続に必要な公開パラメーターだけを渡してください。サーバーの秘密鍵をクライアントに渡す必要はなく、渡してはいけません。ShortIdはサーバーが設定を識別するための情報の一部です。利用可能な値、長さ、形式は実装によって制限されます。空欄を許容する設定があっても、ほかのサーバーでも空欄にできるとは限りません。インポート時に項目が欠落している場合は、まず提供元の元データを確認してください。

Fingerprintは、クライアントのハンドシェイクで使うフィンガープリントの動作を選択します。端末のOSを表すものではなく、特殊な値ほど優れているわけでもありません。現在の実装が対応し、サーバーの要件に合う値を指定してください。選択肢が使えない場合は、独自の名前を入力するのではなく、実行中のコアとクライアントの対応状況を確認します。サーバー名はWebSocketのHost項目とも異なります。特定の構成で値が同じでも、別の階層に属するため、トラブルシューティングでは個別に確認してください。

トランスポートのセキュリティ層にREALITYを使う場合は、サーバーの設定に合わせてPublicKeyとShortIdを確認してください。ハンドシェイク失敗を解決するために、認証を無効にしたり、サーバー名を適当に入力したり、別のサーバーのパラメーターを混ぜたりしないでください。

Visionは特定のデータ経路を最適化する

XTLS Visionは通常、クライアントのフロー制御欄でxtls-rprx-visionと表示されます。特定のトラフィックとトランスポート方式の組み合わせを対象に、重複処理の一部を減らすなど、データ処理の経路を最適化します。汎用のダウンロード高速化スイッチでも、単純に暗号化を無効にする機能でもありません。実際の効果は、トラフィックの特性、コアの実装、使用するセキュリティ層とトランスポート方式によって異なります。サーバー設定と現在の実装が対応している場合に限り、対応するフロー制御を選んでください。すべてのVLESS設定に機械的に追加してはいけません。

一般的な構成では、TCP系のトランスポートと対応するセキュリティ層を組み合わせますが、Visionを使用できるかどうかは、実際のコアの対応状況とサーバーの要件で判断してください。WebSocketやgRPCなどのトランスポート方式は、データの構成方法や接続管理が異なります。どちらもVLESSを運べるからといって、同じフロー制御をそのまま適用できるわけではありません。インポート後にフロー制御が未対応、または組み合わせが無効というエラーが出たら、報告された項目を削除して無理に通すのではなく、元の設定で組み合わせを確認してください。

確認の順序と効果の見込み

手動で追加する場合は、まず実行中のコアを確認し、VLESSと正しいトランスポート方式を選びます。次にセキュリティ層とフロー制御を設定し、最後にサーバー名、フィンガープリント、公開鍵、ShortIdを入力します。保存したら設定を開き直し、各項目が保持されているか確認してください。開き直したときに項目が消えている場合は、編集画面の組み合わせ制限、インポーターの未対応、バージョンによる機能差などが考えられます。クライアントのログを確認しましょう。サーバー一覧に項目が残っているだけで、設定が正しく動くと判断しないでください。

この組み合わせを評価する際は、まずハンドシェイクが正しく行われること、次に安定してアクセスできることを確認し、その後に長時間接続した場合のリソース使用量を見ます。短時間の速度測定はサーバーの帯域幅を反映している可能性があり、フロー制御の効果を証明するものではありません。最初の応答が一時的に遅い場合も、DNSやモバイルネットワークの復帰が原因かもしれません。仕組みを詳しく知りたい場合は、REALITYとXTLS Visionの技術解説をご覧ください。実際に利用する際は、クライアントとサーバーの設定を一致させることが前提です。技術名称に合わせるためだけに、明示されているサーバー設定を変更しないでください。

V2FlyとXray：プロジェクトの関係と設定互換性

共通のルーツがあっても、機能が常に同じとは限らない

Project Vは、プロキシ機能をモジュール方式で構成するエコシステムの基盤です。V2FlyはV2Ray関連の実装を継続的にメンテナンスし、Xrayは関連コードや設定の慣習を引き継ぎながら独自に発展しています。入口、出口、ルーティング、DNSなど共通する概念や設定方法があり、よく似た項目もあります。ただし、別々に開発が進むプロジェクトであり、対応するプロトコル拡張、トランスポートの詳細、既定の動作、設定の検証方法が異なることがあります。プロジェクトの関係だけを根拠に、あらゆる設定が常に双方向で互換だと考えないでください。

一般ユーザーにとって、コアの違いが最も直接影響するのは、特定のパラメーターを実行できるかどうかです。REALITYとXTLS VisionはXrayを選ぶ重要な理由になります。特定の実装向けに書かれた設定も、原則として対象のコアで使ってください。V2Flyは、対応範囲が一致する既存環境に適しています。プロジェクト名だけで一律に優劣を決めることはできません。「どちらのコアが先進的か」と抽象的に比べるより、サーバーが必要な機能を提供しているか、クライアントが設定一式を正しく生成できるかを確認しましょう。

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

デスクトップではWindows、macOS、Linuxに対応し、サーバー設定、サブスクリプションのグループ、ルーティングをまとめて管理しやすいv2rayNを第一候補にできます。切り替え可能なコアは、インストール環境とクライアントの現在の対応状況によります。Androidでは通常、Xrayを使うv2rayNGを優先し、V2Flyと組み合わせる必要がある場合はv2flyNGを検討します。クライアントはプラットフォームとサーバーの要件を先に確認し、次にサブスクリプション形式を見て選びましょう。画面が似ていても、2つのモバイルクライアントが同じ機能を持つとは限りません。

GUIクライアントは、サーバー設定をコアが読み込める形式に変換します。この変換処理では、既定値を補ったり、構造を並べ替えたり、未対応項目を除外したりすることがあります。そのため、サーバー編集画面がコア設定をそのまま表示しているとは限りません。項目を保存できても動作しない場合は、起動ログを確認し、実際に呼び出されているコア、生成された設定が受け付けられたかどうか、起動時と接続時のどちらでエラーが起きたかを調べてください。コア層のトラブルとサブスクリプション層のトラブルは別の問題です。

名称だけを切り替えず、項目ごとに確認

設定の互換性は、構文、項目、動作の3段階に分けて考えられます。構文の互換性はファイルを解析できること、項目の互換性は各モジュールが設定を認識すること、動作の互換性は設定が実際に意図どおり機能することです。たとえば、同じ名前のルーティング設定でも、既定の名前解決方法に影響されることがあります。同じ出口の識別子を使う場合も、ルールから正しく参照されていなければなりません。コアが起動することは必要条件ですが、すべてのルーティング、DNS、トランスポートの組み合わせが検証済みであることを意味しません。

移行する前に、元のクライアントからエクスポートした設定と、必要な画面のスクリーンショットを保存してください。スクリーンショットではサブスクリプションURL、パスワード、個人情報を隠します。まずサーバーを1つだけ移行し、複雑な追加ルールを無効にして、明確なローカルプロキシ入口でテストしてください。その後、ドメインルール、DNSポリシー、TUNによる通信制御を段階的に戻します。コア、プロトコル、名前解決、動作モードを一度に変更すると、異常の原因を特定しにくくなり、ローカルルーティングの問題をコアの非互換と誤認するおそれがあります。

コアを更新する場合も、元に戻せるように準備してください。新しい実装で対応機能が増えることもあれば、以前は無視されていた項目が厳密に検証されるようになることもあります。古い設定でエラーが出た場合は、サーバーが使えなくなったと即断せず、該当項目の説明を確認しましょう。反対に、長期間更新しないと、新しいサブスクリプションの項目を認識できない場合があります。インストーラーとプラットフォームのアーキテクチャはクライアントダウンロードセンターで、3つのクライアントの用途はクライアント選びのガイドで確認できます。このページでは機能の対応範囲を説明しており、一度の更新があらゆる環境で性能向上につながるとは限りません。

速度とリソース：意味のある比較とは

初回応答、転送速度、接続の安定性を分けて考える

接続速度には少なくとも3種類の指標があります。1つ目は、リクエスト開始から応答までの時間で、DNS、下位接続、ハンドシェイクの往復回数に左右されます。2つ目は継続的なデータ転送速度で、回線容量、輻輳、サーバー負荷、出口の制限などが大きく影響します。3つ目は、接続を維持できるか、中断後にどれだけ早く復帰できるかです。最初の応答が速くても継続ダウンロードが遅い構成や、初回アクセスに少し時間がかかっても長時間接続が安定する構成があります。速度を一つの数値だけで評価しないでください。

プロトコルのオーバーヘッドはありますが、影響は接続全体の中で評価する必要があります。ユーザーからサーバーまでの経路、サーバーから接続先までの経路、接続先のサービス自体がボトルネックになる可能性があります。サーバーが異なる比較ではプロトコルの差を切り分けられず、時間帯が異なる比較では負荷の変動が混ざることがあります。トランスポートの違いを調べる場合は、端末、入口の場所、接続先のファイル、測定ツール、通信制御方式をできるだけ揃え、複数回交互に測定してください。一度の短い変動を安定した傾向と結論づけないようにしましょう。

ハンドシェイクの段階数と接続の再利用には、それぞれ異なるコストがある

TCP、TLS、アプリケーション層のトランスポート方式では、接続確立の手順が異なることがあります。WebSocketとgRPCにはそれぞれ独自のプロトコル構造があり、柔軟な導入方法や接続管理も異なります。追加のカプセル化は処理を増やすことがありますが、実際にボトルネックになるかは、サーバー構成、接続の再利用、トラフィックの特性によります。プロトコル名の数だけで必ず遅いと推測したり、同じポートを通るからといって接続コストが同じだと考えたりしないでください。

適切な場面で接続を再利用すると、接続の確立を繰り返す回数を減らせます。一方で、複数のリクエストが同じ下位接続を共有する形になります。共有接続で輻輳や異常が起きると、複数のリクエストに同時に影響することがあります。また、アプリがもともと長時間接続を維持している場合、さらに再利用を加えても効果が薄いことがあります。再利用の設定は、使用するコア、プロトコル、トラフィックの要件に合わせてください。すべてのサーバーに適用する速度向上スイッチとして使わず、変更後は短いリクエストと長時間接続の両方を確認しましょう。

CPUとメモリは処理負荷を揃えて比較する

暗号化方式、ハードウェア命令への対応、プロトコルのカプセル化、データのコピーはいずれもCPU負荷に影響します。古いプロセッサーでは高い転送速度を出す前に計算能力が上限に達することがありますが、新しい端末ではネットワークが主な制約になる場合があります。同じプロトコルを使う2台で結果が異なっても、不自然ではありません。確認時はクライアントとコアのプロセスが継続的に使うCPUを記録し、システム全体の使用率が低いからといって計算負荷を原因から除外せず、単一のコアが飽和していないか見てください。短時間のピークが長期的な負荷を示すとも限りません。

メモリ使用量は、同時接続数、バッファー、ルーティングデータ、DNSキャッシュ、ログなどに左右されます。GUIクライアントとコアのメモリ使用量は分けて確認してください。TUNなどの通信制御コンポーネントが別途負荷を増やすこともあります。デスクトップ向けのフル機能クライアントと単独のバックグラウンドコアを比べても、機能の範囲が揃いません。リソースの限られた端末では、不要な同時速度測定や詳細ログを減らし、普段の利用時の基準値を観察しましょう。測定自体の負荷を日常の消費と取り違えないようにしてください。

再現可能なテスト記録を作る

テスト記録には、動作モード、コア、プロトコルとトランスポートの組み合わせ全体、ネットワークの種類、テスト対象のタスクを記載してください。同じサーバーで繰り返し確認してから、設定を一つ変更します。変更にサーバー側の設定も必要な場合は、両側が一致していることを確かめてください。接続失敗時の自動再試行、バックグラウンドでのサブスクリプション更新、継続的な速度測定は、通常のアクセスデータに混ぜないようにします。測定結果はその条件下でのみ有効です。特定のプロトコルがあらゆる地域、端末、アプリで常に優れていると一般化しないでください。

多くのユーザーにとっては、理論上いくつかの処理手順を減らすことより、接続が安定し、設定を保守でき、パラメーターの出所が明確であることが重要です。必要な用途を満たしているなら、トランスポートの組み合わせを頻繁に変更する必要はありません。プロトコル関連の設定を調整するのは、回線や接続先のサービスではなく、ローカルの計算処理、ハンドシェイク、接続管理がボトルネックだと確認できてからにしましょう。機能が正しく動くことを確かめてから性能を調整すれば、再現できない差を求めて新たな問題を持ち込まずに済みます。

モバイルの電池消費：プロトコル以外の継続的な負荷

電池消費は接続経路全体から生じる

モバイル端末の電池消費は、プロトコル名だけでは判断できません。CPUでの暗号化、仮想ネットワークインターフェース、データ転送、無線通信、アプリのバックグラウンド通信がそれぞれ電力を消費します。プロキシ経由の通信が少なくても、頻繁なハートビート、再接続、バックグラウンドの速度測定によって端末が深いスリープ状態に入りにくくなることがあります。設定の省電力性を評価する際は、実際の通信量、接続の再確立頻度、画面オフ時のバックグラウンド動作も確認してください。クライアントの電池使用画面に表示される割合だけを比べないようにしましょう。

無線ネットワークの動作状態も特に重要です。モバイルデータ通信と無線LANでは、接続維持や省電力の仕組みが異なります。通信量が少なくても、短い間隔で頻繁に通信すると端末を継続的に起動させる場合があります。長時間接続では定期的にキープアライブデータを送ることがあります。これは端末、ルーター、ネットワーク上の中継機器などで接続を維持するためです。間隔を短くすると特定環境で接続を保ちやすくなる一方、通信頻度も増えます。間隔を長くすると接続が切れやすくなる場合があるため、アプリの要件に応じて調整してください。

端末全体の通信制御とアプリ単位の通信制御

Androidクライアントは、システムのVPNインターフェースを使ってローカル通信を制御すると、通常のプロキシ設定に従わないアプリも対象にできます。対象範囲を広げると、より多くのバックグラウンド処理が同じ通信経路を通ることになります。たとえば、もともとLAN内だけで通信するアプリが誤ったルーティングで外部アドレスへの再試行を始めたり、同期アプリが失敗を繰り返して新しい接続を頻繁に作成したりする場合があります。こうした動作はクライアントに関連づけられて記録されますが、原因は暗号化やプロキシプロトコルそのものとは限りません。

クライアントがアプリ単位の通信制御や除外に対応している場合は、必要な範囲に絞れます。ただし、どのアプリがプロキシを経由せずに通信するかを把握してください。ルーティングルールとDNSの処理も一致させる必要があります。アプリを直接接続にしても、名前解決が別経路に流れると、待ち時間やリクエストの重複が起きることがあります。LAN内のデバイス検出、プリンター、家庭内機器の操作を使うアプリは、それぞれ個別に動作を確認しましょう。広いルールを何度も試すより、不要なリクエストを減らすほうが効果的な場合があります。

バックグラウンド制限と持続接続のバランス

OSのバッテリー最適化機能によってバックグラウンドプロセスが制限されると、クライアントの停止後にアプリのリクエストがタイムアウトしたり、再接続を繰り返したりすることがあります。接続を維持するためにバックグラウンド制限を緩和する必要がある場合もありますが、電池消費が自動的に減るわけではありません。まず、プロセスの一時停止、OSによる終了、ネットワーク切り替えによる既存接続の無効化のどれが原因か確認してください。接続が切れるからといって、すべての省電力制限を解除するとバックグラウンド動作が広がるだけで、ハンドシェイクや名前解決の問題は解決しないことがあります。

v2rayNGは通常、AndroidでXray設定を使う場合の第一候補です。v2flyNGはV2Fly環境と組み合わせて使います。画面や実装の違いによって利用できる機能は異なりますが、電池持ちに決まった順位があるとは言えません。比較する場合は、同じ端末、ネットワーク、近い電波状況、同じアプリのタスク、同じ通信制御範囲に揃えてください。画面の明るさやほかのバックグラウンドアプリもできるだけ一致させます。これらの電池消費の差が、プロキシ経路の違いを大きく上回ることもあります。

継続的な速度測定、詳細ログ、接続失敗時の再試行、不要なアプリの通信制御を先に見直してから、プロトコルを比較してください。電池残量の一時的な数値より、説明できるバックグラウンド動作のほうが原因究明に役立ちます。

条件を揃えて異常の原因を絞り込む

まずクライアントを終了した状態で待機時の動作を確認し、次にクライアントを起動して通信を行わない状態を観察します。最後に同じ閲覧やダウンロードを実行してください。各回でネットワークの切り替え、接続の再確立、継続的なエラーの有無を記録します。電池使用量の統計は反映に時間がかかり、OSの集計方法にも左右されるため、ごく短い時間だけで結論を出すのには向きません。端末が発熱すると性能が抑制され、速度が低下することがあります。プロトコルが遅くなったように見えても、実際には放熱と負荷の影響かもしれません。

バックグラウンドログにタイムアウトが続く場合は、パラメーター、DNS、ルーティングを優先して見直します。ネットワークを切り替えた後だけ接続できない場合は、クライアントが接続を再確立し、アドレスを再解決しているか確認してください。特定のアプリだけで異常が起きる場合は、そのアプリの通信を調べます。仮想NICの通信制御範囲については、TUNモードの仕組みと有効化の手順をご覧ください。モバイル端末の権限やバックグラウンド動作の制限は、OSとクライアントの画面に従ってください。プロトコルは安定した利用を実現するために選ぶものであり、OSレベルの電池診断の代わりにはなりません。

サブスクリプションと設定：形式の互換性だけでは不十分

サブスクリプションは設定を配布する仕組みであり、接続プロトコルではない

サブスクリプションURLからサーバー情報を取得します。内容は共有リンクの一覧、エンコードされたテキスト、またはクライアント独自の構造化設定の場合があります。サブスクリプションの取得とプロキシサーバーへの接続は別の処理です。更新に失敗しても、登録済みのサーバーが使えなくなったとは限りません。登録済みサーバーに接続できても、サブスクリプションURLが有効とは限りません。トラブルシューティングでは、取得失敗、内容の解析失敗、項目の変換失敗、接続失敗を区別し、すべてをサブスクリプションの問題とまとめないようにしましょう。

共有リンクでは、アドレス、クエリ項目、エンコードされた構造など、さまざまな場所にパラメーターが格納されます。プロトコルごとのユーザーID、パスワード、暗号方式、トランスポート項目を一律に置き換えられるわけではありません。同じ共有形式に対応しているクライアント同士でも、拡張項目、既定値、名前のエンコード処理が異なる場合があります。シンプルな設定なら相互に利用しやすい一方、REALITY、フロー制御、新しいトランスポート項目を含む場合は、インポーターが重要な項目をすべて保持するか確認してください。

インポート後に設定を開き直して確認

最低限、アドレス、ポート、プロトコル、認証情報、トランスポート方式、セキュリティ層を確認してください。WebSocketではパスと関連するホスト設定、gRPCではサービス名と導入要件、REALITYではサーバー名、フィンガープリント、公開鍵、ShortId、フロー制御も確認します。別名はローカルで見分けるための情報にすぎず、名前が同じでも設定が一致するとは限りません。サブスクリプションの更新後は、選択していた設定が残っているか、同じ名前の別の設定に切り替わっていないかも確認してください。

サブスクリプションの提供元がパラメーターを変更したり、サーバーを入れ替えたりすることがあります。手動で変更したサブスクリプション設定は、次回の更新で上書きされる可能性があります。一時的なテストが必要なら、用途を記載してローカル設定として複製し、元のグループに変更内容が分からない設定を混在させないでください。テストに成功しても、パラメーターがサーバーの要件に基づくものか、特定のルーティング経路を偶然回避しただけかを確認しましょう。グループ管理は、設定の出所と更新範囲を明確にするためのもので、すべてのリンクを一つの長い一覧にまとめるためのものではありません。

クライアントが生成するコア設定を理解する

以下は、入口と出口の関係を理解するためだけの最小限の設定例です。ループバックアドレスでSOCKSポートを待ち受け、受け取ったリクエストをシステムネットワークへ直接渡します。この構成では、2種類のコアに共通する一般的なモジュールを使っていますが、実行環境が対応しており、ポートが使用中でないことが必要です。リモートプロキシは含まれないため、サブスクリプション設定の代わりには使えません。GUIクライアントで接続を管理している場合、本ページを読むためだけにコアを別途起動する必要はありません。

{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "auth": "noauth", "udp": false }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

この例では、入口の識別子でローカル接続を区別し、待ち受けアドレスで接続元の範囲を制限します。ポートはアプリが入口を見つけるために使い、出口はデータがコアからどのように出ていくかを決めます。実際のクライアントは、さらにプロキシ出口、ルーティング、DNSなども生成します。ほかの端末から接続できるようにする目的で、待ち受けアドレスをすべてのインターフェースに安易に変更しないでください。公開範囲が変わるため、認証、ファイアウォール、利用範囲を別途検討する必要があります。設定の構造を理解する目的はデータ経路を把握することであり、入口のアクセス権を広げることではありません。

安全な共有と解析エラーのトラブルシューティング

サブスクリプションURLにアクセス権限が含まれている場合があり、エクスポートした設定にもパスワード、ユーザーID、その他の接続情報が含まれることがあります。相談する際は、プロトコルの種類、トランスポート方式、コアの名称、機密情報を隠したエラーの概要だけを共有してください。サブスクリプション全体を公開したり、内容の分からないオンライン変換ツールに設定を丸ごと貼り付けたりしないでください。公開用の認証情報が含まれていても、同じ設定内の別項目が機密情報である可能性があります。共有前に項目ごとに確認しましょう。

更新に失敗した場合は、まずURLが有効か、システム時刻が正しいか、取得時に接続エラーや証明書エラーが発生していないか確認します。応答内容がサブスクリプションではなく案内ページになっていないかも見てください。更新に成功しても設定項目が欠けている場合は、形式とインポーターの互換性を調べます。設定モジュールの詳しい説明はJSON設定の構造解説をご覧ください。最初のインポートは設定ガイドの手順に沿って進め、基本の接続を確認する前に複雑なカスタム設定を追加しないでください。

用途に合わせた選択とトラブルシューティング：設定一式から安定接続へ

プラットフォームとサーバーの対応状況から選択肢を絞る

デスクトップではv2rayNを優先し、Windows、macOS、Linuxに合ったインストーラーとアーキテクチャを選びます。AndroidでXray設定を使う場合はv2rayNG、V2Fly環境と組み合わせる場合はv2flyNGを検討します。次に、サーバーが提供するプロトコル、セキュリティ層、トランスポート方式の組み合わせを確認してください。クライアント選びは、理論上もっとも優れたプロトコルを一覧から選ぶことではありません。プラットフォームで利用でき、コアが対応し、サブスクリプションに必要な項目が揃い、サーバー設定と一致する選択肢から決めます。

安定して利用できているVMessやTrojanのサーバーがあるなら、自分でVLESSに変更するより、既存の正しい設定を維持するのが一般的に適切です。サーバーがVLESS、REALITY、Visionの組み合わせを明示している場合は、その設定一式に対応するコアとクライアントを選んでください。SSの設定しかない場合は、似た名称のプロトコルに変えるのではなく、指定された暗号方式と鍵の要件を確認します。プロトコルを移行するにはサーバー側に新しい接続口と完全な設定が必要です。クライアント画面の選択肢を変えるだけでは移行できません。

用途に合わせて通信制御方式を選ぶ

ブラウザーやシステムプロキシに従うアプリは、まずシステムプロキシで基本的なアクセスを確認します。ほかのアプリも対象にする必要がある場合は、TUNを検討してください。TUNが変えるのはローカルで通信を取り込む範囲であり、リモート側の認証やセキュリティ層のエラーを自動的に直すものではありません。有効にする前に、通常のプロキシ入口でサーバーに接続できることを確認してから、権限、仮想NIC、ルーティング、DNSに進みます。こうすれば端末全体のアクセスに問題が出ても、リモートの設定をすべて推測し直すのではなく、ローカルの通信制御層に原因を絞れます。

開発やLAN内での連携では、ローカルサービス、内部ドメイン、プライベートアドレスの振り分け方法も確認する必要があります。ルールの順序によって適用される出口が決まり、DNSのポリシーはドメイン名やアドレスを使った判定に影響します。広いルールを一つ追加しただけでテストを終えず、インターネットへのアクセス、内部サービス、名前解決をそれぞれ確認してください。設定項目の関係はDNS分割ルーティングの解説で確認し、変更ごとにテスト結果を記録しましょう。

何度も再インストールする前に障害の段階を特定する

コアが起動しない場合は、まず設定構文、未知の項目、未対応機能、ローカルポートの競合を確認してください。この段階では、リモートサーバーが稼働中かどうかは優先事項ではありません。下位接続がタイムアウトする場合は、アドレス、ポート、現在のネットワークを確認します。接続拒否の場合は、接続先の待ち受け状態とアクセス条件を調べてください。ハンドシェイクに失敗した場合は、ユーザー情報、セキュリティ層、サーバー名、関連パラメーターを確認します。エラーが起きた段階から原因を絞れますが、ログ一行だけで原因を決めつけず、前後の状況も確認してください。

一部のウェブサイトやアプリだけで問題が起きる場合は、まずその通信がクライアントに届いているか、どのルールによってどの出口に送られているかを確認します。ドメインの名前解決、接続先サービスの制限、アプリ独自のプロキシ動作が局所的な問題を起こすこともあります。この場合、プロトコルを変更しても解決しない可能性があり、元の比較条件を失うおそれもあります。カスタムルールを一時的に無効にして確認する場合は、元の設定を保存してください。基本の通信経路が正常であることを確かめたら、ルールを一つずつ戻してアクセスに影響する項目を特定します。

推奨する確認順：設定を読み込める → リモート接続を確立できる → ハンドシェイクと認証が完了する → 接続先にアクセスできる → ルーティングが意図どおりに動く → 速度と電池消費を調整する。

保守しやすい最終設定を残す

動作確認が終わったら、クライアント、実行中のコア、サーバーの提供元、プロトコルの組み合わせ、必要なローカルルールを記録します。公開してはいけない認証情報は記録しないでください。正常に動作すると確認できた設定を基準として残し、以降の更新や調整では変更する要素を一つに絞ります。問題が起きたときは、この基準設定と比較できます。クライアントの再インストール、コアの変更、プロトコルの変更、ルーティングのリセットを一度に行わないでください。変更を元に戻せて、内容を説明できる設定は、項目の多さだけを重視した設定より長く保守できます。

初めて設定する場合は、クイック設定ガイドの手順に沿ってインポートと接続確認を行うか、V2Ray初心者向けよくある質問10選で一般的な接続問題をご確認ください。別のプラットフォーム用インストーラーが必要な場合は、ダウンロードセンターをご利用ください。サブスクリプション設定からクライアントのインストーラーを探す必要はありません。このガイドの選び方の基本は、プラットフォーム、コア、プロトコル、トランスポート方式、セキュリティ層、パラメーターの出所を一致させ、実際の用途で安定性を確認することです。名称だけで接続品質を判断しないでください。