プロトコルと暗号化
接続形式とセキュリティ層
プロトコルは認証情報とデータの構成方法を決め、TLSやREALITYなどのセキュリティ層が接続の各段階を保護します。ノードを読み込む際は、プロトコル名だけでなく転送方式とセキュリティパラメータの整合性も必要です。
- VMess プロトコル
- VMessはProject Vエコシステムのアプリケーション層プロトコルで、認証、時刻検証、データ転送の仕組みを備えています。クライアントには通常、ユーザー識別子、サーバーアドレス、ポート、追加識別子などを設定します。サーバーとローカルのシステム時刻に大きなずれがあると認証に失敗することがあるため、接続トラブルではシステム時計も確認してください。
- VLESS プロトコル
- VLESSは比較的シンプルな構造のプロキシプロトコルで、暗号化と転送時の安全性をTLSやREALITYなどの外側の仕組みに任せます。接続できるかどうかはVLESSという名称だけでなく、転送層、セキュリティ層、サーバー設定が一致しているかで決まります。主な項目にはユーザー識別子、フロー制御方式、サーバー名、公開鍵情報があります。
- Trojan プロトコル
- Trojanはパスワードを認証情報として使い、通常はTLSで接続を確立します。クライアントのアドレス、ポート、パスワード、サーバー名、転送方式はサーバー側と一致させる必要があります。証明書名の不一致やハンドシェイク失敗が起きた場合は、ノードを何度も切り替える前にサーバー名を確認してください。
- REALITY セキュリティ層
- REALITYはXrayエコシステムの転送セキュリティ方式で、VLESSと組み合わせて使われることが多い機能です。クライアント設定には通常、サーバー名、公開鍵、短い識別子、ブラウザーのフィンガープリントなどを含めます。重要項目が欠けていたり、コピーが不完全だったりするとハンドシェイクで停止することがあるため、コアのログで具体的なパラメータを確認します。
- TLS 転送セキュリティ
- TLSは暗号化接続の確立と通信相手の認証に使われる汎用的なセキュリティプロトコルです。クライアント設定では、サーバー名、証明書検証、アプリケーション層プロトコルのネゴシエーション、転送ポートなどに関係します。証明書エラーが出た場合は、システム時刻の異常、サーバー名の不一致、証明書チェーンの問題を切り分ける必要があります。
コアとエコシステム
クライアント、コア、プロジェクトの関係
GUIクライアントは画面、サブスクリプション、設定を管理し、コアはプロトコル処理、DNS、ルーティング、実際の接続を担当します。両者を分けて考えると、問題が画面設定、コアの起動、リモート接続のどの段階で起きたかを判断しやすくなります。
- Project V 技術エコシステム
- Project Vは、ネットワークプロキシプロトコル、ルーティング機能、関連ツールを中心に形成されたオープンソースの技術エコシステムです。V2Rayの設定思想、インバウンドとアウトバウンドのモデル、さまざまなクライアントツールがこの体系に関係します。特定のGUIの名称ではないため、文書を読む際はプロジェクトの概念、コア名、クライアント名を区別してください。
- V2Fly コアの派生版
- V2FlyはV2Rayの技術体系を受け継ぐ、コミュニティ運営のプロジェクトおよびコアの派生版です。プロトコル処理、インバウンド・アウトバウンド、DNS、ルーティングなどの基盤機能を提供し、GUIクライアントが設定を生成して起動できます。v2flyNGを使う場合、画面上の設定は最終的にコアが読み取れる設定へ変換されます。
- Xray プロキシコア
- XrayはV2Rayと近い設定思想を持つプロキシコアで、VLESSやREALITYなどに対応しています。v2rayNとv2rayNGは、適切な設定のもとでXrayを呼び出して実際の接続を処理できます。画面上ではノードが存在するのに接続できない場合は、コアが正常に起動しているか、ログに設定解析エラーやハンドシェイクエラーがないかを確認してください。
- v2rayN デスクトップクライアント
- v2rayNはWindows、macOS、Linux向けのデスクトップGUIクライアントです。サブスクリプション、ノード、システムプロキシ、TUNモード、ルーティングルール、コアプロセスを管理できます。デスクトップ版とWindowsの従来型WPF版では画面実装が異なりますが、設定を読み込み、ノードを選択し、コアを起動して通信の取り込み方式を設定する基本的な流れは共通です。
- v2rayNG Androidクライアント
- v2rayNGはAndroid向けのGUIクライアントで、通常はXrayコアで接続を処理します。システムが提供するVPNサービスを通じてアプリの通信を取り込み、サブスクリプション管理、ノード切り替え、ルーティング設定にも対応します。初回接続時にシステムが表示するネットワーク接続の許可を与えないと、画面上の操作だけでは有効な通信経路が確立されません。
クライアント機能
通信の取り込みと接続テスト
システムプロキシとTUNモードは、対象範囲の異なる通信取り込み機能です。FakeDNS、LAN共有、遅延テストは特定の用途を補助します。機能を多く有効にするほど、ポート、権限、ルートの間に競合がないか確認することが重要です。
- システムプロキシ 取り込みモード
- システムプロキシは、クライアントがOSのプロキシ設定を変更し、システム設定に従うアプリの通信をローカルプロキシポートへ送る機能です。ブラウザーは通常この設定を読み取りますが、ターミナルプログラム、独立したネットワークツール、独自のネットワークスタックを実装するアプリは自動的に従わないことがあります。ブラウザーは使えるのにターミナルが使えない場合は、システムプロキシとターミナルの環境変数を分けて確認してください。
- TUNモード 仮想ネットワークインターフェース
- TUNモードは仮想ネットワークインターフェースを通じて、より多くのアプリの通信を取り込みます。対象範囲は通常システムプロキシより広く、適切なネットワーク権限が必要です。また、システムのルーティングテーブルにルールを追加します。他の仮想ネットワークツールも動作していると、ルート競合、DNS経路の変化、接続の切り替わりが起きる可能性があるため、通信の取り込み口は1つに整理してください。
- FakeDNS DNSマッピング
- FakeDNSはアプリにマッピングアドレスを返し、クライアント内部にそのアドレスと元のドメインの対応関係を保存します。TUN環境でよく使われ、通信がコアへ入った後も対象IPだけでなくドメインルールで判定できるようにします。有効化する際は、FakeDNSのアドレス範囲が既存のLANセグメントと競合しないこと、関連するDNSリクエストが想定した処理経路を通ることを確認してください。
- 実接続遅延 接続テスト
- 実接続遅延は実際にプロトコル接続を確立してノードの応答時間を測定するため、サーバーの到達性だけを調べるテストより実際の動作に近い結果が得られます。ただし、特定の時点、対象、測定方法における結果にすぎません。遅延が低くてもスループットが高いとは限らないため、ノード選択では継続的な接続状態と実際の利用環境も確認してください。
サブスクリプションとノード
設定の取得元とノード管理
サブスクリプションはノード設定の取得元で、ノードはクライアントが実際に選択して接続する個別の記録です。更新、グループ化、遅延テストは管理操作であり、設定の完全性や接続ログの確認に代わるものではありません。
- サブスクリプション 設定集合
- サブスクリプションは、サーバーから提供される複数のノード設定を含むURLまたはデータ集合です。クライアントにURLを保存すると、必要に応じて取得してノードを解析できます。URLは完全な形でコピーしてください。サブスクリプション内のノードをローカルで変更しても次回更新時に上書きされることがあるため、継続的な調整はクライアントのルーティングやグループ設定で行うのが適しています。
- ノード 接続設定
- ノードはクライアントで選択できる1件のサーバー接続設定です。通常、アドレス、ポート、プロトコル、認証情報、転送層、セキュリティ層などで構成されます。ノード名は識別用のラベルにすぎず、名前を変更しても通常は接続パラメータに影響しません。ただし、ユーザー識別子、公開鍵、サーバー名などが欠けると接続に直接影響します。
- 遅延 応答時間
- 遅延はクライアントがプローブを開始してから応答を受け取るまでの時間で、通常はミリ秒で表示します。機能によってTCP接続、プロトコルハンドシェイク、指定先へのアクセスなど測定方法が異なるため、結果を単純に比較することはできません。遅延は応答速度を示すだけで、利用可能な帯域幅、継続的なスループット、長時間の安定性を単独で表すものではありません。
- サブスクリプショングループ 提供元管理
- サブスクリプショングループは、サブスクリプションの提供元ごとにノードを分類するクライアントの管理方式です。提供元ごとの更新、絞り込み、有効化、整理がしやすくなり、複数の提供元が混在した際の識別負担も減らせます。グループを削除する前に対象範囲を確認してください。クライアントによっては、そのグループに取り込んだノード記録も同時に削除されます。
- サブスクリプション更新 同期処理
- サブスクリプション更新は、クライアントがURLへ再度リクエストし、ノード一覧を同期する処理です。失敗した場合は、URLが完全か、現在のネットワークからアクセスできるか、システム時刻が正確か、ログにどのようなリクエスト状態が記録されているかを順に確認します。更新が成功しても一覧が変わらない場合は、内容自体に変更がないか、現在のグループ絞り込みで一部のノードが非表示になっている可能性があります。
ルーティングと振り分け
判定条件と通信の出口
ルーティングモジュールはドメイン、IP、ポート、プロセスなどの情報を読み取り、ルールの順番に従って出口を選択します。DNS解決がどの層で行われるかによって、ドメインルールとIPルールが想定した入力を取得できるかどうかが直接変わります。
- ルーティングルール 判定条件
- ルーティングルールは、ドメイン、IP、ポート、プロトコル、プロセスなどの条件に基づいて通信の出口を決めます。通常は順番に判定され、マッチすると後続の同種条件は評価されません。そのため、具体的なルールと広範なルールの位置を適切に設定する必要があります。ルールが機能しない場合は、まずクライアントで有効なルーティング設定を確認し、対象が想定どおりドメインまたはIPとしてコアに渡っているかを確認してください。
- ルーティング振り分け 出口の選択
- ルーティング振り分けは、異なる対象やアプリの通信をプロキシ、直接接続、ブロックなどの出口へ割り当てる処理です。単一のスイッチではなく、ルーティングルール、DNS解決、インバウンド情報、デフォルト出口が組み合わさった結果です。ルールを変更しても既存の長時間接続は以前の経路を使い続けることがあるため、確認時は対象アプリまたはクライアントの接続を再起動してください。
- GeoIP IPルールセット
- GeoIPはIPアドレスの地域やカテゴリに基づいて判定するデータ集合です。対象がIPへ解決済みであるか、ルーティングモジュールが対象IPを直接取得した場合にのみ利用されます。GeoIPデータには有効期限があり、アドレスの所属が変わると古いデータが想定外の分類を返すことがあります。クライアントを更新する際は、ルールデータのバージョンも確認してください。
- GeoSite ドメインルールセット
- GeoSiteはドメインのカテゴリ別に整理されたルールデータ集合で、ルーティングモジュールが対象ドメインを判定するために使います。判定対象はGeoIPと異なり、こちらはドメイン、GeoIPはIPアドレスです。リクエストがIPだけの状態でコアに入るとGeoSiteルールがマッチしないことがあるため、DNSポリシー、スニッフィング設定、TUNによる通信処理を確認してください。
- DNSリーク 解決経路の逸脱
- DNSリークとは、アプリのドメイン問い合わせが想定したDNS経路を通らず、システムや別のリゾルバーによって直接処理される状態です。切り分けでは、クライアントDNS、システムDNS、ブラウザーのセキュアDNS、TUNルーティング、アプリ独自の解決ポリシーを同時に確認します。DNSアドレスを1つ変更するだけでは、すべてのアプリの問い合わせ経路が変わるとは限りません。誰が問い合わせを開始し、誰が取り込み、最終的にどこへ送っているかを明確にしてから検証してください。
- 直接接続 アウトバウンド方式
- 直接接続は、通信がプロキシノードを経由せず、現在のネットワーク接続から対象へ直接アクセスする方式です。ルーティングルールで明示的に指定されるほか、未マッチ通信のデフォルト出口になる場合もあります。直接接続に失敗しても、必ずしもプロキシノードが原因とは限りません。ローカルネットワーク、DNS解決、対象アドレス、ファイアウォール設定を分けて確認してください。