V2Ray用語解説・設定用語集
プロトコル、コア、クライアント設定、サブスクリプション、ノード、ルーティングルールで使われる概念をまとめて解説します。各用語は実際の設定場面に対応しており、チュートリアルの読解やクライアント項目の確認時にすぐ検索できます。
接続プロトコルとトランスポートセキュリティ
プロトコル、セキュリティ層、トランスポート方式は異なる設定層です。ノードをインポートする際は各層の項目を正しく対応させ、プロトコル名だけで他の設定を判断しないでください。
-
プロトコルと暗号化
- VMess
-
VMessはProject Vエコシステムで使われるノード間通信プロトコルで、クライアントの認証情報、時刻検証、データ転送を担います。一般的な設定にはサーバーアドレス、ポート、ユーザー識別子、追加識別子などが含まれます。VMessはTCPやWebSocketなどのトランスポート方式と組み合わせる必要があり、プロトコル名だけでは接続設定全体を表しません。
-
プロトコルと暗号化
- VLESS
-
VLESSは軽量なプロトコルで、プロトコル層が担う暗号処理を抑え、通常はTLSまたはREALITYに通信の安全性を委ねます。設定ではユーザー識別子、サーバーアドレス、ポート、トランスポート項目を入力します。フロー制御やセキュリティ層はサーバー側の設定で決まるため、クライアントの項目を一致させる必要があります。
-
プロトコルと暗号化
- Trojan
-
TrojanはTLSで安全な接続を確立するプロキシプロトコルで、認証情報は通常パスワードとして設定します。クライアントではアドレスとポートに加え、サーバー名、トランスポート方式、証明書関連の項目を正しく設定する必要があります。共有リンクをインポートした後は、サーバー名が完全に保持されているか確認してください。
-
プロトコルと暗号化
- REALITY
-
REALITYはXrayエコシステムのトランスポートセキュリティ方式で、VLESSと組み合わせて使われることが多い機能です。クライアントでは公開鍵、ショートID、サーバー名、フィンガープリントなどを設定します。独立したノードプロトコルではないため、クライアントではプロトコル一覧ではなく、トランスポートセキュリティ設定に配置されることが一般的です。
-
プロトコルと暗号化
- TLS
-
TLSは汎用的なトランスポート層セキュリティプロトコルで、接続を暗号化し、サーバーの身元を検証します。V2RayクライアントのTLS設定には通常、サーバー名、許可するアプリケーション層プロトコル、証明書検証ポリシーが含まれます。サーバー名を誤ると、アドレスとポートが正しくても安全なハンドシェイクで接続に失敗することがあります。
-
プロトコルと暗号化
- トランスポート方式
-
トランスポート方式はプロトコルデータを運ぶ接続形式で、TCP、WebSocket、gRPC、HTTPUpgradeなどが一般的です。VMessやVLESSの下位層に位置しますが、パス、ホスト名、サービス名などの追加項目に直接影響します。クライアントで選んだ方式はサーバーの待受設定と一致させる必要があります。
Project V、V2Fly、Xray
GUIクライアントは設定のインポート、編集、呼び出しを担い、コアはローカルポートの待受、接続確立、DNS、ルーティングルールの実行を担います。両者のバージョンや対応範囲は完全には一致しません。
-
コアとエコシステム
- Project V
-
Project Vはネットワークプロキシプロトコル、設定構造、実行コアを中心に形成されたオープンソース技術エコシステムです。一般にV2Rayと呼ばれるものは、設定体系、コアプログラム、または関連エコシステム全体を指す場合があります。文書を読む際は文脈から意味を判断し、クライアント名とコア名を混同しないようにしてください。
-
コアとエコシステム
- V2Fly
-
V2FlyはProject Vの技術体系を受け継ぐコミュニティ主導のプロジェクトで、コア実装は通常v2fly-coreと呼ばれます。v2flyNGはこのコア系列を使ってAndroid上の接続とルーティングを処理します。利用できる設定機能はコアの対応範囲で決まり、クライアント画面の見た目だけでは判断できません。
-
コアとエコシステム
- Xray
-
XrayはV2Rayの設定体系と高い互換性を持つコア実装で、VLESS、REALITYなどの機能を拡張しています。v2rayNやv2rayNGでは、一般的な設定の実行にXrayコアが使われます。クライアントの更新とコアの更新は別のもので、バージョンの表示場所も分かれる場合があります。
-
コアとエコシステム
- インバウンド(Inbound)
-
インバウンドはコアが通信を受け取る入口で、設定ファイルの
inboundsに対応します。ローカルのSOCKS、HTTPプロキシポート、TUNインターフェースはいずれもインバウンドとして利用できます。インバウンドはコアへ入る通信を決めますが、最終的にどの出口から送信するかは直接決定しません。
-
コアとエコシステム
- アウトバウンド(Outbound)
-
アウトバウンドはコアが通信を処理して送信する出口で、設定ファイルの
outboundsに対応します。一般的な種類にはプロキシ、直結、ブロックがあります。ルーティングモジュールがルールに基づきアウトバウンドを選ぶため、ノードに接続できてもすべての通信が自動的にそのノードへ送られるわけではありません。
通信の取り込み、DNS、接続テスト
クライアントのスイッチは主に、通信をどのようにコアへ取り込むか、ドメインをどのように解決するかを制御します。システムプロキシとTUNでは適用範囲が異なり、レイテンシテストも測定方法と合わせて確認する必要があります。
-
クライアント機能
- システムプロキシ
-
システムプロキシは、OSのプロキシアドレスをクライアントのローカル待受ポートへ向ける機能です。ブラウザーやシステムプロキシ設定を参照するアプリの通信は、クライアントで処理されます。独自のネットワークスタックを使うアプリやシステム設定を無視するアプリには、システムプロキシだけでは適用できない場合があります。
-
クライアント機能
- TUNモード
-
TUNモードは仮想ネットワークインターフェースでシステム通信を受け取り、システムプロキシ設定を参照しないアプリにも適用できます。通常はネットワークインターフェースに関する権限が必要で、DNSとルーティング設定との併用も求められます。LANアクセスに問題がある場合は、LANバイパスルールと仮想インターフェースのルートを確認してください。
-
クライアント機能
- FakeDNS
-
FakeDNSはアプリにマッピングアドレスを返し、同時にコア内でドメインとマッピングアドレスの関係を保持します。後続の接続がコアに入ると元のドメインを復元し、ドメインルールによる振り分けを続行できます。主にTUN環境でのドメイン識別を改善する機能で、一般的なパブリックDNSサービスとは異なります。
-
クライアント機能
- DNSリーク
-
DNSリークとは、本来指定したDNS経路で処理すべき問い合わせが、システムリゾルバーや別のネットワークインターフェースから直接送信される状態です。解決元の位置が想定と異なったり、ドメインルールが正しく振り分けに使われなかったりする場合があります。確認時はクライアントDNS、システムDNS、ブラウザーのセキュアDNS、TUNの取り込み範囲を同時に調べてください。
-
クライアント機能
- 実接続レイテンシ
-
実接続レイテンシは、実際にプロトコル接続を確立するかテスト対象へアクセスしてノードの利用可否を判断し、完了までの時間を記録します。サーバーポートだけを調べるより実際の接続経路に近い一方、テスト対象、ネットワーク状態、プロトコルのハンドシェイク手順の影響を受けます。1回の結果だけで長期的な安定性を判断することはできません。
ノードの入手元、更新、テスト結果
サブスクリプションは更新可能なノード一覧で、共有リンクは通常1つのノードだけを記述します。インポート成功、サブスクリプション更新成功、ノード接続成功は、それぞれ個別に確認すべき状態です。
-
サブスクリプションとノード
- サブスクリプション
-
サブスクリプションはサーバーが提供するノード一覧のURLで、クライアントは複数の設定を読み込めます。URL自体は通常そのまま接続できるノードではなく、先に更新またはインポートを実行する必要があります。保存後は設定した周期で一覧を再取得できますが、ローカルのメモやグループの扱いはクライアントの実装によって異なります。
-
サブスクリプションとノード
- ノード
-
ノードはサーバー接続に必要な設定一式で、通常はアドレス、ポート、プロトコル、認証情報、セキュリティ層、トランスポート方式を含みます。クライアント一覧の各項目は通常1つのノード設定に対応します。ノード名は識別用のメモにすぎず、実際のパラメータや利用可否の確認に代わるものではありません。
-
サブスクリプションとノード
- サブスクリプション更新
-
サブスクリプション更新は、クライアントがURLへ再アクセスしてノード一覧を同期する操作です。更新後は、新しいノードの追加、パラメータや名前の変更、古い項目の削除が発生する場合があります。一覧に変化がないときは、URL全体、ネットワーク要求の成否、正しいサブスクリプショングループが更新されたかを確認してください。
-
サブスクリプションとノード
- レイテンシ
-
レイテンシはテスト開始から応答を受け取るまでの時間で、通常はミリ秒単位で表示されます。クライアントによってポート接続、プロトコルハンドシェイク、対象へのリクエストなど測定方法が異なるため、結果を単純に比較することはできません。低レイテンシでも、その時の測定時間が短いことを示すだけで、帯域幅、継続的な安定性、すべての宛先への通信品質を保証するものではありません。
照合条件、ルールデータ、実行順序
ルーティングモジュールはノード設定を作成するのではなく、各通信にどのアウトバウンドを使うか判断します。ルール条件、DNSの結果、並び順が最終的な照合結果に影響します。
-
ルーティングと振り分け
- ルーティングルール
-
ルーティングルールはドメイン、IP、ポート、プロトコル、プロセスなどの条件に基づき、通信をどのアウトバウンドへ渡すか判断します。各ルールは通常、照合条件と対象アウトバウンドで構成されます。ルールが処理できるのはコアに入った通信だけなので、システムプロキシやTUNが正しく取り込んでいることが前提です。
-
ルーティングと振り分け
- ルーティング振り分け
-
ルーティング振り分けは、異なる宛先やアプリの通信をプロキシ、直結、ブロックなどのアウトバウンドへ配分する設定方法です。ドメインカテゴリ、IPの地域、ポート、プロセス名などがよく使われます。明確な対象を先に指定し、最後に分かりやすいデフォルトルールを残すのが基本です。
-
ルーティングと振り分け
- GeoIP
-
GeoIPはIPアドレスの地域やカテゴリ別に整理されたルールデータで、解決済みの宛先IPとの照合に使います。IPだけを条件にできる通信に適しており、ドメインルールの補助にもなります。データファイルをコアやクライアントとともに更新しないと、新しく割り当てられたアドレス帯を想定どおり分類できない場合があります。
-
ルーティングと振り分け
- GeoSite
-
GeoSiteは用途やカテゴリ別に整理されたドメインルールデータで、ルーティングモジュールが宛先ドメインをグループ照合するために使います。保存されているのはドメイン集合であり、IPアドレスデータベースではありません。コアが元のドメインを認識できず解決後のIPしか見ていない場合、一部のGeoSiteルールは照合できないことがあります。
-
ルーティングと振り分け
- ルールの優先順位
-
多くのV2Rayルーティング設定はルール一覧を上から順に確認し、最初に一致したルールが使用するアウトバウンドを決めます。範囲の広いルールを前に置くと、後続の詳細なルールが適用されない場合があります。順序を調整するときは、プロセスや完全一致ドメインなど明確な条件を先に置き、その後に広いカテゴリやデフォルト条件を配置してください。