V2Ray 用語集

GUIクライアントは、サブスクリプションのインポート、ノードの選択、プロキシモードの変更、動作状況の確認を行う操作画面です。通常は設定を生成してプロキシコアを起動しますが、基盤となる接続実装そのものではありません。トラブル対処では、クライアント設定とコアの正常動作を分けて確認します。

プロキシコアは設定を読み込み、プロトコルのハンドシェイク、名前解決、ルーティング判断、接続転送を実行します。GUIクライアントで別のコアを選べる場合、利用できる機能はコアの能力に左右されます。コアのエラーが出たときは、システムプロキシの切り替えだけでなく、プロトコルパラメータと設定構文を確認してください。

v2rayN はWindows、macOS、Linux向けのGUIクライアントで、サブスクリプション、ノード、ルーティング、ローカルプロキシ設定を管理します。互換性のあるプロキシコアを呼び出して接続を実行できます。クライアントの「システムプロキシ」と「TUN」はアプリの接続方式であり、ノードのプロトコル名ではありません。

Xray はプロキシコアの一系統で、v2rayN、v2rayNG などの互換クライアントから利用できます。プロトコル、トランスポート、安全性、ルーティングの設定を実行し、クライアントは操作画面を提供します。選定時は、必要なプロトコルと機能を現在のコアがサポートしているか確認してください。

V2Fly は Project V エコシステムに属するコミュニティプロジェクトおよびコア実装の一つです。v2flyNG などのクライアント名に含まれる V2Fly は、通常そのコアの方向性を示しますが、クライアント自体は設定管理ツールです。設定をインポートする前に、サーバー側パラメータが選択したコアの対応範囲に合うか確認してください。

VMess は認証情報と接続パラメータを含むプロキシプロトコルです。通常、ユーザー識別子、アドレス、ポート、トランスポート関連の項目を一致させる必要があります。プロトコル名だけを変更しても、互換性のないパラメータ一式を別のプロトコル設定へ変換することはできません。

VLESS は認証とトランスポート層の役割を分けたプロキシプロトコルで、TLS、REALITY、各種トランスポート方式と組み合わせて使われます。VLESS自体は暗号化トランスポートを意味せず、アプリのローカルプロキシへの接続方法も決めません。接続時はユーザー識別子、フロー制御、安全性、トランスポートのパラメータを併せて確認します。

Trojan は通常TLSと組み合わせ、パスワードで認証します。ドメイン、ポート、パスワード、SNI、証明書関連の設定をサーバー側と一致させる必要があります。システムプロキシの有効化は一部アプリがローカル入口を使うかどうかを決めるだけで、プロトコルパラメータの不一致は解消しません。

REALITY は Xray エコシステムの接続セキュリティ機構で、公開鍵、ショートID、サーバー名、クライアントフィンガープリントなどを設定します。独立したGUIクライアントでも、システムプロキシモードでもありません。項目が欠けていたり対応していなかったりすると、通常は接続確立段階で失敗します。

トランスポート方式はプロキシプロトコルのデータを運ぶ接続形式で、TCP、WebSocket、HTTP/2、gRPCなどがあります。方式によってパス、サービス名、リクエストヘッダーなどの追加項目が必要です。クライアントとサーバーは互換性のある設定を使う必要があり、ポート番号だけを比較してはいけません。

サブスクリプションはサーバーから提供され、1つ以上のノード設定を含む更新可能なURLです。クライアントが取得すると内容を解析し、ローカルの設定一覧へ書き込みます。サブスクリプション自体はプロキシコアではなく、ブラウザーや端末が自動的にプロキシを使うかどうかを決めるものでもありません。

ノードはクライアントに保存されたサーバー接続設定で、通常はアドレス、ポート、プロトコル、認証、安全性、トランスポートのパラメータを含みます。ノードを選ぶことは、コアが試行する設定一式を指定するだけです。アプリはシステムプロキシ、手動プロキシ、TUNなどを通じて接続する必要があります。

サブスクリプション更新は、クライアントが内容を再取得してローカルのノード一覧を更新する操作です。失敗した場合は、URLにアクセスできない、認証が無効、返却形式が異常、ローカルネットワークに問題がある、といった原因を切り分けます。更新成功は一覧を取得できたことを示すだけで、すべてのノードが接続できるとは限りません。

遅延は特定の測定方法で得られる応答時間で、テスト対象、名前解決、ネットワーク経路、当時の負荷に左右されます。クライアントや測定方法が異なる結果を単純比較することはできません。低い測定値だけで実際の接続状態を判断することもできません。

実接続遅延は通常、実際にプロキシ接続を確立し、指定した対象へアクセスして測定した時間を指します。単純な疎通確認よりもプロトコルとハンドシェイクの過程を多く含むため、現在のプロキシ経路に近い状態を示します。失敗時はコアのエラーも確認し、ノードパラメータ、DNS、TLSのどの段階に問題があるか判断します。

システムプロキシは、OSが対応アプリにプロキシのアドレスとポートを通知する接続方式です。一般的なブラウザーは読み取りますが、一部の端末プログラム、独自ネットワークスタック、プロキシを自前で管理するアプリは無視する場合があります。ブラウザーは使えるのに端末から使えない場合は、両者のプロキシ取得元を分けて確認します。

ローカルリスニングは、プロキシコアがローカルアドレスとポートでアプリからの接続を待ち受ける入口です。HTTP、SOCKS、混合リスナーなどがあり、システムプロキシやアプリのプロキシ設定は通常ここを参照します。リスニングポートを変更した場合、古いポートを手動設定しているすべてのアプリを更新する必要があります。

アプリのプロキシ設定は、ブラウザー、ダウンロードツール、開発ツール、その他のプログラム内でプロキシのアドレスとポートを個別に指定するものです。システムプロキシを上書きしたり、現在のアプリだけに適用されたりします。確認時はプロキシ種別とローカルリスナー種別が一致するか、古いポートを参照していないかを確認します。

TUN モードは仮想ネットワークインターフェースでシステム通信を受け取り、システムプロキシを参照しないアプリにも適用できる場合があります。正しいルーティング、DNS、権限設定が必要で、他の仮想ネットワークインターフェースと競合することもあります。TUNはアプリの接続要件に応じて有効化し、あらゆる接続問題の万能な修復策と考えないでください。

HTTP_PROXY、HTTPS_PROXY、ALL_PROXY などの環境変数は、端末プログラムでよく使われるプロキシ入口の設定です。変数は読み取るプロセスにだけ影響し、新しい設定は通常、新しい端末セッションで有効になります。HTTPとSOCKSのリスナーを区別し、クライアントで現在使われているポートを指定してください。

ルーティングルールは、ドメイン、アドレス、ポート、プロトコル、プロセスなどの条件に基づいて出口を選びます。処理対象はすでにプロキシコアへ入った通信であり、システムプロキシを読み取らないアプリを自動的に接続することはできません。複数のルールがある場合は、マッチング順序とデフォルト出口にも注意が必要です。

経路分岐は、異なる対象やアプリに異なる出口を使わせる設定方針です。ドメイン、アドレス、プロセスなどで分類できますが、対象の通信がクライアントまたはコアへ到達していることが前提です。想定どおりに分岐しない場合は、まず接続範囲を確認し、次にルールのマッチング状況を調べます。

GeoIP はアドレス範囲と地域分類のデータを使い、ルーティングのマッチングを補助するリソースです。データファイルに基づいて判断するもので、現在の接続をリアルタイムに測位するものではありません。アドレスの帰属変更やデータバージョンの違いで結果が変わるため、ドメインルールとアドレスルールを組み合わせて確認します。

GeoSite は用途やカテゴリ別に整理したドメイン集合のルールリソースで、ドメインの一括マッチングに使います。ドメイン分類を示すもので、GeoIPのアドレス範囲分類とは異なります。ルールに一致しない場合は、コアがドメイン情報を保持しているか、使用中のデータに対象ドメインが含まれるかを確認します。

DNSはドメインを接続可能なアドレスへ解決します。プロキシ設定では、システム、クライアント、指定リゾルバーのどれが問い合わせを処理するか、またドメインごとにどの解決経路を使うかを決められます。DNSが結果を返してもプロキシプロトコルの接続成功を意味しないため、段階を分けて確認します。

FakeDNS はアプリに予約済み範囲のマッピングアドレスを返し、プロキシコンポーネントが元のドメイン名を復元します。透過接続でドメイン情報を保持し、後続のドメインルーティングを正しく行うために使われます。有効化時は、アドレスプール、ルーティング、DNS処理の流れを連携させる必要があります。

DNSリークは、ドメインの問い合わせが想定した解決経路を通らず、別のネットワークインターフェースやリゾルバーから送信される現象です。アプリが独自DNSを使っていないか、TUNが問い合わせを引き受けているか、システムに他のネットワークコンポーネントが存在しないかを確認します。ノードを交換するだけでなく、問い合わせが実際に通った経路を特定することが重要です。

TLSは接続の暗号化とサーバー認証を提供します。ハンドシェイクを完了するには、クライアントとサーバーが互換性のあるパラメータを使い、証明書、ドメイン、有効期間の検証を通過する必要があります。TLS接続に失敗した場合、システムプロキシの有効化やルーティングルールの変更だけではなく、ハンドシェイクパラメータを確認してください。

SNIはTLSハンドシェイクで接続先サーバー名を示す情報です。通常、設定値をサーバー側の想定および証明書が対象とするドメインと一致させます。アドレスに到達できてもハンドシェイクに失敗する場合、SNIは個別に確認すべき項目です。

証明書チェーンは、サイト証明書から信頼された認証局までの検証関係を示します。チェーンの欠落、証明書の期限切れ、ドメイン不一致はいずれもTLSハンドシェイク失敗の原因になります。日常のトラブル対処では、証明書またはドメイン設定を修正し、証明書検証を恒久的に無効化しないでください。

システム時刻は、証明書が有効期間内にあるかを端末が判断する重要な基準で、一部の接続セキュリティ機構にも影響します。時刻やタイムゾーンが大きくずれていると、正しい証明書でも未発行または期限切れと判定されることがあります。複数のノードで同時に証明書エラーが出た場合は、自動時刻合わせの状態を確認してください。