V2Ray / 設定用語

V2Ray用語集

プロトコルが接続方法を決め、コアが処理を実行し、クライアントが設定を管理します。5つのカテゴリから用語を確認し、役割を整理して実際の設定項目と照らし合わせましょう。

用語26項目 プロトコル・コア · 接続・ルーティング · テスト・名前解決

クライアントを設定する場合は、まずシステムプロキシとルーティングルールを確認しましょう。設定をインポートする場合は、サブスクリプションURLと共有リンクから確認してください。

PROTOCOL / TRANSPORT

プロトコル・通信方式

ノードの種類は設定項目の一つにすぎません。プロキシプロトコル、通信方式、接続のセキュリティ機能は、それぞれサーバー側の設定と合わせる必要があります。

プロトコル・通信方式VMess
VMessはProject Vのエコシステムで使われるプロキシプロトコルで、認証とデータ暗号化の仕組みを備えています。ユーザーの識別にはUUIDが使われることが一般的です。VMessとTCPやWebSocketなどの通信方式は別の階層にあるため、インポート時はプロトコル名だけで判断できません。認証処理の一部は時刻に依存するため、システム時計のずれで接続に失敗することがあります。新しい設定では通常AEAD形式が使われるため、古い解説のパラメーターをそのまま適用しないでください。
プロトコル・通信方式VLESS
VLESSはXrayエコシステムでよく使われる軽量プロキシプロトコルです。一般的な構成では、VLESS自体だけに頼らず、TLSまたはREALITYで接続を保護します。UUID、通信方式、サーバー名、使用する場合はflowもサーバー側と一致させる必要があります。同じVLESSでも設定をそのまま使い回せるとは限らないため、必要なパラメーター一式をコアが認識できるか確認してください。
プロトコル・通信方式Trojan
Trojanは通常、TLS接続上で使用し、パスワードでプロキシ層の認証を行います。パスワードはユーザー認証に使い、サーバー名と証明書の検証はTLS接続先の確認に使います。両者は代用できません。証明書エラーが発生した場合は、ドメイン名、システム時刻、証明書の設定を確認し、証明書検証の無効化を常用しないでください。
プロトコル・通信方式Shadowsocks(SS)
Shadowsocksは暗号化プロキシを中心とするプロトコル群で、クライアントではSSと略されることがあります。暗号化方式とパスワードはサーバー側の要件に合わせる必要があり、AEADと新しいプロトコルの派生形も混在させられません。使用できる暗号化方式、UDP、拡張機能はコアの実装によって異なるため、SSという種類だけでなく、ほかの項目も確認してください。
プロトコル・通信方式REALITY
REALITYはXrayの接続セキュリティ機能の一つで、VLESSと組み合わせて使われることがよくあります。プロキシプロトコルの代わりとして単独で使うノード種別ではありません。公開鍵、サーバー名、shortIdなどのパラメーターはサーバー側に合わせる必要があり、別の設定から任意に組み合わせることはできません。クライアントに入力欄が表示されても、実行中のコアがその組み合わせに対応しているとは限りません。
プロトコルとコアの選び方を確認 →

PROJECT / CORE

コア・エコシステム

GUIクライアントとプロキシコアは別のプログラムです。画面が似ていても、利用できる機能や設定形式が完全に一致するとは限りません。

コア・エコシステムProject V
Project Vは、モジュール型ネットワークプロキシツールを中心に形成されたプロジェクトと技術のエコシステムを指し、V2Rayはその主要な構成要素です。特定のデスクトップやAndroidクライアントの名称でも、ノードの種類に直接指定できるプロトコルでもありません。ドキュメントを読む際は、どのコア、設定形式、GUIクライアントの設定画面に対応しているかを確認してください。
コア・エコシステムV2Fly
V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、コアがプロトコル接続、ルーティング、DNSなどを処理します。v2flyNGはこのコアエコシステムを基盤とするAndroidクライアントです。プロジェクト名とクライアント名は区別してください。V2FlyとXrayには共通する設定概念もありますが、独自に進化した項目や機能が互換性を持つとは限りません。
コア・エコシステムXray
XrayはV2Rayの技術体系から派生し、その後、機能や設定を独自に進化させています。REALITYなどの機能には対応するコアが必要です。v2rayNGはXrayコアを使用しますが、v2rayNで実行できる機能は選択したコアとバージョンによって異なります。コアを変更すると接続パラメーター、ルーティングの動作、ログの内容も変わることがあるため、画面が同じかどうかだけで判断しないでください。
コア・エコシステムコア(Core)
コアは、プロキシプロトコル、接続処理、ルーティング、DNSの設定を実際に実行するプログラムです。GUIクライアントは設定を管理してコアを呼び出します。問題の切り分けでは、画面上で設定を保存できても、コアが正常に起動しているとは限りません。クライアントとコアのバージョンは別の情報です。互換性の問題を報告する際は両方を記録し、画面に項目がない場合とコアのエラーを混同しないようにしてください。

CLIENT / INBOUND

クライアント機能

まず、アプリの通信がどのように処理経路へ入るかを確認しましょう。システムプロキシ、仮想ネットワークインターフェース、アプリごとの設定では、対象となる範囲が異なります。

クライアント機能システムプロキシ
システムプロキシは、ローカルプロキシのアドレスをOSに登録します。主にシステムプロキシ設定に従うアプリが対象で、すべてのネットワーク通信を制御するものではありません。v2rayNの自動設定やシステムプロキシの解除は、この接続入口を変更するもので、サーバー自体には影響しません。アプリ独自のプロキシ設定がシステム設定より優先される場合があります。コアに届いた接続をプロキシ経由にするか直接接続にするかは、さらにルーティングルールで決まります。
クライアント機能TUNモード
TUNモードは仮想ネットワークインターフェースでIPパケットを受け取り、システムプロキシ設定を参照しない一部のアプリも対象にできます。実際の対象範囲は、システムのルーティング、実行権限、除外ルール、クライアントの実装によって異なり、スイッチの状態だけでは判断できません。有効にした後に名前解決の問題が起きた場合は、DNSの取り込み設定やほかの仮想ネットワークインターフェースも確認し、同じ経路を複数のコンポーネントが取り合っていないか調べてください。
クライアント機能VpnService
VpnServiceはAndroidが提供する仮想ネットワークインターフェースのサービス機構です。v2rayNGはこれを使ってアプリの通信を受け取り、コアに渡して処理します。OSのVPN許可ダイアログはインターフェースの作成を許可するもので、すべての接続がリモートサーバーへ送られることを示すものではありません。同じ環境でほかのVPNサービスを使うと競合する場合があります。バックグラウンドで接続が切れる場合は、OSの省電力制限も確認してください。
クライアント機能アプリごとのプロキシ設定
アプリごとのプロキシ設定では、アプリの通信をクライアントのプロキシ処理に渡すかどうかを指定します。選択したアプリだけを対象にする方式と、選択したアプリを除外する方式が一般的です。リストの意味は現在のモードによって異なるため、アプリを選ぶ前に画面の説明を確認してください。対象アプリの通信もルーティングルールによって直接接続になる場合があります。アプリの対象リストとドメインの振り分けルールは分けて確認しましょう。
クライアント機能インバウンド(Inbound)
インバウンドは、コアが接続を受け付ける入口です。一般的な設定では、ローカルHTTPやSOCKSの待ち受けを使い、アドレス、ポート、プロトコルによってアプリの接続方法が決まります。アプリに設定するローカルプロキシのポートは、実際のインバウンドに合わせてください。サーバー側のポートを指定するものではありません。ループバックアドレスでの待ち受けは通常、同じ端末からのみアクセスできます。ほかのネットワークインターフェースで公開する場合は、アクセス制御と公開範囲を検討してください。
クライアントのインストールと接続手順を確認 →

SUBSCRIPTION / TEST

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

サブスクリプションは設定の取得元、ノードは個々の設定情報、テスト結果は特定の条件で得られた測定値です。それぞれ役割が異なり、相互に置き換えることはできません。

サブスクリプション・ノードサブスクリプションURL
サブスクリプションURLは、サーバー設定一式を取得するためのURLです。クライアントが更新を実行すると、内容を再取得して独自の方法でノードを整理します。サブスクリプションサービスの応答形式はクライアントが認識できる必要があり、任意のWebページのURLをインポートできるわけではありません。URLにアクセス情報が含まれる場合があるため、機密情報として扱ってください。更新すると手動で変更したノード設定が上書きされることにも注意が必要です。
サブスクリプション・ノードノード
ノードは、クライアントで選択できるサーバー設定を指す一般的な呼び方です。通常、アドレス、ポート、認証情報、通信方式、接続のセキュリティ設定が含まれます。表示名が異なっていても別々のサーバーとは限らず、同じアドレスでもポートやパラメーターを変えて別の入口を提供する場合があります。設定の重複や無効を判断する際は、名前だけでなく実際の項目と接続ログを比較してください。
サブスクリプション・ノード遅延
遅延は、テスト開始から指定した応答を得るまでにかかった時間です。数値はテスト方法とあわせて初めて意味を持ちます。ICMP pingはネットワーク層の往復時間、TCPテストは主にポート接続のハンドシェイクを測定します。アプリケーションのリクエストテストでは、プロトコルのネゴシエーションや接続先の応答が含まれる場合もあります。遅延が小さくてもダウンロード速度が速いとは限りません。ノードを比較する際は、テスト対象、方法、実施時刻をできるだけそろえてください。
サブスクリプション・ノード実接続遅延
実接続遅延は一般に、現在のプロキシ設定を通してテスト対象へ実際にリクエストを送るのにかかる時間です。計測範囲はクライアントによって異なります。ドメインの名前解決、プロトコルのハンドシェイク、接続先の応答、接続の再利用状態などが影響するため、回線そのものの遅延とは限りません。テストに失敗してもノードが無効とは限らないので、まずテスト対象とローカル設定の影響を切り分けてください。

ROUTING / RESOLUTION

ルーティング・DNS

ルールの適用には照合に使える情報が必要です。ドメイン情報が保持されるか、IPアドレスへの変換が行われるタイミング、クエリの送信元は、いずれもルーティング結果に影響します。

ルーティング・DNSルーティングルール
ルーティングルールは、ドメイン、IP、ポートなどの条件に基づいて接続のアウトバウンドを選択します。V2RayやXrayの一般的なルールは上から順に評価されます。ルール内のoutboundTagは、定義済みのアウトバウンドタグと一致させる必要があります。同じルール内の複数の条件は、通常すべて満たす必要があります。ルールを変更する前に、順序と照合対象を確認し、条件の広いルールが先に接続を処理しないようにしてください。
ルーティング・DNSルーティング
ルーティングは、接続ごとにプロキシ、直接接続、ブロックなどのアウトバウンドを割り当てる処理方針であり、独立したプロトコルではありません。実際の結果は、通信の取り込み範囲、ルールの順序、ドメイン情報、DNS設定によって決まります。特定のアプリが想定と異なる経路を使う場合は、まず通信がコアに届いているかを確認し、次に適用されたルールを調べてください。ノードを切り替えても、設定済みの直接接続ルールは通常変わりません。
ルーティング・DNSGeoIP
GeoIPはここでは、タグで分類したIPアドレスの集合を指します。ルーティングではgeoip:privateなどの式で該当データを参照できます。タグの有無や含まれるアドレスは、使用するルールデータとコアの対応状況によって異なります。IPの割り当て情報は回線品質を示すものではなく、サービスの実際の運営拠点とも限りません。ドメイン接続をIPで照合できるかどうかは、名前解決の設定にも左右されます。
ルーティング・DNSGeoSite
GeoSiteはタグで分類したドメインの集合で、IPアドレスで照合するGeoIPとは異なります。式で指定するタグはルールデータファイルに含まれるものを使います。Webサイト名からタグを推測しても適用されるとは限りません。ルールに接続先IPしか渡されずドメイン名がない場合、ドメインの集合に直接一致しないことがあります。インバウンドから渡される情報やスニッフィングの設定も確認してください。
ルーティング・DNSDNS
DNSはドメインをIPアドレスなどのレコードに変換します。アプリ、OS、プロキシコアがそれぞれクエリを送信する場合があります。コアのDNS設定がシステムのすべてのクエリを処理するとは限らず、ブラウザー内蔵の暗号化DNSが別の経路を使うこともあります。問題を切り分ける際は、誰がクエリを送信し、どのリゾルバーに送り、そのクエリの通信がどのアウトバウンドを使うかを個別に確認してください。DNSサーバーのアドレスだけを見ても十分ではありません。
ルーティング・DNSFakeDNS
FakeDNSはアプリにマッピング用アドレスを返し、内部でそのアドレスと元のドメインとの対応関係を保持して、後続の接続でドメインを復元します。通信の取り込みとマッピングの識別処理との連携が必要で、任意のパブリックDNSサーバーのアドレスとして設定するものではありません。アプリにマッピング用アドレスがキャッシュされたまま、関連機能が無効になったりマッピング情報が失われたりすると、接続に問題が起きることがあります。
ルーティング・DNSDNSリーク
DNSリークは、クエリが想定した名前解決経路を通らない現象です。たとえば、指定した経路で処理するはずのクエリがローカルネットワークのリゾルバーに送られる場合があります。異常かどうかは実際のポリシーに照らして判断してください。検出結果に複数のリゾルバーが表示されるだけで、必ず問題とは限りません。システムDNS、アプリの暗号化DNS、通信の取り込み範囲、コアのログをあわせて確認しましょう。ノードを変更するだけでは、すべてのクエリ経路が自動的に修正されるわけではありません。