VMessプロトコル
VMessはユーザー認証を備えたプロキシプロトコルで、ユーザーIDには通常UUIDを使います。クライアントとサーバーでは、伝送方式や関連するセキュリティ設定も一致させる必要があります。アドレスとポートだけでは接続できません。認証は時刻の条件にも依存するため、接続できない場合はノードを変える前に端末のシステム時刻も確認してください。
V2Ray / 用語集
V2Ray用語解説：
プロトコル・設定・クライアント機能
まず設定のレイヤーを整理してから、各項目の意味を確認しましょう。プロトコルは接続する両端の通信方式を定め、コアは設定を実行し、GUIクライアントはノードやサブスクリプション、操作画面を管理します。
よく使われる用語を30項目掲載しています。各カードはアドレスバーのアンカーから個別に参照できます。各項目が利用できるかどうかは、使用中のクライアントとコアのバージョンで確認してください。
01 / Protocol & transport
プロトコルと伝送方式
プロトコル、伝送方式、通信保護はそれぞれ異なるレイヤーです。ノード名にプロトコル名だけが記載されていても、接続に必要な設定全体はわかりません。
VLESSプロトコル
VLESSは軽量なプロキシプロトコルです。VMessと同じペイロード暗号化の仕組みは備えておらず、実際の運用では通常TLSまたはREALITYと組み合わせます。ユーザーID、伝送方式、必要に応じてflowの設定をサーバー側の指定に合わせてください。VLESS対応でも、すべての組み合わせが使えるとは限りません。コアが必要な機能に対応しているか確認してください。
Trojanプロトコル
Trojanは通常、TLS接続上でプロキシ通信を行い、パスワードで認証します。パスワードとTLSのサーバー名は別の設定項目で、互いに置き換えることはできません。接続先アドレスと証明書のドメイン名が異なる場合もあります。証明書エラーが出たら、検証を無効にするのではなく、サーバー名、時刻、証明書チェーンを確認してください。
REALITYによる通信保護
REALITYはXrayのエコシステムで使われる通信保護の仕組みで、VLESSと並ぶ独立したプロキシプロトコルではありません。通常、サーバーの公開鍵、サーバー名、ショートID、クライアントフィンガープリントなどを設定します。一般的なTLSサーバーと同じ証明書の運用方法は使わないため、TLSノードのセキュリティ項目を1つ変更しただけでREALITYに切り替わるわけではありません。
伝送方式
伝送方式は、TCP、WebSocket、gRPCなどを使ってプロキシデータを基盤の接続経由で送る方法を定めます。パス、サービス名、リクエストヘッダーなどの項目は、使用する伝送方式に固有の設定です。すべてのプロトコルで同じ項目を使うわけではありません。ノードを設定する際は、プロトコル、伝送方式、セキュリティの順に確認してください。パスが一致しないとハンドシェイクに失敗することがあります。
02 / Core & ecosystem
コアとエコシステム
クライアントの画面は操作を受け持ち、コアは接続を処理します。互換性を確認する際は、両方の実装を確認してください。
Project Vエコシステム
Project Vは、V2Rayや関連するネットワークツールを理解する際によく使われるエコシステム名です。ノードのプロトコルでも、GUIの名称でもありません。エコシステムを説明する際は、プロキシコア、クライアント、設定形式を区別してください。名前が似たツールでも、コアや機能の範囲が異なる場合があります。
V2Flyコアプロジェクト
V2FlyはV2Rayプロジェクトの流れをくむコミュニティプロジェクトで、コアが設定の解析、インバウンドの受け付け、アウトバウンド接続などを処理します。Androidクライアントのv2flyNGは、このコアを使う選択肢の1つです。V2FlyとXrayはそれぞれ独自に機能が進化しているため、コアを切り替える前に、既存ノードや設定フィールドとの互換性を確認してください。
Xrayコア
XrayはV2Rayから派生したプロキシコアのプロジェクトです。REALITYなどの機能には、対応する実装が必要です。v2rayNGはXrayを使用します。デスクトップクライアントのv2rayNが実際に使うコアは、画面とログで確認してください。クライアントの更新とコアの更新は別の操作です。設定フィールドのエラーを調べる際は、使用中のコアのバージョンを記録してください。
GUIクライアント
GUIクライアントでは、ノード一覧、サブスクリプションの更新、モード切り替え、ログ確認などを操作できます。通常、設定を生成してコアを呼び出します。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けです。画面に表示される名前やグループは管理用の情報であり、同じ名前のフィールドがコア設定ファイルに含まれるとは限りません。
03 / JSON structure
設定ファイルの構造
接続はインバウンドから入り、ルールによってアウトバウンドが選ばれます。タグは設定項目どうしを関連付け、ポリシーは一部の接続動作を制御します。
JSON設定ファイル
config.jsonはコア設定ファイルでよく使われる名前です。通常、log、inbounds、outbounds、routing、dnsなどの項目を含みます。JSONではカンマ、引用符、データ型に厳密なルールがあります。マニュアルにある部分的な例だけでは起動できない場合があります。クライアントが生成する実行用設定は再生成時に上書きされることもあるため、編集前にカスタム設定の保存場所を確認してください。
インバウンド
インバウンド配列は、コアが接続を受け付ける方法を定義します。ローカルの入口にはSOCKSやHTTPがよく使われます。待ち受けアドレスとポートによってアプリの接続先が決まります。待ち受けアドレスをループバックから全インターフェースに変更すると、接続可能な範囲が広がります。ポートを変更した場合はアプリ側のプロキシ設定も更新し、他のプロセスがそのポートを使用していないことを確認してください。
アウトバウンド
アウトバウンド配列は、コアから接続を送出する方法を定義します。リモートプロキシへの接続、直接接続、通信の遮断などを指定できます。ルーティングルールは通常、クライアント画面に表示されるノード名ではなく、アウトバウンドのタグを参照します。ルールに一致しない場合はデフォルトのアウトバウンド動作も関わるため、個別のルールだけでなくアウトバウンド全体を確認してください。
設定タグ
tagは設定オブジェクトを参照するための名前です。たとえば、直接接続のアウトバウンドにdirectという名前を付け、ルールのoutboundTagから参照できます。ルールのinboundTagは、対象とするインバウンドを限定するために使えます。タグはプロトコルのキーワードではなく、設定に応じて名前を決められます。ただし参照先と名前を一致させ、アウトバウンドのタグが重複して曖昧にならないようにしてください。
接続ポリシー
policyは、ハンドシェイクやアイドル接続のタイムアウト、特定の統計オプションなど、コアの一部の動作を設定します。ドメインごとにプロキシ接続か直接接続かを選ぶroutingとは役割が異なります。フィールド、ユーザーレベル、統計条件への対応状況はコアごとに異なるため、他のツールの設定をそのまま流用せず、対象コアのドキュメントを確認してください。
04 / Routing & DNS
ルーティングとDNS
まず、ルールがドメイン名とIPアドレスのどちらを参照するか確認し、次に名前解決の場所を確認します。ルールの一致とDNS問い合わせの経路は分けて調べてください。
ルーティングルールと振り分け
振り分けとは、ドメイン、IP、ポート、インバウンドのタグなどの条件に応じて、接続を異なるアウトバウンドへ送ることです。ルールは通常、順番に評価され、最初に一致したルールが後続の選択に影響します。1つのルールに複数種類の条件がある場合、それらをすべて満たす必要があるのが一般的です。ルールを変更した後は、画面上のモード名だけで判断せず、ログで実際の宛先と一致結果を確認してください。
IPアドレスの集合
GeoIPは、データファイル内のIPアドレス集合を使って宛先を判定します。geoip:privateはプライベートアドレス範囲の判定によく使われます。アドレスの分類はデータに基づく判定であり、物理的な所在地を正確に証明するものではありません。最初の宛先がドメイン名の場合、名前解決の有無やIPルールへの反映方法はルーティングの名前解決設定によって異なります。
ドメインの集合
GeoSiteは、名前付きドメインの集合を使ってルールを整理します。集合の内容は使用するデータファイルによって決まります。タグ名が同じでも、データの提供元や更新日時を確認してください。集合が特定のサービスの全ドメインを網羅しているとは限りません。存在しない集合をルールから参照すると設定の読み込みに失敗する場合があるため、ルールとデータファイルを合わせて確認してください。
ドメイン名解決
DNSはドメイン名をIPアドレスなどのレコードに変換します。名前解決はアプリ、OS、プロキシコア、リモートコンポーネントのいずれかが行う場合があります。コアのdnsセクションを設定しても、すべてのアプリの問い合わせが自動的にそのモジュールへ送られるわけではありません。問い合わせの入口、上位リゾルバー、DNS通信のアウトバウンド、解決後のアドレスがルーティングに使われる方法を個別に確認してください。
仮想アドレスのマッピング
FakeDNSはアプリにマッピング用の仮想アドレスを返します。その後、接続が対応する処理経路に入ると、内部のマッピングによって元のドメインと関連付けられます。仮想アドレスは実在するサーバーのアドレスではないため、マッピングを理解しないネットワーク経路では使用できません。名前解決の入口、仮想アドレスの範囲、トラフィックの取り込み方法を連携させる必要があります。フィールドを追加するだけでは一連の取り込み設定は完成しません。
DNSリーク
DNSリークは、問い合わせが想定した名前解決経路を通らず、別のリゾルバーに送信される現象です。ローカルでの名前解決がすべてDNSリークにあたるわけではありません。ブラウザー独自の暗号化DNS、システムキャッシュ、アプリ独自のDNSによって問い合わせ経路が変わる場合があります。設定した名前解決方針を基準に確認し、プロキシの出口IPが想定どおりでも、DNS経路まで正しいとは限らない点に注意してください。
関連項目：ルーティング項目とルールの順序 · DNS設定
05 / Subscription & node
サブスクリプションとノード
サブスクリプションは設定の取得、ノードは接続設定の保存、テストは特定条件での測定結果を担います。それぞれ別の役割で、互いに置き換えることはできません。
サブスクリプションURL
サブスクリプションURLは、クライアントがノード設定一式を取得するためのリモートアドレスです。返される形式にクライアントが対応している必要があります。URLに個人用のアクセス情報が含まれる場合があるため、公開スクリーンショットやログに載せないでください。更新に失敗した場合は、URLの無効化、リクエストの失敗、形式の解析エラーを区別してください。クライアントをインストールしても、利用可能なサブスクリプションが自動で設定されるわけではありません。
ノード
ノードは、クライアントに保存されるリモート接続設定です。通常、アドレス、ポート、プロトコル、認証、伝送のセキュリティ設定が含まれます。表示名は管理用のラベルにすぎず、実際の設置地域や回線品質は判断できません。ノードを選択すると候補となるアウトバウンド設定が決まりますが、アプリの通信がそのノードを通るかどうかは、プロキシの入口とルーティングルールにも左右されます。
サブスクリプショングループ
サブスクリプショングループは、取得元やノード一覧を管理し、個別の更新、絞り込み、設定の管理をしやすくするものです。グループ名がコアのルーティング判定に直接使われたり、ルールセットとして機能したりするのが一般的とは限りません。サブスクリプションの更新で取得元のノード情報が置き換わる場合があります。手動で変更した設定が保持されるかはクライアントの動作によるため、重要な変更は独立した設定で管理してください。
TCP接続テスト
TCPingは通常、TCP接続の確立過程を使って宛先ポートへの到達性と所要時間を測定します。具体的なテスト方法はクライアントによって異なります。通常、プロキシ認証までは行わず、TLS、伝送経路、リモート転送が正常であることも確認できません。TCPingが成功してプロキシリクエストが失敗しても矛盾ではありません。接続全体のテスト結果とコアのログを確認してください。
実接続の遅延
実接続の遅延は、選択したノードを通じて実際にプロキシリクエストを送り、測定します。単純なポートテストより多くの接続処理を確認できます。結果はテスト先、DNS、ハンドシェイク、サーバーの応答、測定時のネットワーク状況に左右されます。クライアントによって測定方法も異なる場合があります。遅延は通信速度を示すものではありません。ノードを比較する際は同じ条件で測定し、実際のアプリの通信結果も合わせて確認してください。
06 / Client functions
クライアント機能
まず通信をプロキシ処理に取り込んでから、アウトバウンドの選択を確認してください。画面上のスイッチを切り替えた後は、実際に反映される範囲を確認しましょう。
システムプロキシ
システムプロキシは、OSがアプリに提供するプロキシ設定です。この設定に従うアプリのみ、指定した入口を使います。システム設定を書き込んでもコアが起動したことにはなりません。また、指定ポートはローカルの待ち受けポートと一致させる必要があります。特定のアプリが直接接続を続ける場合は、システムプロキシに対応しているか、アプリ独自のプロキシ設定がないかを確認してください。
TUNモード
TUNは仮想ネットワークインターフェースでIPトラフィックを受け取り、クライアントが選択した実装で接続を処理します。システムプロキシを参照しない一部のアプリも対象にできる場合があります。実際の対象範囲は、システムルーティング、除外ルール、権限、コンポーネントの機能によって異なります。すべての接続が必ずリモートプロキシを通るわけではありません。クライアントと関連ネットワークコンポーネントが連携する機能であり、汎用的なV2Rayのトップレベルフィールドとして記述するものではありません。
自動プロキシスクリプト
PACはスクリプトを使って、リクエストごとにプロキシ接続先または直接接続を選択します。アプリがPACに対応し、実際に使用している必要があります。判定はアプリが接続経路を選ぶ段階で行われ、トラフィックがコアに入った後のルーティング判定とは別です。PACが直接接続を返したリクエストはプロキシの入口を通らないため、その後のコアのルールでも取り込めません。
トラフィックのスニッフィング
スニッフィングは、接続の初期データからドメイン名やプロトコル情報を識別し、ルーティング判定などに利用する機能です。読み取れる情報はプロトコル、暗号化方式、コアの実装によって制限され、暗号化された内容をすべて読み取る機能ではありません。識別したドメイン名で宛先アドレスを上書きするのか、ルーティングの判定だけに使うのかは、各設定項目で区別してください。
ログレベル
ログレベルは、コアが出力する情報の詳細度を制御します。warningは通常、警告やエラーの確認に使います。一時的な調査では必要に応じて詳細度を上げてください。クライアントの操作ログとコアの実行ログは別々に表示されることがあるため、エラーの出所を確認しましょう。ログには接続先、設定ファイルのパス、サブスクリプション情報などが含まれる場合があります。共有前に機密情報を削除してください。