設定リファレンス · 用語28件

V2Ray用語集

プロトコル、コア、サブスクリプション、DNSを解説。クライアント設定での実際の意味を確認し、まず概念を整理してから各項目を照合しましょう。

プロキシプロトコル

まず、接続する両端で使うプロトコルを確認します。セキュリティレイヤーと通信方式も別途合わせる必要があります。REALITYもここで解説しますが、独立したプロキシプロトコルではありません。

VMess
Project Vエコシステムのプロキシプロトコルで、ユーザーIDによって認証します。現在の設定では通常AEADを使用します。クライアントとサーバーでユーザーID、セキュリティ設定、システム時刻を一致させてください。古い解説にある追加の認証パラメーターを、そのまま適用するのは避けましょう。VMessを選んだ後も通信方式とTLS設定の確認が必要です。プロトコル名が同じでも接続設定全体が同じとは限りません。
VLESS
軽量なプロキシプロトコルで、単体では通信を暗号化せず、通常はTLSまたはREALITYと組み合わせて使います。ユーザーID、通信方式、セキュリティレイヤー、flowはそれぞれ個別に確認してください。flowが使えるかどうかは、両端のコアと接続の組み合わせによって異なります。画面上の「暗号化:none」は、接続全体が暗号化されていないことを意味しません。外側のセキュリティ設定も確認してください。
Trojan
パスワードで認証し、通常はTLSで接続を保護するプロキシプロトコルです。サーバーアドレス、ポート、パスワード、TLSサーバー名はそれぞれ別の項目です。パスワードだけをコピーしても接続できません。証明書エラーが発生した場合は、検証を無効にするのではなく、サーバー名、証明書の有効期間、システム時刻を確認してください。
Shadowsocks(SS)
共有鍵またはパスワードと暗号化方式を指定して設定するプロキシプロトコルです。共有リンクは通常ss://で始まります。従来のAEADとShadowsocks 2022ではパラメーターや鍵の要件が異なり、クライアントの対応状況もそれぞれ確認が必要です。プロトコル、暗号化方式、鍵は一組で一致させ、異なる方式の設定項目を混在させないでください。
REALITY
Xrayエコシステムの通信セキュリティ方式で、VLESSと組み合わせて使うことが多く、VLESSの代わりになる独立したプロキシプロトコルではありません。設定には通常、サーバー名、公​​開鍵、shortId、クライアントフィンガープリントなどが含まれます。具体的な項目は使用中のコアとクライアント画面で確認してください。インポート後も、各情報が正しく引き継がれたか確認しましょう。サーバーアドレスだけでは設定の正しさを判断できません。

通信方式と偽装

この層では、データの伝送方法とハンドシェイク方式を指定します。同じ通信方式を選んでも、パス、ホスト名、転送設定を省略できるとは限りません。

TCP
信頼性の高い順序付きバイトストリームを提供するトランスポート層プロトコルで、多くのプロキシ接続で下位の通信方式として使われます。クライアントのTCPテストで測定するのは、通常、指定ポートへの接続にかかる時間です。プロキシ認証やその後のリクエストは検証されません。そのためTCPテストに成功してもブラウジングできないことはあります。次にプロトコルのハンドシェイク、TLS、DNSを確認してください。
UDP
データグラム単位で通信し、データの到達や順序は保証されません。DNSやリアルタイム通信などで使われます。アプリがUDPを必要としていても、システムプロキシを有効にするだけですべてのUDP通信が処理されるわけではありません。ローカルの入口、コア、サーバー、動作モードがすべて対応している必要があります。問題を切り分ける際はUDPとTCPを別々にテストし、WebサイトにアクセスできることだけでUDPの利用可否を判断しないでください。
WebSocket(WS)
双方向通信方式の1つで、プロキシデータの伝送に利用できますが、プロキシプロトコルのユーザー認証を代替するものではありません。クライアントのパス、Host、TLSサーバー名は役割が異なり、サーバー側やリバースプロキシの設定と一致させる必要があります。TLSハンドシェイクが正常でも、パスや転送ルールに誤りがあれば接続に失敗します。
gRPC
HTTP/2をベースにしたリモートプロシージャコールフレームワークで、一部のプロキシコアでは通信方式として使われます。設定するサービス名はサーバー側と一致させてください。経路上にリバースプロキシがある場合は、HTTP/2と適切な転送に対応している必要があります。プロキシプロトコルではなく、あらゆるネットワークや通信内容で他の方式より高速になるわけでもありません。
TLSとSNI
TLSは接続の暗号化と認証を担い、SNIはハンドシェイク時にアクセス先のサーバー名を伝えます。実際の接続先アドレス、SNI、HTTP Hostは異なる場合がありますが、各項目はサーバーの指定に従って設定し、互いに置き換えないでください。証明書は設定した接続先の名称に対して検証する必要があります。任意のドメイン名を入力しても、安全な接続が自動的に確立するわけではありません。

コアとクライアント

コアはプロトコルとルーティングを処理し、GUIクライアントは設定の管理とコアの呼び出しを担います。画面に項目を保存できても、使用中のコアがその機能に対応しているとは限りません。

Project V
V2Rayなどのネットワークツールを中心に形成されたプロジェクトエコシステムを指す概念で、特定のデスクトップアプリやモバイルアプリの名称ではありません。ドキュメントを読むときは、エコシステム、コアプロジェクト、個別のクライアントを区別し、コア向けのパラメーターをそのまま画面上の操作手順として扱わないようにしましょう。本サイトではv2rayN、v2rayNG、v2flyNGの設定を解説しています。
V2Fly
V2Rayプロジェクトの流れをくむコミュニティおよびコアプロジェクトで、プロキシプロトコル、通信方式、ルーティング、DNSなどの機能を提供します。Xrayとは共通の歴史を持ちますが、その後、機能や設定形式、項目への対応に違いが生じています。設定を移行する際は実際に使うコアのドキュメントを確認してください。どちらもJSON形式だからといって、設定ファイルをそのまま交換できるとは限りません。
Xrayコア
V2Rayから派生したプロキシコアプロジェクトで、REALITYなどの機能を提供しながら、独自の設定やプロトコル実装を発展させています。v2rayNGはXrayコアを使用します。デスクトップクライアントの動作は、選択中のコアによって異なります。機能を使えるかどうかは、インストール済みのバージョンとパラメーターの組み合わせ次第です。GUIクライアントの更新とコアの更新は別々に確認してください。
v2rayN
サブスクリプション、サーバー、ルーティング、プロキシモードを管理するデスクトップ向けGUIクライアントで、Windows、macOS、Linuxに対応しています。クライアント画面が設定を生成・整理し、プロトコル接続は選択したコアが実行します。問題を調べる際は画面の設定とコアのログを両方確認してください。クライアント名だけで、すべてのプロトコルやモードが有効だと判断することはできません。
v2rayNG
XrayコアをベースにしたAndroid向けGUIクライアントで、サブスクリプションや共有設定をインポートできます。通常はAndroidのVPN機能を使ってアプリの通信を処理します。システムの許可、アプリごとの設定、バックグラウンド動作の制限によって、実際に処理される範囲が変わることがあります。画面に起動中と表示されても、サービスが動き始めたことを示すだけです。目的のサイトにアクセスできるかは、実際の通信で確認してください。
v2flyNG
V2Flyコアを採用したAndroid向けGUIクライアントで、V2Flyエコシステムに対応するクライアントの選択肢です。v2rayNGと名称は似ていますが、コアが異なるため、REALITY、flowなどの拡張項目も同じように使えるとは限りません。選ぶ前にサーバー側で必要な機能を確認し、インポート後に設定が正しく認識されているか確かめてください。

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

サブスクリプションは設定一式を取得するための入口で、ノードはその中に含まれる接続設定の1つです。インポート、更新、テストでは、それぞれ確認できる内容が異なります。

サブスクリプションURL
クライアントが複数のサーバー設定を取得するためのURLです。更新すると、コンテンツを再取得して解析します。クライアントごとに対応する形式が異なるため、URLを開けても正しくインポートできるとは限りません。アクセス用の認証情報が含まれる場合があるため、URLは機密情報として扱ってください。更新は通常、該当するグループに反映されます。手動で追加した重要な設定は別途保存しておきましょう。
ノード/サーバー設定
クライアントの一覧から選択できる接続設定の1つで、通常はアドレス、ポート、認証、通信方式、セキュリティ設定を含みます。これは論理的な設定であり、独立した物理サーバーに対応するとは限りません。同じアドレスで複数の接続方式を提供する場合もあります。メモ用の名前は識別のためのもので、実際の所在地、性能、プロトコルの正しさを示すものではありません。
遅延
指定したテストを開始してから応答を受け取るまでの時間です。テスト方法を踏まえて解釈する必要があります。ICMP、TCP接続、プロキシ経由のWebアクセスでは、測定する経路や処理が異なります。一覧の数値だけを比べないでください。テストがタイムアウトしても、設定全体が使えないとは限りません。テスト先に到達できるか、想定したプロキシを経由しているかを確認してください。
実接続遅延
クライアントでは通常、プロキシ経由で指定したテスト先にアクセスするまでの時間を指し、ポートの簡易チェックより多くの接続処理を測定します。結果はDNS、プロトコルのハンドシェイク、TLS、接続先サイト、接続の再利用などに左右されます。具体的な測定方法はクライアントの実装によって異なります。ダウンロード速度とは別の指標です。設定を比較する際は、テスト先と方法を統一してください。

ルーティングとDNS

通信がどのようにクライアントへ入り、どのルールに一致し、どこでドメイン名を解決するのかは、それぞれ分けて確認する必要があります。

ルーティングとルール分岐
ドメイン、IP、ポートなどの条件に応じて、接続を直接接続、プロキシ、ブロックなどの異なるアウトバウンドへ振り分けます。一般にルールは順番に照合されます。実際の動作はデフォルトのアウトバウンド、ドメイン名の解決方針、スニッフィング設定にも左右されます。画面上の「ルールモード」は選択中のルールセットを示すだけです。実際の経路は一致順とコアのログで確認してください。
GeoIP
地域や用途ごとに整理されたIPアドレスのリストで、ルーティングルールで対象IPをまとめて照合できます。たとえばgeoip:privateのように指定します。照合対象はアドレスであり、Webサイト名ではありません。ドメイン名が先に解決されるかどうかで、ルールの判定に使えるかが変わります。データファイルが設定に対応している必要があり、IPリストからサービスの所有者や現在のネットワーク上の所在地を正確に判断することはできません。
GeoSite
サイトや用途ごとに整理されたドメインのリストで、ドメインルールを1件ずつ管理する手間を減らせます。たとえばgeosite:cnのように指定します。分類タグが使えるかどうかは、実際に読み込まれたデータファイルによって異なります。解説にある任意のタグがコアに標準搭載されているとは限りません。アプリがIPアドレスしか送らない場合、ドメインルールを適用するにはDNSとの対応付けやスニッフィングによるドメイン情報が必要になることがあります。
システムプロキシ
OSのプロキシ設定を変更し、その設定に従うアプリの通信をクライアントが提供するローカルのプロキシポートへ接続させます。すべてのアプリを自動的に処理するわけではなく、独自のネットワーク処理を使うアプリはOSの設定を無視する場合があります。設定を有効にしてもUDPが転送されるとは限りません。クライアントを終了した後にネットワークの問題が発生した場合は、停止したローカルポートがシステムプロキシに指定されたままになっていないか確認してください。
TUNモード
仮想ネットワークインターフェースでIP通信を受け取り、プロキシコンポーネントに渡して処理する動作モードです。新しいプロキシプロトコルではありません。追加の権限、ルーティング、DNS設定が必要になることが多く、除外ルールによって通信を処理する範囲も変わります。有効にした後は、ローカルネットワークへの接続、ドメイン名の解決、対象アプリをそれぞれ確認してください。「全通信を処理」がすべての通信をプロキシ経由にするという意味ではありません。
FakeDNS
アプリに合成IPアドレスを返し、コアがそのアドレスと元のドメイン名の対応関係を保存します。後続の接続でドメイン名を復元し、ルーティングに利用するための仕組みです。合成アドレスは接続先サイトの実際のアドレスではなく、通信の取り込みと対応関係を維持する仕組みが必要です。設定が不完全だと、合成アドレスが想定した処理経路から外れることがあります。モード切り替え後に古いDNSキャッシュが残っていると、問題の原因になる場合もあります。
DNS漏れ
DNSクエリが事前に設定した名前解決経路から外れる状態です。たとえば、プロキシ経由で処理するはずのクエリがローカルのDNSリゾルバーに送られる場合が該当します。漏れに当たるかどうかは、設定済みの方針に照らして判断してください。意図的に設定した直接接続のDNSを一律に異常とみなすことはできません。調査ではシステムDNS、アプリ内蔵の暗号化DNS、コアのDNSアウトバウンド、ルーティングルールをすべて確認してください。検査サイトの結果だけでは原因を特定できません。