VMess
Project Vエコシステムのプロキシプロトコルで、認証とデータ保護の仕組みを備えています。認証にはUUIDがよく使われます。VMessは特定の通信方式に固定されておらず、同じプロトコルでも異なる通信設定と組み合わせられます。接続を調べる際は、ノード名だけを比べず、プロトコルのパラメーター、通信方式、セキュリティ層を個別に確認してください。
設定項目と接続に関する用語
V2Ray用語集
プロトコルからコア、ルーティング項目まで、設定の階層ごとに確認できます。まず「接続を受け付ける」「出口を選ぶ」「接続を確立する」の違いを整理し、クライアントのメニューやログと照らし合わせて設定を特定しましょう。
同じ名前のメニューでも、クライアントのバージョンによって内容が異なる場合があります。プロトコルや項目が使えるかどうかは、実際に動作するコアとそのバージョンで確認してください。用語の説明は、設定を異なるコア間でそのままコピーできることを意味しません。
プロトコルと通信方式
プロキシプロトコルは接続の動作を定義し、通信方式とセキュリティ層は接続を運び、保護します。それぞれを個別に確認する必要があります。
VLESS
軽量なプロキシプロトコルで、通信内容そのものは暗号化しないため、通常は適切なセキュリティ層と組み合わせて使います。UUIDは認証に使われ、TLSやREALITYなどの設定が接続の安全性に影響します。ノードにVLESSと記載されていても、すべてのコアのバージョンで同じflowや通信方式の組み合わせが使えるとは限りません。
Trojan
通常はTLSと組み合わせ、パスワードで認証するプロキシプロトコルです。認証用パスワードとTLSのサーバー名は別のパラメーターで、相互に置き換えられません。ハンドシェイクに失敗した場合は、パスワードが正しいかだけで判断せず、証明書の検証、サーバー名、通信方式の設定も確認してください。
TLS
通信を暗号化し、完全性を保護するとともに、通信相手を認証するセキュリティプロトコルです。設定のserverNameは通常、証明書名の検証に使われ、SNIとしてサーバーに送信される場合もあります。サーバーアドレスとサーバー名が異なる構成もありますが、明確な根拠が必要です。証明書の検証を無効にすることを、通常のトラブルシューティング手順にしないでください。
REALITY
Xrayエコシステムの通信セキュリティ機能であり、VMessやVLESSと並ぶプロキシプロトコルではありません。対応するコアを使用し、公開鍵、サーバー名、ショートIDなどのパラメーターを一致させる必要があります。TLSと関連する仕組みですが、設定項目をそのまま置き換えることはできません。クライアントが共有リンクを認識しても、現在のコアでその組み合わせが動作するとは限りません。
コアとクライアント
クライアントは画面や管理機能を担い、コアはネットワーク設定を実行します。選ぶ際は両方の要件を確認してください。
Project V
ネットワークプロキシや通信ツールを中心に形成されたオープンソースプロジェクト群で、V2Rayはその主要な構成要素です。日常的な会話では「V2Ray」が関連するエコシステム全体の総称として使われることもあります。解説を読む際は、V2FlyとXrayのどちらを対象としているかを確認し、エコシステムの名称と具体的な実行プログラムを混同しないようにしましょう。
V2Fly
V2Rayプロジェクトの開発と保守を引き継ぐコミュニティで、コアプログラムは一般にv2fly-coreと呼ばれます。コアは設定を読み込み、受信接続を受け付け、ルーティングを実行して送信接続を確立します。Xrayと関連する技術基盤を共有していても、新しいプロトコルや設定形式、項目が常に一致するとは限りません。
Xrayコア
V2Rayから派生した独立系のコアで、独自のプロトコルや通信機能を備えています。クライアント画面で選択したコアによって、設定項目が受け付けられるか、接続方式が使えるかが変わります。不明な項目や未対応プロトコルのエラーが出た場合は、アプリ名だけで判断せず、実際に起動しているコアを確認してください。
v2rayN
Windows、macOS、Linux向けのデスクトップGUIクライアントで、ノード、サブスクリプション、ルーティング設定の管理やコアの起動を行います。画面で保存した設定は変換されてからコアに渡される場合があるため、設定ファイルの内容が実際の実行設定と一致するとは限りません。デスクトップ版と従来のWPF版では画面構成が異なるため、操作時は現在のメニューを確認してください。
v2rayNG
Xrayコアでプロキシ接続を処理し、AndroidのシステムVPNインターフェースを通じて選択したアプリの通信を受け付けるGUIクライアントです。アプリとコアのバージョンは別々の情報で、互換性の調査では両方の確認が必要になる場合があります。特定のアプリの通信がプロキシ経路に入るかどうかは、アプリごとの設定とシステムの許可状態にも左右されます。
v2flyNG
V2Flyコアを採用したAndroid向けGUIクライアントで、特定のコアの動作が必要な場合の選択肢になります。名称がv2rayNGと似ていても、プロトコルの対応状況や設定の互換性が同じとは限りません。ノードをインポートする前に、必要なプロトコル、セキュリティ層、関連項目が実際のコアでサポートされているか確認してください。
設定構造
以下は、一般的なJSON設定で使われる項目です。配列、オブジェクト、タグ参照にはそれぞれ役割があるため、項目名だけを頼りに設定の断片を組み合わせないでください。
JSON
オブジェクト、配列、キーと値でデータを表すテキスト形式で、コアの実行設定によく使われます。標準JSONではキー名と文字列を二重引用符で囲み、末尾のカンマやコメントは使えません。構文が正しくても、ポートの型、プロトコル名、項目の階層が使用するコアの仕様に合っている必要があります。
受信接続
inboundsは、コアが接続を受け付ける方法を定義します。一般的な項目には、待ち受けアドレス、ポート、プロトコル、タグがあります。ループバックアドレスで待ち受ける場合、通常は同じ端末上のプログラムだけが利用できます。別のアドレスに変更する前に、アクセス可能な範囲を確認してください。クライアントが起動してもアプリの通信が流れない場合は、アプリが使うプロキシポートと対応する受信設定が一致しているか確認しましょう。
送信接続
outboundsは、コアが外部へ接続する方法を定義します。プロキシ接続、直接接続、ブロックなどの処理を設定できます。送信側のtagはルーティングから参照するための識別子であり、リモートサーバーのアドレスではありません。タグを変更した場合は、outboundTagなどの参照先も確認してください。更新しないと、ルールが意図した出口を選べないことがあります。
routing（ルーティング設定）
ルーティングの判定方法とルール一覧を格納し、コアに入った通信の出口を決める設定オブジェクトです。domainStrategyは、IPアドレスの名前解決や判定にドメイン名を使うタイミングに影響するため、DNS設定と合わせて理解する必要があります。OSのプロキシ設定を代替するものではなく、コアに入っていないアプリの通信も処理できません。
policy（ポリシー）
接続タイムアウト、ユーザーレベルに関する動作、統計機能の有効・無効など、コアのパラメーターを設定します。ドメインやアドレスに応じて出口を選ぶルーティングルールとは役割が異なります。タイムアウトを変更する前に、問題が名前解決、ハンドシェイク、データ転送のどの段階で起きているかを確認してください。待ち時間を延ばすだけでは、接続パラメーターの不一致は解消できません。
ルーティングとDNS
ドメイン名の解決、ルールが参照する宛先情報、出口の選択は、同じ接続経路における別々の段階です。
ルーティングルール
ドメイン、IP、ポート、受信側のタグなどを条件に通信を判定し、送信先またはロードバランサーを指定します。通常のルール一覧は上から順に判定されるため、先にある広い条件が後続の詳細なルールに先行することがあります。調査時は、ドメインがリストにあるかだけでなく、条件、順序、タグの参照先も確認してください。
通信の振り分け
条件に応じて通信を異なる出口へ振り分ける仕組みです。たとえば、内部アドレスは直接接続し、指定したドメインはプロキシ経由にできます。振り分け結果は、ルールの順序、利用可能なドメイン情報、DNSの結果、デフォルトの出口によって決まります。クライアントの「グローバル」や「ルール」は異なる階層のモードを指す場合があるため、メニュー名だけで全アプリの最終的な経路を判断しないでください。
GeoIP
ルーティングの判定に使うIPアドレスの集合データで、通常は分類ラベルを指定して参照します。IPアドレスの集合だけを照合するため、その結果からサイトの運営者やドメインに関連する地域を直接判断することはできません。名前解決の結果やコンテンツ配信ネットワークの利用状況、データファイルの違いによって、実際の判定結果が変わる場合があります。
GeoSite
ドメインの判定に使う分類済みの集合データで、関連する複数のドメインを同じルールにまとめるのに適しています。分類ラベルや含まれるドメインは読み込んだデータファイルによって異なり、任意のラベルが常に存在するとは限りません。GeoSiteはドメイン、GeoIPはIPを対象としており、併用できますが意味は異なります。
DNS
ドメイン名をIPアドレスなどのレコードに変換するシステムです。コア内蔵のリゾルバーとOSのリゾルバーでは、名前解決の経路が異なる場合があります。dns.serversはコアが使用できるDNSサーバーを指定しますが、実際に呼び出されるかどうかはルーティングや送信先の設定にも左右されます。DNSアドレスを変更しても、アプリのすべてのクエリが自動的にそのリゾルバーを通るわけではありません。
FakeDNS
ドメイン名に合成IPを割り当て、後続の接続時にドメイン情報を復元する仕組みです。合成アドレスは接続先サーバーの実際のグローバルIPではありません。後続の通信も、マッピングを理解できる処理経路に通す必要があります。DNSの応答だけを変更し、接続を連携して処理しないと、アドレスに接続できなかったり、マッピングが失われたりする場合があります。
DNSリーク
DNSクエリが想定した名前解決経路から外れる現象です。たとえば、指定した出口から名前解決するはずが、別のリゾルバーから送信されるケースがあります。判断する際は、画面に表示されるDNSサーバーの場所だけでなく、実際に誰がどこへリクエストを送信したかを確認してください。アプリ独自の名前解決、暗号化DNS、システムキャッシュ、アプリごとの設定も観測結果に影響します。
サブスクリプションとノード
設定のインポート、接続テスト、アプリの通信の取り込みは、それぞれ別の段階です。テスト結果は、測定方法と現在のモードを踏まえて確認してください。
サブスクリプション
リンクからノード設定を取得し、一括でインポートする配布方式です。クライアントでは通常、サブスクリプションごとにグループを分けて管理します。更新時にグループ内のノードが追加、削除、置換される場合があり、手動で変更したノード設定が保持されるとは限りません。サブスクリプションのURLにはアクセス情報が含まれることがあるため、スクリーンショット、ログ、問い合わせ内容などでURL全体を公開しないでください。
ノード
プロキシ接続に使う設定一式で、通常はアドレス、ポート、認証情報、プロトコル、通信方式が含まれます。表示名は識別用のメモにすぎず、サーバーの所在地や実際の接続品質を示すものではありません。ノードをインポートできたのは、クライアントが形式を認識したということにすぎません。接続を開始してログも確認してください。
レイテンシ
特定のテストにかかった時間です。比較するには、まず測定方法を明確にする必要があります。TCP接続で確認できるのはポートへの到達性の一部に限られ、ICMP応答があってもプロキシプロトコルの認証に成功するとは限りません。測定対象、ネットワークの状態、タイムアウト設定によって結果は変わります。レイテンシが低くても、ダウンロード速度が速いとは限りません。
実接続レイテンシ
クライアントでは通常、ノード経由でテスト先に実際のリクエストを送信した際の所要時間を指します。名前解決、接続の再利用、ハンドシェイクが測定に含まれるかは、クライアントの実装とテスト設定によって異なります。テストに成功すれば、その時点で対象へのリクエストが完了したことは確認できますが、ほかのサイトやアプリ、後続の接続でも同じ結果になるとは限りません。
システムプロキシ
OSがアプリに提供するプロキシ設定で、通常は設定に従うリクエストを端末上のクライアントのポートへ送ります。独自のプロキシ設定を使うアプリや、直接接続するアプリもあるため、システムプロキシを有効にしてもすべての通信が転送されるわけではありません。通信がクライアントに入るかどうかを決める設定であり、入った後の出口はコアのルーティングなどによって決まります。
TUNモード
仮想ネットワークインターフェースを介してIPパケットを処理する動作モードで、システムプロキシ設定に従わない通信の一部も対象にできます。実際に取り込まれる範囲は、システムのルーティング、権限、DNSの処理、クライアントの実装によって異なり、有効にすればすべての接続がプロキシ経由になるわけではありません。有効化後に問題が起きた場合は、ほかの仮想インターフェース、ルーティングの競合、アプリごとの設定を確認してください。