プロトコルとトランスポート
プロトコルはプロキシ要求の形式、トランスポートはデータの運び方、セキュリティ層は接続の保護を担います。設定を選ぶ際は、各項目の組み合わせを確認してください。
- VMess
- Project Vエコシステムのプロキシプロトコルで、認証とデータ保護の仕組みを備え、現在の設定では通常AEAD認証を使用します。クライアントとサーバーでユーザーIDなどの設定を一致させる必要があります。システム時刻のずれが大きい場合も、認証に失敗することがあります。VMessは特定のトランスポート方式を指すものではなく、さまざまなトランスポート設定と組み合わせられます。
- VLESS
- 軽量性を重視したプロキシプロトコルで、ペイロード自体は暗号化しません。実際の運用では通常TLSまたはREALITYと組み合わせます。ユーザーID、フロー制御、トランスポート方式、セキュリティ層はサーバーの指定に合わせて設定してください。プロトコルの選択だけをVLESSに変更しても接続できるとは限りません。利用可否はプロトコル名ではなく、組み合わせ全体で決まります。
- Trojan
- 通常はTLSで接続を保護し、パスワードで認証するプロキシプロトコルです。パスワードだけでなく、ポート、サーバー名、証明書検証の設定も確認してください。アドレスに接続できても、認証が成功するとは限りません。証明書エラーが発生した場合は、検証を無効にせず、サーバー名、システム時刻、サーバー証明書を確認してください。
- Shadowsocks
- SSとも呼ばれ、共有鍵と指定された暗号方式を使うプロキシプロトコルです。世代によって暗号方式、鍵の形式、コアのバージョン要件が異なります。特に、異なる形式の鍵をそのまま流用しないでください。インポート時は、アドレスやポートだけでなく、暗号方式と認証項目も確認しましょう。
- REALITY
- Xrayエコシステムのトランスポート層セキュリティ方式で、VLESSと並ぶ独立したプロキシプロトコルではありません。一般的なクライアント設定ではPublicKey、ShortId、SNI、フィンガープリントなどを指定し、サーバー側の設定に合わせる必要があります。Short IDを空欄にできるかどうかもサーバーの設定次第です。公開鍵と秘密鍵は用途が異なるため、クライアントにサーバーの秘密鍵を設定してはいけません。
- XTLS Vision
- Xrayのフロー制御方式で、クライアントでは通常
xtls-rprx-visionと表示されます。トランスポートプロトコルでもセキュリティ層でもなく、対応するVLESS接続の組み合わせで使われます。サーバー設定、トランスポート方式、コアがすべて対応している場合に選択してください。あらゆるノードを高速化する設定ではありません。
- トランスポートプロトコル
- プロキシプロトコルのデータを運ぶ方式で、TCPやWebSocketなどがあります。選べる項目はコアとバージョンによって異なります。プロキシプロトコルが同じでも、トランスポート方式が異なると通信できない場合があります。パスやHostなどの追加項目は、対応するトランスポート方式でのみ意味を持つため、別の方式へそのまま転記しないでください。
コアとエコシステム
クライアントは操作画面を提供し、コアは接続を処理します。機能の対応状況を確認する際は、クライアントの設定画面だけでなく、実際に動作しているコアも確認してください。
- Project V
- ネットワークプロキシツールと関連コンポーネントを中心とするプロジェクト群で、V2Rayはその主要な構成要素の一つです。一般に「V2Rayクライアント」と呼ばれるものはGUIの管理ツールを指すことが多く、すべてのツールが同じコアを使用するとは限りません。この関係を理解すると、画面の機能、設定形式、プロトコルの実装を区別しやすくなります。
- V2Fly
- V2Rayコアを継続的にメンテナンスしているコミュニティプロジェクトで、プロトコル処理、ルーティング、DNSなどの機能を提供します。v2flyNGは、このコアファミリーをAndroid向けの選択肢として採用しています。利用できる機能は実際のコアのバージョンで確認してください。他のコアの設定項目をそのままコピーしたり、クライアント名だけで互換性を判断したりしないでください。
- Xray
- V2Rayと歴史的なつながりを持つプロキシコアプロジェクトで、独自の機能と設定の進化を続けています。REALITYやXTLS Visionなどの機能には、対応するXrayが必要です。v2rayNGはこのコアファミリーを使用しています。設定形式には共通点がありますが、設定一式をそのまま交換できるとは限りません。
- コア
- プロトコル処理、接続確立、DNS、ルーティングを担うコンポーネントです。クライアントは画面、サブスクリプション、設定を管理します。画面に項目が表示されていても、選択中のコアがその機能を実行できるとは限りません。起動に失敗した場合は、まずコアのログを確認し、未対応の項目、パラメーター不足、ポートの競合がないか調べてください。
クライアント機能
通信を取り込むことと、アウトバウンドを選ぶことは別の処理です。システムプロキシやTUNは通信を処理経路へ取り込む方法を決め、ルーティングは取り込んだ後の転送先を決めます。
- システムプロキシ
- OSのプロキシ設定を通じて、その設定に従うアプリをクライアントのローカルプロキシ入口へ接続します。独自のネットワーク設定を使うアプリはシステムプロキシに従わない場合があるため、すべての通信を取り込めるわけではありません。クライアント終了後にWebページの表示がおかしい場合は、ノードの状態だけでなく、システムプロキシ設定が元に戻っているか確認してください。
- TUNモード
- 仮想ネットワークインターフェースとルーティング設定を使って、通信をクライアントの処理経路へ送る動作方式です。通常はシステムプロキシより広い範囲をカバーします。管理者権限が必要な場合があり、正しいルートとDNS設定も必要です。有効にしても、すべての接続がプロキシのアウトバウンドを通るとは限りません。他の仮想ネットワークツールと併用する場合は、ルートの競合を確認してください。
- インバウンドとアウトバウンド
- インバウンドは、ローカルHTTPやSOCKSプロキシの入口など、コアに入る接続を受け付けます。アウトバウンドは、接続をプロキシ経由、直接接続、または遮断のいずれかで転送します。ルーティングルールはアウトバウンドの識別子を使って処理方法を指定します。インバウンドの待ち受けポートはリモートサーバーのポートではないため、一方を変更しても他方には反映されません。
- トラフィックのスニッフィング
- 一部の接続のハンドシェイク情報からドメイン名やプロトコルの手がかりを識別し、ルーティングの判断に利用します。アプリの通信内容を復号する機能ではなく、すべての接続を識別できるわけでもありません。情報を取得できるかはプロトコルやハンドシェイク方式によって異なります。有効にした後もDNSとルーティングの適切な設定が必要で、スニッフィングを完全なドメイン名前解決ポリシーの代わりにはできません。
通信を取り込む範囲と、プロキシ経由になる範囲は異なります。TUNでアプリの通信を取り込んでも、ルールによって直接接続される場合があります。実際の経路を確認するには、アクセス先、適用されたルール、アウトバウンドのログを照合してください。モードのスイッチだけでは判断できません。
サブスクリプションとノード
サブスクリプションは設定の取得元と更新を担い、ノードは個々の接続設定です。インポート、更新、接続テスト、実際のアクセスでは、それぞれ異なる段階を確認します。
- サブスクリプション
- サーバー設定をまとめて取得・更新するための入口です。クライアントが内容を読み込み、管理可能な項目に変換します。サブスクリプションURLには認証情報が含まれる場合があるため、機密情報として扱い、スクリーンショットや公開ドキュメントに載せないでください。更新に成功したことが示すのは、内容の取得と解析ができたことだけです。すべてのノードに接続できるとは限らず、システムプロキシが自動で有効になるとも限りません。
- ノード
- クライアント内の個々のサーバー接続設定を指す一般的な呼び方で、通常はアドレス、ポート、認証情報、トランスポート設定を含みます。名前が異なる複数のノードが同じ基盤を指している場合があります。名前に含まれる地域名だけでは、実際の所在地や接続元の特性を確認できません。利用可否は一覧に表示されているかだけでなく、接続テスト、アプリでのアクセス、ログを合わせて判断してください。
- サブスクリプショングループ
- サブスクリプションURLやサーバー項目を提供元ごとにまとめて管理する単位で、個別の更新、絞り込み、削除に便利です。グループ名は主に管理用で、ルーティングポリシー、自動切り替え、負荷分散を意味するものではありません。グループを削除したりサブスクリプションを更新したりする前に、手動で変更した項目が上書きされないか確認し、必要に応じてクライアントのバックアップ機能を使ってください。
- 遅延と実接続遅延
- 「遅延」はTCP接続の確立時間だけを測る場合があります。「実接続遅延」は通常、選択したプロキシ経由で指定のリクエストを実行するため、アプリの通信経路により近い指標です。ただし測定方法はクライアントによって異なります。結果は接続先サイト、DNS、ハンドシェイク、タイムアウト設定の影響を受け、ダウンロード速度を直接示すものではありません。タイムアウトが発生しても、テスト対象を確認せずにノードの故障と判断しないでください。
ルーティングとDNS
DNS名前解決は取得するIPアドレスを決め、ルーティングは接続をどのアウトバウンドへ渡すかを決めます。両者は相互に影響しますが、別々の設定です。
- ルーティングルールとルール分岐
- ドメイン、IP、ポート、インバウンド識別子などの条件に応じて、接続を指定のアウトバウンドへ振り分ける仕組みです。代表的な項目に
domain、ip、outboundTagがあります。通常はルールの順に照合し、どのルールにも一致しない接続はデフォルトのアウトバウンドで処理します。ルールを設定しただけでは一致が保証されません。コアがドメイン名とIPのどちらを取得しているかも確認してください。
- GeoIP
- 地域やネットワーク種別ごとにまとめたIPアドレスの集合で、ルーティング条件として利用できます。実際のデータファイルとその更新状況に依存し、リアルタイムの位置情報でもドメイン分類の代わりでもありません。コンテンツ配信ネットワークを使う接続先では、解決されるIPアドレスがネットワークの場所によって変わることがあります。GeoIPのラベルだけでサービスの分類を正確に判断できるとは限りません。
- GeoSite
- サービスやカテゴリごとに整理したドメインの集合で、ドメイン分岐やDNSポリシーによく使われます。カテゴリ名、対象範囲、利用可能な項目は使用するデータファイルによって異なり、すべての提供元に同じラベルがあるとは限りません。ルールの読み込みに失敗した場合は、まずカテゴリの有無とファイルの読み取り可否を確認し、その後でドメインの照合方法を調べてください。
- FakeDNS
- ドメイン名に仮想IPを割り当て、その後、通信が対応する処理経路に入った時点でドメインとの関連付けを復元する仕組みです。返されるアドレスは接続先サーバーの実IPではありません。DNS解決、マッピング、ルーティングを連携させる必要があります。アプリが仮想IPを取得した後にクライアントを経由せず接続すると、アクセスに失敗することがあります。方式を切り替える際は、アプリとシステムのDNSキャッシュも考慮してください。
- DNSリーク
- DNSクエリが想定した名前解決経路を通らず、別のリゾルバーへ送られる状態を指します。何を想定した経路とするか、明確な設定目標に照らして判断してください。システムのリゾルバー、アプリ内蔵の暗号化DNS、コアのDNSが併用される場合があります。そのため、Webサイトへの接続元アドレスが想定どおりでも、DNSの経路が意図したとおりとは限りません。調査時はアプリの設定、システムのリゾルバー、コアのログを個別に確認し、1回のテスト結果だけに頼らないでください。