用語集 / 設定用語

V2Ray の主要用語

設定の階層ごとに用語を確認しましょう。プロトコルは接続方式を定め、コアは通信を処理し、サブスクリプションは設定情報を提供します。ルーティングとDNSはリクエストの経路を決めます。まず用語を整理してから、クライアントの設定を確認してください。

各用語には個別のアンカーがあり、ブラウザーのURLをコピーして参照できます。操作手順は使い方ガイドをご覧ください。サブスクリプション、ルーティング、DNSの設定を調整する場合は、応用テクニックを参照してください。

プロトコルと伝送方式

このカテゴリでは、ノード編集画面にあるプロトコル、伝送方式、セキュリティの設定に関する用語を解説します。接続トラブル時は、アドレスとポートだけでなく、それぞれの階層を個別に確認してください。

プロトコルと伝送方式

VMess

プロキシプロトコル

VMessはProject Vのエコシステムで使われるプロキシプロトコルで、ユーザーIDなどのパラメーターによって接続を識別します。プロトコル、伝送方式、TLSはそれぞれ別の設定階層です。UUIDを入力した後も、ほかの項目を確認してください。システム時刻のずれが認証に影響することがあるため、接続に問題がある場合は端末の時刻も確認しましょう。古いガイドの設定項目を、すべての新しいバージョンにそのまま適用することはできません。

プロトコルと伝送方式

VLESS

軽量プロキシプロトコル

VLESSは単体では通信を暗号化せず、通常はTLSやREALITYなどのセキュリティ機構と組み合わせて使います。ユーザーID、伝送方式、該当する場合はflowもサーバー側の設定と一致させてください。ノードのプロトコルをVLESSに変更しただけでは、別プロトコルの設定が利用可能なVLESSノードに変わるわけではありません。

プロトコルと伝送方式

Trojan

パスワード認証 / TLS

Trojanは通常、TLS接続上でプロキシリクエストを転送し、パスワードで認証するプロトコルです。パスワードだけでなく、サーバーアドレス、ポート、サーバー名、証明書の検証設定も確認してください。パスワードが正しいのにハンドシェイクに失敗する場合は、同じ設定を何度も読み込み直すのではなく、TLSと伝送方式の設定を確認しましょう。

プロトコルと伝送方式

REALITY

Xrayの伝送セキュリティ機構

REALITYはXrayエコシステムの伝送セキュリティ機構であり、単独のプロキシプロトコルではありません。VLESSと組み合わせて使われることがよくあります。クライアントには、サーバー側と一致する公開鍵、サーバー名、shortIdなどを設定してください。項目名から値を推測したり、クライアントの秘密鍵欄でサーバーの公開鍵を代用したりすることはできません。インポート前に、使用するコアが対応していることも確認してください。

プロトコルと伝送方式

TLS

トランスポート層セキュリティプロトコル

TLSは通信を保護し、証明書などを通じて通信相手の身元を確認します。ノードのアドレスとサーバー名は異なる役割を持つ場合があり、サーバー名は通常、ハンドシェイクや証明書の検証に使われます。証明書エラーが発生した場合は、ドメイン、証明書の有効期限、端末の時刻を確認し、証明書検証の無効化を通常の対処法にしないでください。

プロトコルと伝送方式

WebSocket

WebSocket / 双方向通信

WebSocketは双方向通信方式の一つで、プロキシコアの伝送層として利用できますが、ノードの認証方式を定義するものではありません。パス、Host、サーバー側のリバースプロキシ設定を一致させてください。パスの大文字・小文字が結果に影響することもあります。WebSocketとTLSは併用できるため、伝送の成否とセキュリティハンドシェイクの成否は分けて確認しましょう。

コアとエコシステム

クライアント名とコア名は同じガイドに登場することがありますが、別のものです。機能が使えるかどうかは、画面に設定項目があるかだけでなく、実際に起動しているコアが対応しているかも確認してください。

コアとエコシステム

Project V

V2Rayのオープンソースエコシステム

Project Vは、V2Rayを中心に形成されたオープンソースのプロキシツールと技術のエコシステムです。プロトコル、伝送方式、ルーティング、設定などの機能を含みます。一般に「V2Rayクライアント」と呼ばれるものは、こうした機能を管理するGUIアプリを指すことが多く、コアそのものとは限りません。資料を読むときは、画面上の操作とコアの設定構文を区別できるよう、まず対象を確認しましょう。

コアとエコシステム

Xray

Xray Core / プロキシコア

XrayはV2Rayエコシステムと技術的な基盤を共有しながら、独自の機能を継続的に開発しています。REALITYもその伝送セキュリティ機構の一つです。v2rayNGはXrayコアを使用しますが、個々の機能が使えるかどうかは、組み込みバージョンと設定の組み合わせによって異なります。「未対応の項目」などのエラーが出た場合は、クライアントの表示名だけでなく、実際に動作しているコアを確認してください。

コアとエコシステム

V2Fly

V2Rayコミュニティ / V2Fly Core

V2FlyはV2Ray関連のオープンソースプロジェクトを維持するコミュニティで、V2Fly Coreはプロキシ処理を担うコアです。v2flyNGはこのコアの系統に属し、Xrayを採用するv2rayNGとは異なるクライアントです。両者には技術的な関連がありますが、新機能、設定項目、設定ファイルをすべてそのまま相互利用できるわけではありません。

コアとエコシステム

クライアントとコア

画面の管理 / 接続処理

クライアントはサブスクリプション、サーバー一覧、設定を管理し、コアは実際の接続、ルーティング、DNSなどを処理します。クライアントに設定をインポートできても、コアがすべての項目を実行できるとは限りません。トラブル時はクライアントのバージョン、コアの種類、起動ログをあわせて確認してください。コアを切り替える前に設定をバックアップし、プロトコルと各項目の互換性を確認しましょう。

コアのエコシステムについて →

サブスクリプションとノード

サブスクリプションは設定情報の取得元、ノードはその中の接続設定、テスト結果は特定のテストで得られた情報です。それぞれを分けて考えると、更新失敗、設定ミス、接続タイムアウトの原因を特定しやすくなります。

サブスクリプションとノード

サブスクリプション

設定の取得・更新方法

サブスクリプションは通常、サーバー設定を取得・更新するためのリンクです。取得するデータの形式は提供元やクライアントによって異なります。更新に成功したという表示は、設定を取得または解析できたことを示すだけで、各ノードに接続できることを保証しません。リンクにアクセス情報が含まれる場合があるため、スクリーンショット、ログ、問い合わせ内容を共有する際は完全なURLを削除し、他人がアクセスできないようにしてください。

サブスクリプションとノード

ノード

サーバー接続設定

ノードはクライアント内のサーバー設定で、通常、プロトコル、アドレス、ポート、認証情報、伝送方式などが含まれます。リスト上の表示名はラベルにすぎず、名前だけで実際の場所、速度、接続可能性を判断することはできません。クライアントをインストールしただけではノードは利用できません。手動で追加する場合は、サービス提供元から必要な設定情報をすべて入手してください。

サブスクリプションとノード

サブスクリプショングループ

提供元や用途ごとに整理

サブスクリプショングループを使うと、提供元や用途の異なるサブスクリプションやサーバーを整理でき、個別に更新、絞り込み、確認しやすくなります。グループ分けはルーティングルールとは異なり、同じグループに入れたノードが同じ種類の通信を自動的に処理するわけではありません。一括更新の前に対象範囲を確認してください。サブスクリプション内のノードを手動で編集しても、次回の更新で上書きされる可能性があるため、別のコピーを保存しておきましょう。

サブスクリプションとノード

レイテンシと実接続レイテンシ

テスト方法 / リクエスト所要時間

レイテンシは特定のテストにかかった時間を示します。TCP接続テストと、プロキシ経由でWebページにアクセスするテストの結果は、直接比較できません。実接続レイテンシは通常、プロキシ経由で指定先にリクエストを送るため、接続先、DNS、ハンドシェイクの影響も受けます。数値が低くてもダウンロード速度が速いとは限らず、タイムアウト時は接続先とログも確認してください。

サブスクリプションの管理とグループ設定 →

ルーティングとDNS

ルーティングは通信の送信先を選び、DNSはドメインを名前解決します。両者は互いに影響するため、片方だけを変更してもう一方を確認しないと、ルールが適用されなかったり、想定外の経路で名前解決されたりすることがあります。

ルーティングとDNS

ルーティングルール

照合条件 / 送信先の選択

ルーティングルールは、ドメイン、IPアドレス、ポートなどの条件に基づき、通信を指定した送信先に振り分けます。通常は上から順に照合されるため、先にある大まかなルールが後続の詳細なルールより優先されることがあります。設定を確認する際は、条件だけでなく送信先の識別子とデフォルトの動作も確認してください。どのルールにも一致しないリクエストは、コアの設定に従って処理されます。

ルーティングとDNS

ルーティング

直接接続 / プロキシ / ブロック

ルーティングは、リクエストごとにポリシーに基づいて直接接続、プロキシ経由、ブロックなどの送信先を選ぶ処理です。特定のモード名を選べば自動的に実現するものではなく、ルールの適用結果です。動作を確認する際は、直接接続するはずの接続先とプロキシを通るはずの接続先をそれぞれ試し、実際の送信先を確認してください。コアが受け取った情報がドメインか、名前解決済みのIPアドレスかも確認しましょう。

ルーティングとDNS

GeoIP

IPアドレスの集合

GeoIPは地域や用途ごとに分類されたIPアドレスの集合で、ルーティングルールから参照できます。データは定期的に更新する必要があり、IPアドレスの分類がサービスの実際の設置場所と完全に一致するとは限りません。関連ルールを使う場合は、照合に必要なIPアドレスがリクエストから得られていることも確認してください。集合名を記述しただけで、ドメインが自動的にすべて名前解決されるわけではありません。

ルーティングとDNS

GeoSite

カテゴリ別ドメイン集合

GeoSiteはドメインをカテゴリ別に整理したデータで、ルーティングやDNSのルールでよく使われます。照合対象はIPアドレスであるGeoIPとは異なります。収録カテゴリ、対象範囲、更新頻度はデータの提供元によって異なります。カテゴリを参照する前に、データにそのカテゴリが存在し、使用中のコアが対応する形式を読み込めることを確認してください。

ルーティングとDNS

DNS

ドメイン名前解決システム

DNSはドメインをIPアドレスなどのレコードに変換しますが、問い合わせの経路は一つとは限りません。システム、ブラウザー、プロキシコアがそれぞれDNSリクエストを送る場合があります。クライアントのDNS設定を変更した後は、対象のアプリがその経路を使っているか確認してください。トラブル時は、名前解決の結果とDNSリクエストの送信先を個別に調べ、「名前解決できる」ことと「接続できる」ことを混同しないようにしましょう。

ルーティングとDNS

FakeDNS

合成アドレス / ドメインマッピング

FakeDNSはドメインを予約済みアドレス範囲の合成アドレスに割り当て、コアが対応する通信を受け取った後にドメイン情報を復元します。返されるアドレスはサーバーの実アドレスではないため、サービスの設置場所の判断には使えません。DNSの横取り、ルーティング、ドメイン情報の復元を連携させる必要があります。関連する経路が欠けていたり古いキャッシュが残っていたりすると、接続先に到達できないことがあります。

ルーティングとDNS

DNSリーク

想定と異なる名前解決経路

DNSリークとは、DNSリクエストが意図したポリシーどおりに送られず、別のリゾルバーや経路で処理されることです。リークに該当するかどうかは、あらかじめ設定したポリシーと照らし合わせて判断してください。ローカルのリゾルバーが結果に表示されたというだけでは、リークとは限りません。アプリ内蔵の暗号化DNS、システムの名前解決設定、TUNによる通信の取り込み範囲を確認しましょう。テストページに表示される情報は、そのテストで使われた名前解決経路だけを示します。

DNS設定と名前解決経路の解説 →

クライアント機能

このカテゴリでは、通信がどのようにクライアントへ取り込まれるかを説明します。システムプロキシ、アプリでの手動設定、TUNでは取り込む範囲が異なります。有効にする前に、対象アプリのネットワーク動作を確認してください。

クライアント機能

システムプロキシ

OSのプロキシ設定

システムプロキシは、ローカルのプロキシアドレスとポートをOSのプロキシ設定に登録し、その設定に従うアプリから利用できるようにします。独自のネットワーク設定を使うアプリもあるため、有効にしても必ずクライアントを経由するとは限りません。また、すべてのUDP通信を取り込む機能でもありません。クライアントを終了した後にWebページが開けなくなった場合は、システムプロキシが停止済みのローカルポートを指したままになっていないか確認してください。

クライアント機能

TUNモード

仮想ネットワークインターフェース / 通信の取り込み

TUNモードは仮想ネットワークインターフェースを通じて、対象の通信をプロキシ処理経路に送ります。通常は追加の権限が必要で、ルーティングやDNSの設定も関係します。システムプロキシに従わない一部のアプリも対象にできますが、範囲は実装、除外ルール、設定によって異なります。有効にした後に接続できなくなった場合は、権限、ほかの仮想ネットワークアダプターを使うツール、DNSの横取り設定を優先して確認し、複数のプロキシモードを重ねて有効にするのは避けてください。

クライアント機能

HTTPプロキシとSOCKSプロキシ

ローカルプロキシの受け入れ口

HTTPとSOCKSは、アプリからローカルプロキシの受け入れ口に接続する際によく使われる方式です。リモートノードでVMessやVLESSを使うこととは別の階層です。アプリには正しいプロキシの種類、アドレス、ポートを設定してください。ポート番号だけをコピーしても接続できません。CONNECTに対応するHTTPプロキシならHTTPSサイトにも接続できます。SOCKSでUDPを使うには、アプリとプロキシ経路の両方が対応している必要があります。

クライアント機能

トラフィックのスニッフィング

Sniffing / ドメイン識別

トラフィックのスニッフィングは、一部の接続のハンドシェイク情報からドメインなどのメタデータを識別し、コアのルーティング判定に役立てる機能です。HTTPSの本文を復号するものではなく、あらゆるアプリの接続先ドメインを識別できるわけでもありません。識別した情報を使って宛先アドレスを書き換えるかどうかは、コアの設定によります。互換性に問題がある場合は、すべてのスニッフィング項目を一度に有効にするのではなく、ログを確認してください。

クライアント機能

LANからの接続を許可

プロキシの共有 / 待ち受け範囲

LANからの接続を許可すると、同じネットワーク内の別の端末からローカルプロキシの受け入れ口に接続できます。ただし、他の端末のプロキシ設定が自動で変更されるわけではありません。共有する際は、待ち受けアドレス、プロキシのポート、ファイアウォールを確認し、別の端末にはパソコンのプライベートIPアドレスを設定してください。信頼できるネットワークだけにアクセスを制限し、待ち受けポートを公衆ネットワークに公開しないでください。共有を停止するときは、関連設定を元に戻してください。

v2rayNのTUNモード設定を見る →

用語を設定の確認に活かす

ノードをインポートできても接続できない場合は、まずプロトコル、伝送方式、セキュリティの設定を確認し、次にコアのログを確認してください。一部のアプリだけに問題がある場合は、システムプロキシやTUNが通信を取り込む範囲を確認しましょう。ドメインルールが適用されない場合は、DNSとルーティングの連携を確認してください。

初めて設定する場合は、使い方ガイドに沿ってインポートと接続確認を行ってください。項目ごとにトラブルを調べる場合は、ヘルプセンターを参照しましょう。複数の設定を一度に変更すると、どの変更が影響したのか判断しにくくなります。