VMess
プロトコルの種類
VMessはProject Vエコシステムのプロキシプロトコルで、認証とデータ保護の仕組みを備えています。接続にはサーバーとポートだけでなく、ユーザーID、通信方式、セキュリティレイヤーなどのパラメーターも一致させる必要があります。認証処理はシステム時刻に依存するため、端末の時刻が大きくずれていると接続に失敗する場合があります。接続できないときは、アドレスだけでなく時刻も確認してください。
プロトコルの選び方を見る →V2Ray / 用語早見表
V2Ray用語集
設定項目の名前から、プロキシプロトコル、コア、通信方式、セキュリティレイヤーの違いを確認できます。
プロトコルの種類
プロキシプロトコルは、クライアントとサーバー間の認証方法やプロキシデータのやり取りを定めます。プロトコル名が同じでも、接続設定全体が同じとは限りません。
VLESS
プロトコルの種類
VLESSは軽量なプロキシプロトコルで、プロキシリクエストと識別情報を扱いますが、ペイロード自体は暗号化しません。実際の運用では、通常TLSやREALITYなどのセキュリティレイヤーと組み合わせます。VLESSを選んだだけで暗号化設定が完了したわけではありません。一部のフロー制御オプションには、特定のコアやパラメーターの組み合わせが必要なため、インポート後に各項目を確認してください。
VLESSとREALITYの違いを見る →Trojan
プロトコルの種類
Trojanは通常TLS接続を使用し、パスワードでプロキシ認証を行います。パスワードが正しいだけでは接続できず、サーバー名、証明書の検証、通信方式もサーバー側と一致させる必要があります。リンクをインポートした後にハンドシェイクが失敗する場合は、同じパスワード項目を何度も変更するのではなく、TLS設定とプロトコル認証を分けて確認してください。
TLSの役割を見る →Shadowsocks / SS
プロトコルの種類
Shadowsocks（SS）は、事前共有鍵を使って設定する暗号化プロキシプロトコルです。暗号化方式やプロトコルの世代によって、鍵の形式や実装要件が異なるため、クライアントがサーバー指定の方式に対応している必要があります。画面に両方ともShadowsocksの選択肢があるからといって、必ず互換性があるとは限りません。異なる形式の鍵を混用しないでください。
プロトコルの互換性を見る →コアとエコシステム
クライアントは操作と設定管理を担い、コアは接続とルーティングを処理します。エコシステムの名称と具体的なソフトウェアパッケージの名称は同じではありません。
Project V
コアとエコシステム
Project Vは、V2Rayの起源やモジュール型プロキシツールの設計を理解するための背景概念で、特定のプロキシプロトコルではありません。このエコシステムについて調べる際は、コアプログラム、プロトコル実装、GUIクライアントのどれを指しているのかを確認しましょう。V2Ray関連の名称を見つけたら、名称だけでインストールパッケージを選ぶのではなく、ソフトウェアが担う役割を確認することが大切です。
クライアントとコアの役割を見る →Xray
コアとエコシステム
XrayはV2Rayのコードベースを基に発展したプロキシコアで、独自のプロトコル、通信方式、セキュリティ機能を保守しています。REALITYなどの機能を使うには、対応する実装とバージョンが必要です。他のコアが同じ設定をそのまま受け付けるとは限りません。コアを切り替える前に、クライアントが必要な項目を生成できるか確認し、現在動作している設定も保存してください。
コアの違いを見る →V2Fly
コアとエコシステム
V2FlyはV2Ray関連の実装を継続的に保守するコミュニティプロジェクトです。クライアントにあるV2Flyコアという選択肢は、通常、V2Flyが保守するコアプログラムを指します。Xrayとは共通の歴史がありますが、機能の進化、設定項目、形式が同じとは限りません。v2flyNGはGUIクライアントの名称で、V2Flyコアそのものを指すわけではありません。
Xrayとの役割の違いを見る →GUIクライアント
コアとエコシステム
GUIクライアントは、サブスクリプションのインポート、ノード選択、ルーティング編集、システム連携などの操作画面を提供し、実際のネットワーク処理はコアが担います。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けで、対応機能は組み込まれたコアによって異なります。画面に項目が表示されていても、選択中のコアやサーバーがその組み合わせに対応しているとは限りません。
プラットフォーム別にクライアントを見る →通信方式と暗号化
プロキシプロトコル、通信のカプセル化、セキュリティレイヤーはそれぞれ異なる役割を示します。どれか1つを選んだだけで、接続方式全体が決まるわけではありません。
TLS
通信方式と暗号化
TLSは通信の暗号化、完全性保護、認証を提供します。プロキシ設定のサーバー名は、ハンドシェイクや証明書の検証に使われることがあります。接続先アドレスと検証に使う名前は異なる場合がありますが、サーバーの構成に合っている必要があります。証明書の検証を無効にすると、認証の安全性が低下します。証明書エラーが出た場合は、名前、証明書チェーン、端末の時刻を先に確認してください。
セキュリティレイヤー設定の範囲を見る →REALITY
通信方式と暗号化
REALITYはXrayエコシステムの通信セキュリティ機構で、VMessやVLESSと同じ階層にある独立したプロキシプロトコルではありません。一般的な設定では、プロキシプロトコルを示すVLESSと、セキュリティレイヤーを示すREALITYを併用します。公開鍵、サーバー名、ショートIDなどはサーバー側の指定に従って入力してください。通常のTLS設定の名前だけを変更して使うことはできません。
VLESSの用語に戻る →通信方式
通信方式と暗号化
通信方式は、TCPを直接使う場合やWebSocket、gRPCなどを利用する場合のように、プロキシデータの運搬・カプセル化方法を示します。必要なパス、サービス名、リクエストヘッダーは方式ごとに異なり、すべてのプロキシプロトコルとセキュリティレイヤーを自由に組み合わせられるわけではありません。同じ名前の選択肢があっても、クライアントとサーバーのコアがどこまで対応しているか確認してください。
プロトコルと通信方式の組み合わせを見る →多重化 / Mux
通信方式と暗号化
多重化は、複数の論理データストリームを少数の下位接続にまとめ、一部の接続確立に伴う重複した負荷を減らします。常に通信を高速化する設定ではなく、下位接続に問題があると複数のリクエストに影響する場合もあります。コアによって実装や互換条件が異なるため、プロトコルの組み合わせ、回線状況、実際のアプリでのテストを踏まえて有効にするか判断してください。
接続テストの注意点を見る →サブスクリプションとリンク
単一の設定と設定の一覧では、インポートする入口が異なります。インポート成功、更新成功、接続成功もそれぞれ別の確認項目です。
サブスクリプションURL
サブスクリプションとリンク
サブスクリプションURLは、複数の接続設定を取得するための入口です。クライアントがURLにアクセスし、返された内容を解析します。URLにはアクセス用の識別情報が含まれることがあるため、機密情報として扱い、公開スクリーンショットや質問文に載せないでください。クライアントによって対応する形式や拡張項目が異なり、URLにアクセスできても内容を正しくインポートできるとは限りません。
サブスクリプションのインポート手順を見る →ノード
サブスクリプションとリンク
ノードは、クライアントで選択できる接続設定を指す一般的な呼び方です。通常、サーバー、ポート、認証、通信方式、セキュリティレイヤーのパラメーターが含まれます。専用の物理サーバーに対応するとは限らず、表示名は識別用のラベルにすぎません。設定が重複しているか同等かを判断するときは、名前、地域表示、並び順ではなく、実際のパラメーターを確認してください。
ノードの共有方法を見る →共有リンク
サブスクリプションとリンク
共有リンクは、接続設定を特定のURI形式で記述したものです。たとえば、vmess://、vless://、trojan://で始まるテキストがあります。通常は単一の設定を表し、複数の設定を定期的に取得するサブスクリプションURLとは異なります。QRコードはテキストを別の形で表示したもので、スキャンしてインポートする場合も、クライアントが該当するプロトコルや項目に対応している必要があります。
サブスクリプションの更新
サブスクリプションとリンク
サブスクリプションの更新は、リモートの内容を再取得してローカルの接続設定に反映する操作です。クライアントやコアのアップデートとは異なります。更新によってノード名、パラメーター、利用可能な一覧が変わることがあるため、サブスクリプション内のノードを編集する前に、クライアントがローカルの変更をどのように扱うか確認してください。更新に失敗した場合は、URLへのアクセス失敗、返された形式の非対応、個別項目の非対応を切り分けます。
インストールと設定のトラブルを見る →ルーティング
ドメインの照合、IPの照合、名前解決は互いに影響します。ルールを確認する際は、順序、条件、最終的な出口を併せて確認してください。
ルーティングルール
ルーティング
ルーティングルールは、ドメイン、宛先IP、ポートなどの条件に基づいて、接続の出口を選びます。一般的な実装では設定順にルールを確認するため、先に一致したルールによって後続のルールが適用されないことがあります。どのルールにも一致しない通信は、既定のポリシーで処理されます。トラブル時は、まず通信がコアに届いているか確認し、次に一致条件を調べてください。ルール名だけで結果を判断することはできません。
ルーティングの選び方と照合方法を見る →GeoIP
ルーティング
GeoIPは通常、地域や事前定義されたカテゴリ別に整理されたIPアドレスの一覧を指します。geoip:cnはよく使われる参照形式です。分類結果はデータソースと更新時期に依存し、サーバーの実際の物理的な場所をリアルタイムに測定するものではありません。共有IPの利用やサービス構成の変更により、IPの分類が特定のサイトの用途に関する判断と一致しない場合もあります。
GeoSite
ルーティング
GeoSiteは、サービスや用途などのカテゴリ別に整理されたドメインルールの一覧です。geosite:cnはよく使われる参照形式です。分類ラベルはコアが自動検出するものではなく、対応するデータファイルが必要です。対象範囲はデータソースによって異なります。GeoIPとは照合対象が異なるため、ドメインカテゴリを関連サービスのすべてのIPアドレスの一覧と捉えることはできません。
ルーティングの振り分け
ルーティング
ルーティングの振り分けは、ポリシーに従って通信を直結、プロキシ経由、ブロックなどの出口に割り当てる方法であり、新しいプロキシプロトコルではありません。画面のルールモードでは、通常、あらかじめ用意されたルーティングルールが有効になりますが、モード名や具体的な動作はクライアントによって異なる場合があります。ルールモードを選んでも、すべてのアプリがプロキシ経由になるわけではありません。通信の入口はシステムプロキシ、TUN、アプリ独自の設定によって決まります。
通信がクライアントに届く仕組みを見る →DNS
ルーティング
DNSはドメインをIPアドレスなどのレコードに変換します。プロキシ環境では、アプリ、OS、コアが名前解決に関わる場合があります。どのリゾルバーを使うか、問い合わせがどの出口を通るか、ルーティング時にドメインとIPのどちらを使うかによって結果が変わります。DNSアドレスを1つ変更しただけでは、すべてのアプリの経路が統一されるとは限りません。キャッシュ、ブラウザーの設定、コアの名前解決ポリシーも確認してください。
名前解決経路のずれを確認する →クライアント設定
まず通信をどこまで取り込むかを理解してから動作モードを選びましょう。テスト結果は問題の切り分けに役立ちますが、実際のアプリでの確認に代わるものではありません。
システムプロキシ
クライアント設定
システムプロキシは、アプリが参照するOSのプロキシ設定で、通常はクライアントが待ち受けるローカルアドレスとポートを指定します。この設定に従うアプリだけが通信を転送するため、有効にしてもすべてのネットワーク通信が対象になるわけではありません。アプリ独自のプロキシ設定、独立したネットワークスタック、他のプロキシツールによって、実際の経路が変わることがあります。
システムプロキシの有効化手順を見る →TUNモード
クライアント設定
TUNモードは、仮想ネットワークインターフェースでIPパケットを受け取り、プロキシコンポーネントに渡します。システムプロキシだけの場合より広い範囲を扱えることが一般的です。追加の権限やルーティング、DNSの設定が必要な場合がありますが、端末上のすべての接続が必ずプロキシを通るわけではありません。他の仮想ネットワークツールと併用するときは、ルートの競合やプロキシ自身の通信がループする問題も確認してください。
通信の取り込み方式と振り分け方針の違いを見る →FakeDNS
クライアント設定
FakeDNSは、ドメインに予約済みアドレス範囲内の合成IPを割り当て、対応関係を保存しておくことで、後続の通信処理でドメインを復元できるようにします。返されるアドレスは接続先サーバーの実IPではありません。アプリがそのアドレスにアクセスした後は、対応するコンポーネントによる処理が必要です。有効化の条件、アドレス範囲、ルーティングを適切に組み合わせてください。対応するマッピングを認識できない経路に合成IPが渡ると、接続に失敗する可能性があります。
DNSとルーティングの関係を見る →DNSリーク
クライアント設定
DNSリークとは、問い合わせが想定した名前解決経路から外れる現象です。たとえば、コアに処理させる予定の問い合わせが、OSのリゾルバーから送信される場合があります。判断する前に、想定するリゾルバー、通信方式、問い合わせの出口を明確にしてください。リゾルバーに表示された地域だけでは判断できません。ブラウザー独自の暗号化DNS、アプリ内の名前解決、複数のネットワークインターフェースによって、経路に違いが生じることがあります。
名前解決と接続のトラブルを見る →レイテンシ
クライアント設定
レイテンシは、測定にかかった時間を示します。ただし、TCP接続、ICMPプローブ、HTTPリクエストでは測定する処理が異なります。TCP接続にかかる時間が短くても、プロキシ認証、TLSハンドシェイク、Webサイトへのアクセスが成功するとは限りません。設定を比較するときは、同じ測定方法と接続先を使い、単回の結果だけでなく安定性や実際のアプリでの使用感も確認してください。
実接続テストの意味を見る →実接続レイテンシ
クライアント設定
実接続レイテンシは通常、クライアントが選択したプロキシ設定を通じてテスト先にリクエストを送り、その所要時間を記録した値です。測定範囲は実装によって異なります。サーバーポートへの単純な疎通確認より実際のプロキシ通信に近いものの、結果が示すのはその接続先と測定時のネットワーク状態だけです。失敗した場合はログを確認し、名前解決、ハンドシェイク、リクエストのどの段階かを切り分けてください。成功しても、すべてのサイトにアクセスできるとは限りません。
接続後の確認手順を見る →