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

VMessはProject Vエコシステムでクライアントとサーバー間の通信に使われるプロトコルで、認証、時刻検証、データ転送の仕組みを備えています。設定の読み込みには通常、サーバーアドレス、ポート、ユーザーID、トランスポート方式、安全性に関するパラメータが必要です。

システム時刻のずれが大きい、ユーザーIDが一致しない、トランスポート層の設定が合わないといった原因で、接続の確立に失敗することがあります。VMessが定義するのは接続設定の一部であり、TLSやWebSocketなどの外側のオプションは別途確認が必要です。

VLESSは比較的シンプルな構造の接続プロトコルで、通信内容の追加暗号化は自身では行わず、通常はTLSやREALITYなどの外側の機構に安全性を委ねます。一般的な設定フィールドには、ユーザーID、トランスポート種別、フロー制御、サーバー名が含まれます。

VLESSとVMessではフィールド構造が異なるため、プロトコル名を変更するだけでは変換できません。調査時は、認証情報、外側のセキュリティ方式、トランスポートパラメータを個別に確認します。

Trojanはパスワードで接続認証を行い、通常はTLSで通信チャネルを確立します。クライアント設定では、サーバーアドレス、ポート、パスワード、サーバー名、証明書関連のオプションを確認します。

パスワードが正しくても接続できるとは限らず、ドメイン、ポート、TLSパラメータもサーバー側と一致させる必要があります。ハンドシェイクエラーが発生した場合は、クライアントログの証明書名と接続段階のメッセージを優先して確認します。

REALITYはXrayエコシステムのトランスポートセキュリティ実装で、VLESSと組み合わせて使われることが多い方式です。設定には通常、公開鍵、ショートID、サーバー名、フィンガープリント、フロー制御などのフィールドが含まれます。

これらのフィールドはそれぞれ役割が異なり、通常のTLS設定でそのまま代用することはできません。ノードの読み込み後に接続できない場合は、公開鍵、ショートID、サーバー名を一つずつ照合し、クライアントの自動補完値が元の設定と異なっていないか確認します。

Project Vは、ネットワークプロキシのコア、プロトコル、ツールを中心に形成されたオープンソース技術エコシステムを指します。V2Rayの設定モデルには、インバウンド、アウトバウンド、ルーティング、DNS、トランスポートなどのモジュールが含まれ、後続の複数のコアやクライアントがその概念を受け継いでいます。

Project Vは特定のGUIクライアントの名称ではありません。ドキュメントを読む際は、エコシステム名、コア名、クライアント名を区別し、画面上の機能をプロトコル自体の能力と混同しないようにします。

V2FlyはV2Rayの技術路線を受け継ぐ、コミュニティ運営のコアおよび関連プロジェクト群です。一部のクライアントはV2Flyコアで設定を解析し、接続を確立してルーティングルールを実行します。

同じ基本設定でも、コアのバージョンによって対応フィールドが異なる場合があります。クライアントを更新した後に古い設定で問題が起きた場合は、現在使用中のコアと対応する設定構文を先に確認します。

XrayはV2Rayの設定体系と高い互換性を持つコアファミリーで、VMess、VLESS、Trojan、REALITYなどのプロトコルまたはセキュリティ機構に対応します。v2rayNとv2rayNGはXrayコアを使って接続を処理できます。

互換性があっても、すべてのフィールドが完全に同じとは限りません。フロー制御、トランスポートセキュリティ、実験的機能に関わる場合は、使用中のコアが認識できる設定構造に従ってください。

v2ray-coreは実際のネットワーク処理を担うコアプログラムで、設定を解析し、インバウンドとアウトバウンドを作成し、DNS問い合わせとルーティングルールの照合を行います。GUIクライアントは通常、起動パラメータや設定ファイルを通じてコアの動作を制御します。

画面が正常に開くことは、クライアントプロセスが動作できることを示すだけで、コアの起動成功を意味しません。接続障害の調査では、クライアントの状態、コアのログ、ローカル待受ポートを同時に確認する必要があります。

サブスクリプションはサーバーが提供する設定一式のURLで、クライアントはそこからノード一覧を取得できます。更新時、クライアントはリモートの内容を取得し、対応する形式として解析してローカル設定に変換します。

サブスクリプションの更新成功は、URLにアクセスでき、内容を読み取れたことだけを示します。一覧内のすべてのノードが接続可能とは限りません。更新に失敗した場合は、URLの完全性、システム時刻、ネットワーク経路、クライアントログを確認します。

ノードはクライアント内の1件の接続設定で、サーバーアドレス、ポート、プロトコル、認証情報、トランスポートパラメータ、表示名を記録します。ノードを選択すると、コアはこれらのフィールドに基づいて対応するアウトバウンドを確立します。

ノード名は管理しやすくするためのラベルにすぎず、プロトコルの種類や回線品質を直接示すものではありません。設定をコピーする際は完全なフィールドを保持し、名前とサーバーアドレスだけをコピーしないでください。

遅延はデータがローカルから宛先へ到達し、戻ってくるまでの時間を示し、通常はミリ秒で記録されます。クライアントの遅延テストにはポート探査、基本的なネットワーク要求、プロキシ経由の要求などがあり、方式の異なる結果をそのまま比較することはできません。

低遅延だからといって、必ずしもダウンロード速度が速いとは限りません。帯域幅、パケットロス、サーバー負荷、接続先の応答が実際の体感に影響します。ノードは接続成功率と実際のアクセス結果も含めて選びます。

実接続遅延は通常、クライアントが選択したノード経由で実際のプロキシ接続を確立し、指定した宛先へリクエストを送って応答時間を記録した値を指します。プロトコルのハンドシェイク、トランスポートの確立、宛先の応答など、より多くの段階を反映します。

テスト結果はテスト先、ネットワークの揺らぎ、キャッシュ状態にも左右されるため、同じ時間帯での相対比較に向いています。1回のタイムアウトだけで設定が無効と判断せず、ログと照らし合わせて再確認してください。

ルーティングルールは、ドメイン、IP、ポート、ネットワーク種別、プロトコル、プロセスなどの条件に基づいて、トラフィックに使用するアウトバウンドを決定します。一般的なアウトバウンドには直接接続、プロキシ、ブロックがあり、具体的な名称はクライアントや設定ファイルによって異なります。

ルールは通常、上から順に照合されます。先にある広い条件によって、後続のルールが機能しなくなることがあります。ルールを変更する際は、まずデフォルト出口を確認し、具体的な条件から一般的な条件の順に並べて一つずつテストします。

ルーティングとは、異なる宛先、アプリ、ネットワーク種別を異なるアウトバウンドへ割り当てる処理です。単独のプロトコルではなく、ルーティングルール、DNS解決、アウトバウンド設定が組み合わさった結果です。

一般的な振り分け条件には、ドメインカテゴリ、IPの地域、ポート、プロセス名があります。ルールが競合する場合は、実際に一致した条件を確認し、照合前にドメインがIPへ解決されていないか確認します。

GeoIPはIPアドレスの所在地域やネットワーク種別ごとに整理したデータセットで、ルーティングルールの照合条件として参照できます。宛先がすでにIPアドレスとして示されている接続の処理に適しています。

GeoIPデータはリアルタイム検索の結果ではなく、データベースのバージョンやアドレスの帰属変更によって分類が変わることがあります。振り分けに誤りがある場合は、データファイルが正しく読み込まれているか、ルールタグが存在するかを確認します。

GeoSiteはWebサイトのドメインカテゴリごとに整理したルールデータセットで、ドメイン単位のルーティング照合に利用できます。各カテゴリにはドメイン、サブドメイン、照合表現が含まれ、ルーティングルールからタグで参照します。

GeoSiteとGeoIPでは判定対象が異なります。前者はドメイン、後者はIPを処理します。アプリがIPへ直接接続する場合、GeoSiteルールだけでは一致しないことがあります。

v2rayNはWindows、macOS、Linux向けのGUIクライアントで、サブスクリプション、ノード、システムプロキシ、TUNモード、DNS、ルーティング設定を管理できます。一般的な設定操作を画面にまとめ、選択したコアを呼び出して実際の接続を処理します。

問題を調査するときは、画面上の設定、コアの起動、システムプロキシの状態を区別してください。クライアントでノードが選択されていても、アプリのトラフィックが対応するローカルプロキシ入口に入っているとは限りません。

TUNモードは仮想ネットワークインターフェースでシステムトラフィックを受け取り、ルーティングとDNS設定に従ってコアへ処理を委ねます。システムプロキシを読み取らない一部のプログラムもカバーでき、トラフィックを一元的に処理したい場面にも適しています。

TUNモードの有効化には通常、システム権限、仮想インターフェース、ルーティングテーブル、DNS設定が関わります。インターネットに接続できなくなった場合は、まずモードを無効にして基本ネットワークを復旧し、権限、インターフェースの競合、バイパスルールを確認します。

システムプロキシは、OSがアプリに提供するプロキシアドレスとポートの設定です。ブラウザや一部のデスクトッププログラムはこの設定に従い、クライアントが開いたHTTPまたはSOCKSの入口へリクエストを渡します。

すべてのプログラムがシステムプロキシを読み取るわけではないため、有効化しても直接接続するアプリが残る場合があります。動作を確認するには、システム設定、ローカルポート、対象プログラム自身のプロキシ設定を併せて確認します。

FakeDNSはアプリにマッピング用アドレスを返し、コア内にそのアドレスと元のドメインの対応関係を保持します。これにより、透過プロキシやTUN環境でも、コアはドメインに基づいてルーティングを判断できます。

FakeDNSはDNSインバウンド、アドレスプール、ルーティング設定と組み合わせて使用する必要があります。アドレスプールの競合、問い合わせがコアに入らないこと、マッピング情報の消失により、解決や接続に異常が生じる場合があります。

DNSはドメインをIPアドレスへ変換する基礎ネットワークサービスです。V2Rayコアでは、複数のDNSサーバー、問い合わせプロトコル、ドメインルール、アドレス選択方針を設定でき、解決結果をルーティング判断に利用します。

DNS問い合わせが成功しても、宛先への接続が成功するとは限りません。両者は異なる段階です。調査では、ドメインを解決できるか、結果が想定どおりか、接続にどのアウトバウンドが使われたかを個別に確認します。

DNSリークとは、指定したクライアント経路やDNSサーバーで処理されるはずのドメイン問い合わせが、実際には別の解決経路へ送られる状態です。アプリ独自のDNS、システムのフォールバック、ブラウザ独自設定、ルーティングの迂回などが一般的な原因です。

調査では、システムDNS、クライアントの待受入口、TUN設定、ブラウザ設定、ログに記録された問い合わせ先を同時に確認します。DNSアドレスを1つ変更するだけでは、すべてのアプリが同じ経路を使うとは限りません。

SOCKSは汎用プロキシインターフェースプロトコルで、アプリはTCPまたはUDP接続を指定したサーバーへ渡して処理できます。V2Rayクライアントは、手動プロキシ設定に対応するソフトウェア向けに、ローカルでSOCKSインバウンドを開くことがよくあります。

SOCKSアドレスは通常、ローカルのループバックアドレスと待受ポートを指定します。アプリのポート入力が誤っている、クライアントが起動していない、ポートが使用中といった場合、ノードのプロトコルへ到達する前に接続が失敗します。

ローカル待受ポートは、クライアントがローカルで開き、アプリからの接続を受け付けるポートです。SOCKSやHTTPプロキシのポートなどが該当します。システムプロキシ設定のポートは、クライアントが実際に待ち受けている値と一致させる必要があります。

他のプログラムがポートを使用していると、コアが該当するインバウンドを起動できない場合があります。起動ログを確認して未使用のポートへ変更し、そのポートを参照するすべてのアプリ設定も更新してください。