設定の階層 · 概要
概念の関係を示す図です。クライアントの操作画面ではありません。
V2Ray用語集
よく使われる用語を6つのカテゴリから確認できます。まず設定の階層を把握し、クライアントの実際の項目と照らし合わせましょう。
プロトコルは通信方式を定め、コアは設定を実行し、クライアントは管理画面を提供します。名称が似ていても機能が同じとは限らず、設定値をそのまま置き換えられるとは限りません。
使い方ガイドを見る →プロトコルとトランスポート
プロトコル名は設定の一部にすぎません。トランスポート方式、認証情報、通信保護の設定も一致させる必要があります。
- プロトコルとトランスポートVMess
- Project Vエコシステムのプロキシプロトコルです。ユーザーIDなどを使って認証し、独自のデータ保護機能を備えています。実際の接続にはトランスポート方式や外側のセキュリティ設定も関わるため、プロトコル名だけでは互換性を判断できません。インポート後に接続できない場合は、ノードの別名だけを変えるのではなく、ユーザーID、サーバー時刻、トランスポート設定を確認してください。
- プロトコルとトランスポートVLESS
- 軽量なプロキシプロトコルで、単体ではペイロードを暗号化しません。通常はTLSやREALITYなどと組み合わせて使用します。VLESS、トランスポート方式、セキュリティ層はそれぞれ別の設定項目です。VLESSという表示だけから他の設定を推測することはできません。ユーザーID、サーバー名、サーバー側が求めるその他の項目を一致させてください。
- プロトコルとトランスポートTrojan
- 通常はTLSで接続を保護し、パスワードで認証するプロキシプロトコルです。クライアントのパスワード、サーバー名、トランスポート設定をサーバー側に合わせる必要があります。サーバーのポートに接続できても、認証が通ったとは限りません。証明書エラーが起きた場合は、サーバー名とシステム時刻を確認してください。証明書検証の無効化を常用するのは避けましょう。
- プロトコルとトランスポートREALITY
- Xrayエコシステムの通信保護機能で、VLESSの接続設定によく使われますが、それ自体はサブスクリプション形式でもGUIクライアントでもありません。公開鍵、サーバー名、short IDなど、サーバー側から指定された値を一致させる必要があります。具体的な項目はクライアントとコアのバージョンによって異なります。未対応の項目がある場合は、パラメーターを手作業で削除する前に、コアが対応しているか確認してください。
コアとエコシステム
V2Ray、V2Fly、Xray、v2rayNはそれぞれ異なる階層に属します。プロジェクト、実行コア、クライアントを分けて理解しましょう。
- コアとエコシステムProject V
- V2Rayなどのネットワークツールを中心とするプロジェクト群と技術エコシステムで、プロトコルの実装、トラフィック処理、関連ツールなどを含みます。特定のデスクトップアプリやインストーラーの名称ではなく、特定の機能が使えるかどうかを直接示すものでもありません。クライアントを選ぶ際は、実際に使用するコアと、そのコアが対応する設定範囲も確認してください。
- コアとエコシステムV2Fly
- V2Rayコアを継続的にメンテナンスするコミュニティプロジェクトで、オープンソースのプロキシツールエコシステムの一部です。Androidクライアントのv2flyNGはこのコアの系統を採用していますが、クライアントの画面名とコアの機能は別のものです。設定が使えるかどうかは対象バージョンの対応状況を確認し、他の派生版の項目をそのまま流用しないでください。
- コアとエコシステムXray
- V2Rayのコードを基盤に独立して発展したプロキシコアプロジェクトで、独自のプロトコル実装と機能開発を行っています。v2rayNGはXrayコアを採用しており、REALITYなどの設定にも対応するコア機能が必要です。XrayとV2Flyには共通の技術的背景がありますが、設定の詳細や対応範囲が常に同じとは限りません。
- コアとエコシステムコア
- プロトコル接続、ルーティング判定、DNSなどを実行するコンポーネントです。GUIクライアントは設定の編集、接続先の選択、実行状態の管理を担います。クライアントの更新とコアの更新は別の操作の場合があり、画面に項目があっても現在のコアが認識できるとは限りません。エラーが発生したら、クライアント名、コアの種類、エラー内容をそれぞれ記録してください。
サブスクリプションとノード
サブスクリプションは設定の取得と更新に使い、ノードはインポート後の接続設定を指します。どちらも、プロキシ接続が確立した状態を意味するものではありません。
- サブスクリプションとノードサブスクリプション
- URLから複数の接続設定を取得し、その後の更新時に取得元から内容を読み直す仕組みです。返される内容はエンコードされたテキスト、共有リンクの一覧、その他クライアントが対応する形式の場合があります。そのため、ブラウザーでURLを開けても、クライアントにインポートできるとは限りません。サブスクリプションURLにはアクセス情報が含まれる場合があるため、スクリーンショットやログ、問い合わせに載せる際はURL全体を隠してください。
- サブスクリプションとノードノード
- クライアントで選択できる接続設定で、通常はサーバーアドレス、ポート、プロトコル、認証情報、トランスポート設定などが含まれます。ノード名は主に識別用です。同じサーバーに複数の設定が対応することもあり、名前が違っても別のサーバーとは限りません。ノードを選ぶだけでは接続されません。コアを起動し、適切な方法でアプリの通信をクライアントに取り込む必要があります。
- サブスクリプションとノードサブスクリプショングループ
- サブスクリプションURLやインポートした設定を取得元ごとに整理するための管理単位です。取得元や更新範囲を区別するのに役立ちます。グループ名は整理用であり、プロトコル、プロキシへの接続方法、ルーティング結果を変えるものではありません。URLの変更やグループの削除前に、含まれる項目の取得元を確認してください。サブスクリプションから生成されたノードを手動で編集すると、次回更新時に上書きされる場合があります。
ルーティングと振り分け
まずアプリの通信がクライアントに取り込まれているか確認し、その後、ルールが出口をどう選択するかを調べてください。接続の取り込み設定とルーティング設定は、互いに代用できません。
- ルーティングと振り分けルーティングルール
- ドメイン、宛先IP、ポート、プロトコルなどの条件に基づき、接続の出口を決める設定です。一般にルールは順番に評価されます。前方の大まかな条件によって、後方の具体的なルールが適用されないことがあります。どのルールにも一致しない通信は、デフォルトの出口にも左右されます。想定と異なる結果になる場合は、ルールの順序、宛先情報を取得できているか、デフォルトの処理方法を確認してください。
- ルーティングと振り分けトラフィックの振り分け
- ルールに応じてトラフィックを直結、プロキシ、ブロックなどの出口へ振り分ける処理であり、独立したプロトコルではありません。システムプロキシは一部アプリの接続方法を制御し、振り分けはクライアントに取り込まれた後の処理を決めます。グローバルプロキシは一般に広い範囲の通信にプロキシを選ぶ設定を指しますが、すべてのアプリが取り込まれることを保証するものではありません。
- ルーティングと振り分けGeoIP
- IPアドレスの集合を使ってトラフィックを判定するためのデータとルール形式です。アドレスの集合は地域別などに整理される場合があります。IPアドレスの割り当てやサーバーの設置場所は変わるため、判定結果がサーバーの現在地を正確に示すとは限りません。関連ルールを変更する際は、クライアントが読み込んでいるデータファイルとタグ、ドメインの名前解決方法が想定どおりか確認してください。
- ルーティングと振り分けGeoSite
- ドメインをサービスやカテゴリごとの集合に分類し、ルーティングルールから参照するためのデータ機能です。IPアドレスで判定するGeoIPとは異なります。タグを利用できるか、どのドメインが含まれるかは、実際に読み込まれているデータソースと内容によって異なります。アプリがIPアドレスを直接使う場合や、クライアントがドメイン情報を取得できない場合は、ドメイン集合のルールだけでは一致しないことがあります。
クライアント設定
項目名はプラットフォームやバージョンによって異なる場合があります。他の端末の設定をそのまままねるより、機能の範囲を理解することが大切です。
- クライアント設定システムプロキシ
- OSがアプリに提供するプロキシ設定で、通常はクライアントがローカルで開いているプロキシ接続先を指定します。この設定に従うアプリだけが利用します。アプリ独自のプロキシを指定していたり、システム設定を無視したりする場合もあります。クライアント終了後も、停止したポートを指すシステムプロキシ設定が残っていると、アプリがネットワークに接続できないことがあります。その場合は該当するシステム設定を元に戻してください。
- クライアント設定TUNモード
- 仮想ネットワークインターフェースでトラフィックを受け取り、プロキシコンポーネントに渡す接続方式です。システムプロキシに従わない一部のアプリにも対応できます。追加の権限が必要になる場合があり、システムのルーティングやDNS、他の仮想ネットワークソフトウェアと干渉することもあります。有効にした後も、実際にどこまで通信が取り込まれているか確認してください。TUNを有効にすれば接続が必ず成功する、またはすべての通信が同じ出口を通るというわけではありません。
- クライアント設定ローカル待ち受けポート
- クライアントがローカルでプロキシリクエストを受け付け、OSやアプリからの接続に使うポートです。リモートサーバーのポートとは別の設定です。アプリを手動で設定する場合は、アドレス、ポート、HTTPやSOCKSなどのプロキシ方式を待ち受け設定に合わせてください。待ち受けアドレスによってアクセス可能な範囲も変わるため、通常のローカル利用では、他の端末から接続できる設定にむやみに変更しないでください。
- クライアント設定トラフィックのスニッフィング
- 接続の初期段階で確認できる情報からプロトコルや宛先ドメインを識別し、ルーティング判定などを補助する機能です。アプリ通信のすべてを復号する機能ではなく、あらゆる接続からドメインを取得できるとも限りません。有効にするか、宛先の書き換えを許可するかは、コアの設定やルールの目的に応じて判断してください。あらゆる接続問題に対する万能な修復スイッチではありません。
ネットワークの基礎
名前解決の成功、ポートへの到達、実際のリクエストの完了は、それぞれ異なる結果です。テスト指標はテスト先、名前解決方法、接続モードと合わせて確認してください。
- ネットワークの基礎DNS
- ドメインをIPアドレスなどのレコードに変換する仕組みで、通常はアプリが接続を開始する前に行われます。システムDNS、クライアント内蔵DNS、アプリが独自に使う暗号化DNSは、それぞれ異なる経路を通る場合があります。設定を一か所変更しても、他の経路には影響しないことがあります。問題を調べる際は、どこがリクエストを発行し、どのDNSに渡しているか、解決結果が後続のルーティングにどう使われるかを確認してください。
- ネットワークの基礎FakeDNS
- アプリに仮想アドレスを返し、内部でドメインと仮想アドレスの対応関係を保持するDNS処理方式です。通信が再びクライアントに入ると、その対応関係を使って宛先ドメインを復元できます。仮想アドレスを実際のサーバーアドレスとして扱うわけではありません。DNS応答、トラフィックの取り込み、対応関係の復元が連携する必要があり、古いキャッシュや不完全な取り込みによって接続に問題が起きることがあります。
- ネットワークの基礎DNSリーク
- 本来予定されていた経路以外のDNSサーバーに、DNSリクエストが送られる現象です。リークにあたるかどうかは、想定したポリシーを基準に判断してください。ルールに従って一部のドメインをローカルで名前解決しても、必ずしも設定ミスとは限りません。確認時はシステム、ブラウザー、クライアント、その他のアプリのDNS設定も考慮し、出口アドレスのテスト結果だけで判断しないでください。
- ネットワークの基礎実接続遅延
- 選択したプロキシ経由でテスト先に接続したときの所要時間です。計測に含まれる段階は、クライアントのテスト方式によって異なります。TCP接続だけを確認するTcpingより実際のリクエストに近い指標ですが、テスト先のアドレス、DNS、サーバーの応答にも影響されます。遅延が小さくてもダウンロード速度が速いとは限らず、テストに成功しても、すべてのWebサイトやアプリが正常に使えるとは限りません。