VMess
VMess protocol
VMessはProject Vエコシステムのプロキシプロトコルです。ユーザーIDなどのパラメーターで認証し、V2Rayの設定やサブスクリプション項目で広く使われています。設定時はアドレス、ポート、ユーザーID、トランスポート方式、セキュリティ設定を確認してください。プロトコル名だけでは十分ではありません。古い解説にある互換性パラメーターが、現行バージョンで使えるとは限りません。認証に失敗する場合は、端末の時刻も確認してください。
V2Ray / 設定リファレンス
V2Ray用語集
設定テーマから用語を探せます。まずプロトコル、トランスポート、コアを区別し、次にサブスクリプション、ルーティング、DNSが接続のどの部分を制御するかを確認しましょう。
全26項目。各用語には個別のアンカーがあり、トラブル対応の記録にリンクをコピーできます。具体的な設定名や利用できる機能は、使用中のクライアントとコアで確認してください。
プロトコルとトランスポート
プロトコル・トランスポート・セキュリティ機構の違い
1つのサーバー設定に、この3種類のパラメーターが含まれることは珍しくありません。プロトコル名が同じでも、パス、フロー制御、セキュリティ設定を使い回せるとは限りません。
VLESS
VLESS protocol
VLESSは軽量なプロキシプロトコルで、独立した通信内容の暗号化機能はありません。通常はTLSやREALITYなどのセキュリティ機構と組み合わせて使用します。設定項目のユーザーID、フロー制御、トランスポートはサーバー側と一致させてください。別の設定からそのまま流用できるとは限りません。クライアントで利用できるかどうかは、実際に使用するコアがその組み合わせに対応しているかも確認が必要です。
Trojan
Trojan protocol
Trojanは通常、TLSで接続を保護し、パスワードでプロキシ認証を行います。ここではネットワークプロトコルを指し、名前だけでファイルの種類を判断するものではありません。パスワードは認証、サーバー名と証明書検証は別の接続確認を担い、相互に代用できません。設定をインポートした後にハンドシェイクエラーが発生した場合は、証明書検証を無効にするのではなく、セキュリティ設定と認証情報をそれぞれ確認してください。
REALITY
REALITY transport security
REALITYはXrayエコシステムのトランスポートセキュリティ機構で、VLESSと並ぶ完全なプロキシプロトコルではありません。クライアントには通常、サーバー名、公鍵、短いIDなど、サーバー側から提供されたパラメーターを設定し、対応するトランスポートとコアの要件を満たす必要があります。REALITYの公鍵をユーザーIDやパスワードの欄に入力しないでください。値が正しくても、設定欄が違えば正しい構成になりません。
トランスポート方式
Transport · TCP / WebSocket / gRPC
トランスポート方式は、プロキシ接続でデータを運ぶ方法を定めます。TCP、WebSocket、gRPCなどがあり、VMessやVLESSといったプロキシプロトコルとは別の階層です。方式によってはパス、Host、サービス名などの入力が必要で、サーバー側の設定と一致させる必要があります。トランスポート名は性能の順位を示すものではありません。トラブル時はまずパラメーターの一致を確認し、その後にネットワーク環境や実装の違いを調べてください。
コアとクライアント
設定を実行するコンポーネントを確認
GUIクライアントは設定の管理や生成を行い、コアは接続を処理します。画面を提供するプログラムの更新と、コアの更新は別の操作とは限りません。
Project V
Project V ecosystem
Project Vはネットワークプロキシ機能を中心に展開するオープンソースプロジェクトのエコシステムで、V2Rayはその中核ソフトウェアです。関連ツールはインバウンド、アウトバウンド、ルーティングを組み合わせて接続を処理します。資料に登場するProject V、V2Ray、V2Fly、Xrayは、それぞれ同じ階層の名称ではありません。設定例を参照する際は、まず対象のプロジェクトとバージョンを確認し、使用中のクライアントで該当項目を生成・読み込みできるか判断してください。
V2Fly
V2Fly / V2Ray core
V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、日常的な議論では該当するコアの系統を指してこの名前を使うこともあります。コアは設定を解析し、接続を確立してルーティングを実行します。サブスクリプションの操作画面を提供するGUIとは異なります。どちらもV2Ray設定と書かれていても、設定形式と機能の対応範囲を確認してください。他のコアで追加された項目を、そのまま使えると決めつけないようにしましょう。
Xray-core
Xray core
Xray-coreはV2Rayから派生した独立コアプロジェクトで、プロキシプロトコル、トランスポート、インバウンド、アウトバウンド、ルーティングなどを実際に処理します。V2Flyとは共通の背景がありますが、後続の機能、設定項目、互換性の範囲は完全には一致しません。クライアントでコアを切り替える場合は、現在の設定に含まれるプロトコル拡張やカスタム設定を確認してください。コアの切り替えは、あらゆる接続トラブルを解決する方法ではありません。
v2rayN
Windows / macOS / Linux
v2rayNはデスクトップ向けのGUIクライアントです。サーバー管理、サブスクリプション更新、システムプロキシ、ルーティングなどの操作を提供し、連携するコンポーネントで接続を処理します。デスクトップ版と従来のWPF版では画面構成が異なります。メニューや利用できる機能は、使用中のバージョンの情報を確認してください。トラブルを調べるときは「V2Rayに接続できない」だけでなく、クライアント名、コアの種類、プロキシモードを記録すると原因を特定しやすくなります。
v2rayNG
Android · Xray
v2rayNGはAndroid向けのGUIクライアントです。このページではXrayコアを使うケースを取り上げ、システムのVPNインターフェースを利用してアプリの通信を取り込む方法を説明します。システムの許可設定、アプリごとのプロキシ設定、メーカーによるバックグラウンド制限が動作に影響する場合があります。サーバー設定だけで判断しないでください。ステータスバーにVPNアイコンが表示されても、リモートサーバー、DNS、接続先への通信がすべて成功したとは限りません。
v2flyNG
Android · V2Fly
v2flyNGはV2Flyコアを採用したAndroid向けGUIクライアントです。コアの要件に応じて選ぶ、別のクライアントとして利用できます。v2rayNGと名前が似ており、一部のインポートや接続操作も共通していますが、対応するプロトコル拡張が同じとは限りません。設定を移行する際は、まずコアの互換性を確認し、次にサブスクリプションの解析とプロキシ設定を確認してください。画面が似ているからといって、設定も必ず共通とは限りません。
サブスクリプションとノード
設定の取得元と接続テストを区別する
サブスクリプションの更新成功、サーバー項目の存在、テスト先への接続は、それぞれ別の確認結果です。互いに代用できません。
サブスクリプション
Subscription
サブスクリプションは、リモートURLからサーバー設定の一覧を取得して配布する方式です。クライアントが更新を実行すると、項目を解析して保存します。URLにアクセス用の認証情報が含まれる場合があるため、スクリーンショット、ログ、問い合わせ内容にはURL全体を載せないでください。更新成功が示すのは、その回の取得と解析が完了したことだけです。すべての項目が接続可能とは限りません。項目が空の場合は、グループのフィルター条件と取得した内容の形式も確認してください。
ノード
Server profile
ノードは一般に、クライアント内の1つのサーバー設定を指します。アドレス、ポート、プロトコル、認証、トランスポートなどを含みますが、必ずしも独立した物理サーバー1台に対応するわけではありません。表示名は識別用のラベルにすぎず、実際の接続先の地域や経路を証明するものではありません。特定のノードを調べるときは、設定項目と接続ログを確認してください。名称、アイコン、1回のテスト結果だけで稼働状況を判断しないようにしましょう。
サブスクリプショングループ
Subscription group
サブスクリプショングループは、取得元と、その取得元に属するサーバー項目を整理するために使います。クライアントによっては、更新URL、フィルター条件、自動更新の設定をグループごとに保存します。グループ名自体はルーティングルールではなく、自動フェイルオーバーやロードバランシングを意味するものでもありません。更新後に項目数が大きく変わった場合は、再インポートする前にグループのフィルター条件と更新結果を確認し、手動で調整した項目が上書きされないようにしてください。
遅延
Latency
遅延は、指定したテストにかかった時間です。テスト方法、対象、計測の開始点と終了点を踏まえて解釈してください。TCP接続の確立とWebページへのリクエスト完了では、測定している内容が異なります。接続にかかる時間が短くても、継続的なダウンロードが速いとは限らず、スループット測定の代用にもなりません。比較する際は対象と方法をそろえ、ネットワークの変動も考慮してください。1回の測定値を長期的な傾向とみなさないようにしましょう。
実接続遅延
Real connection latency
実接続遅延は一般に、選択したプロキシ経由でテスト先にアクセスし、かかった時間を記録するものです。サーバーのポート確認だけの場合より、実際のプロキシ通信に近い測定です。それでもDNS、ハンドシェイク、テスト先、実装方法によって結果は変わります。クライアントが異なる場合、数値を単純に比較することはできません。テストに失敗したときは、プロキシ経路のエラーとテスト先の到達不能を切り分けてください。テストに成功しても、すべてのアプリがプロキシを経由しているとは限りません。
ルーティングと振り分け
接続がどこから入り、どこへ出ていくかを確認
システムプロキシは一部のアプリが通信を渡す方法を制御します。接続がコアに入った後は、ルーティング条件によってアウトバウンドが決まります。まず階層ごとに確認してから、ルールを変更してください。
ルーティングルール
routing.rules / outboundTag
ルーティングルールは、ドメイン、IP、ポート、インバウンドなどの条件に基づいてアウトバウンドを選択します。ルール内のoutboundTagは、定義済みのアウトバウンドタグを参照します。コアは通常、ルールを順番に評価し、最初に一致したルールで接続の経路を決定します。同じルール内の複数条件をどのように組み合わせるかも、コアのドキュメントで確認してください。一致しない場合は、その設定のデフォルト動作に従います。トラブル対応では、ルールの順序、タグの存在、フォールバック先を併せて確認する必要があります。
通信の振り分け
Traffic routing
通信の振り分けは、宛先ドメインやアドレスなど、判定可能な情報に応じて接続をプロキシ、直接接続、ブロックなどのアウトバウンドへ振り分ける方法です。クライアントに表示される「グローバル」は通常、ルーティングのプリセットを指し、すべてのアプリの通信がクライアントに取り込まれていることを意味するわけではありません。振り分けを確認する際は、まず通信の取り込み方法を確認し、次に対象がどのルールに一致したかを調べてください。通信が取り込まれていない状態を、ルーティングの不具合と誤認しないようにしましょう。
GeoIP
geoip:cn
GeoIPは、ルーティングルールから参照するIPアドレスのデータセットで、地域や用途ごとに分類されています。たとえばgeoip:cnは、対応するデータ内のアドレス集合を参照します。照合するのはIPアドレスで、ドメイン名の文字列ではありません。ドメインを事前に名前解決する必要があるかは、ルーティングのドメイン処理設定によって異なります。データのバージョン、接続先の名前解決結果、IPアドレスの割り当て変更が判定結果に影響する場合があります。分類ラベルをリアルタイムの位置情報とみなさないでください。
GeoSite
geosite:category-ads-all
GeoSiteは、ルーティングから参照するドメインのデータセットです。サービス、サイト、用途などで分類され、たとえばgeosite:category-ads-allは、カテゴリに該当するドメインの集合を参照します。カテゴリが存在するか、どのドメインを含むかは、読み込んでいるデータファイルによって異なります。ラベル名だけで収録範囲を判断しないでください。ルールが機能しない場合は、データが正しく読み込まれているか、カテゴリを利用できるか、前のルールに先に一致していないかを確認してください。
システムプロキシ
System proxy
システムプロキシは、OSがアプリに提供するプロキシアドレスの設定です。クライアントはこれをローカルの待ち受けポートに向け、設定に従うアプリから接続を受け取れます。独自のプロキシ設定を使うアプリや、直接接続するプログラムもあるため、システムプロキシを有効にしても端末全体の通信が取り込まれるわけではありません。これはコアのルーティングにおける「グローバル」とは別の階層です。クライアント終了後もネットワークに接続できない場合は、システムプロキシの設定が残っていないか確認してください。
DNSとTUN
名前解決の経路と通信の取り込みを確認
DNSはアドレスの取得方法を決め、TUNは一部の接続を取り込みます。FakeDNSやスニッフィングは、その後の処理に必要なドメイン情報を補います。
DNS
Domain Name System
DNSはドメイン名をIPアドレスなどのレコードに変換します。ブラウザー、OS、プロキシコアがそれぞれ問い合わせを行い、キャッシュを管理する場合があります。設定するDNSサーバー、問い合わせに使うアウトバウンド、ドメイン処理の方針が接続結果に影響します。DNSアドレスを1つ変更しても、すべてのアプリの名前解決経路が変わるとは限りません。トラブル時は、まず誰が問い合わせを行い、どのアウトバウンドを使っているかを確認し、名前解決の失敗、取得したアドレスの不適合、接続失敗を切り分けてください。
TUNモード
TUN virtual network interface
TUNモードは、仮想ネットワークインターフェースでIPパケットを受け取り、プロキシコンポーネントに渡して処理します。システムプロキシに従わないプログラムの通信も一部取り込めます。実際の対象範囲は、システムルーティング、除外設定、権限、コンポーネントの実装にも左右されます。有効にしても、すべての接続がプロキシ経由になるとは限りません。初回設定ではDNSとループバックの回避方法も確認し、複数のVPNや仮想ネットワークコンポーネントがデフォルトルートを取り合わないようにしてください。
FakeDNS
Fake DNS
FakeDNSはアプリに仮想アドレスを返し、仮想アドレスと元のドメイン名の対応関係を管理します。その後、プロキシコンポーネントがドメイン名を復元して接続を処理します。通信の取り込みと対応関係の復元を組み合わせる必要があるため、一般的なパブリックDNSアドレスのように設定するだけで、すべてのプログラムが正常に使えるわけではありません。アプリに古いキャッシュが残っている場合や、関連する通信がプロキシを迂回する場合、仮想アドレスを正しく処理できないことがあります。設定を変更したら、名前解決と接続経路を改めて確認してください。
DNSリーク
DNS leak
DNSリークは、問い合わせが想定した経路やリゾルバーから外れる現象です。たとえば指定したアウトバウンド経由で名前解決する予定なのに、実際にはアプリが別のリゾルバーへ直接問い合わせるケースがあります。リークに当たるかどうかは、想定するポリシーに照らして判断してください。直接接続するドメインをローカルで名前解決すること自体は、必ずしも設定ミスではありません。確認時はシステムDNS、ブラウザーの暗号化DNS、アプリ独自の名前解決、プロキシDNSを併せて調べてください。検査ページを1回使うだけでは、すべてのアプリの動作を把握できません。
トラフィックのスニッフィング
sniffing
トラフィックのスニッフィングは、接続の初期データからプロトコルや外から確認できる宛先ドメインの情報を特定し、ルーティングの判断を補助します。コアに渡された接続に宛先IPしか含まれない場合などに利用されます。通信を復号する機能ではなく、暗号化されたあらゆる通信からドメイン名を復元できるわけでもありません。結果はトラフィックの特徴や実装によって異なります。ルーティング判定と接続先の書き換えで別の設定が使われることもあるため、使用中のコアの説明に従って設定してください。