VMess
VMessはProject Vエコシステムのプロキシプロトコルで、認証とデータ暗号化の仕組みを備えています。設定には通常、ユーザーID、サーバーアドレス、ポートが含まれます。複数のトランスポート方式と組み合わせられるため、プロトコル名だけで設定が完全かどうかは判断できません。一部の認証処理は時刻に依存するため、端末の時刻が大きくずれている場合は、接続を調べる前に時刻を合わせてください。
設定用語 · 用途別に確認
V2Ray用語集
プロトコルは通信方式、コアは設定の実行、クライアントは操作画面を担います。まずこの3つを区別してから、サブスクリプション、ルーティング、DNS、プロキシモードを確認すると、各設定の関係が分かりやすくなります。
このページでは用語と利用上の注意点を解説します。メニュー名はクライアントのバージョンによって異なります。初期設定は入門ガイドから、順を追って確認したい場合は設定・トラブル対処マニュアルをご覧ください。
トランスポートプロトコル
このカテゴリでは、プロキシプロトコルとトランスポートセキュリティ機能を扱います。組み合わせて使うことはありますが、同じ階層の選択肢として置き換えられるものではありません。
VLESS
VLESSは軽量なプロキシプロトコルで、単体ではデータを暗号化しません。通信の保護は通常、TLSやREALITYなどの機能で補います。設定をインポートする際は、ユーザーID、トランスポート方式、セキュリティ設定、必要に応じてフロー制御の項目をサーバー側に合わせてください。VMessとは各設定項目の意味が完全には一致しないため、プロトコルの選択だけを変更しても変換できません。
Trojan
Trojanは通常、TLS接続上でプロキシ通信を行い、パスワードでプロキシ層の認証を行います。サーバーアドレス、認証パスワード、TLSサーバー名は、接続先、アクセス認証、通信相手の確認という別々の役割を持ち、同じ欄に入力するものではありません。接続できない場合は、ローカルの待ち受けポートを何度も変更するのではなく、認証エラーとTLSエラーを分けて確認してください。
REALITY
REALITYはXrayエコシステムのトランスポートセキュリティ機能であり、単独のプロキシプロトコルではありません。一般的な設定ではVLESSと組み合わせます。サーバー名、公開鍵関連のパラメーター、ショートIDなどは、サーバー側から提供された値を入力してください。クライアントと使用するコアも該当の設定に対応している必要があります。インポートできても接続できない場合は、コアの互換性も確認しましょう。
TLS
TLSは通信内容を保護し、証明書などを使って通信相手の身元を確認します。プロキシプロトコルのユーザー認証とは別の仕組みです。接続先にはIPアドレスを指定できますが、検証に使うサーバー名は証明書の要件に合わせる必要があります。証明書エラーは端末の時刻、サーバー名、証明書の設定を確認し、検証の無効化を常用の解決策にしないでください。
コアとエコシステム
同じGUIでも、異なるコアを呼び出す場合があります。プロトコルの対応状況を確認するときは、クライアントだけでなく、実際に使うコアとそのバージョンも確認してください。
Project V
Project Vは、V2Rayと関連ツールの背景を理解するうえで重要なエコシステムです。入出力とルーティングを組み合わせて処理する考え方を採用しています。デスクトップ用インストーラーやサブスクリプションサービスの名称ではありません。各プロジェクトは独立して開発されるため、すべてのクライアントが同じプロトコルや設定項目に対応するとは限りません。
V2Fly
V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、関連するコアとドキュメントを維持しています。表記にv2flyが使われる場合もあります。Androidクライアントのv2flyNGは、このコアエコシステムを採用しており、既存の設定に合わせて選べます。コアごとに拡張機能は異なるため、他のクライアントから移行する際は、プロトコルとトランスポート設定が対応しているか項目ごとに確認してください。
Xray
XrayはV2Rayから派生したプロキシコアプロジェクトで、独自に機能を発展させています。REALITYなどの設定には対応するコアが必要です。v2rayNGはXrayコアを使用しますが、デスクトップクライアントは実際に選択・呼び出しているコアを確認してください。項目が認識されない、またはプロトコルに対応していないというエラーを調べる際は、クライアント名だけでなく、実行中のコアも確認しましょう。
クライアントとコア
v2rayN、v2rayNG、v2flyNGはGUIクライアントで、設定のインポート、サブスクリプションの管理、設定画面の表示を担います。実際の接続とルールの実行はコアが行います。画面で設定を保存できても、使用中のコアが対応しているとは限りません。更新、移行、トラブル対処の際はクライアントとコアの情報を記録し、画面の操作ミスとコアの起動・ネットワーク接続エラーを切り分けましょう。
サブスクリプションとノード
サブスクリプションは設定を配布し、ノードは接続先ごとの設定を表します。グループ管理、設定の更新、接続テストはそれぞれ別の操作です。
サブスクリプション
サブスクリプションは、URLから複数の接続設定を取得・更新する方式です。URLから取得するデータ形式は、クライアントとの互換性が必要です。更新で変わるのは主に設定内容であり、プロキシ接続が確立するわけでも、すべての設定が使えると保証されるわけでもありません。URLに認証情報が含まれる場合があるため、公開のスクリーンショットやログ、チャットに載せないでください。クライアントを変更する際は、既存のグループ設定も引き継ぎましょう。
ノード
ノードは通常、クライアントに登録された接続先ごとの設定を指し、アドレス、ポート、プロトコル、認証情報、トランスポート設定などを含みます。表示名はラベルにすぎず、物理的な場所、回線品質、現在の接続可否を証明するものではありません。ノードを選んだ後も、アプリの通信をシステムプロキシ、TUN、またはクライアントの該当モードからプロキシ処理に渡す必要があります。
サブスクリプショングループ
サブスクリプショングループを使うと、取得元や用途ごとに設定を整理し、個別に更新、絞り込み、管理できます。多くの場合はクライアントの管理機能であり、自動負荷分散やフェイルオーバーを意味しません。サブスクリプションで生成された項目を手動で編集する前に、次回の更新で変更が上書きされるか確認してください。重要なカスタム設定は別途保存しましょう。
実測接続遅延
実測接続遅延は一般に、選択したプロキシ設定を通してテスト先へアクセスしたときの所要時間です。計測範囲はクライアントの実装によって異なります。テスト先、接続の再利用、タイムアウト設定によって結果が変わるため、サーバーとの純粋な往復時間でも、継続的なダウンロード速度でもありません。テストに失敗した場合は、テスト先への到達性やログも確認し、1回の結果だけで設定が無効と判断しないでください。
ルーティングとDNS
名前解決は接続先アドレスの取得方法を決め、ルーティングは通信の出先を決めます。両者は影響し合いますが、1つのスイッチで両方の設定を置き換えることはできません。
ルーティングルール
ルーティングルールは、ドメイン、IPアドレス、ポートなどの条件に応じて、接続を直接接続、プロキシ、ブロックなどの指定したアウトバウンドへ振り分けます。通常、ルールには照合順があります。先に広すぎる条件を置くと、後続の細かなルールが適用されないことがあります。変更時は対象の条件だけでなく、一致しない接続のデフォルト動作も確認し、具体的な利用場面で動作を検証してください。
通信の振り分け
通信の振り分けは、ルールによって接続ごとに異なるアウトバウンドへ割り当てる方式で、独立したプロトコルではありません。クライアントの「中国本土をバイパス」「全般」などの表示は、通常、プリセットのルールや処理方式を指しますが、適用範囲は現在の設定で確認してください。アプリが想定どおりに通信できない場合は、まず通信がクライアントに届いているかを確認し、その後、適用されたルールと名前解決の結果を調べましょう。
GeoIP
GeoIPはルーティング設定で、地域や用途ごとにまとめたIPアドレスの集合を指し、アドレス範囲を一つずつ指定する手間を省きます。分類結果はデータの提供元や更新時期に左右され、サーバーの所在地をリアルタイムで測定するものではありません。ルールの結果が想定と異なる場合は、Webサイト名だけで判断せず、実際の接続先IP、データファイル、分類範囲を確認してください。
GeoSite
GeoSiteはWebサイト、サービス、用途に関連するドメインを分類し、ルールでカテゴリごとに照合しやすくします。対象はドメイン条件であり、IPアドレスを分類するGeoIPとは異なります。また、DNS名前解決の代わりにはなりません。1つのサービスが複数のドメインや外部リソースを使う場合もあるため、一部にアクセスできない場合は、実際のリクエストに使われるドメインが網羅されているか確認してください。
DNS
DNSはドメイン名をIPアドレスなどのレコードに変換し、ドメインを使った接続の基礎となります。OS、ブラウザー、プロキシコアがそれぞれ名前解決を行う場合があるため、DNSアドレスを1か所で変更しても、すべてのアプリに反映されるとは限りません。設定時は、どこが名前解決を行うか、問い合わせがどの経路を通るか、結果がルーティングにどう使われるかを個別に確認してから、DNSサーバーを変更する必要があるか判断しましょう。
FakeDNS
FakeDNSは予約済みアドレス範囲の仮想IPアドレスを返し、そのアドレスと元のドメイン名との対応を保持します。後続の接続をコアが処理し、ドメイン名を復元してからルーティングします。接続先が実際に仮想IPアドレス上にあるという意味ではなく、すべての名前解決結果を1つのアドレスに固定するものでもありません。名前解決と通信の取り込みを連携させる必要があり、有効・無効を切り替えた後は、アプリのキャッシュに古い対応情報が残っていないか確認してください。
DNSリーク
DNSリークとは、問い合わせが想定外のリゾルバーやネットワーク経路を通ることです。判断する前に、まず自分のDNSポリシーを確認してください。テストページに表示されたリゾルバー名だけでは、すべてのアプリのDNS経路が分かるわけではなく、プロキシ接続の失敗を直接示すものでもありません。アプリ内蔵の暗号化DNS、システム設定、クライアントのルールを確認し、実際にどのアプリが問い合わせを行ったかを切り分けましょう。
ドメイン解決ポリシー
ルーティングのドメイン解決ポリシーは、IPルールとの照合に使うドメイン名を、解決するかどうか、いつ解決するかを決めます。たとえばIPIfNonMatchは通常、ドメインルールに一致しない場合に名前解決し、その後IPルールを照合する設定です。DNSサーバーのアドレスでも、すべてのリクエストで特定のアドレスファミリーを強制する設定でもありません。似た名前が異なる設定階層にある場合は、それぞれの意味を確認してください。
プロキシモードとTUN
まず、どのアプリの通信を取り込むかを決め、次にコアへ渡した後の処理ルールを設定します。通信を取り込む範囲と、アウトバウンドの選択は別の設定です。
システムプロキシ
システムプロキシはOSにローカルプロキシのアドレスを登録し、その設定に従うアプリからのリクエストをクライアントへ渡します。すべてのアプリが対象になるわけではなく、すべてのUDP通信がプロキシを通るわけでもありません。クライアントを終了した後にWebページへアクセスできない場合は、リモート設定をすぐに変更するのではなく、ローカルの待ち受けポートを指すプロキシ設定がシステムに残っていないか確認してください。
TUNモード
TUNは仮想ネットワークインターフェースで対象のIP通信を受け取り、コアにルーティングと接続処理を任せます。通常、システムプロキシより多くのアプリを対象にできます。広がるのは通信を取り込む範囲であり、すべての接続が自動的にプロキシへ送られるわけでも、DNS設定が不要になるわけでもありません。有効化には適切な権限が必要な場合があり、他の仮想ネットワークツールとのルーティング競合にも注意してください。
スニッフィング
スニッフィングは、一部の接続の初期データからプロトコルやドメイン名の手がかりを検出し、ルーティングの照合に使える情報を補います。任意の暗号化通信を復号する機能ではなく、すべての接続からドメイン名を復元できるわけでもありません。検出できる範囲はプロトコルや設定によって異なります。宛先アドレスを置き換えるかどうかなどの動作も個別の設定に依存するため、万能な修復機能としてではなく、用途に合わせて有効にしてください。
アプリ別プロキシ
アプリ別プロキシでは、アプリごとに通信を取り込む対象に含めるか、除外するかを選べます。Androidクライアントでは通常、VPNモードと組み合わせて使います。リストは選択したアプリだけをプロキシ経由にする場合と、選択したアプリを除外する場合があるため、現在のモードでの意味を先に確認してください。対象アプリに追加しても通信は引き続きルーティングルールと照合されるため、チェックしたアプリのすべてのリクエストがプロキシへ送られるとは限りません。