プロトコルとトランスポート
VMess
プロキシプロトコル · ユーザー識別子による認証
VMessはProject Vのエコシステムに属するプロキシプロトコルです。ユーザー識別子で認証し、プロトコル独自のセキュリティ機構も備えています。端末の時刻が大きくずれていると認証に影響する場合があるため、接続トラブルの際はシステム時刻が同期されているか確認してください。VMessとトランスポート方式は別の階層です。ユーザー識別子が同じでも、設定全体が一致するとは限りません。
CONCEPT REFERENCE / 25 TERMS
V2Ray用語ガイド
設定の階層ごとに用語を確認しましょう。プロトコルは通信の取り決め、コアは接続の処理、クライアントは設定の管理、ルーティングはアウトバウンドの選択、DNSは名前解決を担います。まず概念を整理してからパラメーターを調整してください。
操作手順に沿ってマニュアルを読む →PROTOCOL / TRANSPORT
プロトコルとトランスポート
プロトコル名だけでは通信速度は分からず、特定のトランスポート方式が自動で含まれるわけでもありません。設定をインポートした後も、クライアントと選択したコアがその組み合わせに対応しているか確認してください。
プロトコルとトランスポート
VLESS
軽量プロキシプロトコル
VLESSはユーザー識別子で認証しますが、プロトコル自体は通信全体を暗号化しません。実際のセキュリティはTLSやREALITYなどの保護層と設定によって異なります。設定内のflowもサーバーおよびコアの対応状況に合わせる必要があります。VLESSを使う際は、プロトコル名だけで接続を判断せず、パラメーターの組み合わせ全体を確認してください。
プロトコルとトランスポート
Trojan
プロキシプロトコル · パスワード認証
Trojanは通常、TLS接続上で動作し、パスワードで認証します。サーバーアドレス、ポート、パスワード、サーバー名は個別に確認してください。接続先アドレスと証明書のドメインが別の役割を持つ場合もあります。証明書の検証に失敗した場合は、サーバー名、証明書チェーン、端末の時刻を確認し、検証の無効化を常用の解決策にしないでください。
プロトコルとトランスポート
REALITY
トランスポート保護機構
REALITYはXrayエコシステムのトランスポート保護機構で、VLESSと並ぶ独立したプロキシプロトコルではありません。VLESSと組み合わせることが多く、クライアントの対応状況を確認したうえで、サーバーが指定する公開鍵、サーバー名、Short IDなどを一致させる必要があります。クライアントによって項目名が異なる場合があるため、通常のTLS設定にそのまま当てはめないでください。
プロトコルとトランスポート
トランスポート方式
Transport · TCP / WebSocket / gRPC
トランスポート方式は、プロキシプロトコルがデータを運ぶ方法を示します。主な方式はTCP、WebSocket、gRPCです。WebSocketのパスやリクエストホスト、gRPCのサービス名などはサーバー側と一致させる必要があります。方式の変更には通常、サーバー側の設定も必要です。クライアントの選択肢を変更するだけでは完了しません。
CORE / ECOSYSTEM
コアとエコシステム
プロジェクト、クライアント、コアはそれぞれ別の主体です。機能を確認する際は、クライアント名だけでなく、実際に動作しているコアとそのバージョンも確認してください。
コアとエコシステム
Project V
モジュール型ネットワークプロキシのエコシステム
Project Vは、モジュール型ネットワークプロキシの機能を軸に形成されたプロジェクトとエコシステムです。V2Rayはその技術体系を理解するための重要な入口です。特定のGUIクライアントの名称でも、共通のサブスクリプションサービスでもありません。V2Ray公式サイトやクライアントの配布元を探す際は、コアのプロジェクト、GUIのプロジェクト、ドキュメントを提供するナレッジサイトを区別してください。
コアとエコシステム
V2Fly
V2Rayコミュニティのコアプロジェクト
V2FlyはV2Rayコアの開発を引き継ぐコミュニティプロジェクトで、インバウンド、アウトバウンド、ルーティング、DNSなどの機能を提供します。v2flyNGは、このコア体系を利用するAndroid向けGUIクライアントの1つです。利用できるプロトコル、設定形式、機能は実際のコアのバージョンによって異なります。画面に項目が表示されているだけで、対応していると判断しないでください。
コアとエコシステム
Xray
独自に開発されるプロキシコア
XrayはV2Rayの技術体系を基にし、共通する概念を引き継ぎながら独自機能を開発しています。REALITYもその機能の1つです。一部のプロトコルや項目がV2Flyと共通していても、設定全体に互換性があるとは限りません。コアを切り替えた後はログと生成された設定を確認し、専用項目が引き続き有効かチェックしてください。
コアとエコシステム
プロキシコア
コア · 接続を実行するコンポーネント
プロキシコアは接続、プロトコル、ルーティング、名前解決を実際に処理し、GUIクライアントは設定の管理や起動・停止を担います。クライアントの画面が更新されても、コアが同時に更新されたとは限りません。また、画面上で設定を保存できても、現在のコアがその設定を実行できるとは限りません。問題の切り分けでは、画面操作のエラーとコアの実行エラーを分けて確認しましょう。
コアとエコシステム
GUIクライアント
v2rayN / v2rayNG / v2flyNG
GUIクライアントはウィンドウ、メニュー、スイッチを使って、サブスクリプション、サーバー設定、プロキシ接続を管理します。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けです。利用できる機能はコアとアプリのバージョンにも左右されます。クライアント名はプロトコル名とは異なり、1つのクライアントで複数のプロトコル設定を管理できる場合もあります。
OSに合ったクライアントを選ぶ →CLIENT / SUBSCRIPTION
クライアントとサブスクリプション
設定の入手元を確認してから、インポートと更新を行ってください。リストにサーバーが表示されても、設定が読み込まれたことを示すだけで、接続経路が利用可能と確認されたわけではありません。
クライアントとサブスクリプション
サブスクリプション
Subscription · 設定の配布方式
サブスクリプションはURLを使って複数のサーバー設定を取得・更新する仕組みです。クライアントが配信データの形式に対応している必要があります。URLに認証情報が含まれる場合があるため、スクリーンショット、ログ、問い合わせ内容を共有する際はURL全体を隠してください。サブスクリプション変換で変わるのは設定の表現形式です。新しいサーバーが追加されたり、コアに未対応のプロトコルが使えるようになったりするわけではありません。
クライアントとサブスクリプション
ノード
Node · サーバー設定1件
ノードは、クライアント上のサーバー接続設定1件を指す一般的な呼び方です。通常、アドレス、ポート、プロトコル、認証、トランスポートのパラメーターが含まれます。リスト上の表示名はラベルにすぎず、サーバーの物理的な所在地や回線品質を正確に示すとは限りません。名前が異なる2つの設定が同じアドレスを指す場合もあるため、違いを確認するには実際のパラメーターを比較してください。
クライアントとサブスクリプション
サブスクリプショングループ
Subscription group · 配信元の管理
サブスクリプショングループは、配信元ごとに設定を整理し、個別の更新、検索、削除をしやすくします。通常はクライアント上の管理単位にすぎず、通信経路を自動で決めるものでも、ルーティングルールが参照するアウトバウンドタグでもありません。サブスクリプションから生成された項目を手動で変更する前に、更新時に変更が上書きされるか確認してください。必要に応じて独立した設定として保存します。
クライアントとサブスクリプション
システムプロキシ
System proxy · アプリの接続方式
システムプロキシは、OSの設定に従うアプリをクライアントのローカル待ち受けポートへ接続します。独自のネットワーク設定を使うアプリもあるため、システムプロキシを有効にしても、すべての通信がクライアントに入るとは限りません。取り込まれた通信のアウトバウンドは引き続きコアのルーティングで選択されます。システムプロキシのスイッチと、グローバルやバイパスなどのルーティングモードを混同しないでください。
プロキシモードの解説を見る →クライアントとサブスクリプション
実接続遅延
Connection test · プロキシ経由の接続テスト
実接続遅延は通常、クライアントがプロキシ経由でテスト先にアクセスした際の所要時間を指します。ハンドシェイクなどを含むかは実装によって異なります。ポートへの到達性だけを調べるTCPテストとは異なり、ファイルのダウンロード速度に直接換算することもできません。結果を比較する場合は、テスト先、ネットワーク環境、測定方法をそろえてください。一度の失敗だけで設定が無効だとは判断できません。
ROUTING / OUTBOUND
ルーティングとトラフィック振り分け
通信はまずコアに入り、その後、条件に応じてアウトバウンドが選択されます。ルーティングを確認する際は、ルールの順序、利用可能なドメイン情報、データセットの内容をあわせて確認してください。
ルーティングとトラフィック振り分け
ルーティングルール
Routing rule · 条件によるマッチング
ルーティングルールは、ドメイン、IP、ポート、ネットワーク種別、インバウンドタグなどの条件に応じてアウトバウンドを選択します。一般にルールは順番に評価されるため、具体的な条件を広い条件より先に配置し、先にマッチしてしまうのを防ぎます。ルール間の順序と、1つのルール内で複数の項目を組み合わせる方法は別の問題です。変更する前にマッチングの仕組みを確認してください。
ルーティングとトラフィック振り分け
トラフィック振り分け
Traffic routing · 条件に応じた経路選択
トラフィック振り分けは、通信の特徴に応じて直接接続、プロキシ、ブロックなどの経路を選択する方式です。通常、グローバルモードはコアに取り込まれた通信を優先的にプロキシ経由にする設定で、すべてのアプリの通信を自動で捕捉するわけではありません。バイパス系のモードではルールに従って一部の通信を直接接続します。実際の結果はメニュー名ではなく、クライアントが生成するルーティング設定で決まります。
ルーティングとトラフィック振り分け
GeoIP
IPアドレスの分類データ
GeoIPはIPアドレスをカテゴリ別にまとめ、ルーティング条件から参照できるようにします。たとえばgeoip:privateはプライベートアドレス範囲の判定によく使われます。結果はデータセットの収録内容や更新状況に左右され、サーバーの実際の所在地をリアルタイムで測定するものではありません。宛先がドメインの場合、IPルールを適用できるかどうかはドメイン戦略や名前解決の結果にも左右されます。
ルーティングとトラフィック振り分け
GeoSite
ドメインの分類データ
GeoSiteはドメインをカテゴリ別にまとめます。たとえばgeosite:cnをドメインのマッチング条件として使えますが、タグの具体的な内容は使用するデータセットによって異なります。メンテナーが登録したドメイン一覧に基づいて判定するため、アクセス先サーバーの所在地を調べる機能ではありません。ドメイン集合とIP集合は用途が異なり、同じ接続先でも分類結果が一致するとは限りません。
ルーティングとトラフィック振り分け
アウトバウンドタグ
tag / outboundTag
アウトバウンドオブジェクトはtagで識別子を宣言し、ルーティングルールからoutboundTagで参照します。direct、proxy、blockはよく使われる慣例名ですが、実際の動作はオブジェクトのプロトコルと設定で決まります。タグ名を入力しただけでアウトバウンドが作成されるわけではありません。参照先と実際の設定を一致させてください。
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}DNS / TRAFFIC CAPTURE
DNSとTUN
名前解決と通信の取り込み設定は互いに影響します。設定を変更する前に元に戻せる状態を保ち、ネットワークアダプター、ルート、リゾルバーを同時に変更して原因を特定できなくならないようにしてください。
DNSとTUN
TUNモード
仮想ネットワークインターフェースによる通信の取り込み
TUNモードは仮想ネットワークインターフェースとシステムルートを使って通信を取り込み、システムプロキシに従わない一部のアプリにも対応します。管理者権限やネットワークへのアクセス許可が必要な場合があり、対象範囲はクライアントの実装とシステムルートによって異なります。TUNを有効にしてもすべての通信がプロキシ経由になるわけではありません。トラフィック振り分け、DNS、ローカルネットワークの例外、ほかのネットワークソフトとの競合も考慮してください。
DNSとTUN
FakeDNS
合成IPアドレスとドメインの対応付け
FakeDNSはアプリに合成IPアドレスを返し、そのアドレスと元のドメインとの対応を保持します。後続の接続時にドメインを復元し、ルーティングに利用できます。公開DNSリゾルバーではなく、ドメインが実際にそのIPアドレスへ名前解決されたことを示すものでもありません。DNSの取り込みと通信の捕捉を連携させる必要があります。関連モードを終了した後もアプリに合成アドレスがキャッシュされている場合は、再度名前解決するかアプリを再起動してください。
DNSとTUN
DNSリーク
想定した経路から外れる名前解決リクエスト
DNSリークとは、名前解決リクエストが想定した経路を通らず、別のリゾルバーやインターフェースから送信される状態です。判定するには、まず想定していたポリシーを明確にし、OS、ブラウザー独自の名前解決、コアのDNS、アプリのキャッシュを確認してください。テストページに表示されたリゾルバーの地域だけでは、リークの証拠にはなりません。重要なのは、リクエストが実際にどの経路を通ったかです。
DNSとTUN
ドメイン戦略
routing.domainStrategy
ルーティングのdomainStrategyは、マッチング中にドメインをいつ名前解決し、IPルールの判定に使うかを制御します。たとえばIPIfNonMatchは、ドメインがルールにマッチしなかった場合に名前解決を試み、その後に再度マッチングします。アウトバウンド接続先のアドレス選択戦略ではありません。同じ、または似た名前の項目でも、設定内の階層を確認して意味を判断してください。この設定を変更しても、DNS設定全体が完了するわけではありません。
DNSとTUN
トラフィックスニッフィング
Sniffing · 宛先情報の抽出
トラフィックスニッフィングは、一部の接続からプロトコルの特徴を読み取り、宛先ドメインなどの情報を抽出します。宛先IPしか含まない接続をドメインベースのルーティングに利用する際に役立ちます。アプリの内容を復号する機能ではなく、識別できる範囲はプロトコルや暗号化方式によって異なります。ルーティングだけに使うのか、宛先アドレスも書き換えるのかは設定によって異なるため、互換性の問題が起きた場合は適用範囲を確認してください。
用語の理解から設定へ
用語で設定の階層を把握したら、具体的なメニューの場所や確認手順は対応するドキュメントを参照してください。バージョンによって画面上の名称が異なる場合は、パラメーターの意味と実行ログを基準に判断します。
初回インストールと設定のインポート
クライアントの選択、サブスクリプションのインポート、接続方式の設定、接続確認の順に進め、設定は一度に1つの階層だけ変更してください。
使い方ガイドを読む →ルーティングとトラブルシューティング
まず通信がコアに入っているか確認し、次にルールのマッチングとアウトバウンド接続を調べてください。DNSの問題をすぐにプロトコルの選択ミスと決めつけないことが大切です。
よくある質問を見る →