設定用語クイックリファレンス

V2Ray用語集：プロトコル・コア・ルーティング・DNS

VMess、VLESS、REALITYから、サブスクリプション、ルーティングルール、システムプロキシ、FakeDNSまで、設定場面に沿ってよく使われる用語を解説します。各項目では概念の範囲と、v2rayN、v2rayNGの設定における実際の位置づけも説明します。

Protocols & Security

プロトコルと暗号化

プロトコルはクライアントとサーバーが認証し、データを交換する方法を定めます。トランスポートのセキュリティ層は、接続の暗号化やサーバー認証などを担当します。ノードをインポートする際は、各フィールドをサーバー設定と一致させる必要があり、名称だけを見て置き換えることはできません。

VMess: VMessは、Project Vエコシステムで早くから使われてきたクライアント・サーバー間通信プロトコルです。ユーザー識別子と時刻情報で認証します。ノードでは通常、TCP、WebSocket、gRPCなどのトランスポート方式を指定し、TLSを重ねることもできます。システム時刻のずれが大きいと認証に失敗する可能性があるため、接続トラブルではまず端末の時刻を確認してください。

VLESS: VLESSは比較的シンプルな認証構造を採用し、トランスポート層の暗号化は担いません。TLSまたはREALITYと組み合わせて使うことが一般的です。設定には通常、ユーザー識別子、フロー制御、トランスポート方式、セキュリティ種別が含まれます。VMessとはフィールド構成が異なるため、プロトコル名を変更しても別のプロトコルへ自動変換されるわけではありません。

Trojan: TrojanはTLS接続を基盤とし、パスワードで認証するプロトコルです。クライアント設定には通常、サーバーアドレス、ポート、パスワード、サーバー名、証明書検証に関する項目が含まれます。システム時刻、SNI、証明書チェーンに問題があると、認証リクエストを送る前にTLSハンドシェイクが失敗して接続が中断することがあります。

REALITY: REALITYはXrayが提供するトランスポートセキュリティ方式で、VLESSと組み合わせて使われることが多い機能です。クライアント側では公開鍵、サーバー名、短いID、クライアントフィンガープリントなどの指定が必要になる場合があります。これらの値はサーバー側と一致させてください。REALITYは単独のノードプロトコルではなく、画面上では通常、プロトコル選択欄ではなくトランスポートセキュリティ設定にあります。

TLS: TLSはネットワーク接続を保護する汎用的な暗号化プロトコルで、暗号化通信路を確立し、サーバーの身元を検証します。ノード設定のサーバー名、証明書のドメイン名、システム時刻が検証に関わります。証明書エラーが出た場合は、証明書検証を無効にする前に時刻とSNIを確認してください。

Cores & Clients

コアとクライアント

GUIクライアントはサブスクリプション管理、パラメータ編集、状態表示を担当し、コアは設定の解析、接続の確立、ルーティングの実行を担当します。この2層を区別すると、問題が画面設定、生成された設定、コアの実行段階のどこにあるか判断しやすくなります。

Xray: XrayはV2Ray技術エコシステムにおけるコア実装の一つで、VMess、VLESS、Trojan、REALITYのほか、多様なルーティング機能とDNS機能に対応します。v2rayNとv2rayNGの一般的な設定からもXrayを呼び出せます。画面に「Coreタイプ Xray」と表示される場合、現在の接続設定がXrayによって解析・実行されることを意味します。

V2Fly: V2FlyはProject Vの技術体系を受け継ぐコミュニティ製コア実装で、プロキシプロトコル、トランスポート層、DNS、ルーティングに対応します。Xrayとは共通の技術的ルーツを持ちますが、対応プロトコルの範囲や一部の設定項目は完全には一致しません。コアを選ぶ前に、必要な機能が使用するバージョンでサポートされているか確認してください。

v2rayN: v2rayNはWindows、macOS、Linux向けのGUIクライアントで、サブスクリプション、ノード、システムプロキシ、TUN、ルーティングルールを管理できます。画面上の選択項目を、コアが読み取れる設定へまとめ、コアプロセスの起動・停止も行います。クライアントの接続成功はプロセスが動作していることを示すだけで、目的の通信ができるかはログとルーティング結果も確認する必要があります。

v2rayNG: v2rayNGはAndroid向けのGUIクライアントで、通常はXrayコアを使ってノードとルーティング設定を実行します。接続時はシステムが提供するVPNサービスインターフェースを通じてアプリの通信を受け取りますが、これはノードプロトコル自体が変わるという意味ではありません。省電力設定、バックグラウンド制限、権限の状態が継続的な接続に影響することがあります。

Core（コア）: Coreは、クライアントが実際に呼び出すネットワークコアを指します。GUIはパラメータを収集し、コアはローカルポートの待ち受け、アウトバウンド接続の確立、DNS解析、ルーティングルールの適用を担当します。クラッシュや起動失敗を調べる際は、画面の短い状態表示よりも、コアのログに詳しい原因が記録されていることが多くあります。

Subscriptions & Nodes

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

サブスクリプションは更新可能なノード一覧で、ノードは具体的な接続パラメータの一式です。遅延結果は特定のテスト条件における応答状況を示すだけで、プロトコルの互換性、帯域幅、長時間接続の安定性を単独で判断するものではありません。

サブスクリプション: サブスクリプションは通常、更新可能なURLとして提供され、クライアントがアクセスするとノード一覧や設定内容を取得します。更新時にはリモートデータを再取得するため、ローカルに表示されるノード名、パラメータ、並び順が変わる場合があります。インポートに成功したのに一覧が空の場合は、URLが完全か、システム時刻が正しいか、更新ログに解析エラーがないか確認してください。

ノード: ノードはクライアントが接続するサーバー設定の一式で、通常はプロトコル、アドレス、ポート、認証情報、トランスポート方式、セキュリティ設定を含みます。ノード名は識別用のラベルにすぎず、接続認証には使われません。同じ名前でも、アドレス、プロトコル、ルーティング結果がまったく異なる場合があります。

サブスクリプショングループ: サブスクリプショングループは異なる提供元を区別し、関連するノードを同じ管理単位にまとめるために使います。クライアントではグループごとにノードを更新、絞り込み、確認できるため、複数の提供元が1つの一覧に混在するのを防げます。グループを削除すると、その提供元に属するローカルノードにも影響することがあるため、操作前に対象範囲を確認してください。

遅延テスト: 遅延テストは、現在のネットワーク条件におけるノードの応答速度を推定するものです。ただし、テスト方法によって測定対象の段階は異なります。ポートのみのテストで分かるのは通常、サーバーポートへ到達できるかどうかであり、プロキシプロトコルの認証完了を証明するものではありません。結果はローカルネットワーク、DNS、接続先、同時実行タスクの影響も受けます。

実接続遅延: 実接続遅延では、ノードを介して実際にプロキシ接続を確立し、テスト先へアクセスして応答時間を記録します。単純なTCPポートテストより完全な通信経路に近く、プロトコルパラメータやTLS設定の誤りも見つけやすくなります。ただし、1回の結果はその時点のサンプルにすぎないため、複数回のテストと実際の接続状況を合わせて判断してください。

Routing

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

ルーティングシステムは、ドメイン、IP、ポート、プロトコルなどの条件に基づいてアウトバウンドを選択します。条件を正しく記述するだけでなく、ルールの順序にも注意が必要です。複数のルールが同じリクエストに一致する場合、通常は先にある有効なルールが処理方法を決めます。

ルーティングルール: ルーティングルールは、「条件」と「対象アウトバウンド」の対応関係です。ドメイン、IP、ポート、ネットワーク種別、プロセスなどの情報でトラフィックを判定できます。ルールに一致すると、コアはリクエストを指定されたプロキシ、直接接続、ブロックのアウトバウンドへ渡します。順序が不適切だと、広い条件が後の細かな条件を先に上書きすることがあります。

トラフィック分岐: トラフィック分岐は、異なるネットワークリクエストを別々のアウトバウンドへ振り分ける設定方式です。たとえば、あるドメイン群は直接接続し、別のリクエストは現在のノード経由にできます。分岐結果は、コアがドメインや解析後のIPを取得できるか、ルールの優先順位がどうなっているかに左右されるため、DNS設定と密接に関係します。

GeoIP: GeoIPは、IPアドレスの地理情報やネットワークカテゴリに基づいて整理されたデータ集合で、ルーティングルールから分類を参照できます。判定対象は解析後または接続先のIPであり、ドメイン文字列そのものではありません。定期的に更新しないと、新しく割り当てられたアドレス範囲や変更された範囲を想定どおり分類できない場合があります。

GeoSite: GeoSiteは、用途やカテゴリ別に整理されたドメインルールの集合で、関連するドメイン群をまとめて参照するのに適しています。GeoIPとは判定対象が異なり、GeoSiteはドメイン、GeoIPはIPアドレスを処理します。利用時はルールセット名が存在することを確認し、クライアント内蔵データとカスタムデータの提供元の違いにも注意してください。

アウトバウンド（Outbound）: アウトバウンドは、コアが処理したトラフィックの送信先を表します。現在のノード経由で接続するもの、システムネットワークから直接接続するもの、条件に一致するリクエストをブロックするものなどがあります。ルーティングルールは最終的に有効なアウトバウンドのタグを参照する必要があり、タグ名が一致しないと正しく関連付けられません。

Network & DNS

ネットワークとDNS

システムプロキシとTUNはクライアントがアプリの通信を受け取る方法を決め、DNSはドメインをアドレスへ変換し、トラフィック分岐に関わります。接続に問題がある場合は、「アプリの通信がクライアントに入っているか」「ドメインがどう解析されているか」「最終的にどのアウトバウンドへ送られたか」を分けて確認してください。

システムプロキシ: システムプロキシは、OSがプロキシ対応アプリへローカルプロキシのアドレスとポートを通知する方式です。有効にすると、ブラウザーなどシステム設定に従うプログラムがv2rayNへリクエストを渡しますが、独自にネットワーク接続を管理するアプリはこの設定を参照しないことがあります。モードを切り替えた後も古い接続が以前の経路を使い続ける場合があるため、必要に応じて接続を再確立してください。

TUNモード: TUNモードは仮想ネットワークインターフェースでシステム通信を受け取り、システムプロキシを参照しないアプリにも適用できます。通常はルーティングテーブル、DNSの制御、システム権限に関わるため、一般的なシステムプロキシより設定項目が多くなります。有効化後に通信できない場合は、仮想インターフェース、ルーティングルール、DNS設定、他のネットワークツールとの競合を順に確認してください。

FakeDNS: FakeDNSは、まずドメインに予約アドレスを返し、通信がコアに入った後で元のドメインを復元してルーティング判定に使います。これにより、アプリがシステム側で実際の名前解決を先に行う状況を減らし、ドメイン情報を使った分岐を維持できます。実IPによる検証、特殊なUDP動作、解析結果の直接記録に依存するアプリには適さない場合があります。

DNSリーク: DNSリークは、名前解決のリクエストが想定した経路で処理されず、別のリゾルバーへ到達する現象です。アプリがDNSを独自指定している、ブラウザーが独立した暗号化DNSを有効にしている、TUNの制御が不完全、ルーティングルールが不足しているなどが主な原因です。判断時はリゾルバー、問い合わせ経路、最終接続先のアウトバウンドを同時に確認し、単一の表示結果だけで判断しないでください。

SNI: SNIは、TLSハンドシェイクで接続先サーバー名を示すフィールドです。クライアントのノード設定ではserverNameまたはサーバー名として表示されることがあります。通常は証明書やサーバー設定と一致させる必要があり、ノードのアドレスをそのまま入力すればよいとは限りません。誤入力すると証明書名の不一致、ハンドシェイク拒否、接続タイムアウトが発生する可能性があります。

Mux: Muxは、少数の基盤接続上で複数の論理リクエストを処理する多重化方式です。接続を何度も確立する負荷を減らせる可能性がありますが、どのネットワーク環境でも高速になるわけではありません。有効化するかどうかは、プロトコルの対応状況、サーバー設定、長時間接続の安定性、実際のアプリの種類を踏まえて検証してください。