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

VMessはProject Vエコシステムで使われるクライアントとサーバー間の通信プロトコルです。ノードには通常、ユーザーID、サーバーアドレス、ポート、暗号化関連の設定が含まれます。クライアントではVMessをTCPやWebSocketなどのトランスポートと組み合わせるため、プロトコル名だけの確認では設定は完了しません。読み込みに失敗した場合は、トランスポート種別、パス、サーバー名、ポートを続けて確認します。

VLESSは比較的シンプルな構造の通信プロトコルで、認証情報、暗号化チャネル、下位トランスポートは通常それぞれ別の設定項目で指定します。TLS、REALITY、TCP、WebSocket、gRPCと組み合わせて使われることが多くあります。クライアントのフロー制御、サーバー名、公開鍵、ショートIDは常に必須とは限らないため、実際のノード構成に従ってください。

Trojanはパスワードでクライアントを認証し、通常はTLSで接続を確立します。設定時はパスワード、サーバー名、ポート、証明書検証関連のオプションをまとめて確認します。プロトコル名が同じでも設定を流用できるとは限らず、トランスポート層の項目はサーバー側と一致させる必要があります。

REALITYはXrayコアがサポートするトランスポートセキュリティ方式で、VLESSと組み合わせて使われることが多くあります。クライアント設定では、公開鍵、ショートID、サーバー名、フィンガープリントなどの項目を使います。これらの値が連携して接続を確立します。現在のコアやクライアントが項目を認識しない場合は、項目を勝手に削除せず、まずコアの種類と設定形式を確認してください。

WebSocketはHTTPのアップグレード機構で双方向接続を確立し、クライアントではWSと略されることがあります。ノードではWSトランスポートに加えてパスやHostの入力が必要な場合があります。パスのスラッシュ、大文字・小文字、追加パラメータが接続結果に影響するため、手入力では一項目ずつ正確に転記してください。

gRPCはHTTP/2を基盤とするリモートプロシージャコールフレームワークで、VLESSなどの下位トランスポートとしても利用できます。クライアント設定ではサービス名や多重化関連のオプションがよく使われます。WebSocketとは接続モデルが異なるため、トランスポート名だけを変更して以前の項目をすべて残すことはできません。

TLSは通信の暗号化とサーバー認証を提供し、クライアントのサーバー名は通常、証明書の検証に使われます。ノードアドレスがIPの場合でも、証明書と一致するドメイン名を別途入力する必要があることがあります。証明書名の不一致やハンドシェイク失敗が起きたら、まずシステム時刻、サーバー名、ノードのセキュリティ層設定を確認してください。

サブスクリプションはサーバーから提供され、クライアントで定期的に更新できるノード設定の集合です。通常はサブスクリプションURLから読み込みます。URLを追加しただけでは取得元が登録されるだけで、サーバー一覧を得るにはクライアントで更新を実行する必要があります。更新に失敗した場合は、URLが完全か、ネットワークに到達できるか、サブスクリプショングループのフィルターが有効になっていないかを確認してください。

ノードはクライアント内の1件のサーバー接続設定で、アドレス、ポート、プロトコル、認証情報、トランスポート設定を含みます。ノード名は識別用であり、実際の接続性能を決めるものではありません。同名のノードが別のサブスクリプションに存在することもあるため、変更前に所属グループと全設定を確認してください。

サブスクリプショングループは、異なる取得元や用途のノードを分けて管理する機能です。グループごとに更新、有効化、絞り込みができます。複数のサブスクリプションを使う場合も、同名ノードによる混乱を減らせます。グループを削除すると、その取得元から生成されたノードも削除されることが多いため、手動設定を残すか事前に確認してください。

サーバーフィルターは、ノード名のキーワード、正規表現、その他の条件で一覧を整理します。包含条件は一致する項目を残し、除外条件は不要な項目を非表示にします。サブスクリプション更新後に一覧が空になった場合は、まずフィルターを一時的に無効にし、元のサブスクリプションがノードを返しているか確認してください。

遅延は、クライアントからデータを送信して応答を受け取るまでの時間です。ただし、テスト対象と方法によって数値の意味は変わります。TCPハンドシェイク、ICMP応答、完全なプロキシリクエストは、それぞれ異なる段階を測定します。ノード選択では接続成功率、対象サービスの応答、継続利用時の安定性も考慮してください。

実接続遅延は、実際にプロキシ接続を確立してテスト対象へリクエストを送り、利用可能性と応答時間を確認します。サーバーポートを探るだけの測定に比べ、プロトコルのハンドシェイク、トランスポートセキュリティ層、プロキシリクエストなど多くの段階を含みます。テスト失敗だけでサーバー停止と判断せず、DNS、ルーティング、コアのログも確認してください。

システムプロキシは、クライアントがOSのプロキシ設定を変更し、その設定に従うアプリの通信をローカルプロキシポートへ送る仕組みです。すべてのプロセスを自動的に取り込むわけではなく、独自のネットワーク設定を使うアプリや直接接続するアプリもあります。クライアントを終了する前にシステムプロキシを元に戻すと、ローカルの待受停止後もアプリが無効なポートを参照し続ける事態を防げます。

TUNモードは仮想ネットワークインターフェースでシステム通信を取り込み、システムプロキシを参照しないアプリにも適用できます。ルーティングテーブル、DNS、仮想ネットワークアダプターを扱うため、システムプロキシより多くのシステム設定が関係します。有効化に失敗した場合は、権限、仮想ネットワークアダプターの状態、通信を二重に取り込むプログラムがないかを確認してください。

FakeDNSはアプリにマッピングされたアドレスを返し、同時にコア側でそのアドレスと元のドメインの対応関係を保持します。通信がコアに入るとドメインを復元し、ドメインルーティングルールを続けて適用できます。TUNモードと併用されることが多く、アドレスプールとDNSの処理手順を統一して設計し、既存のLANセグメントとの衝突を避ける必要があります。

DNSはドメインをIPアドレスへ変換する基礎ネットワークサービスです。クライアントではドメインごとにDNSサーバーや問い合わせ方法を指定できます。名前解決がシステム、アプリ、プロキシコアのどの層で行われるかによって、ドメインルーティングの有効性が変わります。DNSを変更する際は元の設定を記録し、名前解決とノード接続を分けてテストしてください。

DNSリークは、DNS問い合わせが想定した経路やルールで処理されず、別の名前解決経路へ送信される現象です。アプリ独自の名前解決、DNSを取り込まないシステムプロキシ、不完全なTUNルール、先に応答する予備DNSなどが原因になります。調査では、各ドメインを誰が解決する設計かを明確にし、システム、クライアント、コアの設定を順に確認してください。

LAN共有を有効にすると、同じLAN上の他のデバイスからクライアントが開放したローカルプロキシポートへ接続できます。有効化後は待受アドレス、ポート、ファイアウォール、デバイス間のネットワーク到達性を確認してください。管理下のネットワークだけで公開し、各デバイスには正しいホストアドレスとプロキシ種別を設定します。

実行ログには、コアの起動、設定の読み込み、DNS問い合わせ、ルーティング照合、接続確立、エラー情報が記録されます。読むときは最初に現れたエラーを探し、時系列と照らして名前解決、ハンドシェイク、対象への接続のどの段階で起きたかを判断します。ログレベルを上げると詳細を確認できますが、調査後は通常のレベルに戻すと不要な出力を減らせます。