プロトコル名から設定項目まで、用途別に確認できます。まずクライアント、コア、接続パラメーターを区別し、オプションを画面で変更するのか、config.jsonで設定するのかを確認しましょう。
プロトコルはデータのやり取り方法、トランスポートは接続の運搬方法、セキュリティ層は対応するハンドシェイクと保護を担います。3つの層をそれぞれサーバー側に合わせる必要があります。
VMessはProject Vのエコシステムに属するプロキシプロトコルです。ユーザーIDなどのパラメーターで認証するため、接続設定をサーバー側と一致させる必要があります。認証に失敗した場合は、アドレス、ポート、UUIDに加えて、端末のシステム時刻も確認してください。時刻のずれがハンドシェイクに影響することがあります。VMessとWebSocketは同じ種類の設定ではありません。前者はプロキシプロトコル、後者はそのデータを運べるトランスポート方式です。
outboundの設定項目を見る →VLESSは軽量なプロキシプロトコルで、プロトコル自体はデータを暗号化しません。通常はTLSやREALITYなどのセキュリティ層と組み合わせて構成します。VLESSを選んだ後も、トランスポート方式、サービス名、セキュリティ設定を個別に確認してください。UUIDを入力しただけでは設定は完了しません。組み合わせや拡張機能の対応状況はコアごとに異なるため、実際に使うバージョンを確認してください。
VLESSとREALITYの違いを見る →Trojanは通常、TLS接続上でプロキシデータを送信し、パスワードで認証します。パスワードが正しくても、ハンドシェイクが成功するとは限りません。サーバー名、証明書の信頼関係、トランスポート設定も正しく設定する必要があります。証明書エラーが発生した場合は、検証を無効にするのではなく、まずドメイン名と端末の時刻を確認してください。
接続パラメーターを確認 →REALITYはXrayエコシステムのトランスポートセキュリティ機構です。独立したプロキシプロトコルでも、ノードのアドレスでもありません。VLESSと組み合わせて使うことが多く、クライアント側ではサーバーに対応する公開鍵、サーバー名、Short IDなどを設定する必要があります。画面でREALITYを選べても、すべてのコアでこの組み合わせが動作するわけではありません。実際に接続を処理するコアが対応している必要があります。
Xrayの定義を見る →トランスポート層は、プロキシデータをどの接続方式で送るかを定めます。一般的な選択肢にはTCP、WebSocket、gRPCがあります。WebSocketのパスやgRPCのサービス名などは各方式固有の設定で、サーバー側や中継設定と一致させる必要があります。トランスポート名が同じでも接続できるとは限らないため、TLSなどのセキュリティ層の設定も確認してください。
トランスポートの設定箇所を見る →プロジェクト名、実行コア、GUIクライアントはそれぞれ異なるレイヤーです。クライアント名だけでは、実際に使われるコアはわかりません。
Project Vはネットワークプロキシや通信ツールを中心とするプロジェクト群です。V2Rayは、その技術体系を理解するための重要な入り口です。inbound、outbound、ルーティングの基本モデルはこの設定方式に基づいており、その後、さまざまなプロジェクトやフォークが生まれました。古い解説を読む際は、Project VやV2Rayの名前だけを根拠に、新しい設定項目が使えると判断しないでください。
プロジェクトとクライアントの違いを見る →V2Flyは、V2Ray関連のコア実装とドキュメントを継続的に保守するコミュニティプロジェクトです。一般にV2Fly-coreは、そのコアプログラムを指します。Androidクライアントのv2flyNGは、V2Flyコアを接続処理の基盤として使用し、対応する設定体系が必要な場合に適しています。設定形式や対応範囲はバージョンごとに確認してください。他のコア向けの新しいパラメーターを、そのまま流用できるとは限りません。
Androidクライアントを見る →XrayはV2Rayの技術体系から発展したコアプロジェクトで、プロトコル、セキュリティ層、設定項目に独自の実装があります。v2rayNGはXrayコアをベースとしており、v2rayNで使える機能は選択したコアによって異なります。両コアには共通する設定概念もありますが、すべてのJSON設定を相互に使えるわけではありません。
コア選定の解説を読む →コアは接続の確立、ルーティング、名前解決の処理を担います。クライアントは設定編集、サブスクリプション管理、動作制御を行います。v2rayN、v2rayNG、v2flyNGはクライアント名です。画面上の設定はコアの設定に変換される場合もあれば、クライアント自体にのみ影響する場合もあります。機能の対応状況を判断するには、クライアントとコアの両方が対応しているか確認してください。どのクライアントをインストールしたかだけでは判断できません。
クライアントとプラットフォームを見る →config.jsonのトップレベル項目から役割を把握します。まず接続の入口と出口を確認し、次にルーティングによるoutboundの選択方法を見ていきましょう。
config.jsonは一般的なコアのJSON設定ファイル名です。通常、inbounds、outbounds、routing、DNS、policyなどの設定項目が含まれます。JSONでは引用符、カンマ、括弧の書式が厳密に決められており、通常のJSONファイルに説明用コメントは追加できません。クライアントが生成する実行用設定と、クライアント独自の設定ファイルは異なる場合があります。生成ファイルを直接編集しても、次回起動時に上書きされることがあります。
inboundsは接続を受け付ける方法を定義する設定配列です。たとえば、ローカルで待ち受けるSOCKSプロキシやHTTPプロキシを設定できます。各inboundでは待ち受けアドレス、ポート、プロトコル、タグなどを指定します。127.0.0.1は通常、同じ端末からの接続のみを受け付けます。待ち受けアドレスをすべてのインターフェースに変更すると、アクセス可能な範囲が広がるため、認証やファイアウォールの制限も検討してください。
outboundsは、接続を次にどの方法で送るかを定義する設定配列です。プロキシ、直接接続、ブロックなどを指定できます。outboundのtagはルーティングから参照するための識別子で、プロトコル名が固定で入るものではありません。必要に応じて名前を付けられます。outboundを定義するだけでは不十分です。ルーティングから選択されることと、ルールに一致しない場合のデフォルト動作も確認してください。
routingは、ドメイン名、宛先IP、ポート、inboundのタグなどの条件に基づいてoutboundを選択します。ルールは通常、上から順に評価されます。広い条件を先に置くと、その後の詳細なルールが適用されないことがあります。1つのルール内に異なる種類の条件を指定した場合、複数条件をすべて満たす必要があることもあります。すべての項目を「どれかに一致すればよい」と解釈しないでください。
policyは接続処理のポリシーを設定する項目です。ユーザーレベルごとに、ハンドシェイクのタイムアウト、アイドルタイムアウト、バッファーなどを設定できます。routingとは役割が異なり、特定のドメインをプロキシ経由にするか直接接続にするかは決めません。タイムアウトやバッファーを大きくしても速度が上がるとは限りません。変更前に項目の単位、デフォルト値、コアの対応状況を確認してください。
ドメイン名の解決と接続の転送は互いに影響しますが、同じ処理経路ではありません。ルール用データ、DNS問い合わせ、最終的なトラフィックの経路をそれぞれ確認してください。
DNSはドメイン名をIPアドレスに変換します。V2Ray設定のdns項目では、通常、内蔵リゾルバーの動作を設定します。OS、ブラウザー、コアがそれぞれ名前解決を行う場合があるため、内蔵DNSを変更してもすべてのアプリがそれを使うとは限りません。問題を調べる際は、まずどのレイヤーで名前解決されているかを確認し、DNSサーバー、問い合わせ経路、関連するルーティング設定を見直してください。
GeoIPは、識別子ごとに整理されたIPアドレスの集合です。geoip:cnなどの式をルーティング条件に使えます。判定するのは宛先IPが指定の集合に含まれるかどうかであり、ウェブページの言語やサーバーのリアルタイムな物理所在地ではありません。判定結果はローカルデータファイルの内容によって異なります。ドメイン名しかわからない場合は、その後の名前解決方法も関係します。
GeoSiteは、分類ごとに整理されたドメインルールの集合です。ルーティングによる振り分けや、対応するDNS設定での名前解決対象の限定に使えます。設定内のgeosite:cnはデータファイル内の分類を参照するもので、インターネットから項目を自動取得するものではありません。分類名や収録範囲はデータの提供元によって異なります。分類がなかったり、ファイルのパスが正しくなかったりすると読み込みに失敗することがあります。
FakeDNSは合成IPアドレスでドメイン名の問い合わせに応答し、IPアドレスとドメイン名の対応関係を内部に保存します。後続の接続処理でドメイン名を復元するための仕組みです。一般的なパブリックDNSのアドレスではなく、トラフィックの取り込み、対応関係の復元、ルーティングと組み合わせる必要があります。アプリがキャッシュした合成アドレスが対応する処理経路から外れると、接続に失敗する場合があります。モードを切り替えた後に関連キャッシュの削除が必要なこともあります。
DNS設定項目の範囲を見る →DNSリークとは、ドメイン名の問い合わせが想定した名前解決経路を通らない状態です。たとえば、プロキシ経由で名前解決する想定でも、システムが別のDNSサーバーに問い合わせることがあります。テストページに表示されたDNSサーバーの所在地は手がかりにはなりますが、すべての通信経路を証明するものではありません。ブラウザーのセキュアDNS、システムの名前解決設定、コアのログを合わせて確認してください。暗号化DNSを使っても、問い合わせが想定したoutboundを通るとは限りません。
DNSルーティングの解説を読む →ルーティングは、条件に応じて接続ごとに異なる経路へ振り分けることです。たとえば、特定のドメインには直接接続し、それ以外はプロキシのoutboundに送れます。自動速度測定とは異なり、ノードの障害時に自動で切り替える機能が含まれるとも限りません。効果はルールの順序、ドメイン名が参照できる状態かどうか、ルールに一致しない場合のデフォルトoutboundにも左右されます。
ルーティング設定の例を見る →これらの用語は主にクライアントの画面で使われます。設定のインポート、アプリのトラフィックの取り込み、接続テストはそれぞれ別の手順です。
サブスクリプションは、複数の接続設定を取得・更新するためのURLまたはデータソースです。クライアントが読み込むと、選択可能なノードに変換されます。サブスクリプションURLにアクセス認証情報が含まれる場合があるため、機密情報として扱い、公開されるスクリーンショットやログに載せないでください。更新で設定一覧は新しくなりますが、システムプロキシ、DNS、ローカルネットワークの設定が自動で修復されるわけではありません。
サブスクリプションのインポート手順を見る →ノードは、クライアントでサーバーへの接続設定一式を指す一般的な呼び方です。通常、アドレス、ポート、プロトコル、認証、トランスポートの設定が含まれます。表示名は提供元やユーザーが変更できるため、サーバーの所在地、回線の種類、性能を示すものではありません。ノードをインポートできても、クライアントがデータ形式を受け付けたことを示すだけです。実際の接続にはコアを起動してテストする必要があります。
outboundの設定に対応させる →システムプロキシは、アプリが参照するためにOSが提供するプロキシ設定です。通常、クライアントがローカルで待ち受けるアドレスとポートを指定します。この設定に従うアプリだけが該当する接続を送信するため、システムプロキシを有効にしても端末の全トラフィックが取り込まれるわけではありません。アプリ独自のプロキシ設定、直接接続、独立したネットワーク機能を使う場合は、それぞれ実際の経路を確認してください。
TUNモードと比較する →TUNモードは仮想ネットワークインターフェースとルーティング設定を使ってトラフィックを取り込み、システムプロキシを参照しないアプリもクライアントの処理経路に通せるようにします。実際の対象範囲は管理者権限、ルーティング、除外ルール、ほかのネットワークソフトにも左右されます。スイッチを有効にしただけで全トラフィックがプロキシ経由になるとは限りません。TUNはクライアントとOSの連携機能であり、任意のコアのJSON設定に同名の項目を追加するだけでは有効になりません。
TUN設定の解説を見る →レイテンシは、特定のテスト方法で計測した所要時間です。ICMPの往復時間、TCP接続の確立時間、リクエスト全体の処理時間などを指す場合があります。測定方法によって対象となるネットワーク処理の段階が異なるため、名称の異なる数値をそのまま比較することはできません。レイテンシが低くてもダウンロード速度が速いとは限りません。スループット、パケットロス、継続的な安定性は別途確認してください。
実接続レイテンシとの違いを見る →実接続レイテンシは通常、選択した接続設定を使ってクライアントからテスト対象へアクセスした際の所要時間です。サーバーのポートを単に確認するより、実際のリクエストに近い測定です。DNS、TLSなどを計測に含むかどうかは、クライアントの実装やテスト方法によって異なります。名称だけで一律に解釈しないでください。タイムアウトはテスト対象やルーティングルールが原因の場合もあるため、通常のアクセス結果と合わせて判断してください。
接続確認の手順を見る →