設定の参考に · よく使う25の用語
V2Ray用語集
プロトコル・コア・プロキシ設定
用語を整理してから設定を変更しましょう。クライアントで見かける項目から解説を探せます。接続できない場合は、トラブル対処ガイドで問題の発生箇所を確認してください。
VMess / VLESS
Xray / V2Fly
TUN / DNS
プロトコルと通信方式
プロトコルは認証とデータ交換の方法、通信方式はデータを運ぶ経路、安全層は接続を保護します。設定をインポートする際は、それぞれの項目を個別に確認してください。
- VMess
- V2Rayエコシステムで使われるプロキシプロトコルです。ユーザーIDなどのパラメーターで認証し、プロトコル層でデータを保護します。設定には通常、リモートアドレス、ポート、通信方式、安全層も含まれます。ユーザーIDが正しいだけでは接続できません。VMess共有リンクをインポートした後は、元の設定値を維持してください。認証エラーが起きた場合は、端末の時刻も確認しましょう。
- VLESS
- 軽量なプロキシプロトコルで、単体では通信を暗号化しません。実際の運用では通常、TLSやREALITYなどのセキュリティ機構を組み合わせます。ユーザーID、通信方式、flowなどの項目はサーバー側の指定に合わせる必要があり、別の設定からそのまま流用することはできません。VLESSと表示されていても、プロトコル名だけで互換性を判断せず、安全層と通信方式の設定も確認してください。
- Trojan
- 通常はTLS接続上で動作し、パスワードで認証するプロキシプロトコルです。接続には正しいパスワードだけでなく、サーバー名、証明書の検証、通信方式の一致も必要です。証明書エラーが発生した場合は、まずサーバー名と端末の時刻を確認してください。証明書の検証を無効にすると接続時の信頼条件が変わるため、通常の対処方法としては推奨されません。
- REALITY
- Xrayがサポートする通信のセキュリティ機構で、VMessやVLESSと並ぶ独立したプロキシプロトコルではありません。クライアントでは公開鍵、サーバー名、shortId、フィンガープリントなどを設定する必要があります。具体的な組み合わせはサーバー側の指定によって異なります。インポート後にハンドシェイクに失敗する場合は、これらの項目とコアの対応状況を確認してください。ローカル待ち受けポートの変更だけでは解決しません。
- 通信方式
- プロキシプロトコルのデータを運ぶ通信経路です。生のTCP、WebSocket、gRPCなどがあり、画面上の名称はコアやバージョンによって異なる場合があります。パス、Host、サービス名は各通信方式の接続パラメーターであり、自由に変更できるメモではありません。通信方式は速度のランクではありません。まずサーバー側の設定に合わせ、実際のリクエストで動作を確認してください。
コアとエコシステム
GUIは操作を担当し、プロキシコアは処理を実行します。機能が使えるか確認する際は、クライアントとコアの両方の対応状況を確認してください。
- Project V
- ネットワーク通信ツールを中心とするプロジェクト群で、V2Rayはその中核プロジェクトです。一般に「V2Rayクライアント」と呼ばれるものは、関連するプロトコルやコアに対応したGUIツールを指すことが多く、同じソフトウェアパッケージとは限りません。この関係を理解すると、画面、コア、リモートサーバーの設定がそれぞれどこに影響するかを区別しやすくなります。
- V2Fly
- V2Rayコアを保守し、コア機能や関連する設定への対応を発展させるコミュニティプロジェクトです。v2flyNGは、V2Flyコアを使用するAndroid向けGUIクライアントです。プロトコル名が似ていても、拡張項目がすべて共通とは限りません。設定に互換性がない場合は、クライアント名だけを比べず、使用中のコアのバージョンで対応状況を確認してください。
- Xray
- V2Rayの技術基盤から派生したプロキシコアプロジェクトで、複数のプロトコル、通信方式、セキュリティ機構に対応しています。v2rayNGはこのコアを使用します。XrayとV2Flyには共通する概念もありますが、拡張機能や設定の詳細は異なります。あるコアで有効な設定が別のコアでも使えるとは限らないため、特に安全層やflowの設定を確認してください。
- クライアントとコア
- v2rayNなどのクライアントは、サブスクリプション管理、サーバー選択、設定画面を提供します。コアは待ち受け、接続、ルーティング、通信の転送を担当します。画面が開いているのはGUIが動作していることを示すだけで、コアの起動成功を意味しません。すべての接続に失敗する場合は、コアの起動ログとポートの待ち受け状態を確認してから、リモートサーバーとローカル設定のどちらを調べるか判断してください。
- インバウンドとアウトバウンド
- インバウンドはローカルアプリや仮想ネットワークインターフェースからの通信を受け取り、アウトバウンドはその通信の送信方法を表します。1つの設定に複数のインバウンドとアウトバウンドを定義し、ルーティングルールで適切な送信先を選べます。ルール内の
outboundTagはアウトバウンドのタグを指定する項目で、設定内に実際に定義されたタグと一致させる必要があります。サーバーの別名や任意の説明文ではありません。
クライアント機能
プロキシの入口でクライアントに取り込む通信を決め、ルーティングで取り込んだ後の処理を決めます。モードを有効にしても、すべてのアプリが同じ経路を通るとは限りません。
- システムプロキシ
- OSがアプリに提供するプロキシアドレスの設定で、通常はクライアントがローカルで待ち受けるアドレスとポートを指定します。この設定を利用するアプリだけがプロキシを使い、独自のネットワーク設定を持つアプリは別の経路を使う場合があります。v2rayNでシステムプロキシを設定した後は、コアが動作していることも確認してください。「システムプロキシを自動設定」はOSの設定操作を指し、ノードの自動選択ではありません。
- TUNモード
- 仮想ネットワークインターフェースを通じてIP層の通信を受け取る動作モードです。プロキシを直接設定できないアプリや、システムプロキシに従わないアプリにも適しています。通常は適切な権限が必要で、ルーティング、DNS、ループバックの除外設定も正しく構成する必要があります。TUNで広がるのは通信を取り込む範囲であり、すべての通信が自動的にプロキシ経由になるわけではありません。他の仮想ネットワークソフトウェアと併用する場合は、ルートの競合も確認してください。
- ローカル待ち受けポート
- クライアントがローカルでアプリからの接続を受け付けるポートです。アプリには対応するプロキシの種類とポート番号を設定してください。解説記事などでよく見かける
10808は、実際の設定と照合が必要な値です。使用するポートは現在のクライアント設定で確認してください。ポートが使用中だとコアが起動できない場合があります。LAN内の端末から接続するには、待ち受けアドレスやファイアウォールの設定も必要で、ポート番号の変更だけでは対応できません。
- アプリ別プロキシ
- アプリごとに通信をプロキシに通すかどうかを設定する機能です。v2rayNGでは通常、VPNモードと併用します。リストが「プロキシを使うアプリ」なのか「プロキシを迂回するアプリ」なのかを確認してください。意味を混同しないよう注意しましょう。リストで通信の取り込み範囲を決めた後も、ルーティングルールによって通信を振り分ける場合があります。変更後は画面の案内に従って接続を再起動し、動作を確認してください。
- Mux（多重化）
- 複数の論理接続を、より少数の基盤接続で共有する仕組みです。接続を繰り返し確立する負荷を軽減する場合があります。一方、基盤接続が混雑したりパケットロスが起きたりすると、共有するリクエスト同士が影響し合うこともあるため、Muxは汎用的な高速化機能ではありません。有効にするかどうかは、プロトコル、コア、利用状況に応じて判断してください。効果を比較する際は、同じノードとテスト先を使い、一度に変更する設定は1つにします。
サブスクリプションとノード
まず設定の入手元を確認し、接続の可否、リクエストの応答時間、実際のスループットを区別しましょう。これらは別々の指標です。
- サブスクリプション
- 1つのURLから接続設定の一覧を取得・更新する方法です。サブスクリプションURLと、一覧に含まれるサーバーのアドレスは通常別のものです。v2rayNではサブスクリプショングループで取得元を管理し、v2rayNGではサブスクリプション設定から更新できます。更新後、クライアントが取得した内容を解析します。URLにアクセス認証情報が含まれる場合があるため、公開しないでください。更新に失敗しても、登録済みノードが必ず無効になったとは限りません。
- ノード
- クライアントの一覧に登録された、リモートサーバーへの接続設定です。通常はアドレス、ポート、プロトコル、認証、通信方式が含まれます。ノード名は識別用の文字列にすぎず、実際の所在地、経路、サービス品質を証明するものではありません。ノードを選択した後は、現在の接続先として有効になっていることも確認してください。サブスクリプションの更新で項目が置き換えられたり削除されたりする場合があるため、必要に応じて選択状態を確認し直してください。
- TCPing
- 対象のTCPポートへの接続にかかる時間を測定するテストで、ICMP Pingとは異なります。アドレスとポートへの到達性を確認する参考になりますが、通常はプロキシ認証、セキュリティハンドシェイク全体、対象サイトへのアクセスまでは確認しません。TCPingに成功してもブラウザーでアクセスできない場合は、プロトコル設定と実際のプロキシリクエストを続けて確認してください。ダウンロード帯域を直接示すものでもありません。
- 実接続遅延
- 選択したプロキシ設定を使ってテスト先へリクエストを送り、応答にかかった時間を測定します。単純なポート確認より実際のアクセス経路に近い指標です。ただし、テスト先、DNS、ハンドシェイク、その時点のネットワーク状況に左右されるため、条件の異なる測定結果を直接比較しないでください。1回のテストに成功しても、すべてのアプリの通信が取り込まれているとは限らず、継続的なスループット測定の代わりにもなりません。
ルーティングとDNS
通信の振り分けには照合条件が必要で、DNS名前解決によって接続先のアドレスが決まります。アクセスの問題を調べる際は、通信の出口と名前解決経路の両方を確認してください。
- ルーティングルールと通信の振り分け
- ドメイン、IPアドレス、ポートなどの条件に応じてアウトバウンドを選ぶ仕組みです。主な処理には、直接接続、プロキシ、ブロックがあります。通常はルールの上から順に照合されます。範囲の広いルールを先に置くと、後続の詳細なルールに一致しないことがあります。変更時は照合条件、ルールの順序、アウトバウンドのタグを合わせて確認してください。システムプロキシの切り替えによって、ルーティングルールが自動で変更されることはありません。
- GeoIPとGeoSite
- GeoIPはIPアドレスの集合、GeoSiteはドメインの集合との照合に使われます。コアは対応するデータファイルを使い、ルールで指定されたカテゴリを判別します。カテゴリ名を使えるかどうかは、現在のデータファイルに依存します。名前だけで判断しないでください。また、GeoIPの結果はサービスの実際の物理的な所在地を示すものではありません。ルールが機能しない場合は、サブスクリプションを更新するだけでなく、データファイルが読み込まれているか、指定したカテゴリが存在するかを確認してください。
- DNS名前解決
- ドメイン名をIPアドレスなどのレコードに変換する処理で、通常はアプリが接続を開始する前に行われます。OS、ブラウザー、プロキシコアがそれぞれ名前解決を行う場合があるため、システムDNSを変更しても、すべてのアプリの名前解決方法が変わるとは限りません。問題を調べる際は、どこが名前解決を行い、どの出口からクエリが送信されるかを確認してから、キャッシュと応答内容を確認してください。名前解決に成功しても、接続先への通信が成功するとは限りません。
- FakeDNS
- ドメインに合成IPアドレスを割り当て、コアにドメインとアドレスの対応関係を保存することで、後続の接続を元のドメインに関連付けます。通常のパブリックDNSサーバーの代わりになるものではありません。DNSクエリと対応する通信を、連携した処理経路に通す必要があります。合成アドレスがアプリにキャッシュされた状態で、関連する通信の取り込みを無効にすると、アクセスに問題が起きることがあります。その場合は対応する設定を元に戻し、必要に応じてキャッシュを削除してください。
- DNSリーク
- DNSクエリが想定した経路を通らずに送信される状態です。たとえば、指定した名前解決先から送信する想定なのに、OSの別の経路からクエリが送られる場合があります。複数の名前解決サービスが表示されるだけで、リークと判断することはできません。まず想定する動作を明確にし、ブラウザーの暗号化DNS、OSの名前解決設定、コアのDNSルーティングを確認して、ログから原因を調べてください。ノードを変更しても、クエリを送るアプリの設定は変わらない場合があります。