VMess
Project Vのエコシステムに属するプロキシプロトコルで、ユーザー認証とデータ保護の仕組みを備えています。一般的な設定では、ユーザー識別にUUIDを使用します。VMessはさまざまな通信方式と組み合わせられるため、プロトコル名だけではWebSocketやTLSを使っているか判断できません。認証エラーが発生した場合は、ユーザー識別子に加えて、システム時刻と現在のコアに対応した設定形式かどうかも確認してください。
関連項目：通信方式 WebSocket →設定項目を読むための用語集 · よく使う26語
V2Ray 用語集
まずプロトコル、コア、通信方式を整理し、次にルーティングとテスト結果を確認しましょう。クライアントで見かける用語を項目別に解説し、各項目へ直接移動できるリンクを用意しています。
読む順番
クライアントが設定を管理し、コアが接続を処理します。プロトコルがリクエストを構成し、通信方式とセキュリティ設定がデータを運びます。サブスクリプションは設定を更新するもので、接続品質を決めるものではありません。
リクエスト形式と認証
プロキシプロトコル
プロトコル名は接続設定の一部にすぎません。通信方式、セキュリティレイヤー、サーバー側のパラメーターも個別に確認してください。
VLESS
軽量なプロキシプロトコルで、アプリケーションデータ自体は暗号化しません。接続の保護は通常、TLSやREALITYなど外側の仕組みが担います。UUID、通信方式、セキュリティ設定、flowをセットで確認してください。サーバーアドレスだけを置き換えても接続できるとは限りません。flowは速度設定ではありません。クライアントのコアとサーバーの両方が対応する組み合わせの場合にのみ指定してください。
関連項目：REALITYのセキュリティ設定 →Trojan
通常はTLS接続上でプロキシリクエストを送受信し、パスワードで認証するプロトコルです。パスワードが正しくても接続全体の設定が適切とは限りません。サーバー名、証明書の検証、接続ポートも一致させる必要があります。TLSハンドシェイクエラーが出た場合は、まずセキュリティレイヤーを確認しましょう。ハンドシェイクを通過してから認証パラメーターを調べるほうが、原因を絞り込みやすくなります。
関連項目：TLSと証明書の検証 →Shadowsocks
所定の暗号方式と鍵でプロキシ通信を保護するプロトコル群です。方式や拡張機能によっては相互運用できません。クライアントの方式名、パスワード、拡張パラメーターがあれば、それらを元の設定と一致させてください。ノードをインポートできたとしても、設定形式を読み取れたにすぎません。選択したコアがその方式に対応しているかも確認が必要です。
関連項目：ノードに含まれる設定項目 →設定を管理するのはクライアント、接続を処理するのはコア
コアとクライアント
問題を報告する際は、クライアント名、クライアントのバージョン、実行中のコアをそれぞれ記録し、画面の問題と接続の問題を区別してください。
V2Ray
Project Vのエコシステムに属するネットワークプロキシツールの名称で、日常的な会話では関連クライアントや設定体系を指す総称として使われることもあります。そのため「V2Rayに接続できない」だけでは、どのレイヤーに問題があるか特定できません。トラブル対処では、使用中のGUIクライアント、実際に動作しているコア、それぞれのバージョンを確認し、ログから問題箇所を判断しましょう。
トラブル対処の手順を見る →V2Fly
V2Ray関連の開発を引き継ぐコミュニティプロジェクトです。プロキシコアが接続、ルーティング、DNSなどを処理します。クライアント画面の「v2fly」は通常、コアの選択肢を指し、サブスクリプション形式や特定のノードプロトコルではありません。サブスクリプションに別のコア固有の設定が含まれている場合、V2Flyに切り替えても引き継げないことがあります。事前に機能の対応範囲を確認してください。
比較して読む：Xrayコア →Xray
V2Rayと技術的なルーツを共有するプロキシコアプロジェクトで、プロトコル接続、ルーティング、通信処理を担います。V2Flyとは機能、設定項目、対応する組み合わせが異なり、単に名前が違うだけではありません。REALITYや特定のflowを使う場合は、コアの種類に加えて、実行中のバージョンがサーバー側の要件に対応しているか確認してください。
関連項目：REALITYとコアの対応状況 →v2rayN
プロキシ設定やサブスクリプショングループを管理し、コアを実行するデスクトップ向けGUIクライアントです。Windows、macOS、Linuxに対応しています。画面の項目、必要な権限、コアの対応状況は、バージョンや配布パッケージによって異なります。従来版とクロスプラットフォーム版で画面が違うこともあります。ガイドを読む際は、ボタンの位置が完全に一致するかより、設定名と役割を確認しましょう。
デスクトップクライアントの基本操作を見る →v2rayNG
Android向けのGUIプロキシクライアントで、接続処理にはXrayコアを使うことが一般的です。起動時に求められるVPNサービスの許可は、端末内の通信を取り込むトンネルを作成するためのものです。通信がリモートノードまで届いたことを示すものではありません。実際にリクエストがプロキシを通るかどうかは、アプリごとの設定、ルーティングルール、ノードの利用可否にも左右されます。
VPNの許可とアプリごとの設定を見る →v2flyNG
Android向けのGUIクライアントで、V2Flyコアを使用します。V2Fly対応設定の代替候補として利用できます。名称や操作感が似ていても、v2rayNGが対応するコアの機能をすべてサポートするとは限りません。ノードを移行する際は、プロトコルと通信方式を改めて確認し、システムの許可設定やバックグラウンド実行の制限も個別に確認してください。
Androidクライアントの解説を見る →データの運び方と保護の仕組み
通信方式と暗号化
ここではクライアントの設定項目に沿って分類しています。TLSとREALITYはセキュリティの仕組み、WebSocketとgRPCは一般に通信方式で、同じレイヤーではありません。
TLS
通信を保護し、接続先の相手を認証するためのセキュリティプロトコルです。プロキシプロトコルは、TLSが確立した安全な通信路でデータを送信できます。サーバー名は証明書の検証やハンドシェイクに使われるため、別のドメインを適当に入力しないでください。証明書エラーが発生した場合は、システム時刻、サーバー名、証明書の有効期限、信頼チェーンを確認し、証明書検証を無効にして回避しないでください。
比較して読む：Trojanのセキュリティレイヤー →WebSocket（ws）
HTTPハンドシェイクで双方向通信を確立する通信方式で、設定ではwsと略されることがあります。プロキシプロトコルそのものではなく、使用すれば自動的にTLSが有効になるわけでもありません。同じプロキシプロトコルでも、異なる通信方式を利用できます。パス、Host、TLSサーバー名は別々の設定項目です。リバースプロキシを経由する場合は、サーバー側の設定と個別に照合してください。
関連項目：TLSサーバー名 →gRPC
HTTP/2をベースとすることが多い通信フレームワークで、プロキシコアの通信方式として利用できます。クライアントのサービス名はサーバー側やリバースプロキシの設定と一致させてください。WebSocketのパスで代用することはできません。リバースプロキシ経由で転送する場合は、中継経路がHTTP/2とgRPCのリクエストを正しく処理できるかも確認してください。
接続・通信エラーのトラブル対処を見る →REALITY
Xrayのエコシステムにおける通信保護の仕組みで、VLESSと組み合わせて使われることが多いものの、独立したプロキシプロトコルではありません。サーバー名、公鍵、shortIdなどを一致させる必要があり、具体的な項目や対応する組み合わせはコアのバージョンによって異なります。クライアントに必要な公鍵とサーバーの秘密鍵を混同しないでください。画面でREALITYを選んだだけで設定が完了したとは限りません。
比較して読む：VLESSとflow →リクエストがプロキシに入るか、入った後どこへ向かうか
ルーティングとDNS
振り分けのトラブル対処では、まずアプリの通信がクライアントに渡っているか確認します。名前解決の問題を調べる前に、ドメイン名をアプリ、OS、コアのどれが処理しているかを特定しましょう。
ルーティングルールと振り分け
ドメイン名、IPアドレス、ポートなどの条件に応じて、リクエストの接続先を直接接続、プロキシ、遮断から選ぶルール体系です。結果はルールの照合順序、同じルール内の複数条件の組み合わせ、条件に一致しない場合のデフォルト接続先によって決まります。クライアントの「グローバル」は通常、ルーティングのプリセット名です。すべてのアプリが自動的に通信をクライアントへ渡すという意味ではありません。
違いを確認：システムプロキシ →GeoIP
ルーティングでIPアドレスの範囲を照合するためのルールデータで、地域や用途別に分類されることが一般的です。リアルタイムの位置情報サービスではなく、ネットワーク構成の変更によりアドレスの割り当て先が変わることもあります。照合精度はデータの更新状況にも左右されます。複数の接続先アドレスを使うサービスでは、実際に接続したIPアドレスによって適用されるルールが変わります。
比較して読む：ドメイン名で照合するGeoSite →GeoSite
ドメイン名をサイト、サービス、カテゴリ別にまとめたルールデータで、名前を基準に接続先を選ぶ際に使います。利用できるカテゴリは、クライアントが実際に読み込んだデータファイルによって異なり、任意のタグをそのまま入力できるわけではありません。ドメイン名による分類とIPアドレスによる分類は必ずしも対応しません。ルールを追加した後は、照合ログで結果を確認してください。
関連項目：ルールの順序とデフォルト接続先 →DNS
ドメイン名をIPアドレスなどのレコードに変換するシステムで、ドメイン名によるアクセス経路の一部です。アプリ、OS、プロキシコアがそれぞれ名前解決に関わる場合があります。クライアントのDNSアドレスを一つ変更しても、すべての問い合わせが同じ経路に切り替わるとは限りません。調査時は、問い合わせ元、利用する接続先、結果がキャッシュ由来かを確認してください。
関連項目：DNS問い合わせの経路 →FakeDNS
仮想IPとドメイン名の対応付けを使って通信を処理する仕組みです。返されたアドレスは接続先サーバーの実アドレスではありません。リクエストがコアに届いた後、保存されている対応関係からドメイン名を復元し、ルーティングと接続を行います。DNS応答と通信の取り込み範囲が一致しない場合や、古い対応関係が失われてもアプリ側にキャッシュが残っている場合は、アクセスに失敗することがあります。
FakeDNSの仕組みと利用場面を解説 →DNSリーク
DNS問い合わせが想定した名前解決経路を通らず、別の経路から送信される状態です。該当するか判断する前に、想定しているポリシーを明確にしてください。問い合わせが直接接続されても、ローカルで名前解決するルールが明示されている場合は異常とは限りません。調査時はOSの名前解決、ブラウザーのセキュアDNS、アプリ内蔵の名前解決、コアのDNS処理を個別に確認しましょう。検査ページを一度見ただけで判断しないでください。
DNSの名前解決手順に戻る →システムプロキシ
OSがアプリに提供するプロキシアドレスの設定です。利用するかどうかはアプリの実装によって異なり、独自のネットワーク設定を使うプログラムもあります。システムプロキシはリクエストがローカルプロキシに届くかを決め、コアのルーティングは受け取ったリクエストの接続先を決めます。待ち受けポートを変更した場合は、システムプロキシが指すアドレスも確認してください。クライアントを終了する前に、プロキシ設定が正しく元に戻ることも確認しましょう。
比較して読む：TUNによる通信の取り込み →TUNモード
仮想ネットワークインターフェースとシステムルーティングを使ってIP通信を取り込む方式で、システムプロキシを利用しない一部のアプリにも適しています。通常は追加の権限が必要で、DNS設定、ルーティングテーブル、ほかのネットワークソフトとの連携にも影響します。すべてのアプリやプロトコルを取り込めるとは限りません。有効にした後でネットワークに問題が起きた場合は、ルーティングの競合と名前解決経路を確認してください。複数の通信取り込みツールを重ねて使うのは避けましょう。
システムのネットワーク設定と権限のトラブル対処を見る →設定の取得元と接続テスト
サブスクリプションとノード
更新の成功、ノードが接続できること、速度が適切であることは、それぞれ別の結果です。テスト方法とテスト先を揃えてから比較してください。
サブスクリプション
リンクから複数のノード設定を取得・更新する配布方式で、クライアントでは通常、サブスクリプショングループとして管理します。更新に成功したことが示すのは、データの取得と解析が完了したことだけで、すべてのノードへの接続を保証するものではありません。サブスクリプションURLにはアクセス権限の情報が含まれる場合があります。スクリーンショット、公開ログ、問い合わせ文にURL全体を載せないでください。
サブスクリプションのインポート手順を見る →ノード
クライアント上で選択できるリモート接続設定です。通常、サーバーアドレス、ポート、プロトコル、認証情報、通信パラメーターが含まれます。表示名はメモにすぎず、サーバーの所在地、通信経路、実際の性能を示すものではありません。同じ名前でも設定が異なる場合があります。問題の切り分けでは、一覧の名前だけでなく具体的な項目を比較してください。
ノードのタイムアウトを調べる手順を見る →遅延テスト
特定のテストにかかる時間を測る操作です。ICMP応答、TCP接続の確立、プロキシ経由のリクエストなどが対象になります。テスト方法によって測定する経路が異なるため、数値をそのまま比較することはできません。遅延が小さくても継続的なダウンロード速度が速いとは限らず、後者は帯域幅、混雑状況、接続先のサービス、端末の負荷にも左右されます。
関連項目：実接続遅延 →実接続遅延
通常、選択中のプロキシを経由して指定されたテスト先に実際のリクエストを送り、その所要時間を測った値です。具体的な測定方法はクライアントのバージョンによって異なります。単純なポート接続テストより多くの処理を含みますが、反映されるのはそのテスト先と測定時点の状況に限られます。タイムアウトの原因はテスト先、DNS、ハンドシェイク、ルーティングなどさまざまです。ログと実際のアクセス結果を合わせて確認し、サーバー停止と決めつけないでください。
テストのタイムアウトとアクセス障害の対処を見る →症状に合わせて次の情報を確認
実際に操作する場合は、ガイドに沿って設定のインポート、モード選択、接続確認を順に行ってください。エラーが発生した場合は、症状に応じてトラブル対処ガイドを参照してください。この記事では概念を解説しており、クライアントのバージョンごとのデフォルトポートや画面上の位置を一律には定めていません。