プロキシプロトコル
VMess
VMessはProject Vのエコシステムに属するプロキシプロトコルで、認証とデータ暗号化の仕組みを備えています。ユーザーID、サーバーアドレス、トランスポート設定を一致させる必要があり、アドレスとポートだけでは接続できません。システム時刻が大きくずれていると認証に影響することがあるため、認証エラーが発生した場合は端末の時刻も確認してください。
プロトコル · 設定項目 · オプション
V2Ray用語集
まずプロトコル、トランスポート、コアの違いを確認し、次に設定項目を探しましょう。以下の27項目を設定レイヤー別に分類しています。用語名からページ内リンクをたどれます。
設定値を変更する場合は設定リファレンス →をご覧ください。サーバー設定を初めて読み込む場合は、先に使い方ガイド →をご確認ください。
プロトコルとトランスポート
プロキシプロトコルはデータの構成や認証方法を定め、トランスポート方式は接続の運び方を決めます。セキュリティレイヤーは暗号化と相手の認証を担います。名称が似ていても、相互に置き換えられるものではありません。
プロキシプロトコル
VLESS
VLESSは軽量なプロキシプロトコルで、単体ではデータを暗号化せず、通常はTLSまたはREALITYと組み合わせて使います。クライアントとサーバーでユーザーID、トランスポート方式、適用するフロー制御の設定を一致させてください。共有リンクがvless://で始まっていても、それだけではセキュリティレイヤーとトランスポートの組み合わせまでは分かりません。
プロキシプロトコル
Trojan
Trojanは通常TLS接続上で動作し、パスワードで認証します。パスワードが正しくても接続設定全体が正しいとは限りません。サーバー名、証明書の検証、トランスポート方式も一致させる必要があります。証明書エラーが発生した場合は、証明書の検証を無効にして回避するのではなく、ドメイン名、時刻、証明書チェーンを確認してください。
トランスポートセキュリティ
REALITY
REALITYはXrayエコシステムのトランスポートセキュリティ機能で、VLESSと並ぶ独立したプロキシプロトコルではありません。通常、クライアントではサーバーから提供された公開鍵、サーバー名、Short IDなどを一致させる必要があります。項目の詳細はコアのバージョンによって異なります。画面上のセキュリティ種別を変更するだけでは、通常のTLS設定を使用可能なREALITY設定に変換できません。
トランスポートセキュリティ
TLS
TLSは通信を暗号化し、完全性を保護するとともに、通信相手を認証します。サーバーアドレスにはIPアドレスを指定できますが、証明書の検証に使うサーバー名は、実際の証明書とサーバー側の設定に合わせる必要があります。画面の「安全でない接続を許可」は通常、証明書検証に関する設定です。接続品質や速度を改善するために常用するオプションではありません。
トランスポート方式
WebSocket
WebSocketはプロキシ通信を運べますが、プロキシ利用者の認証方法を定めるものではありません。利用時はパス、Host、ポートに加え、リバースプロキシが接続を正しく転送しているか確認してください。サーバー名、HTTP Host、接続先アドレスはそれぞれ異なる役割を持つ場合があり、すべて同じ値にすればよいとは限りません。
コアとエコシステム
画面は管理を担当し、コアは処理を実行します。あるプロトコルが使えるか判断するには、クライアントが対応する設定を生成できるかだけでなく、実際に呼び出されるコアがその設定に対応しているかも確認してください。
プロジェクトの背景
Project V
Project Vは、V2Rayのモジュール型ネットワークプロキシ設計と関連エコシステムを理解するための背景概念であり、クライアントの接続モードではありません。関連技術では、受信、送信、ルーティング、トランスポートの機能が別々のモジュールに分かれています。資料を読む際は「V2Ray」という総称だけで互換性を判断せず、対象のコアとバージョンを確認してください。
コアプロジェクト
V2Fly
V2FlyはV2Rayコアを保守するコミュニティプロジェクトです。コアはプロトコル接続、ルーティング、DNSなどを実際に処理します。v2flyNGは関連するコア機能を呼び出すAndroid向けGUIクライアントで、両者は異なるソフトウェアレイヤーに属します。設定項目はコアの形式とバージョンに照らして確認し、他のコアで追加された機能をそのまま適用しないでください。
コアプロジェクト
Xray
XrayはV2Rayの技術体系から派生し、その後、独自のプロトコルやトランスポート機能を発展させました。REALITYはそのエコシステムを代表する機能の一つです。XrayとV2Flyは設定構造の一部が似ていますが、すべての項目や動作が同じとは限りません。機能が見つからない場合は、GUIクライアントだけでなく、実際に動作しているXrayコアのバージョンも確認してください。
アプリケーションレイヤー
GUIクライアント
GUIクライアントは、サブスクリプションの読み込み、サーバー選択、ログ確認、設定変更などの画面を提供し、通常はコア用の実行設定を生成します。当サイトで紹介するv2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けです。設定一覧に項目が表示されても、それは読み込みが成功したことを示すだけです。コアの起動や実際の接続を確認する必要があります。
クライアントの選び方を見る →動作方式
コアの切り替え
コアの切り替えとは、クライアントが呼び出すネットワーク処理プログラムを変更することです。画面テーマの変更とは異なります。切り替える前に、使用中のプロトコル、セキュリティレイヤー、ルーティング設定が切り替え先のコアに対応しているか確認してください。切り替え後は、設定の再読み込みが必要になる場合があります。特定のコア専用の機能は、クライアントに同名の項目が残っていても、別のコアで自動的に有効になるわけではありません。
コアの対応範囲を見る →設定ファイルの構造
まず通信がどこから入るかを確認し、次にルールがどこへ送るかを見ていきましょう。以下ではJSONやログで検索しやすいよう、設定項目名の大文字・小文字を原文のまま記載します。
設定ファイルの構造
inbounds · 受信設定
inboundsは受信接続用の配列で、アプリや他の機器からの接続をコアがどのように受け付けるかを定義します。待ち受けアドレス、ポート、プロトコル、通信のスニッフィングなどを設定でき、SOCKSやHTTPをローカルの接続口として使えます。ループバックアドレスで待ち受ける場合と、すべてのネットワークインターフェースで待ち受ける場合では、外部からアクセスできる範囲が異なります。LANに接続口を公開する前に、認証とファイアウォールの設定を確認してください。
設定ファイルの構造
outbounds · 送信設定
outboundsは送信接続用の配列で、プロキシ経由、直接接続、通信のブロックなど、通信の処理方法を定義します。画面上のサーバー一覧をそのまま複製したものではなく、コアが実際に選択できる送信先の集合です。ルーティングルールが参照する送信先は、設定内に存在している必要があります。一般的なV2Ray / Xrayの設定では、どのルールにも一致しない通信は通常、最初の送信先を使います。
設定オブジェクトの参照
tag と outboundTag
tagは設定オブジェクトの名前を指定し、ルーティング内のoutboundTagは送信先の同じタグを参照します。タグは識別子にすぎません。たとえばdirectという名前の送信設定でも、直接接続用のプロトコルを実際に設定する必要があります。名前だけで直接接続になるわけではありません。参照時は綴りと大文字・小文字を一致させ、存在しない送信先を指定しないようにしてください。
トランスポート設定
streamSettings
streamSettingsは、接続のトランスポート方式とセキュリティ設定をまとめます。ユーザーIDやパスワードなどのプロトコル認証情報とは別の設定です。内部にはトランスポートの種類、TLS、REALITYなどの設定が含まれる場合があり、構造はコアのバージョンによって異なります。設定をコピーする際はサーバー側の要件と全体を照合してください。トランスポート名だけを変更して、互換性のないサブ項目を残さないようにしましょう。
受信側の処理
sniffing · 通信のスニッフィング
sniffingは通常、受信設定に追加します。接続開始時の一部データを解析し、プロトコルやドメインの手掛かりを特定して、後続のルーティングを補助します。暗号化された内容を復号する機能ではなく、すべての接続でドメインを特定できるわけでもありません。コアによってルーティング補助のオプションや宛先の上書き動作が異なるため、有効にした後はログを確認し、ルールがどの情報を使ったかを確かめてください。
ルーティングとDNS
ルール分岐の結果は、照合条件、ルールの順序、利用可能なドメイン情報によって決まります。DNSは名前解決を担当し、送信先の選択とは別の機能です。両者は連携しますが、同じ設定として扱うことはできません。
通信の振り分け先
ルーティングルールとルール分岐
ルール分岐とは、ドメイン、IP、ポート、受信側のタグなどの条件に応じて、接続ごとに送信先を選ぶことです。一般的なフィールド形式のルールは上から順に評価され、最初に一致したルールで送信先が決まるため、具体的なルールを広範囲に一致するルールより前に置くのが基本です。1つのルールに複数の条件を指定する場合は、それらの組み合わせ方も確認してください。すべての条件がいずれか1つに一致すればよいとは限りません。
ルーティング設定を見る →IPルールデータ
GeoIP
GeoIPはIPアドレスの範囲をカテゴリや地域ごとに整理したデータで、ルーティングからgeoip:privateなどのタグで参照できます。利用できるタグと対象範囲はローカルのデータファイルによって異なり、すべてのデータソースに同じ情報が含まれるとは限りません。IPアドレスの登録地域は、Webサイトの運営地域を示すものではありません。共有IPアドレスやアドレス変更がある場合は、ドメインルールも併せて確認してください。
ドメインルールデータ
GeoSite
GeoSiteはカテゴリごとに整理されたドメインルールの集合で、通常はgeosite:cnのような形式でルーティングに使います。照合するのはドメインであり、接続先IPの地域ではありません。接続時にIPアドレスしか分からない場合、該当ルールに一致しないことがあります。データを更新するとカテゴリの対象範囲が変わるため、ルールを変更する前にクライアントが実際に読み込んでいるデータファイルを確認してください。
ルーティング時の名前解決方針
domainStrategy
routing.domainStrategyは、ルーティングルールの照合時にドメインを解決するか、いつ解決するかを制御します。一般的な値はAsIs、IPIfNonMatch、IPOnDemandです。たとえばIPIfNonMatchは、ドメインがルールに一致しない場合に名前解決を試し、その結果をIPルールの照合に使います。他のオブジェクトにある同名の設定項目は別の処理段階に影響する場合があるため、ここでの意味をそのまま当てはめないでください。
ドメインとIPの対応付け
FakeDNS
FakeDNSはドメインに合成IPを割り当て、両者の対応を保持することで、接続を引き継いだプロキシプログラムが宛先ドメインを復元できるようにします。割り当てられるIPはWebサイトの実際のサーバーアドレスではなく、連携する通信経路で識別・処理する必要があります。FakeDNSだけを有効にして接続を正しく引き継げないと、アクセスに失敗することがあります。DNSの問い合わせ経路、ルーティング、キャッシュを合わせて確認してください。
名前解決の経路
DNSリーク
DNSリークとは、ドメインの問い合わせが想定した名前解決経路を通らないことで、DNSの名前解決に失敗することとは異なります。OSのリゾルバー、ブラウザーのセキュアDNS、アプリ内蔵の名前解決機能、プロキシで捕捉されない問い合わせなどが結果に影響します。調査時は、想定しているリゾルバーと実際の問い合わせ先を確認してください。Webページにアクセスできるだけでは、DNSが設計どおりに処理されているとは判断できません。
DNS設定を見る →サブスクリプションとクライアント
サブスクリプションは設定の取得元、ノードは個々の設定レコード、プロキシモードはアプリの通信をコアへ渡す方法です。テスト結果は測定方法と併せて確認し、1回の測定だけで長期的な品質を判断しないでください。
設定の取得元
サブスクリプション
サブスクリプションは、クライアントが複数のサーバー設定を取得するための更新用URLです。通常はURLにアクセスすると、クライアントが読み込める形式の設定が返されます。サブスクリプションURLにはアクセス情報が含まれる場合があるため、公開画像に載せたり、他人に転送したりしないでください。更新すると設定を再取得しますが、備考が上書きされるか、手動変更が保持されるか、無効な項目が削除されるかは、クライアントやグループ設定によって異なります。
サブスクリプション管理を見る →サーバー設定レコード
ノード
ノードは、クライアントに登録する個々のサーバー接続設定を指す一般的な呼び方です。通常、アドレス、ポート、プロトコル、認証情報、トランスポート設定が含まれます。リスト上の名前は備考にすぎず、サーバーの所在地、帯域、運営元を示すものではありません。名前が違っていても同じサーバーを指すことがあるため、重複を調べる際は実際の設定項目を比較してください。
接続テスト
レイテンシと実接続テストのレイテンシ
レイテンシは測定方法と併せて判断する必要があります。TCP接続の確立時間と、プロキシ経由でWebページを取得する時間では、測定する処理が異なります。「実接続テスト」のレイテンシは通常、選択したプロキシ経由で指定のテスト先にアクセスして測定します。ハンドシェイクや応答待ちが含まれることがあり、詳細はクライアントによって異なります。数値が低くてもダウンロードが継続的に速いとは限りません。タイムアウトの原因はテスト先、DNS、証明書にある場合もあります。
アプリの通信設定
システムプロキシ
システムプロキシは、クライアントがローカルプロキシのアドレスとポートをOSに登録する機能です。通常はこの設定に従うアプリにのみ影響します。クライアントの「グローバル」や「ルール」などのルーティング設定とは別のレイヤーであり、システムプロキシを設定しても、すべての通信がコアを通るとは限りません。アプリが独自のプロキシを指定していたり、独立したネットワークスタックを使用していたりする場合は、接続経路を別途確認してください。
システムプロキシの説明を見る →ネットワーク通信の取り込み
TUNモード
TUNモードは仮想ネットワークインターフェースを通じて、OSのルーティング条件に合致するIP通信を受け取ります。システムプロキシを参照しないアプリの通信も、プロキシ処理の経路に取り込める場合があります。通常、追加の権限、ルーティングの変更、DNSの制御が必要で、動作はクライアントと使用するコアによって異なります。TUNはすべてのV2Ray / Xray JSONで共通の単一スイッチではなく、すべての接続がプロキシ経由になることを意味するものでもありません。
TUN設定の対応範囲を見る →