VMess
VMessはProject Vエコシステムのプロキシプロトコルです。ユーザーIDで認証し、現在の設定では通常AEAD方式を使用します。異なるトランスポートと組み合わせられるため、VMessという表示だけではTCPかWebSocketかは判断できません。クライアントとサーバーの認証情報は一致させる必要があります。また、システム時刻が大きくずれていると接続に失敗することがあります。
VLESSの暗号化範囲を確認 →glossary
V2Rayの用語を、一覧で確認
接続設定からトラフィックの出口まで、設定の階層ごとに用語を確認できます。よく使われる30の概念について、意味や範囲、混同しやすい点を解説します。プロトコル名だけで性能を判断することはできません。
設定を読むときは、まずクライアント、コア、プロキシプロトコル、トランスポート、安全機能を確認し、次にサブスクリプションの提供元、トラフィックの入口、ルーティングの出口を見ていきます。実際の操作手順はクイックスタート、詳しい解説は使い方ガイドをご覧ください。
protocols
接続方式、プロトコルとトランスポート
プロトコルはデータのカプセル化と認証、トランスポートはデータの運び方、安全機能は接続の保護を担います。それぞれ分けて確認しましょう。
VLESS
VLESSはプロキシデータのカプセル化と認証を担いますが、プロトコル自体に通信内容の暗号化機能はありません。通常はTLSまたはREALITYと組み合わせます。ユーザーID、トランスポート、安全機能、フロー制御の設定がそろって初めて接続できます。既存ノードのプロトコル名をVLESSに変更するだけでは不十分で、サーバー側も対応する設定が必要です。
セキュリティ層の用語を確認 →Trojan
Trojanは通常、TLS接続上で使用するプロキシプロトコルです。パスワードで認証します。サーバーアドレス、パスワード、TLSのサーバー名はそれぞれ役割が異なり、パスワードが正しくても証明書の検証に成功するとは限りません。接続に失敗した場合は、認証エラー、TLSハンドシェイクエラー、ネットワーク到達不能を切り分けてください。
TLSの役割を確認 →Shadowsocks
Shadowsocksは事前共有鍵を使う暗号化プロキシプロトコルです。接続する双方で、互換性のある暗号方式と鍵を使用する必要があります。プロトコルのバージョンや暗号方式によって設定要件は異なるため、名称が似ているだけで置き換えることはできません。インポート後は、提供元の暗号方式を維持し、トラブル対処のためにむやみに変更しないでください。
ノードに含まれる設定項目を確認 →トランスポート層
ここでいうトランスポート層は、TCP、WebSocket、gRPCなど、プロキシプロトコルのデータを運ぶ接続方式です。プロキシプロトコルとは異なります。WebSocketのパスやリクエストホスト、gRPCのサービス名は、接続時に一致させる必要がある場合があります。トランスポートの選択はサーバー側の構成によって決まるため、サーバー設定を確認せずに速度だけを比較することはできません。
設定全体の解説を確認 →cores
画面と処理、コアとクライアント
画面上で設定を保存できても、現在のコアがその機能を実行できるとは限りません。互換性を調べるときは、クライアントと実際に起動しているコアの両方を確認してください。
Project V
Project Vは、V2Rayを中心に発展したオープンソースのプロキシツール群です。プロトコル、設定、関連実装を含みます。V2Rayという言葉は、このエコシステム全体を指す場合と、コアプログラムを指す場合があります。ガイドを読むときは文脈を確認し、エコシステム名を特定のGUIクライアントと混同しないようにしましょう。
エコシステムとプロキシコアの違いを確認 →プロキシコア
プロキシコアは、接続、プロトコル処理、DNS、ルーティングルールを実行するプログラムです。GUIクライアントは設定を生成し、コアを起動します。コアの起動に失敗すると、画面にノードが表示されていても、利用可能なローカルプロキシは作成されません。どの段階で失敗したかを特定するには、画面のスイッチを何度も切り替えるより、実行ログを確認するのが効果的です。
GUIクライアントの役割を確認 →Xray
XrayはV2Ray関連のコードから派生したオープンソースのプロキシコアです。VLESS、REALITY、XTLS Visionなどに対応しています。実際に使える機能は、コアのバージョンやビルド、設定の組み合わせによって異なります。コアの名称だけで、すべてのパラメーターが利用できるとは判断できません。v2rayNGはXrayコアを使用します。デスクトップ版v2rayNでは、現在のノードとコアの設定を確認してください。
REALITYの設定項目を確認 →V2Fly
V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、コアは通常V2Fly Coreと呼ばれます。Xrayと共通のエコシステムを背景に持ちますが、機能の開発状況や設定への対応は同一ではありません。v2flyNGはV2Flyコアを採用したAndroidクライアントです。特定のコア機能を使う場合は、設定が対応しているか先に確認してください。
Androidクライアントの選び方を確認 →GUIクライアント
GUIクライアントでは、ノード一覧、サブスクリプション管理、プロキシモード、ログなどを操作でき、設定を手動で編集する手間を減らせます。このサイトでは、デスクトップ向けのv2rayNと、Android向けのv2rayNG、v2flyNGを紹介しています。同じ設定でもクライアントによって名称や場所が異なる場合があるため、使用中の画面とコアを確認してください。
クライアントと対応プラットフォームを確認 →subscription
設定の取得元、サブスクリプションとノード
サブスクリプションは設定の配布、ノードは接続情報の記述を担います。テスト結果は一度の測定を示すもので、実際のアプリでの動作確認に代わるものではありません。
サブスクリプション
サブスクリプションは、1つのURLから複数のノード設定を取得・更新する仕組みです。単一のノードとは異なります。サブスクリプショングループを追加した後、通常は更新を実行してノード一覧に反映します。更新に失敗しても、登録済みノードが使えなくなったとは限りません。サブスクリプションURLにはアクセス情報が含まれる場合があるため、機密情報として保管し、ログを共有するときに公開しないでください。
サブスクリプションの追加手順を確認 →ノード
ノードは、リモートのプロキシサーバーに接続するための設定一式です。通常、アドレス、ポート、プロトコル、認証情報、トランスポート、安全機能などを含みます。一覧に表示される名前は識別用で、接続設定は変わりません。インポートに成功しただけでは接続できるとは限らないため、サーバーに到達できること、認証が有効であること、設定が一致していることを確認してください。
接続テストで確認できる範囲を見る →共有リンクとQRコード
共有リンクはノード設定をテキストに変換したもので、QRコードは通常、同じテキストを別の形式で表したものです。共有リンクを1つインポートしても、継続的なサブスクリプション更新は設定されません。設定が変わった場合は、再インポートまたは編集が必要です。リンクやQRコードに認証情報が含まれる場合があるため、スクリーンショットを公開するときは内容全体を隠してください。
Androidでのインポート方法を確認 →レイテンシ
レイテンシは、1回の測定で応答が返るまでの往復時間です。ただし、測定方法によって対象は異なります。TCPによる測定では、ポートへの接続時間だけを反映し、プロキシ認証やウェブリクエストまでは確認しない場合があります。結果を比較するときは、同じ方法、同じ接続先、近いネットワーク条件を使ってください。レイテンシが低いからといって、帯域幅が大きいとは限りません。
実接続レイテンシとの違いを確認 →実接続レイテンシ
クライアントの実接続レイテンシは通常、プロキシ経由でテスト先に接続してリクエストを実行します。ポートへの単純な接続テストより、実際の利用経路に近い測定です。接続先、DNS、ハンドシェイク、ネットワーク状況などが結果に影響し、計測範囲はクライアントの実装によって異なります。テストに失敗しても、すべての接続先が使えないとは限りません。成功しても、すべてのアプリがプロキシを使っているとは限りません。
アプリの通信がプロキシを通っているか確認 →routing
トラフィックの出口、ルーティングと振り分け
ルーティングが処理するのは、すでにコアに届いたトラフィックです。ルールが適用されるかどうかは、ルールの順序、条件、コアがその時点で取得できる情報によって決まります。
ルーティングルール
ルーティングルールは、ドメイン、IPアドレス、ポート、プロトコルなどを条件にトラフィックの出先を選びます。一般的な設定では、上から順に確認し、最初に一致したルールが適用されます。複数の条件の組み合わせ方は、使用するコアの構文に従ってください。通常は、より具体的な例外ルールを広範なルールより前に配置し、変更後はログで実際の出先を確認します。
ルーティング設定の解説を確認 →GeoIP
GeoIPは、地域やカテゴリごとに整理されたIPアドレスの一覧です。ルールでは、たとえばgeoip:cnのように指定します。照合対象はIPアドレスであり、ドメインの末尾や運営会社の登記国ではありません。IPアドレスの割り当てやデータの内容は変化するため、ルールが想定どおりに動かないときは、接続先の名前解決結果と使用中のデータが適切かどうかも確認してください。
GeoSite
GeoSiteはカテゴリ別に整理されたドメインの一覧で、設定ではgeosite:cnなどのタグで参照します。アクセスのたびにサイトの所在地をオンライン判定するのではなく、読み込まれたカテゴリデータをもとに照合します。カテゴリ名が存在するか、どのドメインが含まれるかは、実際に使用するデータファイルによって異なります。タグの表記が正しくても、対応するデータが必要です。
ルーティング振り分け
ルーティング振り分けは、ルールに応じてトラフィックごとに異なる出先を選ぶことです。直接接続、プロキシ経由、ブロックなどに振り分けます。「グローバル」や「中国本土をバイパス」は通常、クライアントが用意するルーティングのプリセットであり、新しいプロキシプロトコルではありません。グローバル設定でも、クライアントに届いたトラフィックだけが対象です。システムプロキシに従わないアプリは、独自の経路で通信する場合があります。
トラフィックの入口と出口の違いを確認 →アウトバウンドとoutboundTag
アウトバウンドは、コアがトラフィックを送信する方法です。outboundTagは、定義済みアウトバウンドをタグで参照します。設定でよく使われるdirectやproxyはタグの慣例にすぎず、実際の動作は対応するアウトバウンドの定義で決まります。存在しないタグを参照したり、別の設定のタグ名を使ったりすると、起動エラーや意図しない出先につながることがあります。
proxy / tun
トラフィックの入口、システムプロキシとTUN
まずアプリがどのようにトラフィックをクライアントへ渡しているかを確認し、その後でDNSとルーティングを調べます。入口の設定とルーティングのプリセットは、別々の問題です。
システムプロキシ
システムプロキシは、OSがアプリに提供するプロキシ設定です。この設定に従うアプリだけが、トラフィックをローカルプロキシに送ります。ブラウザー、ターミナルツール、ゲームでは対応状況が異なるため、ウェブページにアクセスできても、すべてのアプリがプロキシを使っているとは限りません。Linuxデスクトップのネットワークプロキシ設定と、コマンドラインの環境変数は分けて確認してください。
プロキシを有効にする手順を確認 →SOCKS・HTTPローカルプロキシ
SOCKSとHTTPは、クライアントがローカルで提供する2種類のプロキシ接続先です。アプリ側で対応する方式、アドレス、ポートを指定する必要があります。127.0.0.1は現在の端末自身を指し、リモートノードのアドレスではありません。ポートはクライアントの実際の設定を確認してください。ドメイン名をプロキシ側で名前解決するかどうかは、プロトコルやアプリの実装によって異なります。SOCKSを設定しただけでDNSの経路が変わるとは限りません。
TUNモード
TUNモードは仮想ネットワークインターフェースでシステムのトラフィックを受け取り、クライアントの関連コンポーネントで処理します。通常はシステムプロキシより広い範囲をカバーします。権限、システムルート、DNS、除外ルールなどに関わりますが、端末上のすべての通信が必ずプロキシを通るわけではありません。有効化後に問題が起きた場合は、ネットワークを制御する他のソフトを終了し、ログとルートの変化を確認してください。
TUNの設定とメンテナンスを確認 →FakeDNS
FakeDNSは、ドメインの問い合わせに合成IPアドレスを返し、そのアドレスと元のドメインとの対応関係を保存して、後続の接続処理に使います。合成アドレスは接続先サーバーの実際のIPアドレスではありません。トラフィックの取り込みと、対応関係を復元する仕組みとの連携が必要です。FakeDNSで名前解決した後に接続が取り込み経路を通らないと、アプリが合成アドレスを使って接続できない場合があります。
DNS設定の解説を確認 →DNSリーク
DNSリークとは、ドメインの問い合わせが想定した経路を通らず、別のリゾルバーやネットワーク出口で処理される状態です。アプリ内蔵の暗号化DNS、システムリゾルバー、クライアントのDNSが同時に使われることがあります。ウェブ通信がプロキシ経由でも、DNS問い合わせが同じ経路を通るとは限りません。原因を調べるときは、問い合わせを行うアプリ、使用するリゾルバー、問い合わせ通信の出先を個別に確認してください。
DNSのトラブル対処を確認 →security
認証と保護、暗号化とセキュリティ層
認証情報は接続先の身元を確認し、セキュリティ層は通信を保護します。設定はサーバー側と一致させ、検証を無効にして設定ミスを隠さないでください。
TLS
TLSは接続の暗号化、認証、通信の完全性を保護します。一般的な設定では、証明書でサーバーの身元を確認します。接続先のアドレスと証明書の検証に使うサーバー名は異なる場合がありますが、検証名は証明書とサーバーの設定に一致させる必要があります。証明書エラーが発生した場合は、証明書検証を無効にしたままにせず、システム時刻、サーバー名、信頼チェーンを確認してください。
サーバー名の意味を確認 →REALITY
REALITYはXrayが提供するセキュリティ層の方式です。クライアントは公開鍵などのパラメーターでサーバーを検証するため、サーバー自身のドメイン用に通常の証明書を用意する必要はありません。公開鍵、サーバー名、shortIdなどはサーバー側の設定と一致させてください。任意の値を組み合わせることはできません。REALITYはプロキシプロトコルではなく、あらゆるTLS設定より接続性能が優れているという意味でもありません。
VLESSとの役割の違いを確認 →XTLS Vision
XTLS Visionは、Xrayの特定のVLESS設定で使われるフロー制御機能です。条件を満たす場合、TLSトラフィックの重複した暗号化処理を抑えられます。設定でよく見られるフロー制御値はxtls-rprx-visionです。これは別のトランスポートプロトコルでも、REALITYと同じものでもありません。利用するには、クライアント、サーバー、トランスポートの組み合わせがすべて対応している必要があります。
SNIとserverName
SNIはTLSハンドシェイクで通知するサーバー名です。クライアントのserverNameパラメーターは通常、ハンドシェイク時の名前や証明書の検証に関係します。ノードの接続先アドレスとは異なり、WebSocketリクエストのHostフィールドと単純に置き換えることもできません。接続先にIPアドレスを指定していても、正しくハンドシェイクするために指定のサーバー名が必要な場合があります。
UUIDと認証情報
UUIDはVMessまたはVLESSのユーザーIDとして使用でき、TrojanのパスワードやShadowsocksの鍵は別の認証方式を使います。UUIDの形式だけではノードの品質は分からず、公開してよいことにもなりません。ノード設定全体があれば、他の人が対象サービスを利用できる場合があります。公開の場で相談するときは、認証情報、サブスクリプションURL、QRコードを隠し、機密情報ではないエラー情報を残してください。
設定とトラブル対処のQ&Aを確認 →