V2Ray用語集：プロトコル・サブスクリプション・ルーティング・DNSを解説

PROTOCOL / TRANSPORT SECURITY

プロトコルと通信方式

プロキシプロトコルと通信のセキュリティ機構を区別し、サーバーから指定されたパラメーター一式を確認しましょう。

VMess

VMessはProject Vのエコシステムに属するプロキシプロトコルです。ユーザーIDを使って認証し、プロトコルに応じたデータのカプセル化を行います。特定の通信方式を指すものではなく、VMessと表示されていても通信パラメーターは異なる場合があります。認証に失敗する場合は、サーバーアドレスだけでなく、ユーザーID、システム時刻、サーバー側の要件も確認してください。

VLESS

VLESSは軽量なプロキシプロトコルで、独立したデータ暗号化層は備えていません。通常、TLSやREALITYなどの仕組みで接続を保護します。VLESSという名称だけで判断せず、通信方式、サーバー名、セキュリティ設定も確認してください。特定の組み合わせは対応するコアが必要です。共有リンクをインポートできても、使用中のコアで接続できるとは限りません。

Trojan

Trojanは通常、TLSで接続を保護し、パスワードでプロキシ認証を行います。サーバー名、証明書の検証、通信パラメーターをサーバー側の設定と一致させる必要があり、パスワードが正しくても接続できるとは限りません。証明書エラーが発生した場合は、システム時刻、サーバー名、サーバー証明書を確認してください。証明書の検証を無効にする方法を恒久的な対処にするのは避けましょう。

読む：詳細設定

REALITY

REALITYはXrayのエコシステムに属する通信のセキュリティ機構で、VMessやVLESSと並ぶ独立したプロキシプロトコルではありません。接続には、サーバーが指定する公開鍵、サーバー名、ショートIDなどのパラメーターを一致させる必要があります。具体的な項目は設定形式によって異なります。セキュリティ方式だけをREALITYに変更し、ほかのパラメーターをそのまま使っても、正しく設定できるとは限りません。

コアとエコシステム

プロジェクト名は技術の由来を示し、クライアント名は操作するためのアプリを示します。両者は同じものではありません。

Project V

Project Vは、V2Rayのモジュール型プロキシ体系を理解するうえでの背景となるプロジェクトです。基本的な考え方は、通信の受信、ルールの照合、通信の送信を個別に処理することです。この仕組みを利用するGUIクライアントは、サーバー管理やシステム連携の機能を提供します。技術資料を読む際は、プロジェクトの構成、コアの設定、クライアントの画面のどれを扱っているか確認しましょう。

Xray

XrayはV2Rayから派生し、その後、独自のプロトコルや通信機能を備えるようになりました。v2rayNGはXrayコアを使用しますが、クライアントの画面で設定できる機能は、コアの統合方法によっても異なります。コアを選ぶ際はサーバーが必要とする機能を基準にし、共通の歴史だけを理由にXrayとV2Flyの設定をそのまま使い回さないでください。

読む：クライアント比較

V2Fly / V2Ray

V2Fly

V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、v2flyNGはこの系列のコアを使用します。Xrayと共通の歴史を持ちますが、その後の機能、設定構文、対応範囲は異なる場合があります。独自設定を使う際は、資料が対象とするコアと設定のバージョンを確認してください。別のコア向けのサンプルを、そのまま動作する設定として扱わないようにしましょう。

比較：Xray

Core / GUI

コア

コアは、プロトコルネゴシエーション、プロキシ接続、ルーティング、関連するDNS処理を実行するプログラムコンポーネントです。GUIクライアントは設定の保存、コアの起動、ログの表示を担うため、画面が開いていてもコアが正常に動作しているとは限りません。起動に失敗した場合は、まずコアのログで設定項目のエラーやポートの競合を確認し、その後クライアント側の設定を見直しましょう。

読む：設定の階層

SUBSCRIPTION / SERVER PROFILE

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

インポートで作成されるのは設定の登録です。更新と接続確認は、その後に行う別の手順です。

Subscription

サブスクリプション

サブスクリプションは、クライアントが指定したURLから複数のサーバー設定を取得・更新する管理方法で、コア共通のトップレベル設定キーではありません。レスポンスはエンコードされたリンク一覧など、クライアントが対応する形式で届く場合があります。形式が合わないと解析に失敗します。サブスクリプションURLには認証情報が含まれる可能性があるため、機密情報として保管し、スクリーンショットや公開ログ、共有ドキュメントに載せないようにしてください。

読む：サブスクリプションのインポート手順

Node / Server Profile

ノード

ノードは、クライアントで使われるリモートプロキシ接続設定の一般的な呼び方です。通常、アドレス、ポート、認証情報、プロトコル、通信パラメーターが含まれます。ノード名は一覧で識別するためのもので、サーバーの実際の場所や性能を示すものではありません。名前が異なる項目でも同じサーバーを指す場合があるため、比較時は名称ではなく実際の接続設定を確認してください。

サブスクリプションの更新

サブスクリプションの更新では、URLに再度リクエストを送り、サーバー設定を解析・同期します。更新に成功しても、ノードの接続テストに合格したとは限りません。同期によってサブスクリプション項目の手動変更が上書きされる場合があるため、重要な変更は事前にバックアップするか、独立した設定として保存してください。更新に失敗した場合は、リクエストの失敗、レスポンスの異常、形式の非対応を切り分け、すべてのグループをむやみに削除しないようにしましょう。

読む：サブスクリプションの管理

MATCH / DISPATCH

ルーティングとトラフィック分割

ルールはマッチング条件を定め、アウトバウンドは通信の処理先を示します。ルールデータは再利用できるマッチング用の集合を提供します。

routing.rules

ルーティングルール

ルーティングルールは、ドメイン、宛先アドレス、ポート、インバウンドなどの条件に基づいてアウトバウンドを選択します。一般的な設定場所はrouting.rulesです。通常、ルールは順番に評価されるため、広い条件を先に置くと、後続の詳細なルールに一致しないことがあります。変更時は、指定したアウトバウンドのタグが存在することも確認し、ドメインの名前解決方式を踏まえて実際のマッチングを判断してください。

読む：ルーティングルールの実践

Traffic Policy

トラフィック分割

トラフィック分割は、通信の特徴に応じて直接接続、プロキシ、ブロックなどの経路を選ぶ方針で、通常はルーティングルールで実現します。すべての接続を同じリモートサーバーに送ることや、最速のサーバーを自動選択することとは異なります。期待どおりに動作するか確認するには、直接接続とプロキシ接続の両方の宛先を個別に確認し、ログで実際に使用されたアウトバウンドを調べてください。

GeoIP

GeoIPルールデータは、地域などの単位でIPアドレスを分類し、アドレスのマッチングに利用します。分類結果はデータの出典や更新時期によって異なるため、サーバーの物理的な所在地を正確に示す証拠にはなりません。ドメインルールやアドレスルールの動作は名前解決方式にも左右されるため、GeoIPの項目を追加するだけでは期待どおりに通信を振り分けられない場合があります。

GeoSite

GeoSiteは、サイトやカテゴリごとに整理されたドメインのマッチングデータです。各グループには複数の形式のドメインルールを含められます。マッチング対象はドメイン情報であり、サイトが最終的に接続するすべてのIPアドレスではありません。使用前に、現在のデータファイルに対象カテゴリが含まれていることを確認してください。マッチングが想定どおりでない場合は、クライアントがルーティングに必要なドメイン情報を保持または復元しているかも確認しましょう。

比較：GeoIP

RESOLUTION / NETWORK STACK

DNSとネットワークスタック

ドメインの名前解決とアプリの通信は、関連していても別の経路です。それぞれ個別に確認しましょう。

DNS / Resolver

DNS

DNSはドメインをアドレスなどのレコードに変換します。名前解決リクエストの経路は、その後のアプリ通信の経路とは異なる場合があります。OS、ブラウザー、クライアント、リモートサーバーが名前解決に関与することがあるため、DNSの設定を1か所変更しても、すべてのアプリに反映されるとは限りません。問題を調べる際は、まずリクエストの送信元と使用するリゾルバーを特定し、その後、想定した経路で処理されているか確認してください。

読む：DNS設定の最適化

FakeDNS / Mapping

FakeDNS

FakeDNSはドメインに仮想アドレスを割り当て、対応関係を保持します。その後、通信がプロキシの処理経路に入ると、対応関係を使って元のドメインを特定します。仮想アドレスは接続先サーバーの実アドレスではなく、DNSの制御や通信の入口との連携が必要です。関連モードを無効にした後もアプリに古い対応関係が残っている場合は、DNSキャッシュの削除やアプリの再起動後に確認してください。

DNSリーク

DNSリークとは、名前解決のリクエストが想定したDNS経路を通らず、別のリゾルバーに処理される状態です。判断する前に、まず想定するポリシーを明確にしてください。プロキシの接続表示だけでは、すべてのDNSリクエストが制御されているとは限りません。ブラウザー独自の暗号化DNSが別の経路を使う場合もあります。OSやアプリの設定、名前解決のログをあわせて確認し、単発のWebテストだけで判断しないようにしましょう。

比較：システムプロキシの適用範囲

TUN / Virtual Interface

TUNモード

TUNモードは、仮想ネットワークインターフェースでIPトラフィックを受け取り、クライアントのネットワークスタックに渡して処理します。システムプロキシを直接利用できないアプリにも適しています。実際に制御される範囲はルーティング、権限、除外設定、DNS設定によって異なり、すべての通信が必ずプロキシのアウトバウンドを通るわけではありません。有効にする前に、競合するほかの通信制御ツールを停止し、モードを無効にしてネットワークを復旧する手順を確認しておきましょう。

読む：v2rayNのTUNモード

CLIENT / CONNECTION TEST

クライアント機能

通信の制御方法、速度テストの結果、通信の入口はそれぞれ異なる工程を示します。1つの状態表示だけで全体を判断することはできません。

System Proxy

システムプロキシ

システムプロキシは、OSにプロキシのアドレスとポートを登録し、その設定に従うアプリで利用できるようにする機能です。すべての通信を自動的に制御するものではありません。アプリ独自のプロキシ設定を使うものもあれば、直接接続するものもあるため、個別に確認してください。クライアント終了後にWebページを開けない場合は、システムプロキシが停止済みのローカルポートを参照したままになっていないか確認しましょう。

関連：ローカルのインバウンドポート

Latency / Test Method

レイテンシ

レイテンシは、特定の宛先と条件でテストした際に記録される時間の指標で、ネットワークの往復、TCP接続の確立、アプリのリクエストにかかる時間などを測定します。テスト方法によって対象となる接続段階が異なるため、結果をそのまま比較することはできず、ダウンロード速度の指標にもなりません。サーバーを比較する際は、テスト方法、宛先、ネットワーク環境をそろえ、1回の最小値ではなく複数回の結果を確認してください。

比較：実接続レイテンシ

Real Connection Test

実接続レイテンシ

実接続レイテンシは一般に、選択したプロキシ経由でクライアントが実際にテストリクエストを送り、その所要時間を測定した値です。測定範囲はクライアントの実装やテスト先によって異なります。単にポートへ接続できるか確認する方法より多くの工程を測定できますが、あくまでその宛先への1回のリクエストを示すものです。テストに成功した後も、実際のアプリでルーティング、DNS、アクセス動作が期待どおりか確認してください。

読む：接続の確認方法

inbounds

インバウンド

インバウンドは、コアがアプリの通信を受け取る入口です。ローカルのSOCKSまたはHTTP待ち受けポートが一般的で、設定項目はinboundsです。クライアント端末でリクエストを受け取る方法を示すもので、リモートノードのサーバーポートではありません。端末内だけで使う場合は待ち受けアドレスを確認してください。ほかのネットワークインターフェースにも公開する場合は、アクセス制御と公開範囲を明確にする必要があります。

アウトバウンド

アウトバウンドは、コアが通信を次のホップや宛先へ送る方法を定義します。リモートプロキシ、直接接続、ブロックなどがあり、設定項目はoutboundsです。ルーティングルールは通常、outboundTagを使ってアウトバウンドを指定するため、タグを正確に一致させる必要があります。通信がコアに届いているのに想定どおり転送されない場合は、一致したルールとアウトバウンドの接続設定をあわせて確認してください。

読む：ルールとアウトバウンドの関連付け