VMess
VMessはProject Vエコシステムのプロキシプロトコルで、ユーザー認証とデータ保護の仕組みを備えています。ノードではUUIDでユーザーを識別することがよくあります。接続時にはユーザー識別子だけでなく、トランスポート方式とその追加パラメーターも一致させる必要があります。時刻のずれが認証に影響することがあるため、ハンドシェイクに繰り返し失敗する場合は端末の時刻同期も確認してください。
設定の階層ごとに、よく使われる24の用語を解説します。接続プロトコル、処理を担うコア、通信経路を整理したうえで、クライアントの設定項目から問題の箇所を確認できます。
初めて設定する場合は使い方ガイドを、明確なエラーが出ている場合はトラブルシューティングをご覧ください。このページの用語名は固定アンカーとして参照できます。
protocol / transport
プロトコルは認証と転送のルールを定め、トランスポート設定はデータの運び方を決めます。
VMessはProject Vエコシステムのプロキシプロトコルで、ユーザー認証とデータ保護の仕組みを備えています。ノードではUUIDでユーザーを識別することがよくあります。接続時にはユーザー識別子だけでなく、トランスポート方式とその追加パラメーターも一致させる必要があります。時刻のずれが認証に影響することがあるため、ハンドシェイクに繰り返し失敗する場合は端末の時刻同期も確認してください。
VLESSは軽量な認証と転送を重視し、汎用的なデータ暗号化は行わないため、通常はTLSまたはREALITYと組み合わせます。設定のprotocol、flow、トランスポートセキュリティは別々の項目です。VLESSという名称だけでノード設定がそろっているとは判断できません。利用できる機能はコアの実装によって異なるため、クライアントとサーバーの設定を一致させてください。
Trojanは通常、TLS接続上で動作し、パスワードでユーザーを認証します。通信の保護はTLSが担います。アドレス、ポート、パスワードが正しくても、証明書の検証に成功するとは限りません。サーバー名も運用側の指定と一致させる必要があります。問題の切り分けでは、パスワード認証、TLSハンドシェイク、宛先への接続失敗を区別してください。
ここでは、TCPやWebSocketなど、プロキシプロトコルのデータを運ぶ方式を指します。Xrayの設定では通常、streamSettingsに関係します。WebSocketを選んだ場合も、パスや関連するリクエストパラメーターをサーバー側と一致させる必要があります。トランスポート名だけ変更しても動作しません。TLSとREALITYはトランスポートのセキュリティ設定であり、データの運搬方式とは別の項目です。プロトコルを変更しても、これらの設定が自動で修正されるわけではありません。
ecosystem / core
エコシステム、コア、GUIはそれぞれ役割が異なります。互換性の問題を調べる際は、実際に動作しているコアを確認してください。
Project Vは、モジュール型ネットワークプロキシツールを中心に形成されたプロジェクトエコシステムを指します。V2Rayはその中でも重要なプロジェクト名です。特定のデスクトップアプリのメニュー名ではなく、関連するすべてのクライアントが同じ機能を備えているという意味でもありません。設定について話すときは、クライアント名、実行中のコア、関連機能を明示し、「V2Ray」だけで問題を説明しないようにしましょう。
Xray-coreはプロトコル、インバウンド・アウトバウンド、ルーティング、DNSなどを処理するプロキシコアで、GUIクライアントから呼び出して接続を実行できます。VLESS、REALITY、Visionなどの機能は、画面に該当する選択肢があるかではなく、実際のコアのバージョンと設定を確認してください。2つのコアの系譜については、Xray-coreとV2Flyの違いをご覧ください。
V2FlyはV2Rayプロジェクトのコミュニティとコアの系譜を引き継いでいます。Xray-coreとは歴史的なつながりがありますが、その後の機能や設定の詳細は分化しています。一方のコアで読み込める設定が、もう一方でもすべての項目に対応するとは限りません。Android向けのv2flyNGは、この系譜のGUIクライアントの選択肢です。利用する前に、サブスクリプションが必要とするプロトコルに対応しているか確認してください。
GUIクライアントは、ノード一覧、サブスクリプションのグループ、プロキシのオン・オフ、ログへのアクセスなどを操作する画面を提供します。例として、デスクトップ向けのv2rayNやAndroid向けのv2rayNGがあります。画面上の設定からコア用の設定を生成するため、メニュー名がJSONの項目名と完全に一致するとは限りません。GUIの更新、コアの更新、ルールファイルの更新は別々の操作です。互換性の問題が起きた場合は、それぞれを確認してください。
interface / traffic entry
まずアプリの通信がクライアントに渡されているかを確認し、次にコアがどのアウトバウンドから送信しているかを調べます。
システムプロキシはローカルプロキシのアドレスをOSの設定に登録し、その設定を参照するアプリにのみ適用されます。一部のコマンドラインツール、独立したネットワークコンポーネント、独自のプロキシ設定を使うソフトウェアは自動では従いません。有効にしてもブラウザーが直接接続する場合は、リモートノードが無効と決めつけず、アプリ側のプロキシ設定とローカルの待ち受けポートを確認してください。
TUNは仮想ネットワークインターフェースでIPパケットを受け取り、プロキシプログラムに通信を渡して処理します。通常、システムプロキシとは通信を取り込む範囲が異なります。実際に動作するには、システム権限、ルーティング、DNSの連携が必要です。スイッチをオンにしただけで処理経路全体が構築されたとは限りません。他の仮想ネットワークソフトウェアと併用する場合は、ルートの競合、インターフェースの選択、ローカルネットワークへのアクセスを重点的に確認してください。
インバウンドはコアが接続を受け付ける入口で、ブラウザー向けのローカルHTTPやSOCKSの待ち受けポートなどが該当します。設定ではinboundsにあたります。待ち受けアドレスによって接続できる端末が決まり、ポートはアプリ側の設定と一致させる必要があります。この端末内だけで使う場合は、ローカルアドレスで待ち受けてください。LANに公開する前に、アクセス制御と認証の要件を明確にしましょう。
アウトバウンドは、コアが通信を次の経路へ送る方法を決めます。プロキシ転送、直接接続、ブロックなどがあり、設定ではoutboundsにあたります。ルーティングではoutboundTagを使ってアウトバウンドを指定します。タグは単なる名前であり、directという名前を付けただけで直接接続になるわけではありません。ルールの参照先とアウトバウンド定義を一致させないと、設定エラーや想定外の経路につながる場合があります。
subscription / measurement
設定の取得、サーバーへの接続、テスト結果は、それぞれ独立した段階です。
サブスクリプションは、ノード設定をまとめて取得するためのURLまたはコンテンツです。更新すると、通常は対象グループのノード一覧が再取得されます。更新が成功したということは、リクエストとコンテンツの処理が完了したという意味にすぎず、ノードへの接続や各ノードの利用を保証するものではありません。サブスクリプションURLにアクセス用の認証情報が含まれる場合があるため、公開しないでください。更新に失敗した場合は、サブスクリプション更新のトラブルシューティングを参考に、URL、ネットワーク、形式の問題を切り分けましょう。
ノードは、クライアントで接続に使うサーバー設定のまとまりです。通常、アドレス、ポート、プロトコル、認証、トランスポート、セキュリティ設定が含まれます。表示名は識別用であり、名前に地域が書かれていてもサーバーの実際の場所や通信経路は決まりません。インポート後にサーバー名や公開鍵などの必須パラメーターが欠けていると、アドレスとポートに到達できてもハンドシェイクを完了できない場合があります。
レイテンシは、特定のテスト方法で往復通信が完了するまでの時間です。数値を見る前に、何を測定した結果なのかを確認してください。TCPポートへの接続に成功しても、そのポートに到達できたことを示すだけで、プロキシ経由のリクエスト全体を検証したことにはなりません。レイテンシが低くてもスループットが高いとは限りません。ダウンロード速度は帯域幅、パケットロス、接続先のサービス、回線の混雑にも左右されます。
実接続レイテンシは通常、選択したプロキシ設定を使ってテスト先へリクエストし、完了までの時間を測定します。具体的な方法はクライアントの実装によって異なります。より多くの実際の接続処理を含むテストですが、結果はテスト先、タイムアウト値、ネットワークの状態にも左右されます。一度の失敗だけでノードが使えないと判断せず、ログを確認し、別のテスト先でも試してください。初回利用時は初回接続の確認手順も参考になります。
routing / name resolution
ルールは通信経路を選び、DNSは名前を解決します。相互に影響しますが、同じ機能ではありません。
振り分けとは、ドメイン、IP、ポート、インバウンドなどの条件に応じて、接続に使うアウトバウンドを選ぶことです。ルールは通常、設定された順に照合されます。広範囲に一致するルールを先に置くと、後続の細かい条件が評価されない場合があります。どのルールにも一致しない場合のデフォルトのアウトバウンドも確認してください。domainStrategyは、ドメインをいつIP解決に使うかに影響します。たとえばIPIfNonMatchでは、ドメインルールに一致しなかった後にIPを解決して照合します。
GeoIPは、タグごとに整理されたIPアドレスの集合です。geoip:privateなどの式を使って照合できます。タグが示すのはデータベースに登録されたアドレス範囲であり、現在の接続の物理的な位置をリアルタイムに測定するものではありません。ドメインを使う接続がIPルールに一致するかどうかは、名前解決の方針にも左右されます。データを更新した後は、ルールが利用可能なタグを実際に参照しているか確認してください。
GeoSiteは、用途、サービス、地域などのタグごとに整理されたドメインの集合で、geosite:cnのような形式で参照します。ドメインの照合を補助するもので、ドメインをIPに名前解決したり、特定のサービスに属するすべてのドメインを網羅したりするものではありません。タグがあるかどうかは使用中のルールデータベースによって異なります。関連ファイルの更新についてはGeoIP・GeoSiteの更新方法をご覧ください。
FakeDNSはアプリに合成IPアドレスを返し、プログラム内部でアドレスと元のドメインの対応関係を管理します。これにより、後続の接続をドメインに基づいて処理できます。合成IPは接続先サイトの実際のアドレスではありません。通信は、対応関係を復元できる処理経路に通す必要があります。DNS側だけを有効にして通信を取り込まないと、アクセスできなくなる場合があります。モードを切り替えた後は、システムやアプリに残った古いDNSキャッシュにも注意してください。
security / verification
認証、通信経路の暗号化、DNSの経路は個別に確認してください。1つのスイッチだけで全体を判断することはできません。
TLSは暗号化された通信経路を確立し、証明書などを使って接続先の身元を検証します。サーバー名、証明書チェーン、システム時刻は検証結果に影響します。serverNameには、サービスの構成と関係のないドメインを指定しないでください。証明書エラーが発生した場合は、名前、時刻、サーバー側の設定を確認し、証明書検証のスキップを恒久的な解決策にしないでください。
REALITYはXrayエコシステムのトランスポートセキュリティ機能で、VLESSと組み合わせて使われることがよくあります。単独のノードプロトコル名ではありません。サーバー名、公開鍵、ショートIDなどのクライアント側パラメーターをサーバー側の指定と一致させる必要があります。セキュリティ方式をREALITYに変更するだけでは移行できません。ハンドシェイクの仕組みと適用条件はREALITYとXTLS Visionの仕組みをご覧ください。
Visionは、VLESSでxtls-rprx-visionと表記されることが多いフロー制御方式で、条件を満たすTLS通信の処理を最適化します。対応するトランスポート方式とTLSまたはREALITYを組み合わせ、クライアントとサーバーの両方でサポートされている必要があります。独立したプロトコルでも、すべての接続を高速化する機能でもありません。パラメーターが一致しない場合、まず接続やハンドシェイクの問題として現れます。
DNSリークとは、ドメインの問い合わせが想定した名前解決経路を通らない状態です。たとえば、指定したリモート側で解決するはずの問い合わせが、ローカルネットワークに送られるケースがあります。システムDNS、ブラウザーのセキュアDNS、クライアント内蔵DNS、振り分けルールをあわせて確認してください。検査ページに表示されたリゾルバー名だけでは判断できません。一部のドメインをローカルで解決する設定が意図されている場合、その問い合わせは必ずしも異常ではありません。実際の動作が想定した範囲に収まっているかが重要です。
まず問題がどの階層にあるかを確認し、該当する設定を調べてください。インポート成功、ポートへの到達、プロキシ経由のリクエスト成功は、それぞれ個別に検証が必要です。
初回接続がまだの場合は、サブスクリプションのインポートとプロキシモードの使い方から始め、設定、ノードの選択、アプリからのリクエストを順番に確認してください。接続できるのに一部のアプリで機能しない場合は、関係のない項目を何度も変更せず、システムプロキシ、TUN、インバウンド、ルーティングを優先して確認しましょう。
タイムアウト、名前解決エラー、クライアントの異常が発生した場合は、トラブルシューティングで症状に応じた項目を確認してください。ログを共有する前に、サブスクリプションURL、ユーザー識別子、パスワードなどの認証情報を削除してください。エラーの種類、発生した処理段階、関連する設定名を残せば、切り分けに役立ちます。