設定項目ガイド · 26用語

V2Ray用語集:
プロトコル・サブスクリプション・ルーティング設定

v2rayNGの設定で見慣れない項目があれば、まずカテゴリ別に意味を確認し、元のメニューでパラメーターを照らし合わせてください。デスクトップ版v2rayNの同じ概念も確認できます。メニュー名はバージョンによって多少異なる場合があります。

プロトコルと転送方式

ノードの編集画面を開き、プロトコルの種類、認証項目、転送方式、安全設定の順に確認します。4つの設定はサーバー側とまとめて合わせる必要があり、プロトコル名だけを置き換えても接続できません。

プロトコル解説#

VMess

VMessは認証と暗号化の仕組みを備えたプロキシプロトコルです。主な設定項目にはユーザーID、暗号化方式、追加IDがあります。古い設定をインポートする際は、追加IDがサーバー側の指定に合っているか確認し、別のノードの値をそのまま使わないでください。端末の時刻が大きくずれていると認証に影響することもあります。接続できない場合は、まずシステムの日時を自動設定にしてください。

プロトコル解説#

VLESS

VLESSは軽量なプロキシプロトコルで、VMessのようなデータ暗号化機能はありません。通常はTLSまたはREALITYと組み合わせて使用します。ノード編集画面にencryption: noneと表示されても、接続全体が暗号化されていないとは限りません。セキュリティ層の設定も確認してください。対応する組み合わせはコアとバージョンによって異なり、クライアント名だけでは判断できません。

プロトコル解説#

Trojan

Trojanは通常TLS接続上で動作し、パスワードで認証します。ノードを編集する際は、パスワード、サーバーアドレス、ポート、TLSパラメーターをサーバー側に合わせてください。パスワードをユーザーID欄に入力してはいけません。ハンドシェイクエラーが発生した場合は、システム時刻、サーバー名、証明書を確認し、証明書検証を無効にして済ませないでください。

プロトコル解説#

Shadowsocks

Shadowsocksの主な設定項目は、サーバーアドレス、ポート、パスワード、暗号化方式です。クライアントとサーバーの両方で同じ暗号化方式を使用する必要があります。新しい方式の一部では鍵の形式も指定されており、任意の文字列をパスワードにできるとは限りません。設定をインポートしても接続できない場合は、プロキシモードを何度も切り替える前に、現在のコアがその方式に対応しているか確認してください。

プロトコル解説#

TLSとSNI

TLSは接続を暗号化し、相手を認証します。SNIはハンドシェイク時に接続先サーバー名を指定します。クライアントでは「サーバー名」またはserverNameと表示されることがあり、通常は証明書とサーバー側の設定に合わせます。接続先アドレスにIPを指定していても、SNIまで同じIPに変更してよいとは限りません。

プロトコル解説#

REALITY

REALITYはXrayエコシステムの安全な通信方式で、VLESSと並ぶプロキシプロトコルではありません。よく使われる構成はVLESSとREALITYの組み合わせです。設定をインポートする際は、サーバー側から提供された公開鍵、サーバー名、Short ID、フィンガープリントなどを確認してください。通常のTLS設定は、安全方式を1項目変更するだけではREALITYに切り替えられません。必要なパラメーターを推測で入力しないでください。

プロトコル解説#

転送方式

ノード編集画面の転送方式は、プロキシプロトコルを接続上でどのように運ぶかを決めます。一般的な選択肢はTCP、WebSocket、gRPCです。WebSocketのパスやHost、gRPCのサービス名などはサーバー側の設定に合わせてください。プロトコルが同じでも転送方式が異なるノード間では、これらの項目をそのまま入れ替えられません。また、ここでの分類はネットワークの教科書にある「トランスポート層」と完全に同じ意味ではありません。

コアとクライアント

クライアントの「情報」画面やログで、実際に使用しているコアを確認してください。未対応の項目に関するエラーが出た場合は、まず設定を実行するコアを特定し、そのうえで設定の変更やクライアントの更新が必要か判断します。

コアとクライアント#

Project VとV2Ray

Project Vはモジュール型のネットワークツール群で、V2Rayはその中核プロジェクトの名称です。日常的な会話では、この設定エコシステム全体を指してV2Rayと呼ぶこともあります。V2Rayは単一のプロトコルでも、特定のAndroidアプリの正式名称でもありません。解説を読む際は、クライアント、コア、VMessなどのどれを指しているのか確認し、異なる層の説明を混同しないようにしてください。

コアとクライアント#

Xray

Xrayはプロトコル処理、ルーティングの照合、接続の確立を担うコアの系統です。v2rayNGはXrayを使って設定を実行します。リンクをインポートできても、コアが含まれるすべての拡張項目に対応しているとは限りません。互換性を確認する際は、クライアントとコアのバージョン、ログに記録されたエラーを控えてください。特にREALITYや新しい転送設定を使う場合は確認が必要です。

コアとクライアント#

V2Fly

V2FlyはV2Rayの開発を継続するコミュニティプロジェクトです。コアは一般にv2flyと表記され、v2flyNGはこのコア系統を使用するAndroidクライアントです。Xrayとは同じエコシステムに由来しますが、すべてのプロトコル拡張や設定項目が共通とは限りません。コアを切り替える前に、現在のノードの要件を確認し、復元できるよう元の設定を保存してください。

コアとクライアント#

GUIクライアント

GUIクライアントはサブスクリプション、ノード編集、モード切り替え、ログなどの画面を提供し、設定をコアに渡して実行します。Androidではv2rayNGまたはv2flyNG、Windows、macOS、Linuxではv2rayNを利用できます。クライアント自体はノードサービスではありません。インストール後も有効な接続設定のインポートが必要です。同じ用語でも、クライアントによってメニュー内の場所が異なる場合があります。

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

サブスクリプショングループの設定でURLを保存し、更新を実行してからノード一覧を確認してください。サブスクリプションの取得、ノードへの接続、アプリからのアクセスは、それぞれ異なる確認段階です。

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

サブスクリプションURL

サブスクリプションURLは、クライアントが複数のノード設定を取得するためのもので、通常のWebページのURLではありません。v2rayNGのサブスクリプショングループ設定に入力して保存した後、メニューから更新を実行してください。URLに個人用のアクセス情報が含まれる場合があるため、機密情報として管理しましょう。スクリーンショットやログを共有したり、質問したりする際は、URLに含まれる識別情報を必ず隠してください。

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

ノード

ノードはクライアントに保存されたリモート接続設定です。通常、アドレス、ポート、認証情報、プロトコル、転送パラメーターが含まれます。一覧の名前はメモにすぎず、物理的な場所、回線品質、接続可能性を保証するものではありません。ノードはサブスクリプションから取得するほか、共有リンクから1件ずつ手動でインポートすることもできます。問題を調べる際は、名前だけで判断せず、具体的な項目とログを確認してください。

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

サブスクリプショングループと更新

サブスクリプショングループは提供元ごとに設定を整理するためのもので、更新するとリモートからノード情報を再取得します。更新後にノードが追加、削除、改名されることがあり、手動で変更したノードも上書きされる場合があります。独自の設定を長期保存する場合は、事前にエクスポートするか、別の設定として保存してください。一覧が空の場合は、更新ログ、URLの有効性、取得データの形式を確認します。

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

遅延と実接続遅延

遅延は、特定の方法で測定した所要時間です。TCP接続テストと、プロキシ経由でWebページにアクセスするテストでは、測定対象が異なります。実接続遅延は通常プロキシ経由でテスト先にアクセスして測りますが、名前解決やハンドシェイクなどが計測に含まれるかはクライアントの実装によります。比較する際は同じテスト方法と接続先を使ってください。数値が低くてもダウンロードが速いとは限らず、タイムアウトしてもすべての接続先にアクセスできないとは限りません。

ルーティングとDNS

ルーティング設定では、「どの条件で照合するか」と「照合後にどのアウトバウンドへ送るか」を分けて考えてください。DNSはアドレスを取得し、ルーティングは通信経路を選びます。相互に影響しますが、同じ設定ではありません。

ルーティングとDNS#

ルーティングルールとトラフィック分割

ルーティングルールは、ドメイン名、IP、ポートなどの条件で接続を照合し、プロキシ、直接接続、ブロックなどの送信先を指定します。ルールを使って通信ごとに異なる経路へ振り分けるのがトラフィック分割です。一般的なXrayのルーティング設定では、ルールは順番に評価され、先に一致したルールが後続の処理に影響します。ルールを追加する前にアウトバウンドのタグが存在するか確認し、条件の具体性に応じて適切な順序に並べてください。幅広いルールに先に一致してしまうのを防げます。

ルーティングとDNS#

GeoIP

GeoIPはカテゴリ別に整理されたIPアドレスの集合です。ルーティングではgeoip:privateのような形式でカテゴリを指定できます。参照されるのは読み込み済みデータファイルのアドレス範囲であり、リアルタイムの位置情報ではありません。また、サーバーの実際の設置場所を示すものでもありません。ドメイン名による接続がIPルールに一致するかどうかは、名前解決の結果とdomainStrategyにも左右されます。

ルーティングとDNS#

GeoSite

GeoSiteはカテゴリ別に整理されたドメイン名の集合で、関連するドメインをまとめてルーティング条件に指定できます。ルールで指定するカテゴリ名は、現在のデータファイルに存在している必要があります。他の設定からコピーしたカテゴリ名がそのまま使えるとは限りません。サービスの通信が想定どおりに振り分けられない場合は、サービスの表示名だけでルールの一致を判断せず、実際にアクセスしているドメイン名とリストの対象範囲を確認してください。

ルーティングとDNS#

domainStrategy

ルーティング設定のdomainStrategyは、照合時のドメイン名の扱いを決めます。AsIsは元のドメイン名で照合し、IPIfNonMatchは一致しなかった場合に名前解決を試み、IPOnDemandはIPルールの照合に必要な場合に名前解決します。同じ名前の項目が別の設定箇所にある場合、意味や選択肢が異なることがあります。単純な「高速化」スイッチではなく、すべてのアプリのDNSサーバーを直接決める設定でもありません。

ルーティングとDNS#

ローカルDNS

ローカルDNSとは、端末上でクライアントがドメイン名の問い合わせ処理に関与する機能です。「ローカル」だからといって、すべての応答がオフラインキャッシュから返されるわけではありません。v2rayNGで関連設定を有効にした後の問い合わせ経路は、VPNによる通信の取り込み、DNSルーティング、上流の名前解決設定によって変わります。アプリ独自の暗号化DNSが別経路を使う場合もあるため、スイッチの状態だけで判断せず、ログも確認してください。

ルーティングとDNS#

FakeDNS

FakeDNSはアプリに合成IPアドレスを返し、その後の接続がコアに渡された際にマッピングを使って元のドメイン名を復元します。これにより、ドメイン名に基づく処理を維持できます。DNS問い合わせ、通信の取り込み、関連するコア設定を連携させる必要があり、パブリックDNSのアドレスを入力するだけでは有効になりません。モードを切り替えてもアプリが古いアドレスをキャッシュしている場合は、接続を作り直すか、関連するキャッシュを消去してください。

ルーティングとDNS#

DNSリーク

DNSリークとは、ドメイン名の問い合わせが想定した経路で送信されない状態を指します。たとえば、プロキシ経由の想定でも別の経路で名前解決される場合があります。クライアントのDNS設定、問い合わせに使うアウトバウンド、ブラウザーやアプリ独自の暗号化DNSを確認してください。テストページに表示されるリゾルバー名は手がかりにすぎません。リゾルバーの場所だけでは実際の通信経路は分からないため、設定とログも照らし合わせましょう。

システムプロキシとTUN

まず、アプリの通信がクライアントに取り込まれているか確認し、その後でノードとルーティングを調べます。通信を取り込む範囲と、プロキシへの送信先は別の設定です。VPNやTUNに取り込まれた通信でも、ルールによって直接接続される場合があります。

システムプロキシとTUN#

システムプロキシ

システムプロキシは、OSがアプリに提供するプロキシのアドレスとポートの設定です。デスクトップ版v2rayNでは、この設定を使って対応アプリをローカルプロキシに接続させられます。独自のネットワーク処理やプロキシ設定を持つアプリは、システムプロキシに自動では従いません。ブラウザーではアクセスできても他のアプリでは使えない場合、ノードの障害と決めつける前に、通信が取り込まれている範囲を確認してください。

システムプロキシとTUN#

VPNとTUNモード

Androidクライアントは通常、システムのVPNサービスを使って選択した通信を取り込みます。初回起動時にはシステムの許可が必要です。デスクトップ版v2rayNのTUNモードは、仮想ネットワークインターフェースを通じて通信を取り込みます。どちらも独立した商用VPNサービスへの接続を意味するものではなく、最終的な送信先はノードとルーティングで決まります。デスクトップでTUNを有効にするには追加の権限が必要な場合があり、他の通信制御ツールとの競合にも注意してください。

システムプロキシとTUN#

アプリ別プロキシ

アプリ別プロキシでは、アプリごとに通信をクライアントの処理対象にするかどうかを指定します。通常はAndroidのVPNモードと組み合わせて使用します。設定を開いたら「選択したアプリのみを対象にする」のか「選択したアプリを除外する」のか、まず確認してください。同じチェック操作でもモードによって意味が逆になります。アプリをクライアントに取り込んだ後もルーティング判定は行われるため、選択した通信がすべてプロキシノードを通るとは限りません。

システムプロキシとTUN#

ローカルインバウンドとアウトバウンド

インバウンドは、ローカルのSOCKSやHTTPリスナーなどを通じてアプリからコアに渡された通信を受け取ります。アウトバウンドは、その通信をリモートプロキシ、直接接続、その他の方法で送信します。ルーティングではoutboundTagなどの項目でアウトバウンドのタグを参照します。このタグは設定内の識別子であり、プロトコル名ではありません。ローカルの待ち受けポートを変更した場合は、プロキシを手動設定しているアプリ側も変更してください。端末内だけで使う場合は、待ち受け範囲を制限しておきましょう。

用語に対応する設定手順

項目の意味を確認したら、具体的な手順に戻って動作を検証します。元の設定を保存し、一度に1項目だけ変更して、ログに記録された実際のエラーを確認してください。

サブスクリプションのインポートと接続確認

ノード一覧が空の状態から設定する場合は、サブスクリプションの保存、更新、ノードの選択、接続確認の順に進めてください。最初に高度なルーティングを変更する必要はありません。

使い方ガイドを見る

クライアントの選び方とエラー対処

まず端末のプラットフォームとコアの要件を確認してからクライアントを選びます。サブスクリプションが空、起動できない、アプリがプロキシを使わないなどの問題は、症状に応じて対処法を確認してください。