V2Rayプロトコルガイド
プロトコルの種類とコア選定

01 · プロトコルの階層と VMess

サーバー名だけでは接続設定を特定できない

クライアントのサーバー設定には通常、サーバーアドレス、ポート、プロキシプロトコル、通信方式、通信の保護方式、認証情報が含まれます。プロトコルは宛先の指定、ユーザー認証、リクエストの構成を担い、通信方式はデータを運ぶ方法、セキュリティ層は接続先の認証と通信の保護を担います。サブスクリプションの説明にプロトコル名しかなくても、実際の接続には一連の設定が必要です。プルダウンで VMess を VLESS に変えるだけでは、既存の接続先を別のプロトコルに変換できません。

トラブル対処では、設定を3つの層に分けて確認します。プロキシプロトコル、基盤となる通信方式、セキュリティ設定の順に記録しましょう。たとえば VMess は WebSocket と TLS、VLESS は直接接続と REALITY を組み合わせられます。同じアドレスを使う設定でも、ポートや接続先の受け入れ口が異なる場合があります。ここで示す組み合わせは構成を説明する例であり、利用できるかどうかはサーバー側の設定によります。クライアントは指定された内容で接続を開始しますが、接続先にない機能を自動で補うことはできません。

VMessの設計背景と認証の特徴

VMessは、Project Vが初期のプロキシ環境を構築する際に採用した主要プロトコルの一つです。プロトコル層でユーザー認証とプロキシリクエストを処理し、複数の通信方式と組み合わせられます。単純なソケット転送形式でも、特定の外部暗号化接続そのものでもありません。この点を理解すれば、同じ VMess と呼ばれる設定でも、ハンドシェイク、外部の保護、接続の多重化、ネットワーク上の挙動が異なる理由がわかります。名称だけから実際の性能を判断することはできません。

現行の VMess 設定では、AEAD認証に対応した実装を使用してください。古い資料にある追加のID数や旧式の認証方式を、新しい設定にそのまま流用しないでください。クライアントに alterId などの旧式フィールドが表示される場合は、サブスクリプションの提供元とコアの説明を確認しましょう。現在一般的な設定では値をゼロにします。認証方式とペイロードの暗号化アルゴリズムは別の概念です。セキュリティ設定のプルダウンに表示されるアルゴリズムだけで、認証方式の世代を判断することはできません。

VMessの認証にはシステム時刻が影響します。端末の長時間のスリープ、手動での時刻変更、時刻同期の失敗により、アドレスや認証情報が正しくても接続を拒否されることがあります。まず、タイムゾーンの表示と実際の時刻を区別してください。画面上のタイムゾーンが異なるだけなら問題とは限りませんが、実際の時計がずれている場合は対処が必要です。トラブル対処では、システムの自動時刻設定を有効にしてから再接続し、時刻のずれをサーバー障害やプロトコル非互換と誤認しないようにしましょう。

設定項目を確認する順序と注意点

インポート後は、アドレス、ポート、ユーザーID、通信方式、TLS、サーバー名、通信パスの順に確認しましょう。ユーザーIDは認証情報なので完全な状態で保持し、公開するスクリーンショットには表示しないでください。通信パスはローカルのファイルパスではありません。また、WebSocket の Host がサーバーアドレスと常に同じとは限りません。これらは接続先での振り分けに使われる場合があるため、重複して見えても削除せず、ドメインの項目をすべて名前解決後のアドレスに置き換えることも避けてください。

VMessのペイロード暗号化方式は、コアの実装、プロセッサーの性能、サーバー側の設定によって選びます。ハードウェアアクセラレーションに対応したプロセッサーでは、特定のアルゴリズムが適する場合があります。モバイル端末では、OSのスケジューリングも実際の性能に影響します。自動選択を基準にし、双方の対応が明確で再現可能なテストを行える場合に限り、手動でアルゴリズムを指定しましょう。ペイロード暗号化の一層を無効にしても、接続全体が別の保護を得るわけではありません。外部のセキュリティ層は別途確認してください。

安定して使えている VMess 設定は、名称を変えるだけのために移行する必要はありません。新しい機能が必要なら、まず現在のコアが対応しているか確認し、設定の提供元から新しい接続情報一式を入手してください。移行前後を比較する際は、端末、ネットワーク、接続先、テスト時間帯をできるだけそろえましょう。そうしないと、接続先の変更による差をプロトコルの違いと誤認し、再現できない速度評価につながります。

02 · VLESS と REALITY

軽量なプロトコルでも通信保護は必要

VLESSは、V2Rayエコシステムにおいて、認証とリクエストの構成を簡素化する方向で設計されています。VMessとは異なり、基本プロトコル層で同様のペイロード暗号化を担わず、組み合わせる通信のセキュリティ方式で接続を保護します。「プロトコルが軽い」とは役割分担を指し、どのネットワークでも平文で使えるという意味ではありません。一般的な VLESS 設定で encryption が none となっているのは、このフィールドのプロトコル設定を示すものであり、接続全体にセキュリティ層がないという意味ではありません。

クライアントで VLESS を選んだ後は、接続先が TLS、REALITY、または明示的に対応する別の組み合わせを使っているか確認してください。接続先のハンドシェイク方式と一致させる必要があるため、セキュリティのプルダウンを好みで切り替えてはいけません。ユーザーIDが同じでも、2つの接続先を相互に置き換えられるとは限りません。インポーターが未知のセキュリティ方式を既定値に置き換えた場合、サーバー項目は作成されても、実際のハンドシェイクが元の設定と異なる可能性があります。すぐに設定画面で項目を確認してください。

REALITYはセキュリティ方式であり、単独のプロキシプロトコルではない

REALITYはXrayエコシステムの通信セキュリティ方式で、VLESSと組み合わせて使われることがよくあります。変更されるのはセキュリティハンドシェイクと認証方式であり、プロキシプロトコルが担う宛先の指定やユーザーリクエストの意味を置き換えるものではありません。サブスクリプションで「REALITYノード」と記載されている場合、接続設定一式を指す略称であることが一般的です。選定時は、VLESSを置き換える項目としてプロトコル一覧から REALITY を探すのではなく、基盤プロトコル、通信方式、フロー制御を確認しましょう。

一般的な証明書の設定手順とは異なり、REALITYは独自の認証パラメーターとハンドシェイク方式を使います。クライアントには通常、サーバー名、公開鍵に関する認証情報、shortId、実装が求めるクライアントフィンガープリントが必要です。公開鍵はクライアントのユーザーIDではなく、shortIdも任意のメモではありません。クライアントやコアによって項目名が変わることがあります。古い手順の項目位置をそのまま写すのではなく、インポート元と現在の実装に照らして確認してください。

サーバー名はハンドシェイクや接続先の認証に関わる処理で使われ、通常はサーバー側で許可された名前を設定します。接続アドレスと文字列が完全に一致する必要はありませんが、任意のドメインに変更してよいわけでもありません。接続アドレスはクライアントが最初に接続する先を決め、サーバー名はセキュリティハンドシェイクの構成と検証に影響します。両者を同じ「ドメイン」と考えると、トラブル対処の方向を誤ります。アドレスには到達できるのに認証に失敗する場合は、項目を分けて確認しましょう。

Vision、フィンガープリント、通信方式の組み合わせ

XTLS Visionは通常、flow フィールドで指定し、代表的な値は xtls-rprx-vision です。特定の接続構成でデータの流れを処理するもので、設定すればするほど速くなる汎用的な高速化スイッチではありません。有効にできるかどうかは、サーバー、コア、通信方式の組み合わせによります。特に、直接接続向けの設定を WebSocket などの通信方式へ機械的に流用しないでください。提供元からフロー制御の指定がなければ、別の設定に値があるという理由だけで追加してはいけません。

クライアントフィンガープリントはTLSクライアントハンドシェイクの一部の特徴を制御しますが、対応するブラウザーがインストールされるわけではなく、すべてのアプリの挙動が変わる保証もありません。フィンガープリントの選択肢にはコアの対応が必要で、同じ名前の設定項目でも実装によって処理が異なる場合があります。接続に失敗したら、まずサブスクリプションの元の値に戻し、ログに記録されたセキュリティ層のエラーを確認してください。そのうえで、フィンガープリントの非対応、認証情報の誤り、サーバー名の不一致を切り分けます。

REALITY や Vision が必要な場合、Android では v2rayNG に搭載された Xray の対応状況を、デスクトップでは v2rayN で実際に有効になっているコアを確認しましょう。既存の VLESS 設定に重要な認証情報が欠けている場合は、値を推測せず、共有情報一式を入手し直してください。実装ごとの違いはコアの系統で解説しています。プロトコル名が一致することは、互換性確認の出発点にすぎません。

03 · Trojan と Shadowsocks

Trojan：TLSを利用した認証とプロキシリクエスト

Trojanは、TLS接続の内側でプロキシ認証とリクエストを行う設計です。一般的な設定では、パスワードをユーザー認証情報として使います。プロトコル層と外部のセキュリティ境界が比較的わかりやすく、設定どおりにTLS接続を確立してからプロキシリクエストを交換します。Trojanを選んでも、証明書の問題が自動で解決するわけではありません。サーバー名、証明書チェーンの信頼性、端末の時刻が正しくないと、プロキシ認証の開始前に接続が終了することがあります。

標準的な Trojan 接続では、VMessのようなユーザーIDは通常必要ありません。別のプロトコルから設定をコピーして無関係な項目を残すと、クライアントが無視する場合もあれば、誤った設定を作る場合もあります。使用するプロトコルのサーバー項目を新規作成し、元の共有情報に従ってパスワード、アドレス、ポート、セキュリティ設定を入力しましょう。パスワードに特殊文字が含まれる場合、共有リンクを手作業で組み立てるとエスケープの誤りが起きやすいため、クライアントのインポート・エクスポート機能を使ってください。

証明書の検証に失敗しても、検証のスキップを常用しないでください。まず接続アドレスとサーバー名を取り違えていないか確認し、続いてシステム時刻、証明書の有効期間、証明書チェーン、接続先が実際にTLSを提供しているかを調べます。安全でない接続を許可すると、接続先の認証範囲が変わり、誤った接続先まで受け入れる可能性があります。原因の特定のために一時的に設定を変更する場合は記録を残し、速やかに元へ戻してください。長期的には検証失敗の根本原因を解消しましょう。

Shadowsocks：暗号化方式と鍵で互換性が決まる

ShadowsocksはSSとも呼ばれ、比較的シンプルな暗号化プロキシ形式を採用しています。VMessやTrojanとは認証方式やデータ構成が異なるため、パスワード欄が似ているだけで互換性を判断できません。SSを選ぶ際は、少なくともサーバーアドレス、ポート、暗号化方式、パスワードまたは鍵を確認してください。暗号化方式名はプロトコルの仕様の一部であり、クライアント側で自由に変更できる好みの設定ではありません。クライアントとサーバーでアルゴリズムと鍵の解釈を一致させる必要があります。

初期のストリーム暗号方式、後発のAEAD方式、Shadowsocks 2022シリーズでは、設計と設定要件が異なります。現行の実装でサポートされているAEAD方式を優先するのが一般的ですが、「SS対応」がすべての世代に対応するという意味ではありません。新しい方式では特定の形式や長さの鍵が必要な場合があります。短いパスワードを入力しても、コアが互換性のある値を自動生成するとは限りません。具体的な形式は、接続先が指定する方式の説明を確認してください。

SSの共有リンクには、歴史的に複数のエンコード方式があります。暗号化方式とパスワードをまとめてエンコードするもの、認証情報だけをエンコードするものがあり、後ろにメモやプラグイン設定が付く場合もあります。インポートに失敗したら、リンク全体が欠けていないか、チャットアプリで途中が切れていないかを確認し、それから現在のクライアントが拡張機能に対応しているか調べましょう。エンコード内容を何度もデコードして適当に組み直すと、特殊文字や区切り文字が壊れ、新たなエラーの原因になります。

追加のラッパー機能をプロトコル標準の機能と混同しない

一部のSS設定では、追加プラグインや専用の外部ラッパーが必要です。プロトコル自体への対応とプラグインへの対応は別の機能です。GUIクライアントが方式名を認識しても、対応するプラグインの実行環境があるとは限りません。このガイドでは、追加クライアントを推奨対象に含めていません。追加コンポーネントが必要な共有設定を使う場合は、v2rayN、v2rayNG、v2flyNGの現在の実装で一式を扱えるか確認してから、設定を残すか判断してください。

UDPも個別に確認が必要です。プロトコル仕様でUDP転送が可能でも、サブスクリプションの接続先、リモートサーバー、クライアントの動作モード、ローカルアプリですべて有効とは限りません。Webページが開けても、一部のTCPリクエストが使えると確認できただけで、リアルタイムの音声・映像やその他のデータグラム通信が正常とは限りません。特定のアプリだけに問題がある場合は、フォールバックの有無、接続先ポートの対応、ルーティングで2種類の通信が別々の出力先に振り分けられていないかを確認してください。

互換性のある設定一式がそろっている場合、Trojanは一般的なTLSの運用方法を継続したい環境に向いています。SSは対応するサーバー構成があり、方式の要件を把握している場合に適しています。どちらも、構成がシンプルに見えるという理由だけで高速と判断できません。プロトコルを変更するなら、新しいプロトコル用に接続先が実際に用意した設定を入手してください。元のポートを残してクライアントの種類だけ変えてはいけません。

04 · 接続速度、リソース、モバイル端末の電力消費

最初のリクエストと継続的な通信を分けて比較する

アクセスにかかる時間には、名前解決、接続の確立、セキュリティハンドシェイク、プロキシ認証、接続先の応答が影響します。プロトコルが関わるのはその一部です。短時間の接続を多く行うアプリはハンドシェイクのコストに敏感ですが、大容量の転送は回線帯域、輻輳制御、リモート側の出口に左右されやすくなります。プロトコルを比較する前に、ページの表示、初回応答、継続的なスループットのどれを測るのか明確にしましょう。これらを一つの速度として扱っても、問題の発生箇所は特定できません。

外部の通信方式は、追加のリクエストやハンドシェイクを生むこともあれば、接続を再利用して後続の負荷を減らすこともあります。TLSやWebSocketを有効にしたり、複数ストリーム対応の通信方式を使ったりしても、速度の優劣が一律に決まるわけではありません。ネットワークの往復遅延が大きい場合は追加の往復が目立つことがありますが、接続を再利用できれば、新しいリクエストで毎回すべての初期化処理が必要とは限りません。そのため、同じ設定でも初回の表示と連続した再読み込みの体感は単純に比較できません。

継続的な通信時のプロセッサー負荷は、アルゴリズムの実装、ハードウェアアクセラレーション、バッファー処理、データコピーなどによって変わります。同じプロトコルでも、デスクトップのプロセッサーとモバイル端末のチップではボトルネックが異なる場合があります。暗号化やカプセル化の負荷を検討するのは、プロセッサーが継続して高負荷で、回線にも余裕がある場合に限りましょう。すべての設定が同じような地点で速度低下するなら、プロトコル名を次々に変える前に、ネットワークと接続先のリソースを調べてください。

Muxは万能な高速化スイッチではない

Muxは複数の論理接続を少数の基盤接続にまとめ、頻繁な接続確立のコストを下げることがあります。一方、複数のリクエストが同じ回線のブロッキングの影響を受ける場合もあります。効果はプロトコル、通信方式、コアの実装、用途によって異なります。複数ストリーム機能を備えた組み合わせでは、従来型Muxを重ねても効果がない場合があり、フロー制御の方式によっては組み合わせに制約があります。テストではまず元の設定を使い、再利用の設定だけを一度に一つ変更してください。

モバイル端末の電池消費は、暗号化の計算だけで決まるわけではありません。VPNサービスの継続動作、アプリのバックグラウンド通信、DNSの再試行、ネットワークの切り替えも、プロセッサーや無線モジュールを起動させることがあります。クライアントの消費電力が増え、他のアプリも大量に通信しているなら、まず通信の発生元を確認してください。アプリがプロキシ経由で通信した際のネットワーク負荷は、VPNサービスの消費電力として一部計上される場合があります。システムの消費電力統計をすべてプロトコルの効率の問題と解釈しないようにしましょう。

バックグラウンド制限、接続維持、ネットワーク切り替え

バッテリー最適化の制限が厳しすぎると、バックグラウンドサービスが終了し、切断と再接続を繰り返す場合があります。一方、制限をすべて解除すると不要なバックグラウンド動作が長引く可能性があります。まずサービスが実際に終了させられているか確認し、必要なバックグラウンド権限だけをクライアントに許可してください。システムの接続維持、Mux、DNS、アプリ別ルールを同時に変更するのは避けましょう。一度に多くの条件を変えると、電池消費が減っても、通信量の減少と設定改善のどちらが原因か判断できません。

Wi-Fiからモバイルネットワークへ切り替えると、既存の接続は通常再確立が必要になり、DNSキャッシュやネットワークインターフェースの状態も変化する場合があります。一時的な接続失敗が認証エラーとは限りません。ネットワークが安定するまで待ってから一度手動で再接続し、ログで名前解決、接続、ハンドシェイクのどの段階にエラーがあるか記録しましょう。特定のネットワークだけで失敗するなら、そのネットワークのアドレスファミリー、パスMTU、到達性を確認します。回線の問題を隠すために認証情報を何度も変更しないでください。

再現性のある比較では、端末、アプリ、接続先、ネットワーク環境をそろえ、起動直後のアクセス、連続したリクエスト、アイドル状態でのバックグラウンド動作をそれぞれ確認します。各回で変更する要素は一つにし、接続が安定するまで十分に待ちましょう。テスト中はバックグラウンドのダウンロード、システム更新、その他の高負荷作業を避けてください。誰にでも通用する順位を求める必要はありません。現在の端末と用途で、どの設定が失敗、再接続、継続的なリソース消費を減らしたかを説明できることが大切です。

アプリ別プロキシを使うと、プロキシが不要なアプリの通信をVPN経由にせずに済みます。ただし、アプリ間の遷移、ログイン用コンポーネント、システムサービスへの依存も考慮してください。メインのアプリだけをプロキシ対象にして認証コンポーネントを除外すると、ページは開いてもログインに失敗することがあります。性能改善は、必要な機能がすべて動作することが前提です。利用できることを確認してから、不要なプロキシ対象やバックグラウンド動作を減らしましょう。名前だけ軽そうなプロトコルを選ぶより、安定した結果を得やすくなります。

05 · Project V、V2Fly、Xray

クライアントの画面とコアは別の層

Project Vは、V2Rayエコシステムの背景を理解するための出発点です。V2FlyはV2Rayのコミュニティ開発を継承し、Xrayは関連するコード体系から分岐して独自の機能を発展させています。両者には共通の歴史や設定概念がありますが、同じプログラムの別名ではありません。プロトコル名、JSONのフィールド、ディレクトリ構成が似ていても、それは共通の基盤があることを示すだけです。新機能が両方で同時に使えることや、同じ設定が常に同じ挙動になることを意味しません。

GUIクライアントは、サブスクリプションの管理、設定編集、ルーティング、起動制御などを担い、コアが実際の接続確立と転送を処理します。画面に選択肢があっても、実際に動作するかどうかは選択したコアに左右されます。入力欄に値を設定できても、コアが受け付けるとは限りません。設定を保存できても、実行時の設定ファイルに反映されているとは限りません。トラブル対処では、ウィンドウのタイトルだけを見るのではなく、クライアント、コアの系統、実際に有効な設定をすべて確認しましょう。

3つのクライアントの選び方

デスクトップでは v2rayN を第一候補とし、Windows、macOS、Linux 向けのインストール先を選びます。サブスクリプション、ルーティング、デスクトッププロキシを一元管理できますが、OSごとに画面やシステムとの連携が完全に同じとは限りません。プロトコルの機能を使う際は、現在選択されているコアと実際の同梱内容を確認してください。別の端末の v2rayN で使えた組み合わせが、現在のインストール環境でも使えるとは限りません。

Android版の v2rayNG は Xray コアを採用しており、対応するプロトコルの組み合わせが必要な設定に向いています。v2flyNG は V2Fly コアを使用し、V2Fly実装の代替として利用できます。選ぶ際は、必要な機能を基準にしてください。名称が似ているからといって自由に置き換えられるわけではありません。サブスクリプションで REALITY や Vision が明示されている場合は、まず Xray の利用を確認します。V2Fly の設定を管理する場合は、V2Flyの現行フィールドと動作に沿って確認しましょう。

どちらのコアも広く使われているプロトコルや通信方式に対応していますが、対応範囲や具体的な仕様は実装の進化に伴って変わります。REALITY と Vision は Xray の対応状況を確認するうえで重要な項目です。これらのフィールドを含む設定を、そのまま V2Fly に渡すことはできません。逆に、V2Fly固有の通信方式や設定構造も、Xrayで使えるとは限りません。コアを変更するときは項目ごとに確認し、設定ファイル全体を上書きして起動できるかだけで判断しないでください。

設定を移行するときは構造と意味を確認する

コアの設定には通常、インバウンド、アウトバウンド、ルーティング、DNS、ログなどが含まれます。アウトバウンドだけを移行すると、そのタグを参照するルーティングやDNSポリシーが抜ける場合があります。設定全体を移行すると、端末に存在しない待ち受けアドレス、ポート、ファイルパスが含まれることがあります。まず動作する状態のバックアップを残し、モジュールごとに移行してください。フィールドの検証に通っても、対象の通信が想定したアウトバウンドに入るか、DNSが元のポリシーで処理されるか確認しましょう。

ログに記録される未知のフィールド、未対応のセキュリティ方式、サポートされないフロー制御は、互換性を調べる手がかりです。エラーを消すために該当フィールドを削除してはいけません。重要なフィールドを削除すると、プログラムが起動しても必要な接続動作が失われることがあります。まず、そのフィールドを提供している実装を特定し、対応するコアへ切り替えるか、現在のコアに適した設定を入手し直してください。無闇にフィールドを削除するより、設定の意味を保ちやすくなります。

クライアントの更新とコアの更新も分けて考えてください。画面側の更新でインポート解析が修正されることもあれば、コアの更新でプロトコル対応が変わることもあり、解決する問題は異なります。更新前にサブスクリプションとローカルルールを保存し、更新後は既知の設定を一つ試してから複雑なルーティングを戻しましょう。問題が再発したら、「更新後に使えない」とだけ記録せず、どの段階でどのフィールドに問題があるかを記録してください。コアの系統ごとの違いは、XrayとV2Flyの違いと設定互換性で詳しく解説しています。

06 · 通信パラメーター、ルーティング、DNS

パス、Host、サーバー名はそれぞれ役割が異なる

通信方式は、プロキシのデータをどのように運ぶかを決めます。TCPを直接使う接続は比較的シンプルな構造です。WebSocketではHTTPのアップグレード処理が入り、gRPCなどの通信方式にもそれぞれのリクエスト形式や複数ストリームの仕様があります。これらはクライアント側だけで決める装飾的な選択肢ではなく、接続先の受け入れ設定の一部です。サーバーが特定の方式しか受け付けない場合、ローカル側で別の方式に変えると、認証前に失敗することがあります。性能を比較する前に、比較対象の組み合わせが実際に存在することを確認してください。

WebSocketのパスはリクエストのルーティングに使われ、Hostはリバースプロキシの仮想ホスト判定に関わる場合があります。TLSのサーバー名はセキュリティハンドシェイクに使われます。これらは同じ値の場合も、構成に応じて別々に設定する場合もあります。パスの大文字・小文字、先頭のスラッシュ、特殊文字はそのまま保持してください。リバースプロキシが正しいバックエンドへリクエストを転送していない場合、証明書のハンドシェイクに成功しても通常のWebページやエラーレスポンスが返ることがあります。それだけでプロキシプロトコルが正常に動作しているとは判断できません。

gRPCで使うサービス名も接続先と一致させる必要があり、クライアント上で見やすくするためのメモではありません。ALPNはセキュアな接続でアプリケーションプロトコルをネゴシエートする仕組みです。候補を誤って制限すると、必要な通信方式を確立できない場合があります。構成の説明で明示されていない限り、別の接続先で使っているALPNの一覧をそのまま流用しないでください。アドレスへの到達、セキュリティハンドシェイク、通信プロトコル、プロキシ認証の順に調べ、失敗箇所を特定してから該当項目を調整します。

ルーティングの順序でプロトコルの適用範囲が変わる

プロキシのアウトバウンドを選んでも、すべての通信がそこを通るとは限りません。システムプロキシ、VPNによる取り込み、アプリ独自のプロキシ設定、コアのルーティングが通信経路を決めます。システムプロキシが影響するのは、その設定に従うアプリだけです。VPNや仮想ネットワークインターフェースのモードはより広い範囲を取り込みますが、除外設定や権限による制限もあります。特定のアプリだけ挙動が異なる場合は、まずリクエストがクライアントに届いているか確認しましょう。入口の問題に対してアウトバウンドのプロトコルを調べても解決しません。

ルーティングルールは通常、記述された順に照合されます。先に広い条件のルールを置くと、後続の細かいルールが一度も適用されないことがあります。既定のアウトバウンドは、どのルールにも一致しない通信を処理します。以下はルールの一部であり、単体で動作する完全な設定ではありません。既存の direct と block のアウトバウンド、および対応するルールリソースが必要です。統合時はタグが存在するか確認してください。JSONの構文が正しいだけで、ファイル全体を安全に置き換えられると判断してはいけません。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNSとアウトバウンドはセットで検証する

DNSは解析サーバーのアドレスを入力するだけではありません。どこが名前解決を行うのか、リクエストがどのアウトバウンドを通るのか、返されたアドレスが後続のルーティングにどう使われるのかを確認する必要があります。アプリが独自の暗号化DNSを使う場合や、システムが別の名前解決経路を持つ場合もあります。コアのDNS設定がこれらを必ず制御するわけではありません。クライアントにリモートDNSを設定した後も、実際のリクエスト経路を検証しましょう。設定画面の表示だけで、DNSがプロキシ経由になったと判断してはいけません。

リモートDNSの設定によって、起動時の依存関係が生じることがあります。プロキシサーバーのアドレスがドメイン名で、その名前を解決するDNSサーバーへの接続にも、まだ確立されていないプロキシが必要だと循環が発生します。サーバー名を解決できる明確な経路を用意し、起動用の経路が意図せずすべての通信を処理しないようにしてください。サーバーアドレスの名前解決と接続先サイトの名前解決を区別すると、特定の設定でキャッシュを消した後に初めて問題が表面化する理由を把握しやすくなります。

FakeDNSは合成アドレスを使ってドメイン名との対応を保つ仕組みです。特定の通信取り込みやルーティングとの組み合わせに適していますが、有効にするだけで情報漏えいを防げるわけではありません。合成アドレスは、それを認識できる処理経路に戻す必要があります。無関係なアプリやアウトバウンドが実アドレスとして扱うと、接続に失敗します。キャッシュ、アドレスファミリー、ルールも連携させてください。具体的な検証方法はDNSリクエスト経路の確認と設定手順をご覧ください。変更前に元の設定を保存しましょう。

通信方式とDNSを調整したら、ドメイン名でのアクセス、名前解決が必要なプロキシ接続先、用途で必要となるデータグラム接続を個別に確認してください。Webページ一つだけで判断すると、キャッシュがDNSの問題を隠したり、接続の再利用がハンドシェイクの問題を隠したりする場合があります。新しい接続を少なくとも一度テストし、ログで適用されたアウトバウンドのタグを確認しましょう。これにより、プロトコルが使えない、ルールが一致しない、名前解決経路に問題があるという代表的な原因を区別できます。

07 · サブスクリプション形式とクライアント間の互換性

サブスクリプションは配布形式であり、通信プロトコルではない

サブスクリプションのリンクからサーバー情報を取得し、クライアントが実際の動作設定に変換します。サブスクリプション自体はデータの通信方式を定義せず、含まれるすべての項目が現在のコアに適しているとも限りません。更新の成功で確認できるのは、コンテンツの取得と解析処理の一部が完了したことだけです。その後、項目数以外の品質も確認してください。プロトコルが正しく認識されているか、セキュリティ設定が保持されているか、現在のコアが各フィールドを解釈できるかを調べましょう。

一般的な内容には、1行ずつの共有リンク、エンコードされたリンクの集合、特定の実装向けの完全な設定などがあります。拡張子やURLの見た目だけでは実際の形式を特定できません。クライアントは返された内容に基づいて判定する必要があります。取得したものがWebページ、ログイン画面、エラーテキストであれば、何度コピーしてもサブスクリプションのデータにはなりません。まず提供元で認証が必要か、返却内容が想定どおりかを確認し、その後に解析の互換性を調べます。最初にクライアントを再インストールする必要はありません。

形式の識別だけでは設定の意味まで保持できない

VMessの共有情報には構造化されたフィールドが含まれることが多く、VLESSやTrojanの共有リンクではアドレスとクエリパラメーターでセキュリティや通信方式を指定します。SSには別の歴史的なエンコード方式があります。クライアントによって、別名、任意パラメーター、拡張フィールドへの対応範囲が異なります。インポーターが未知のパラメーターを無視しても、見た目には完成した項目が表示される場合があります。クライアント間で移行した後は、名称とアドレスだけで判断せず、編集画面を開いて項目ごとに照合してください。

見落としやすい項目は、サーバー名、フロー制御、フィンガープリント、shortId、通信パス、サービス名です。特定のセキュリティ方式や通信方式でのみ表示される項目もあり、方式の判定を誤ると後続のフィールドが非表示になったり消去されたりする場合があります。元の共有情報にある項目が画面に見当たらない場合は、まずクライアントとコアが対応しているか確認しましょう。未知のパラメーターをメモ欄に貼り付けたり、見た目が似た別の入力欄で代用したりしないでください。

サブスクリプションに含まれるのは接続先の情報であり、ルーティング、DNS、システムプロキシ、アプリ別ルールまでそろっているとは限りません。同じサブスクリプションを2台の端末にインポートしても、ローカルのポリシーが同期されないため、通信の挙動が異なる場合があります。デスクトップからAndroidへ移行するときは特に、サーバー情報とローカル設定を分けて考えてください。まずサーバーを移行し、その後にルーティングとVPN設定を個別に確認します。手順は複数端末でのサブスクリプション、共有コード、バックアップのインポート方法をご覧ください。

更新、グループ分け、ローカル編集の注意点

自動更新では通常、サブスクリプション元から対応するグループの項目が再生成されます。ローカルで手動編集した内容が次回更新で失われるかどうかは、クライアントの実装によります。長期間保持するテスト設定は、明確な手動グループにコピーし、元のサブスクリプション項目との関係を記録しておきましょう。出所のわからない変更項目を同じグループに混在させ、メモから更新で上書きされるか推測する運用は避けてください。更新の前後では並び順だけでなく、重要なセキュリティ設定も確認します。

サブスクリプションのフィルターやメモの正規表現は、項目の取り込みや一覧表示に影響するだけで、プロトコルの利用可否を自動で検証するものではありません。条件が厳しすぎると、使える接続先まで除外されることがあります。名称が似ていても、設定が同じとは限りません。「更新後にサーバーが見つからない」場合は、まずフィルターを解除してグループを確認し、サブスクリプション元が本当に項目を削除したか調べましょう。詳しくはサブスクリプショングループとサーバーのフィルタリングをご覧ください。表示上の問題をコアの障害と誤認しないようにしましょう。

QRコードはテキストを別の形で表したものであり、対応プロトコルが増えるわけではありません。スキャン自体の失敗は画像認識の問題かもしれません。スキャンできてもインポートに失敗するなら、テキスト形式の問題が考えられます。これらは分けて対処しましょう。まず端末内で読み取り結果のプロトコル接頭辞と構造を確認し、認証情報を含む内容を不明な変換サービスに送信しないでください。長い共有テキストをチャットアプリで転送するときは、改行、句読点の置換、末尾の欠落にも注意が必要です。

確実な移行記録には、サーバー一覧のスクリーンショットだけでなく、情報の種類、クライアント、コアの系統、主要な設定の組み合わせを含めます。移行後は、構造がシンプルで出所が明確な設定を一つテストしてから、まとめてインポートしてください。テストが通った後に、フィルター、自動更新、複雑なルールを戻します。問題が起きたら、取得、解析、生成、起動、ハンドシェイクの5段階に沿って原因を探りましょう。初期の手がかりを失うような全設定の入れ替えは避けてください。

08 · 用途に合わせて選ぶ

条件を整理してからプロトコルを比較する

選定で最初に確認するのは速度の順位ではなく、接続先で利用できる接続方式です。次に端末のOS、クライアント、コアの系統、必要な用途、運用方法を確認します。サーバーが一つの設定しか提供していない場合は、まずその設定を正しく動作させてから、別のプロトコルが必要か検討しましょう。クライアントが接続先の機能を作り出すことはできません。ローカルでプロトコルの種類だけ変更しても、通常は対応する受け口のない設定になります。

デスクトップで日常的に使う場合は、v2rayNを選び、元のサブスクリプションをインポートして、動作を把握しやすい既定設定を保ちましょう。REALITYやVisionが必要なら、その組み合わせに対応したXrayを選んでいるか確認してください。安定して使えている VMess、Trojan、SSの設定は、具体的なフィールドとコアの対応を確認し、名称をそろえるためだけに移行する必要はありません。インストールパッケージとシステムアーキテクチャはダウンロードページで選択してください。このページではインストール後に設定の互換性を判断する方法を解説します。

Androidと電池消費を重視する場合

AndroidでXrayの機能が必要な場合は、まず v2rayNG を確認してください。V2Flyの設定を運用する場合は、v2flyNG を選び、該当する実装に合わせてパラメーターを確認します。初回のテストでは、Muxとアプリ別ルールを、挙動を説明しやすい状態にしておきましょう。その後、段階的に調整します。バックグラウンドで切断する場合は、OSがVPNサービスを終了させていないか確認してください。接続が安定しているのに電池消費が増えた場合は、アプリのリクエストとネットワークの再接続状況を確認し、OSのスケジューリング問題をプロトコルのヘッダー処理負荷と混同しないようにしましょう。

電池消費を抑えたい端末では、設定項目を減らすことだけを目指すのではなく、不要な継続的通信を減らしてください。安定して接続でき、再接続が少なく、用途を満たす構成を選んだうえで、実際に使うアプリに合わせてアプリ別プロキシを設定します。リアルタイムの音声・映像やデータグラム通信が必要なら、UDP経路を個別に確認してください。Webページだけを使う場合は、通常の閲覧リクエストで基準を作れますが、その結果をすべてのアプリが使える根拠に広げないでください。

既存の安定した設定と新規導入では判断基準が異なる

安定している既存設定では、運用コストも選定基準に含めましょう。プロトコルを変えると、接続先の設定、セキュリティパラメーター、サブスクリプションの生成方法、すべての端末との互換性に影響することがあります。一方、得られる効果がプロトコル自体によるとは限りません。現在のコアに必要な機能がない、ハンドシェイクのコストが実際のボトルネックになっている、現在の方式が運用に適さなくなったなど、明確な要件がある場合に移行を検討しましょう。目標はテストで検証できるものにし、「何かを新しくする」といった曖昧な理由で進めないでください。

新規導入では、双方が明確に対応し、資料がそろっていて確認しやすい組み合わせを選びます。一般的なTLS運用方式が必要なら、Trojanまたは互換性のあるVLESS構成を検討しましょう。SSの環境がすでにある場合は、現行の暗号化方式、鍵の形式、データグラムへの対応を確認します。VMessを使うなら、現行の認証方式と時刻同期を確認してください。REALITYでは、クライアントに名称が表示されるかだけでなく、Xrayの対応状況と認証情報の管理方法も評価しましょう。

エラーの発生段階から選択肢を絞る

インポート時に失敗するなら、共有形式とクライアントの解析を確認します。コアが起動しない場合は、フィールドの構造と機能の対応状況を調べましょう。アドレスに接続できないなら、名前解決、ポート、ネットワーク経路を確認します。セキュリティハンドシェイクに失敗する場合は、サーバー名、証明書、REALITYのパラメーターを確認してください。ハンドシェイクが成功してもアプリが使えない場合は、プロキシ認証、ルーティング、通信の取り込み範囲を調べます。段階ごとに得られる証拠は異なります。すべてを「プロトコルの問題」として片付け、設定一式を一度に変更しないでください。

既知の正常な設定を一つ残しておくと、トラブル対処に役立ちます。障害が端末全体、現在のネットワーク、特定の接続先のどこにあるかを切り分けられます。比較時にネットワーク、コア、プロトコルを同時に切り替えず、まず元の環境で再テストしてから一つずつ変更してください。ログを共有する際は認証情報を隠し、発生順序とエラーの種類は残します。手順に沿って基準となる環境を作り直す場合は使い方ガイドに戻り、具体的な問題はFAQで該当する項目を確認してください。

プロトコル選びに、環境を問わず通用する唯一の正解はありません。管理しやすい設定とは、重要な各フィールドの入手元を説明でき、通信がどの経路でコアに入るかを把握し、名前解決の失敗とハンドシェイクの失敗を区別でき、更新後も基本テストを再現できるものです。プロトコル、セキュリティ層、通信方式、ローカルポリシーをそれぞれ管理し、最後に全体として検証しましょう。そうすれば、端末の移行やコアの変更後も安定した動作を保てます。一度だけ偶然つながった状態に頼る必要はありません。