VMess
VMess ProtocolVMessはProject Vのエコシステムに属するプロキシプロトコルで、認証とデータ保護の仕組みを備えています。設定をインポートしたら、ユーザー識別子、通信方式、セキュリティ層をそれぞれ確認してください。サーバーアドレスとポートだけでは不十分です。古い設定にある追加の識別パラメーターを経験だけで補わず、サーバーから提供された情報と使用中のコアの対応状況を確認しましょう。
設定用語・6カテゴリ
V2Ray用語集
プロトコル、コア、クライアントの違いから、サブスクリプション、ルーティング、DNSの設定まで解説します。
カテゴリを選ぶと該当するセクションへ移動します。各用語はアドレスバーのアンカーで個別に参照できます。似た設定名がある場合は、使用中のクライアントとコアを確認してから説明を参照してください。
クライアントの設定手順を見る →プロトコルと通信方式
プロトコルはプロキシ通信の仕組みを定め、通信方式はデータの運び方を定めます。別々の設定項目として扱い、混同しないようにしましょう。
VLESS
VLESS ProtocolVLESSは軽量なプロキシプロトコルで、単体では通信を完全に暗号化しません。通常はTLSやREALITYなどのセキュリティ層と組み合わせて使います。同じプロトコル名でも、設定をそのまま相互に使えるとは限りません。フロー制御、通信方式、セキュリティパラメーターも一致させる必要があります。クライアントがリンクを読み込めても、実際の接続に必要な条件がそろっているとは限りません。
Trojan
Trojan ProtocolTrojanは通常、TLSで接続を保護し、パスワードで認証します。このパスワードはノードの認証情報であり、クライアントのローカル管理用パスワードではありません。接続できない場合は、認証情報だけでなく、接続先のドメイン名、証明書の検証、通信パラメーターも確認してください。パスワードの再入力だけでは、すべてのハンドシェイクの問題は解決しません。
通信方式
Transportクライアント設定における通信方式は、通常、TCP、WebSocket、gRPCなど、プロキシプロトコルのデータを運ぶ方法を指します。厳密なネットワーク階層モデルに沿った用語ではありません。WebSocketのパスやHost、gRPCのサービス名などはそれぞれ用途があり、サーバー側の設定と一致させる必要があります。通信方式の切り替えは単なる性能設定ではなく、むやみに変更すると接続できなくなることがあります。
コアとクライアント
GUIは設定を管理し、コアプログラムは接続を処理します。必要な機能を使えるかどうかは、両方が対応しているかで決まります。
V2RayとProject V
V2Ray / Project VProject Vはモジュール型のネットワークプロキシツール群で、V2Rayはその主要な実装の一つです。プロトコル処理、ルーティング、DNSなどの機能を備えています。日常的な検索で使われる「V2Rayクライアント」は、GUIの管理ソフトを広く指すことがありますが、GUIとコアは別のものです。問題を調べる際は、クライアント名と実際に起動しているコアを分けて記録し、画面の不具合と接続の問題を混同しないようにしましょう。
Xrayコア
Xray CoreXrayはV2Rayと歴史的なつながりを持つ、独立したプロキシコアプロジェクトです。接続の確立、プロトコル処理、ルーティングの実行などを担います。v2rayNGはXrayコアを使用します。デスクトップクライアントで利用できるコアは、実際の設定を確認してください。対応するプロトコルやパラメーターはコアのバージョンによって異なります。コアを切り替えた後も、すべての詳細設定が同じ意味で使えるとは限りません。
V2Fly
V2Fly CommunityV2FlyはV2Rayのコアや関連コンポーネントを継続的に保守するコミュニティプロジェクトです。v2flyNGはAndroidでこのコア系統を利用できるクライアントです。V2FlyとXrayの機能の進化は完全に同じではなく、一方のコアで認識される拡張パラメーターが、もう一方でも使えるとは限りません。名称が似ているという理由だけで置き換えず、設定の要件を確認して選びましょう。
GUIクライアント
Graphical ClientGUIクライアントでは、サブスクリプションの追加、ノードの選択、ルーティングの管理、プロキシモードの切り替えなどを行い、コアに接続処理を依頼します。v2rayNはWindows、macOS、Linux向け、v2rayNGとv2flyNGはAndroid向けです。同じ機能でもクライアントによってメニュー名が異なる場合があります。デスクトップのシステムプロキシ設定を、そのままモバイル端末に当てはめないでください。
クライアントの比較を見る →サブスクリプションとノード
サブスクリプションは設定の取得元、ノードは個別の接続設定です。疎通テストの結果は、その時点での参考値にすぎません。
サブスクリプション
Subscriptionサブスクリプションはリンクから複数の接続設定を取得・更新する仕組みであり、プロキシプロトコルでも接続を有効にする操作でもありません。インポート後はリストを更新し、ノードを選び、適切なプロキシモードを設定してください。サブスクリプションURLにはアクセス認証情報が含まれる場合があります。スクリーンショット、ログ、問い合わせ内容を共有する前にURL全体を隠し、公開ページに掲載しないでください。
サブスクリプションの追加手順を見る →ノード
Node / Connection Profileノードはクライアントに登録された個々の接続設定で、通常、サーバーアドレス、ポート、プロトコル、認証情報、通信パラメーターが含まれます。リストに表示される名前は識別用のラベルにすぎず、実際の場所や利用可否、性能を名前だけで判断することはできません。ノードを選択した後も、コアが起動していることと、アプリの通信が実際にクライアントへ流れていることを確認してください。
サブスクリプショングループ
Subscription Groupサブスクリプショングループを使うと、提供元や用途ごとにサブスクリプションとノードを整理でき、個別に更新、絞り込み、管理できます。グループを更新すると、サブスクリプションの内容が置き換わる場合があります。手動編集したノードのパラメーターも、次回の更新で上書きされることがあります。挙動はクライアントによって異なります。長期的に残す手動設定は、自動更新されるサブスクリプションと分けて管理しましょう。
遅延と実接続遅延
Latency / Real Connection Latency遅延は、特定の方法で通信を測定した際にかかる時間です。TCPによる測定と、プロキシ経由でテスト先にアクセスする「実接続遅延」は同じ指標ではありません。実接続遅延はDNS、ハンドシェイク、テスト先、現在のネットワーク状況にも左右されます。測定値が低くてもダウンロード速度が速いとは限りません。テストに失敗した場合は、ノードが利用できないのか、テスト先に到達できないのかをまず切り分けましょう。
ルーティング
まず通信がクライアントに届いているかを確認し、その後でルールによる出口を調べましょう。
ルーティング
Routingルーティングでは、ドメイン名、IPアドレスなどの条件に基づき、通信をプロキシ経由、直接接続、ブロックのいずれにするか決めます。一般的な設定ではルールを順に照合し、先に一致したルールが後続の処理に影響します。どのルールにも一致しない場合は、デフォルトの出口を確認してください。グローバルモードでも、すべてのアプリの通信が自動的に取り込まれるとは限りません。通信がクライアントに届いていなければ、内部のルールは適用されません。
GeoIP
IP Address Rule DatasetGeoIPは、地理的な地域やその他の分類に基づいてIPアドレスをまとめたルールデータです。宛先アドレスに応じて通信の出口を決める際に利用できます。リアルタイムの位置情報サービスではなく、データの更新状況やサービスの配置によって、アドレスの分類にずれが生じる場合があります。ドメイン名を使う通信では、名前解決のタイミングやIPアドレスの照合方法も、ルーティングのドメイン名設定に左右されます。
GeoSite
Domain Rule DatasetGeoSiteは、Webサイト、サービス、用途ごとにドメイン名をまとめ、ルーティングルールで複数の宛先を一括して照合できるようにします。ラベル名がサービスの範囲を常に網羅しているとは限りません。同じサービスでも、ログイン、静的コンテンツ、CDN用に別のドメインを使う場合があります。一部のページが読み込めない場合は、すべての通信を同じ出口に変更する前に、ログで照合されていないリクエストを確認しましょう。
システムプロキシとTUNモード
System Proxy / TUNシステムプロキシはOSのプロキシ設定を通じて、設定に従うアプリの通信を受け付けますが、一部のアプリはこの設定を無視します。TUNモードは仮想ネットワークインターフェースで通信を受け取り、通常はルーティング、DNS、必要な権限の設定も必要です。対象範囲は実装によって異なります。まず通常のプロキシモードで接続を確認してからTUNを有効にすると、複数の仕組みが同時に介在するのを避け、問題を切り分けやすくなります。
プロキシモードの対処方法を見る →セキュリティと暗号化
暗号化は通信内容を保護し、認証は接続先を確認します。検証を無効にしても、設定の問題は解決しません。
TLS
Transport Layer SecurityTLSは通信データを保護し、接続先の正当性を確認します。プロキシ接続ではセキュリティ層として設定されることがあります。証明書のドメイン名が一致しない、証明書が期限切れ、本体の時刻が大きくずれているといった原因で、ハンドシェイクに失敗する場合があります。TLSが保護するのは対象となる接続経路であり、接続先のサービスの信頼性を保証するものではありません。アプリ自体のアカウントやデータを守る対策の代わりにもなりません。
REALITY
REALITY SecurityREALITYはXrayのエコシステムにおける通信セキュリティ機構です。独立したサブスクリプション形式でも、特定のGUIクライアントでもありません。設定時にはサーバーの要件に合わせて公開鍵、サーバー名、ショートIDなどを指定し、クライアントとコアの両方が対応している必要があります。通常のTLS設定でセキュリティ層の名称だけをREALITYに変更しても、接続できるようにはなりません。
SNI
Server Name IndicationSNIはTLSハンドシェイクで接続先のサーバー名を示す拡張機能です。同じアドレスで複数のサービスを提供するサーバーが、適切なサービスや証明書を選ぶのに使われます。実際の接続先IPアドレスとは異なる場合がありますが、サーバーの設定と認証要件に合っている必要があります。ドメイン名に関するエラーが起きた場合は、設定の提供元にサーバー名を確認してください。他のWebサイトのドメイン名を安易に入力しないでください。
allowInsecure
Skip TLS Certificate VerificationallowInsecureは、一部の設定でTLS証明書の検証をスキップするかどうかを指定するオプションです。有効にすると接続先の認証が弱まります。誤ったSNI、証明書チェーン、システム時刻の問題は解決せず、互換性のないプロトコルを使えるようにするものでもありません。証明書エラーが起きた場合は、まず原因を特定してください。通常の利用で検証のスキップを万能な解決策として使うべきではありません。
ネットワーク基礎
ドメイン名の解決、接続の確立、ローカルでの待ち受けはそれぞれ別の処理です。個別に確認しましょう。
DNS
Domain Name SystemDNSはドメイン名をIPアドレスなどのレコードに変換し、多くの場合、アプリが接続を確立する前に利用されます。OS、ブラウザー、プロキシコアがそれぞれ異なる名前解決経路を使う場合があります。そのため、Webページの通信がプロキシを経由していても、DNS問い合わせが同じ経路を通るとは限りません。まず誰がどこに問い合わせているかを確認し、次に名前解決の結果と接続後の出口を調べてください。
FakeDNS
Synthetic DNS MappingFakeDNSはドメイン名に合成IPアドレスを割り当て、その対応関係を保持します。プロキシコアが後続の接続を受け取る際にドメイン名を復元し、ルーティングや接続処理に利用できます。返されるアドレスは通常、実際のサーバーアドレスではないため、サーバーの場所を判断する用途には適しません。有効にする場合は、該当する通信が対応関係を識別できるコアに戻るようにする必要があります。そうしないと、名前解決に成功しても接続できないことがあります。
DNS漏れ
DNS LeakDNS漏れとは、ドメイン名の問い合わせが想定した名前解決経路を通らず、別のリゾルバーやネットワーク経路から送信される現象です。漏れの有無を判断するには、まず想定する経路を明確にしてください。テストページに表示されたリゾルバー名だけでは判断できません。システムDNS、ブラウザーのセキュアDNS、TUNによるDNS制御の設定も結果に影響します。実際の問い合わせ動作を確認しましょう。
ローカル待ち受けポート
Local Listening Portローカル待ち受けポートは、クライアントがローカルPCでアプリからの接続を受け付ける入口です。一般的な画面では10808などが表示されますが、実際の設定を確認してください。アプリ側のプロキシ方式、アドレス、ポートは対応する待ち受け設定と一致させる必要があります。HTTPとSOCKSの入口を混同しないでください。ポートを変更した場合は、システムプロキシや手動設定したアプリも更新します。ほかのプロセスがポートを使用中だと、コアが正常に起動しない場合があります。