V2Ray用語集

VMessはProject Vエコシステムで早くから使われてきたクライアントとサーバー間の通信プロトコルです。ノード設定には通常、サーバーアドレス、ポート、ユーザーID、トランスポート方式、安全性に関するオプションが含まれます。

設定をインポートする際は、各フィールドを元の内容どおり対応させ、アドレスとポートだけをコピーしないでください。ユーザーID、トランスポートパス、セキュリティ設定が一致しなければ、ネットワークに到達できてもプロトコル接続は完了しません。

VLESSは構成が比較的シンプルなプロキシプロトコルで、単体では追加のデータ暗号化を担いません。実際の設定では通常、TLS、REALITY、その他のトランスポートセキュリティ方式と組み合わせます。

VLESSノードを確認するときは、ユーザーID、フロー制御方式、トランスポート種別、セキュリティレイヤーのパラメータも確認します。プロトコル名が同じでも、2つのノード設定でフィールドをそのまま交換できるとは限りません。

TrojanはTLSで安全な通信経路を確立するプロキシプロトコルで、一般的な設定にはサーバードメイン、ポート、パスワード、サーバー名が含まれます。ここでいうパスワードはプロトコルの認証情報であり、サーバー側の設定と一致させる必要があります。

接続を切り分ける際は、パスワードだけでなく、システム時刻、ドメイン解決、TLS設定、SNIも確認します。サーバーポートにアクセスできることだけでは、完全なハンドシェイクが成功したとは判断できません。

REALITYはXrayエコシステムのトランスポートセキュリティ方式で、VLESSと組み合わせて使われることが多い機能です。クライアント設定には公開鍵、ショートID、サーバー名、フィンガープリントなどが含まれる場合があります。

これらのフィールドはサーバー側の設定で決まるため、インポート後に文字面だけを見て変更するべきではありません。公開鍵やショートIDが一致しないと、通常はセキュリティハンドシェイクの段階で接続に失敗します。

TLSはネットワーク接続の内容を保護し、通信相手の身元を確認する汎用的なセキュリティプロトコルです。V2RayクライアントのTLS設定は、証明書のドメイン、SNI、システム時刻、トランスポート方式とともに確認することが多い項目です。

証明書の検証には正しいシステム時刻とサーバー名が必要です。証明書の期限切れ、名前の不一致、ハンドシェイク失敗が表示された場合は、まずこれらの基本条件を確認し、いきなりプロトコル種別を変更しないでください。

サブスクリプションはサービス提供者が公開する設定一覧のURLです。クライアントが読み込むと、ノード名、プロトコルパラメータ、グループ情報が選択可能な設定リストへ変換されます。

サブスクリプションの追加と更新は別の操作です。初回追加ではURLを保存し、更新操作で内容を再取得します。更新後も一覧が変わらない場合は、まずクライアントの通知を確認し、その後URLがまだ有効か確認してください。

ノードはクライアント内の1つのサーバー接続設定で、通常はアドレス、ポート、プロトコル、認証情報、トランスポート方式、セキュリティパラメータを含みます。ノード名は識別用のラベルにすぎず、実際の接続判定には使われません。

ノードを選んだ後も、クライアントはコアを起動して該当するトラフィックを処理する必要があります。ノードが表示されるのに接続できない場合は、ローカルネットワーク、システム時刻、設定パラメータ、サーバー状態を分けて確認します。

遅延は、テスト用リクエストをローカルから送信して応答を受け取るまでの時間で、通常はミリ秒で表示されます。テスト対象、ネットワーク経路、サーバー負荷、ローカルの無線ネットワークが結果に影響します。

クライアントによって遅延テストの方法が異なるため、数値をそのまま横並びで比較するのは適切ではありません。遅延が小さいほど応答が速い傾向はありますが、ダウンロード速度が高いことや接続が常に安定していることを意味しません。

実接続遅延は、実際にプロキシ接続を確立してテスト対象へアクセスした際の応答時間です。プロトコルハンドシェイクとプロキシ経由のアウトバウンドを含むため、サーバーへの到達性だけを確認するテストより実際の接続過程に近い結果になります。

テスト失敗の原因は、ノードパラメータ、DNS、対象サイト、ローカルネットワークなどさまざまで、1つに限りません。連続してテストする前にログを確認し、プロトコルエラーを単なるネットワークの揺らぎと誤判定しないようにしましょう。

ノード速度テストは、遅延テスト、実接続テスト、通信テストなどでノードの現在の状態を比較する総称です。テストごとに注目する指標が異なり、簡易テストは初期選別に適していますが、実際の使用感は接続の継続性や対象サービスにも左右されます。

一括速度テストでは多くのネットワーク通信を同時に確立するため、結果がテスト順の影響を受けることもあります。まず候補を数本に絞り、その後に個別の接続検証を行うほうが確実です。

TUNモードは仮想ネットワークインターフェースでシステムのトラフィックを受け取り、プロキシコアがDNS、ルーティング、アウトバウンド処理を実行する方式です。システムプロキシ設定を参照しない一部のアプリにも適用でき、より多くの種類の接続を処理できます。

有効化には通常、ネットワーク関連の権限をシステムから許可する必要があり、他の仮想ネットワークツールとインターフェースやルートが競合することもあります。通信できなくなった場合は、まずTUNモードを終了し、システムのルーティングが復元したか確認してください。

FakeDNSはアプリに一時的なマッピングアドレスを返し、コアが受け取った後に元のドメインを復元します。これにより、その後のルーティングでもドメイン条件を使いやすくなり、早い段階でIPアドレスだけになるのを防げます。

一時アドレスは対応するマッピング環境内でのみ意味を持ち、対象サービスの実アドレスではありません。マッピング状態が失われたり、トラフィックがコアを迂回したりすると、ドメインを期待どおり復元できない場合があります。

DNSリークとは、アプリのドメイン問い合わせが想定したDNS経路を迂回し、別のリゾルバーで処理される現象です。アプリが独自の名前解決方式を指定している、システムに複数のネットワークインターフェースがある、一部のリクエストがプロキシコアに入っていない、といった原因が考えられます。

切り分けでは、まず実際に問い合わせを行っているプログラムを確認し、次にクライアントのDNS設定、システムのネットワーク設定、ルーティングモードを調べます。DNSアドレスを1つ変更するだけでは、すべてのアプリの問い合わせ経路が変わるとは限りません。

システムプロキシは、OSがアプリに提供するプロキシのアドレスとポート設定です。ブラウザーや一部のデスクトップアプリは自動的に従いますが、ネットワーク接続を独自に管理するアプリは無視することがあります。

システムプロキシを有効にしても、すべてのデバイス通信が自動的にクライアントへ入るわけではありません。システムプロキシを使わないプログラムまで対象にする必要がある場合は、TUNモードが適しているか検討してください。

インバウンドはプロキシコアが接続を受け付ける入口で、一般的な設定にはリッスンアドレス、ポート、接続プロトコルが含まれます。システムプロキシでは通常、アプリのリクエストがローカルのHTTPまたはSOCKSインバウンドへ送られます。

ローカルアドレスでリッスンする場合は、通常その端末だけが利用できます。LANからの接続を許可する場合は、リッスン範囲とシステムファイアウォールも同時に確認してください。インバウンドのポートが別のプログラムに使われていると、コアの起動に失敗します。

アウトバウンドは、プロキシコアがトラフィックを処理した後の出口です。プロキシサーバーへの接続、対象への直接アクセス、遮断を実行でき、各アウトバウンドには通常、ルーティングルールから参照する個別のラベルがあります。

ノード設定からは通常プロキシ用アウトバウンドが生成され、クライアントは直接接続用と遮断用のアウトバウンドも用意します。ルーティングを読む際は、ルール内のアウトバウンドラベルを実際の定義と照合すると、トラフィックの最終的な行き先が分かります。

DNSはドメイン名をネットワークアドレスへ変換する名前解決システムです。クライアントでは、問い合わせ先、ドメインマッチングルール、問い合わせ種別、リクエストに使うアウトバウンドを設定し、ルーティングと連携させられます。

接続問題の原因は必ずしもノードとは限らず、ドメインを解決できない場合もリクエストは失敗します。切り分けでは、解決結果が得られていないのか、アドレスは得られたものの後続の接続がタイムアウトしているのかを区別してください。

SNIはTLSハンドシェイクで接続先のサーバー名を示す情報です。1つのサーバーアドレスで複数のドメインサービスを提供している場合、サーバーはこの名前を基に適切な証明書と接続設定を選択します。

ノードパラメータのSNIは、サーバーアドレスの文字列と必ずしも同じではありませんが、サーバー側の設定に合っている必要があります。勝手に空欄にしたり置き換えたりすると、証明書名の不一致やハンドシェイク失敗につながることがあります。