V2Rayプロトコル解説

設定の階層：プロトコル、トランスポート、セキュリティ層

プロトコル名だけでは接続方式は決まらない

クライアントでいう「プロトコル」は、通常はプロキシプロトコルを指し、認証や宛先、データ転送の方式を定めます。VMess、VLESS、Trojan、Shadowsocksはこの層に属します。これらが定めるのは、クライアントとサーバーが同じプロキシリクエストをどう解釈するかであり、ネットワーク上のあらゆる挙動ではありません。どちらもVLESSと表示されていても、トランスポートやセキュリティ層、サーバー側の接続口が異なれば、接続経路はまったく違う場合があります。名前だけで互換性や性能を判断することはできません。

トランスポート層は、TCPを直接使うか、WebSocketやgRPCなどを介するかといった、プロキシデータの運び方を定めます。トランスポートの設定はサーバー側の接続口と一致させる必要があります。WebSocketをTCPに変更しても、クライアントが別の接続口を自動で探すわけではありません。パス、サービス名、リクエストホストなどの項目にもそれぞれ役割があり、任意のメモのように見えても、サーバー側の振り分けに使われることがあります。サブスクリプションに設定済みの項目は、代替設定がそろっていると確認できるまで変更しないでください。

セキュリティ層は、接続の暗号化と接続相手の認証を担います。一般的なのはTLSで、REALITYは対応する特定のコアで利用できるセキュリティ方式です。REALITYはVLESSと並ぶ独立したプロキシプロトコルではなく、クライアントでは両者を組み合わせる構成がよく使われます。編集画面で複数の選択肢が同じカードに並んでいても、技術的に同じ階層とは限りません。設定を読むときは、プロキシプロトコル、トランスポート、セキュリティ層を分けて確認してから認証情報を見れば、各項目の役割を把握しやすくなります。

クライアント、コア、通信の取り込み方式はそれぞれ役割が異なる

GUIクライアントは設定の編集・保存・インポートを行い、コアの起動やシステム連携機能も提供します。プロトコルのハンドシェイク、ルーティング判定、データ転送を実際に処理するのはコアです。画面に項目が表示されるのは、クライアントがその設定を認識していることを示すだけで、起動中のコアが対応しているとは限りません。インポートできても起動に失敗する場合は、保存された設定、選択中のコア、ログに記録された実際の処理をあわせて確認しましょう。インポート成功は接続成功を意味しません。

システムプロキシ、TUN、AndroidのVPNモードは通信を取り込む方式であり、リモート側のプロトコルではありません。システムプロキシの影響を受けるのは、通常、システムのプロキシ設定に従うアプリだけです。TUNはより多くの通信を取り込めますが、権限やルーティング、DNSの設定も関係します。AndroidでVPN接続中と表示されるのは、ローカルの仮想ネットワークインターフェースが許可されたという意味で、リモート側のプロトコルを示すものではありません。そのため、取り込み方式を変更すればアプリがプロキシを通らない問題を解決できる場合はありますが、ユーザーIDやサーバーポートの誤りは直りません。

階層に沿って問題を切り分ける

接続は少なくとも、ローカルでの通信取り込み、名前解決、トランスポート接続の確立、セキュリティハンドシェイク、プロキシ認証を経て行われます。ログの「接続タイムアウト」と「認証失敗」は異なる段階を示します。後者は通常、リクエストに応答できる接続先まで到達したことを意味します。まずどの階層で止まっているかを特定し、その層に関係する項目を変更してください。DNS、プロトコル、ルーティングを一度に変更すると、接続が復旧しても原因を特定できず、次回のサブスクリプション更新後に同じ問題が再発しかねません。

プロトコル選びも同じ順序で進めます。まずサーバーが提供する構成一式を確認し、次にローカルのコアが対応しているかを調べ、最後に端末の負荷やアプリの要件を比較します。クライアントはプロトコル変換ツールではないため、メニューを変えるだけで既存アカウントを別のサービスに切り替えることはできません。動作するインポート設定を保存し、別のテスト項目を作って比較すれば、手動変更でサブスクリプションの設定を上書きせずに済みます。ルーティングルールについては、ルーティングルールの実践ガイドもご覧ください。

VMessとVLESS：認証と暗号化の違い

VMessの背景と既存設定

VMessはProject Vの初期から使われてきた主要なプロキシプロトコルです。ユーザー認証、リクエストの記述、データ保護をひとつのプロトコル設計にまとめています。広く使われているため、既存のサービスやサブスクリプションには今もVMessの設定が残っています。利用する妥当な理由は、利用中のサービスが一式に対応し、設定の入手元が信頼でき、現在のクライアントで正しく動作することです。名称に特定のプロジェクト名が含まれるからといって、あらゆる環境に適しているわけではありません。安定稼働している設定を、プロトコル名を変えるだけのために移行する必要はありません。

VMessには、ハンドシェイクやセキュリティ設定が異なる旧形式の設定があります。現在利用する場合はAEAD関連の対応状況を確認し、古いガイドのパラメーターを新しい設定にそのままコピーしないでください。古い共有設定に追加のID項目や異なる暗号方式名が含まれることがあります。クライアントが互換性のために読み込めても、コアが受け付けるかは別途確認が必要です。古いサブスクリプションを取り込んだ後に起動できない場合は、現在の形式を入手し、ログにある項目の説明を確認しましょう。適当な値を試し続けても、サーバー側の要件が自動で補われることはありません。

システム時刻もVMessのトラブルシューティングで重要です。認証処理には時刻の条件があり、端末の時刻が大きくずれていると、正しいユーザーIDとポートでも接続に失敗することがあります。OSの日付と時刻を正しく同期し、実際の時刻のずれとタイムゾーン表示の違いを区別してください。タイムゾーン表示が異なるだけで、必ず認証エラーになるわけではありません。システム時刻を確認せずにタイムゾーンを何度変更しても、通常は解決しません。セキュリティ層にTLSを使う場合は、証明書の有効期限も時刻に基づいて判定されます。

VLESSで簡素化された点

VLESSは、認証とリクエストのカプセル化を比較的簡潔にする設計で、VMessと同じデータ暗号化機能をプロトコル自体では提供しません。接続を保護する外側の仕組みとして、TLSやREALITYと組み合わせて使われます。クライアントに「暗号化：none」と表示されても、それだけで構成全体が暗号化されていないとは限りません。セキュリティ層が正しく有効になっているかを確認してください。反対に、適切なセキュリティ層がない場合、プロトコル名が新しいからといって、認証情報や通信データが十分に保護されるわけではありません。

VLESSのユーザーIDにはUUID形式がよく使われますが、見た目が同じだからといってVMessのアカウントと交換できるわけではありません。サーバーが待ち受けるプロトコル、ユーザー設定、トランスポートの接続口をすべて一致させる必要があります。構成によっては、Visionなど特定の処理フローを示すflow項目も含まれます。これは汎用の高速化スイッチではなく、どのVLESSノードにも自由に追加できるものではありません。サーバー、トランスポート、セキュリティ層がすべて要件を満たす場合にのみ、その処理フローが機能します。

2つのプロトコルを正しく比較する方法

設計上、VLESSはプロトコル層で一部の暗号化処理を重ねて行わないため、構成によっては処理負荷を抑えられる可能性があります。しかし、実際の接続にはセキュリティハンドシェイク、ネットワークの往復時間、サーバーの待ち行列、アプリのリクエストなども関わります。こうした要因は、プロトコルヘッダーの差より大きく影響することがあります。地域や事業者の異なる2つの接続先を比べても、わかるのは経路全体の差であり、VMessとVLESSの純粋なプロトコル差ではありません。そのため、環境を問わない一律の速度ランキングは示せません。

クライアントで選ぶ際は、まずサーバー側が明示的に提供する設定一式を使ってください。両方のプロトコルを利用できる場合は、接続先、トランスポート経路、テストするアプリをできるだけそろえ、初回起動、連続通信、短時間のアイドル後の復帰を確認します。クライアントの一覧にある一度きりの接続テストだけで判断しないでください。実際のWebアクセスが試されていない場合や、アプリ固有のDNS処理や接続再利用が再現されない場合があります。日常の作業が改善したかを判断できる方法でテストし、単独の結果だけを比べないことが大切です。

既存設定を多く管理するデスクトップユーザーにとっては、移行そのものより互換性と設定の追跡しやすさが重要なことがよくあります。新しく接続を作る場合は、現在のコアに対応したVLESSのセキュリティ構成がサーバーから提供されていれば、候補として検討し、モバイル回線への切り替え、UDPを使うアプリ、ルーティングの要件を確認します。VMessしか使えない場合は、現在サポートされている方式を使い、時刻を同期してください。どちらを選ぶ場合も実際の導入条件に従う必要があり、クライアント側だけでサーバーの機能を変えることはできません。

TrojanとShadowsocks：導入方式と設定項目

TrojanはTLSを基本とする

Trojanは、クライアントとサーバー間の接続をTLSで保護し、その上でプロキシ認証とデータ転送を行う設計です。UUIDを使うプロトコルとは異なり、クライアントではパスワードを使うのが一般的です。ただし、パスワードは認証情報の一部にすぎません。サーバーアドレス、ポート、証明書の検証名、トランスポート設定も正しく一致させる必要があります。対応するTLSサーバー設定があり、証明書管理の仕組みを活用したい場合に適していますが、証明書の検証を省略したり、パスワードだけで信頼できる接続が成立すると考えたりしないでください。

ドメイン名で接続する場合、クライアントは通常、設定に基づいてサーバー名を送信し、証明書を検証します。接続先アドレスと証明書名は同じ場合も、サーバー構成により異なる場合もあり、一律に置き換えられるものではありません。サーバー名専用の項目が指定されている場合は、元の情報に従って入力してください。説明がなければ、別のノードのドメイン名を流用しないでください。接続できない場合は、まずシステム時刻、ドメインの入力ミス、証明書の有効性を確認しましょう。詳しくはTLSハンドシェイクと証明書エラーの解説をご覧ください。

Trojanの異なるトランスポート構成や拡張実装を、同じ形式として互換利用できるとは限りません。クライアントがTrojanとして認識しても、その派生機能すべてを実行できるとは限りません。共有リンクをインポートした後は、トランスポート、セキュリティ層、追加項目がすべて保持されているか確認してください。サーバーが要求する機能に現在のコアが対応していない場合、パスワードを変更しても解決しません。要件に合う設定一式に切り替えるか、その構成を明確にサポートするクライアントとコアを使用してください。

Shadowsocksのシンプルさと方式の適合性

ShadowsocksはSSとも略され、事前共有鍵と指定された暗号方式でプロキシ通信を行います。設定は比較的簡潔で、主な項目はサーバー、ポート、パスワード、方式名です。初期の設計と現代のAEAD方式では、安全性や互換性の要件が異なります。「SS」という名前だけで設定が同等だと判断しないでください。新しく設定する場合は、サーバーとコアの両方が対応する現代的な方式を使い、古いガイドとの互換性のために、すでに推奨されない旧方式へ戻さないようにしましょう。

方式名は正確に一致させ、パスワードの形式もその方式の要件に合わせる必要があります。特に一部の現代的な方式では、指定された長さの鍵素材が必要で、任意の短いパスワードでは代用できません。共有リンクでは、方式名とパスワードが一体でエンコードされる場合と、別項目になっている場合があります。リンクの見た目だけで判断して、手作業で一部を切り出してパスワードにしないでください。まずクライアントに全体を解析させ、提供元の説明と項目を照合します。解析できない場合は、理解できない文字を順に削除するのではなく、リンク形式を確認してください。

Shadowsocks 2022などの方式には、より具体的な互換性要件があります。「コアがShadowsocksに対応している」ことから「すべての方式に対応している」とは判断できません。また、追加のトランスポート拡張や外部コンポーネントが必要な構成もあり、本サイトで扱う3つのクライアントが全プラットフォームで同じ機能を備えているとは限りません。現在のクライアントでそのまま実行できる設定を優先してください。別のコンポーネントが必要な場合は、クライアントのドキュメントとサーバー側の要件を確認し、別のソフトウェア環境の設定ファイルをそのままインポートできるサブスクリプションとして扱わないでください。

UDP対応と運用負荷も選択基準に

TrojanとShadowsocksでUDPが使えるかどうかは、プロトコルの実装、クライアントの通信取り込み方式、サーバー設定、ネットワーク経路をあわせて確認する必要があります。通常のWebページが開けても、一部のTCPリクエストが使えたことを示すだけで、通話、ゲーム、その他のデータグラム通信が正常とは限りません。システムプロキシがこうしたアプリの通信を取り込まない場合もあります。テストでは、まずアプリの通信がクライアントに入っているか確認し、その後ログに該当する転送があるかを調べてください。そうしないと、通信の取り込み範囲の問題を、プロトコルが本質的にその用途に対応できないと誤解しやすくなります。

運用面では、TrojanはTLS証明書と名称の一致、Shadowsocksは方式と鍵素材の一致を重点的に確認します。両者ではトラブルシューティングの要点が異なります。サーバーがどちらか一方を安定して提供しており、対象端末すべてで正常に動作するなら、設定を簡素化して接続元の情報を保つ方が、頻繁に方式を切り替えるより有益です。プロトコル選びの目的は認証、互換性、用途の要件を満たすことであり、一覧にある種類を増やしたり、名前の新旧で品質を判断したりすることではありません。

TLSとREALITY：セキュリティ層の設定を確認する

TLSでは接続先の検証が重要

TLSは通信を暗号化するだけでなく、証明書と名前を検証して接続先を確認する仕組みでもあります。サーバー証明書が有効期間内にあり、証明書チェーンが端末から信頼され、検証名が証明書の対象範囲に一致している必要があります。暗号化接続に失敗する原因は、これらのいずれにもありえます。証明書関連の問題をすべて「プロトコルの非互換」と決めつけると、端末時刻の誤り、接続先の入力ミス、サーバー証明書チェーンの更新漏れなど、より直接的な原因を見落とします。

SNIはハンドシェイク時に送信されるサーバー名で、サーバーが証明書や接続先を選ぶ際に使われます。一方、クライアントが実際に使う検証名は、実装と設定によって決まります。両者は同じことがよくありますが、用途は混同しないでください。手動で、アクセスできる一般のWebサイトのドメイン名に変更しても、現在のサービスでその証明書が使えるようにはなりません。IPアドレスで接続し、設定に別のサーバー名が指定されている場合は、それぞれの役割を保ち、IPアドレスをすべての名前項目に機械的にコピーしないでください。

ALPNはアプリケーション層のプロトコルをネゴシエートするためのもので、フィンガープリント設定はクライアントのハンドシェイク特性に関わります。どちらもパスワードではなく、性能を調整するために自由に切り替える設定でもありません。サーバーや中継側に具体的な要件がある場合、設定の組み合わせを間違えると、ハンドシェイクが成功しても接続を利用できないことがあります。元の共有設定を維持し、導入環境での対応状況が明確な場合だけ、これらの詳細設定を変更してください。名称が似ていて挙動が異なる項目は、画面の日本語だけで判断せず、使用中のクライアントでの実際の対応を確認します。

REALITYでは設定一式の整合性が重要

REALITYはXray環境のVLESS構成でよく使われます。セキュリティハンドシェイクとサーバー認証の仕組みを変えるもので、独立したアカウント種別ではありません。クライアントには対応する公開検証情報と接続パラメーターを設定します。サーバー側の秘密情報をクライアントのサブスクリプションに含めてはいけません。この仕組みを理解すれば、共有設定を適切に確認できます。クライアントはサーバーを検証する必要がありますが、サーバーの秘密情報一式を持つ必要はなく、サーバー設定ファイル全体をコピーするよう求めるものでもありません。

主な項目には、サーバー名、公開検証情報、ショートID、クライアントフィンガープリントがあります。構成によっては対応するflowも必要です。項目名はクライアントやコアの更新に伴って変わることがあるため、古い画面のスクリーンショットだけを頼りに同名の入力欄を探さず、現在の画面の説明と共有設定を照合してください。公開検証情報とショートIDは同じサービス設定から取得する必要があり、別々のノードから使える値を半分ずつ組み合わせてはいけません。文字列の項目でも、形式や用途はまったく異なる場合があります。

REALITYを使っても、時刻、ネットワークへの到達性、トランスポートの一致を無視できるわけではありません。クライアントが正しいアドレスとポートに接続でき、セキュリティハンドシェイクが実装の要件を満たす必要があります。更新後に動かなくなった場合は、まず該当構成に対応するコアが実際に起動しているか確認し、次にサブスクリプションの解析で項目が欠落していないか、最後にサーバー側も変更されたかを確認します。セキュリティ層を通常のTLSに変更しても、同じ接続口で別のハンドシェイクを受け付けるとは限らないため、通常は解決しません。

暗号化の範囲とアプリ自体の安全性

プロキシ接続のセキュリティ層が保護するのは、クライアントからプロキシサーバーまでの区間です。アプリ自体のHTTPSなど、エンドツーエンドの保護に代わるものではありません。データがサーバーに到達した後、宛先にどうアクセスするかは、宛先のプロトコルとサーバーの挙動によって決まります。そのため、プロキシ接続にTLSが表示されていても、Webサイトの証明書警告を無視してはいけません。また、コアの接続成功を、すべてのアプリの通信内容が同じ安全性で保護されたという意味に捉えないでください。選択時には各層の保護範囲と信頼する接続先を把握しましょう。

通常のTLSとREALITYのどちらを使うかは、まずサーバーが提供する設定一式と端末の対応状況を確認し、その後に運用要件を検討します。証明書管理が整っている環境なら、対応するTLS接続を引き続き利用できます。REALITYを採用しているサービスでは、必要なパラメーター一式を維持してください。単一のスイッチで一方から他方へ「アップグレード」できるものではありません。複数の端末で同じサブスクリプションを使う場合は、各端末のパーサーとコアが関連項目をすべて保持できるか確認し、難しければ互換性に応じて接続先を分けましょう。

XrayとV2Fly：コアの系統と設定の互換性

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

Project VはV2Rayエコシステムの背景を理解するうえで重要です。V2FlyはV2Ray関連のコア開発を引き継ぎ、Xrayは関連コードを基にしながら独自の開発路線を歩んでいます。インバウンド、アウトバウンド、ルーティング、DNSなど共通する概念は多くありますが、機能拡張、項目の意味、既定の挙動が常に一致するとは限りません。同じプログラムの別名ではなく、共通の背景を持つ2つの実装系統と捉える方が正確で、設定移行のリスクも判断しやすくなります。

プロトコルの対応状況は、プロトコル、セキュリティ層、トランスポート、拡張機能の組み合わせごとに確認する必要があります。Xray環境のREALITYやVisionなどの機能が、V2Flyに切り替えても使えるとは限りません。V2Flyで継続的に追加される機能も、項目名が似ているだけでXrayが同じ挙動をすると判断できません。両方が同じ上位プロトコルを認識することは、互換性確認の第一段階にすぎません。実際の対応範囲は、使用中のコアの説明、クライアントへの組み込み状況、起動ログで確認してください。

コアによって、ドメイン名の扱い、DNS処理、接続再利用、ルーティングルールの細部が異なることもあります。移行後にリモート接続が確立できても、ローカルの通信が従来どおり振り分けられているか確認してください。一部の項目はエラーにならず無視され、名前解決の場所やアウトバウンドの選択が変わる場合があります。複雑な設定を長期間運用している場合は、「起動できる」「宛先にアクセスできる」「ルールが意図どおり動作する」を別々の検証段階として、ひとつずつ確認してから普段使いの設定を置き換えましょう。

3つのクライアントの選び分け

v2rayNは本サイトがデスクトップ向けに推奨するクライアントで、Windows、macOS、Linuxに対応しています。GUIで設定を管理できますが、プラットフォーム、配布形態、同梱バージョンによって利用できるシステム機能は異なる場合があります。コアを選べる場合は、設定が必要とする機能を確認してから適切なものを選んでください。メニューに別のコア名を表示させるためだけに切り替えてはいけません。画面で項目を編集できることと、インストール先のコアがその機能に対応していることは、別々に確認する必要があります。

Androidではv2rayNGを主に選び、Xrayを中心としたコア機能を利用します。v2flyNGはV2Fly系の代替候補です。名前が似ていても、高度なパラメーターやネイティブ設定をそのまま交換できるわけではありません。サーバーが特定のXray拡張を使う場合は、v2rayNGの現行バージョンでの対応状況を確認してください。設定がV2Flyの挙動に明確に依存している場合は、v2flyNGを検討します。VPNによる通信取り込みを2つのクライアントで同時に有効にして比較すると、実際の通信経路が変わるため避けてください。

切り替え前後の確認手順

JSONの構文を共有していても、設定の意味まで完全に共通とは限りません。ネイティブ設定を別のコアに渡す前に、プロトコル名、トランスポート項目、セキュリティ設定、ルーティング参照、リソースファイルがすべて認識されるか確認してください。次の例は、該当するルール一覧に追加できる簡単なルールオブジェクトです。プライベートアドレス範囲の通信をdirectという名前のアウトバウンドに送ります。これは完全な設定ではありません。使用する前に該当アウトバウンドを定義し、利用可能なGeoIPリソースを用意してください。

{
  "type": "field",
  "ip": ["geoip:private"],
  "outboundTag": "direct"
}

このように短いオブジェクトでも、前後の設定に依存します。アウトバウンドのタグが存在し、ルールファイルを読み取れ、先行するルールが同じ通信を先に振り分けていないことが必要です。複雑な設定を移行する際は、まず最小限の動作するアウトバウンドを複製に残し、DNS、ルール、接続再利用の設定を少しずつ追加してください。起動に失敗したら、ログで非対応項目、参照先の不足、ローカルポートの競合を確認しましょう。具体的な手順はv2rayNのコア起動エラーとログの確認方法を参照し、すべてのパラメーターを一度に書き換えないでください。

接続性能、リソース使用量、モバイル端末の電池消費

初回接続と連続通信は分けて比較する

ユーザーが感じる「速さ」は、ページの初回表示か、大容量ファイルの連続転送かで異なり、影響する要因も違います。初回アクセスではDNS、下位接続の確立、セキュリティハンドシェイク、プロキシ認証、宛先からの応答が関わります。連続通信では、回線容量、混雑、パケット損失、サーバー負荷、端末の処理能力がより大きく影響します。プロトコルのカプセル化にも負荷はありますが、こうした条件を切り離して結論を出すことはできません。初回のハンドシェイクがスムーズな接続先でも、負荷が続くと大きく変動することがあります。

トランスポート方式も性能に影響します。中間のカプセル化層を追加すると処理が増える場合がありますが、既存のサーバー接続口に合わせるために必要なこともあります。接続再利用で接続確立の一部を省けますが、複数の通信が同じ下位接続を共有すると、互いに影響することもあります。短時間のパケット損失、待ち行列、復旧に敏感な用途もあるため、平均転送量だけで再利用を有効にするか決めないでください。サーバーが要求または明示的にサポートしていない限り、Muxを既定で有効にすべき最適化と考える必要はありません。

テストでは条件をそろえましょう。できるだけ端末、接続ネットワーク、対象コンテンツ、時間帯を近づけ、コールドスタート、連続アクセス、アイドル後の復帰、ネットワーク切り替えをそれぞれ確認します。クライアントの接続テストは参考情報にすぎず、アプリでの実使用を代替するものではありません。特定の接続先を使うテストや、実際と異なるルーティング経路を使うテストもあります。候補となる接続先の設置場所やリソースが異なる場合、結果は「この2つの接続先の性能」と記録し、プロトコル全体に当てはまるランキングにしないでください。

CPUとメモリの負荷は暗号化だけでは決まらない

暗号化と復号にはCPUリソースが必要です。端末が対応する命令最適化、コアの実装、パケットサイズも実際の負荷に影響します。新しいプロトコル名やアルゴリズムが、すべての端末でより省リソースとは限りません。カプセル化が簡潔でも、追加のトランスポート層で利点が相殺される場合があります。低電力端末では、実際の作業中にCPU使用率が高い状態が続かないか、発熱が目立たないか、アプリが快適に動くかを確認し、異なる構成の端末で得た経験をそのまま当てはめないようにしましょう。

メモリ使用量は、同時接続数、バッファー、DNSキャッシュ、ルールの規模、ログ量にも左右されます。詳細なデバッグログを長時間記録すると、ストレージへの書き込みと処理負荷が増えるため、普段は適切なログレベルに戻してください。広範囲の速度テストや自動検出がバックグラウンドで接続を繰り返し、プロトコルの評価を妨げることもあります。リソース使用量を比較する前に不要なテストを止め、ルールと通信の取り込み方式をなるべくそろえましょう。条件が違うと、観測した差の理由を説明しにくくなります。

モバイル端末の電池消費は再接続や復帰を確認

Androidの電池消費は、無線ネットワークの状態に大きく影響されます。短いリクエストが頻発する、キープアライブの間隔が短すぎる、ネットワーク品質の低下で再送が増える、接続失敗後に何度も再試行するといった状況では、無線モジュールが長く動作状態になります。プロトコル自体の処理負荷が小さくても、こうした挙動で電池消費が増えることがあります。待機中の消費が異常な場合は、まずログで再接続が続いていないか確認し、次にバックグラウンドアプリからリクエストが繰り返されていないかを調べてから、プロトコル構成の変更を検討してください。

VPNモードでは、より多くの通信がローカルの処理を通ります。そのため、電池使用量の表示でクライアントの割合が増えても、増加分のすべてがクライアント自体で発生したとは限りません。転送処理の一部がシステム上でクライアントに計上されることがあります。アプリごとのプロキシ設定で処理範囲を絞れますが、プロキシを通す必要があるアプリを選び、対象に含めるリストと除外するリストの違いを理解してください。システムの電池最適化がバックグラウンド接続を繰り返し停止すると、復帰や再接続が発生し、使用にも影響するうえ、電池消費の評価も不正確になります。

実際の選択では、ピーク性能より安定した復帰を優先する方法もあります。Wi-Fiとモバイル回線を頻繁に切り替える場合は、切り替え後に正常に再接続できるか、通話、メッセージ、バックグラウンドタスクに影響しないかを確認してください。ネットワーク切り替えで既存の接続が切れること自体は、必ずしもプロトコルの欠陥ではありません。大切なのは、クライアントとアプリが速やかに復帰できることです。日常のタスクを安定して実行できる構成を優先し、トランスポート、接続再利用、セキュリティ設定を変える価値があるか、再現可能なテストで判断しましょう。

サブスクリプションと共有形式：インポートできても動作するとは限らない

共有リンク、サブスクリプション、ネイティブJSONの違い

共有リンクは通常、プロトコル、アドレス、認証情報、いくつかのトランスポート項目など、ひとつの接続を記述します。サブスクリプションはクライアントが設定一覧を定期取得するための入口で、応答内容は複数の共有リンクを並べたテキスト、Base64エンコードされたデータ、特定形式の構造化データなどです。ネイティブJSONは通常、コアの実行設定を記述し、ローカルのインバウンド、複数のアウトバウンド、DNS、ルーティングを含むことがあります。3つは目的が異なります。テキストとしてコピーできるからといって、同じインポート画面で相互に使えるとは限りません。

Base64はデータのエンコード方式であり、情報を秘匿する機能も、内部で使うプロトコルを決める機能もありません。エンコードされたサブスクリプションに複数の共有リンクが含まれる場合も、一つの共有リンクの一部だけがエンコードされる場合もあります。形式を判断するときは、末尾の記号だけでなく、デコード後の構造とクライアント側の要件を確認してください。サブスクリプションURLや共有情報には、サービス利用に使える認証情報が含まれることがよくあります。形式を調べるために、信頼できないオンラインツールへ送信しないでください。

ネイティブJSONとGUIクライアントが生成する設定では、管理範囲も異なります。ネイティブ設定のインポートは、一覧にサーバーをひとつ追加するだけでなく、コアに完全なルール一式を実行させることを意味する場合があります。ローカルの待ち受け、ログ出力、ルーティングが変わる可能性があります。インポート前に、クライアントが完全な設定として使うのか、一部の項目を抽出するのかを確認してください。用途を理解しないまま、外部から入手した完全な設定で、正常に動作しているローカル管理設定を上書きしないでください。

パーサーとコアの2段階で互換性を確認

サブスクリプションのインポートでは、まずクライアントのパーサーが共有形式を読み取り、パラメーターを内部の設定項目に変換します。次にクライアントが、コアで実行できる設定を生成します。つまり、インポートできるかどうかと実行できるかどうかは別々の確認段階です。パーサーがリンクを受け付けても、未知の新しい項目を取りこぼすことがあります。コアが機能に対応していても、現在の画面では必要な設定を完全に生成できない場合もあります。一覧に項目が表示されたことは途中経過にすぎません。編集画面での確認と実際の起動テストが必要です。

サーバー名、トランスポートのサービス名、フィンガープリント、セキュリティ層の追加項目などは、名称やエンコード方法が異なる場合があります。別のクライアントを経由してエクスポート・インポートすると、こうした項目が失われたり意味が変わったりしやすくなります。照合時は用途に基づいて比較し、両方でまったく同じラベルで表示される必要はありません。ただし、値が既定値や空欄に変わっていないことを確認してください。元のクライアントでは動作し、書き出し後に使えなくなった場合は、アカウントを再発行したりサーバー側を変更したりする前に、これらの詳細項目を比べましょう。

サブスクリプション変換とは、元の形式を解析してから、変換先の形式でデータを再構成することです。変換先に対応する項目がなければ、元の意味を完全に表現できず、インポートできても重要な情報が失われている場合があります。特定のセキュリティ層や拡張処理を使う接続では、提供元が直接用意した対応形式を優先してください。形式の違いについてはBase64形式のサブスクリプション、ネイティブJSON、共有リンクの比較をご覧ください。形式変換でコアの機能が増えるわけではありません。

サブスクリプション更新と手動編集を両立する

サブスクリプション管理を使うと、接続元から設定をまとめて更新できますが、一覧が再構築されることもあります。重複項目、メモ、手動編集をクライアントがどう扱うかは一様ではなく、ローカルの変更が永久に保持されるとは限りません。プロトコルを試す前に、元の項目はサブスクリプショングループに残し、テスト用の複製は独立した手動グループに置き、変更内容をメモに記録しましょう。これならサブスクリプションの更新を受け取りながら、テスト設定が最新の接続情報と一致しているかも把握できます。

更新エラーは、「応答を取得できない」場合と「内容を取得できたが解析できない」場合に分けて考えます。前者はサブスクリプションURLの有効性、接続方式、名前解決などが原因になりえます。後者は、Webページ、アカウントに関する案内、非対応形式が返された可能性が高くなります。エラー応答をサブスクリプションとして変換し続けないでください。また、認証情報を含むURL全体を公開しないでください。複数の接続元を管理する方法は複数サブスクリプションのグループ分けとフィルター設定をご覧ください。基本的なトラブルはよくある質問のインストール・設定・トラブル対処の項目もご確認ください。

用途別の選び方：利用可能な構成から安定した設定へ

まず互換性を確認し、その後に使い勝手を比較

選択を始める前に、好みのプロトコル名を決めるのではなく、サーバーが実際に提供する設定一式を洗い出してください。各設定には、少なくともプロキシプロトコル、トランスポート、セキュリティ層、必要な拡張機能が含まれます。そのうえで、ローカルのクライアントとコアで一式を設定できるか確認します。項目が不足している、実装が対応していない、依存条件が不明な構成を除外し、残った候補をテストしてください。この順序なら、サーバー側の対応がないローカル設定に時間を費やさずに済み、端末間で設定を共有する際の誤解も減らせます。

デスクトップで日常的にWeb閲覧や仕事をする場合は、まずv2rayNを使い、サブスクリプションで指定されたセキュリティ設定を維持してください。アプリがシステムプロキシに従うなら、まずシステムプロキシで接続を確認します。アプリがプロキシ設定を参照しない場合に限ってTUNを検討してください。通信を広く取り込むために、プロトコル、DNS、ルーティングを同時に変更しないでください。接続できたら、普段使うWebサイト、ファイル転送、仕事用アプリを試し、スリープから復帰した後も正常か確認しましょう。一度きりの接続テストより、日常の作業が安定して完了することの方が参考になります。

Androidの日常利用では、v2rayNGを主な選択肢とします。VPNの許可、アプリごとの対象範囲、バックグラウンド動作の設定、ネットワーク切り替え後の復帰を確認してください。端末上のプロトコル名を比べるだけでは不十分です。既存設定がV2Flyの挙動に明確に依存している場合は、v2flyNGで個別に検証できますが、2つのクライアントを切り替えて通信を取り込むと比較結果が混乱するため避けてください。テスト中は、実際に通信を取り込むクライアントをひとつだけにし、使用した設定の入手元とコアの系統を記録します。

用途に応じてテスト項目を決める

通話、ゲームなどのリアルタイム通信では、UDP転送、通信経路、接続の安定性を重点的に確認します。通常のWebサイトは使えるのにリアルタイム通信だけ失敗する場合は、まずアプリの通信がクライアントに取り込まれているか確認し、次にサーバーが該当する転送を許可しているか、中間ネットワークに必要な条件がそろっているかを調べてください。TCPを使う接続先が利用できるからといって、あらゆるデータグラム通信も利用できると判断しないでください。トランスポートの組み合わせによってデータの運び方が異なる場合があります。アプリの要件を満たすかどうかは実際に確認する必要があり、プロトコル名だけでは保証されません。

複数の端末でサブスクリプションを共用する場合は、すべての端末が対応する機能一式を優先してください。デスクトップでは使える拡張機能でも、モバイル側のパーサーが項目を保持できない場合は、デスクトップ専用のグループに分け、モバイル側には明確に互換性のある接続先を残します。すべての端末で一覧を同じにするために、互換性のない設定を無理に複製しないでください。長期運用では、グループ分け、設定元の記録、更新手順も選択の一部です。後のトラブルシューティングにかかる手間を大きく減らせます。

リソースに制約のある端末では、追加処理を抑えた設定から試しましょう。必要なルーティングルール、適切なログレベル、明確な通信の取り込み範囲を保ち、不要なバックグラウンド検出は停止します。それでも接続の負荷が高ければ、プロトコルとトランスポートの組み合わせを比較してください。端末が古いからといって、認証やセキュリティ層を無効にしないでください。安全性を下げることは性能改善策ではありません。残す価値のある変更は、同じ作業で効果を繰り返し確認でき、アプリの要件と接続先の検証を損なわないものです。

元に戻せる手順を確保し、変更内容を最小限記録する

設定の最適化は複製上で行い、一度に変更するパラメーターの種類をひとつにして、何を改善するのか記録してください。接続再利用のオン・オフだけを比較するなら、プロトコル、接続先、ルーティング、テストするアプリをそろえます。セキュリティハンドシェイクを調べるときは、DNSルールを同時に変更しないでください。結果が悪化したら、すぐに直前の動作する設定へ戻せるようにします。問題が起きた場合は、「ローカルでの通信取り込み、名前解決、下位接続、セキュリティハンドシェイク、プロキシ認証、宛先へのアクセス」の順にログを確認し、誤った階層を何度も変更しないようにしましょう。

最終的な選択で、すべてのプロトコルを網羅したり、すべての端末に同じ高度な機能を使わせたりする必要はありません。サーバーが明確に対応し、クライアントで一式を設定でき、コアが正しく実行し、実際のアプリで安定して使えること。この4つがそろえば、現在の用途に合った設定です。初めて設定する場合はクイックスタートガイド、プラットフォームに合うインストーラーはダウンロードページをご覧ください。問題が続く場合はよくある質問のカテゴリから絞り込みましょう。本ページのプロトコル解説は、選択の違いを理解するための参考情報であり、実環境での検証に代わるものではありません。