V2Ray設定用語インデックス

V2Ray用語集：プロトコル、コア、サブスクリプション、ルーティング

VMess、VLESS、REALITYから、サブスクリプション、ノード、TUNモード、GeoSite、実行ログまで、設定の流れに沿って主要用語を解説します。各項目では概念の境界、属する層、トラブルシューティングでの実用的な意味を説明し、v2rayN、v2rayNG、v2flyNGの画面とドキュメントを対応づけやすくしています。

6カテゴリ 28用語プロトコルと設定を並行して解説

READING GUIDE

まず用語が属する層を確認する

GUIクライアント、コア、プロトコル、トランスポート、サブスクリプション、ルーティングは同じ概念ではありません。接続に問題があるときは、設定のインポート、コアの起動、プロトコルのハンドシェイク、DNS名前解決、トラフィックの取り込みのどの段階で起きているかを先に切り分け、該当する用語を確認すると、設定を何度も変更するより原因を絞り込みやすくなります。

設定管理層

クライアント、サブスクリプション、ノード

GUIクライアントは設定を保存・整理し、サブスクリプションはノードを一括提供し、ノードは個別の接続設定を表します。一覧の更新に成功しただけでは設定データがクライアントに入ったことしか分からず、コアによる読み込みと実接続の確認が必要です。

接続実行層

コア、プロトコル、トランスポート

XrayまたはV2Flyのコアがクライアントの生成した設定を読み込み、VMess、VLESS、Trojanなどのプロトコルで接続を確立します。REALITY、TLS、その他のトランスポートパラメータは接続方式の一部であり、関連項目をまとめて一致させる必要があります。

トラフィック判断層

インバウンド、ルーティング、アウトバウンド

アプリの通信は、システムプロキシやTUNなどを通じてまずクライアントに入り、ルーティングルールが宛先を判定し、最後に直接接続、プロキシ、ブロックなどのアウトバウンドへ渡されます。どの層か一つでも想定どおりに動かなければ、最終的なアクセス結果に影響します。

PROTOCOLS

プロトコルと暗号化

プロトコルは、クライアントとサーバーが認証し、データを交換する方法を決めます。トランスポートのセキュリティ方式は、ハンドシェイクや外側の接続パラメータを補います。設定をインポートするときは関連項目全体を一つの方式として扱い、プロトコル名だけで設定の同一性を判断しないでください。

VMess: Project Vエコシステムにおけるクライアントとサーバー間の通信プロトコルです。通信する双方で、ユーザー識別子、トランスポート方式、ポート、セキュリティ関連のパラメータを一致させる必要があります。クライアントが共有情報を認識できても、すべてのパラメータが有効とは限らないため、利用前に接続テストを行います。

VLESS: 比較的シンプルな構造のプロトコルで、通常はTLS、REALITY、その他のトランスポート層設定と組み合わせて使用します。VLESS自体は完全な接続方式ではないため、調査時はアドレス、ポート、ユーザー識別子、トランスポート種別、外側のセキュリティ項目を併せて確認します。一部の項目だけを変更すると、元の組み合わせが崩れることがあります。

Trojan: パスワードを主な認証情報として使用するプロキシプロトコルで、TLSと組み合わせて設定することがよくあります。クライアントのサーバーアドレス、ポート、パスワード、サーバー名、トランスポートパラメータをサーバー側と一致させる必要があります。証明書名、時刻、認証情報が一致しない場合、接続確立の途中で終了することがあります。

REALITY: Xrayエコシステムのトランスポートセキュリティ方式で、VLESSと組み合わせて使われることが多い機能です。設定時はサーバー名、公開鍵、ショートID、フィンガープリントなどを確認する必要があり、アドレスとポートだけでは不十分です。共有リンクの解析が不完全だったり、クライアントのコアが古かったりすると、関連パラメータを正しく読み込めない場合があります。

CORE & CLIENT

コアとクライアント

クライアントはユーザーが操作する画面で、コアはネットワーク処理を実行するプログラムです。両者は別々に更新されることがあるため、画面のバージョン、コアのバージョン、設定形式を個別に確認する必要があります。すべての異常を一つの「クライアントバージョン」の問題として扱わないでください。

Xray: V2Rayエコシステムにおけるコア実装の一つです。設定の解析、接続の確立、ルーティング、DNS処理を担います。v2rayNやv2rayNGなどのGUIクライアントは、画面上の設定をコアが読み込める設定へ変換します。プロトコルを利用できるかどうかは、画面に項目があるかだけでなく、使用するコアが対応しているかにも左右されます。

V2Fly: コミュニティによって維持されているProject Vの後継プロジェクトおよびコアファミリーです。Xrayとは共通する技術的背景を持ちますが、対応プロトコル、機能実装、更新ペースは個別に確認する必要があります。v2flyNGは主にV2Flyコアの系統に対応しており、既存設定でこのコアが明確に指定されている場合に適しています。

GUIクライアント: サブスクリプション、ノード、ルーティング、システムプロキシを管理するデスクトップまたはモバイル向けの画面プログラムです。GUIクライアントは通常、すべてのネットワーク処理を直接行うのではなく、設定を生成してコアを呼び出します。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けで、画面名やメニュー位置には違いがあります。

コア: インバウンドの待ち受け、アウトバウンド接続、DNS問い合わせ、ルーティング判定を実際に実行する中核プログラムです。クライアントの画面とコアのバージョンは別の層にあります。画面が正常に開いても、設定エラーによってコアの起動に失敗することがあります。実行ログを確認すると、設定がコアに渡され受け付けられたかを判断できます。

SUBSCRIPTION

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

サブスクリプションは設定の一括配布と更新を担い、ノードは選択可能な個別の接続設定です。更新、選択、速度測定、接続は連続していますが別々の操作であり、ある段階が成功しても次の検証の代わりにはなりません。

サブスクリプション: 設定プロバイダーが公開するノード情報の集合です。クライアントはサブスクリプションURLから取得して更新します。更新によってローカルのノード一覧は変わりますが、現在選択中のノードが自動的に切り替わるとは限りません。更新前後でグループ名が同じでも、内部のノード内容が変わっていないとは判断できません。

ノード: クライアント内の1件のサーバー接続設定です。通常はアドレス、ポート、プロトコル、認証情報、トランスポートパラメータなどを含みます。一覧に表示されるのは設定が読み込まれたことを示すだけで、接続できるとは限りません。ノードを選択した後は対応するプロキシモードを起動し、実際のリクエストで通信経路を確認します。

サブスクリプショングループ: 複数のサブスクリプション元やノードを分類するためのクライアント内の管理単位です。設定元を整理し、更新、有効化、絞り込みを個別に実行できます。グループを削除すると、そのグループ内のローカルノードも削除されることが多いため、操作前にノードの取得元を確認してください。

サブスクリプションURL: クライアントがサブスクリプション内容を取得するためのアドレスです。インポート時は文字列全体を保持してください。途中で切れていたり、前後に空白が混入していたり、URLが無効だったりすると更新に失敗します。ブラウザーでは開けるのにクライアントの更新に失敗する場合は、クライアントの通信経路とログの具体的な応答も確認します。

ROUTING

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

ルーティングルールが処理するのは、「クライアントに入った通信をどこへ送るか」です。ルールの判定とトラフィックの取り込みは別の段階であり、アプリがクライアントに入っていなければ、どれだけ完全なルールを用意しても判定されません。

ルーティングルール: ドメイン、IP、ポート、プロトコル、プロセスなどの条件に基づいて、トラフィックの行き先を決める判定ルールです。通常は上から順に評価されるため、広すぎるルールを先に置くと、後続の具体的な条件が適用されないことがあります。ルールを変更したら設定を再読み込みし、ログでどのアウトバウンドに一致したか確認します。

トラフィック分岐: リクエストごとに、直接接続、プロキシ、ブロックなどのアウトバウンド方式を振り分ける設定方法です。結果はルールの順序、ドメインの名前解決結果、アプリの通信がクライアントに取り込まれているかどうかで決まります。特定サイトへの経路に問題がある場合は、設定全体を書き換える前に一致したルールを特定します。

GeoIP: IPアドレスの地理的所属地域に基づいて判定するデータ集合です。すでに取得されたIPに対して適用されるため、判定精度はデータベースのバージョンやアドレスの所属変更に左右されます。ドメインでリクエストを行う場合は、DNSの名前解決結果も後続のGeoIP判定に影響します。

GeoSite: ドメインのカテゴリ別に整理されたルールデータの集合で、ルーティングルールによるサイトドメインの一括判定に利用できます。GeoSiteはドメインルールを扱うもので、IPに基づいて判定するGeoIPとは区別してください。コアが元のドメインを取得できない場合、ドメインベースの判定が想定どおりに動かないことがあります。

インバウンド: コアがローカルアプリからの接続を受け取る側です。たとえばローカルのSOCKS、HTTP待ち受けポート、TUNインターフェースなどが該当します。アプリが適切なインバウンドに入って初めて、その後のルーティングとアウトバウンドルールが適用されます。調査時はログでリクエストが指定した待ち受けポートに到達しているか確認できます。

アウトバウンド: コアが処理したトラフィックを送信する方式です。直接接続、選択したノード経由の転送、ブロックなどが一般的です。ルーティングルールは、条件に一致したリクエストを最終的にいずれかのアウトバウンドへ渡します。アウトバウンド名は設定上の識別子にすぎず、実際の接続方式は内部で参照するノードや動作によって決まります。

NETWORK

ネットワークの基礎

システムプロキシ、TUN、DNSは、アプリのリクエストをクライアントへ取り込み、十分な宛先情報を維持する役割を担います。相互に関連しますが役割は異なるため、プロキシが有効か確認するときは、通信の入口、名前解決、最終アウトバウンドを分けて観察します。

TUNモード: 仮想ネットワークインターフェースを通じて、より多くのアプリ通信を取り込む動作モードです。システムプロキシを参照しないアプリに適していますが、有効化後は権限、ルーティングテーブル、DNS、他のネットワークツールとの競合にも注意が必要です。クライアントを終了する前に関連設定を元へ戻すと、システムのネットワーク状態が残って判断を妨げる事態を減らせます。

システムプロキシ: OSがアプリに提供するプロキシ設定です。ブラウザーなどは通常この設定に従いますが、一部のコマンドラインプログラムや独自のネットワークスタックを持つアプリでは個別設定が必要になる場合があります。クライアントにシステムプロキシが有効と表示されても、待ち受けポートが正常に起動していることを確認してください。

FakeDNS: ドメインに予約範囲のマッピングアドレスを返し、その後コアが元のドメインを復元してルーティングするDNS処理方式です。ドメイン情報を維持しやすくなりますが、TUN、DNS、ルーティングの設定を連携させる必要があります。マッピングアドレスは対象サーバーの実アドレスではないため、接続先の所属を直接判断する用途には使えません。

DNSリーク: アプリのドメイン問い合わせが、想定したDNS経路に入らず、別のリゾルバーで処理される現象です。調査時は、システムDNS、ブラウザーのセキュアDNS、TUNの取り込み範囲、クライアントのルールを同時に確認します。ノードを変更するだけでは、名前解決経路の設定不一致は通常解決しません。

遅延: ローカル端末から対象への1回の疎通確認に要する時間で、通常はミリ秒で表示します。測定方法によって対象となる区間が異なるため、単純なネットワーク測定だけではプロトコル接続や実際のリクエスト性能を完全には評価できません。遅延が小さくても、スループット、安定性、対象への到達性が優れているとは限りません。

実接続遅延: ノードのプロトコルで実際に接続を確立し、対象へのリクエストを完了するまでにかかった時間です。単なる到達性の確認よりクライアントの利用経路に近い指標ですが、ローカルネットワーク、測定対象、その時点の経路状態にも左右されます。ノード選択時の参考にし、実際のアクセス結果でも確認してください。

LOGS

ログとトラブルシューティング

ログに現れる単独の英単語は、結果だけを示して原因まで特定できないことがよくあります。前後数行を残して読み、対象アドレス、アウトバウンド名、発生時刻、直前に変更した設定項目も併せて記録してください。

ログレベル: コアが記録する情報の詳しさを制御する設定です。一般的なレベルでは情報、警告、エラーなどを区別します。トラブルシューティング時は一時的に詳細度を上げ、DNS、ルーティング、接続の過程を確認します。原因を特定したら通常のレベルに戻し、細部が本当に重要なエラーを埋もれさせないようにします。

timeout: 接続またはリクエストが、指定された時間内に完了しなかったことを示します。サーバーに到達できない、ポートが遮断されている、DNSに異常がある、トランスポートパラメータが一致しない、対象の応答が遅いなどの原因が考えられます。timeoutの前に記録された処理段階から、名前解決、接続確立、応答読み取りのどこで時間切れになったかを判断します。

rejected: クライアントのルール、リモートサービス、または接続先によって接続が明確に拒否されたことを示します。原因を判断するには、その前後のアウトバウンド名、対象アドレス、より具体的なエラー内容を併せて確認します。ブロックルールへの一致も同時に表示される場合は、プロトコルパラメータを変更する前にルーティングを確認してください。

invalid user: 通常、認証情報がサーバー側で受け付けられなかったことを示します。ユーザー識別子、パスワード、時刻設定、関連プロトコルの項目を確認してください。システムプロキシのモードを繰り返し切り替えるだけでは解決しません。サブスクリプション更新後も古いノードを手動で残していると、変更前の認証情報が使われ続ける場合があります。

NEXT STEP

用語を実際の設定手順に結びつける

用語を確認したら、「サブスクリプションをインポート—ノードを選択—システムプロキシまたはTUNを設定—ルーティングを確認—接続を検証—ログを確認」の順で設定します。概念と操作を対応づけることが重要です。サブスクリプションの問題は更新ログ、取り込みの問題はシステムプロキシまたはTUN、宛先が想定と異なる場合はルーティングとDNSを確認します。

設定ガイドを見る完全なドキュメントを読む