プロトコルとトランスポート
プロトコルは通信方式、トランスポートはデータの運び方、セキュリティ機構は接続の保護を担います。名称が似ていても、これらの役割は相互に置き換えられません。
- VMessプロキシプロトコル · ユーザーID認証
- VMessはProject Vのエコシステムに属するプロキシプロトコルです。ユーザーIDで認証し、一般的な設定にはサーバーアドレス、ポート、トランスポート方式、セキュリティ設定も含まれます。クライアントとサーバーでこれらの値を一致させる必要があり、アドレスだけでは接続できません。認証には時刻も関係するため、端末の時刻が大きくずれている場合は、設定の不備を疑う前にシステム時刻を同期してください。
- VLESS軽量プロキシプロトコル · セキュリティ層と併用
- VLESSはプロトコル層の処理を簡素化しており、通信内容の暗号化機能はありません。通常はTLSやREALITYなどのセキュリティ機構と組み合わせます。インポート時はユーザーIDだけでなく、トランスポート方式、サーバー名、フロー制御などの元の設定も保持してください。VLESSとVMessは相互に置き換えられるものではなく、プロトコルの選択欄を書き換えても設定の変換にはなりません。
- Trojanプロキシプロトコル · パスワードとTLS
- Trojanは通常、TLS接続上でプロキシ通信を行い、パスワードで認証します。アドレスとパスワードに加え、サーバー名、証明書の検証、実際のトランスポート方式も接続結果に影響します。証明書エラーが発生した場合は、ドメイン名、端末時刻、サーバー設定を確認してください。証明書検証を無効にする方法を常用するのは避けましょう。
- REALITYトランスポート層のセキュリティ機構 · Xrayエコシステム
- REALITYはXrayエコシステムのトランスポート層のセキュリティ機構で、単独のプロキシプロトコルではありません。VLESSと組み合わせて使われることがよくあります。接続には公開鍵、サーバー名、ショートIDなどの設定を一致させる必要があり、利用できる項目はクライアントやコアのバージョンによって異なります。REALITYを使う場合は、プロトコル一覧にVLESSがあるかだけでなく、使用中のコアが設定に対応しているか確認してください。
コアとエコシステム
設定を行うのは画面、接続を実行するのはコアです。互換性の問題を調べるときは、ソフトウェア名だけでなく両方を確認しましょう。
- Project Vプロジェクト群 · モジュール型プロキシ通信
- Project Vは、モジュール型のプロキシ通信を中核とするプロジェクト群です。V2Rayはそのエコシステムを理解する出発点となります。日常的な会話で「V2Ray」は、コアそのものを指す場合も、対応するプロトコルやクライアント全般を指す場合もあります。解説を読む際は文脈を確認しましょう。ソフトウェアを選ぶ前に、プロトコル、実行コア、GUIクライアントを区別すると、それぞれの機能を混同せずに済みます。
- V2Flyコミュニティプロジェクト · V2Rayコアの保守
- V2FlyはV2Rayコアと関連コンポーネントを保守するコミュニティプロジェクトです。実際に利用できる接続機能は、使用するコアのバージョンによって異なります。Androidクライアントのv2flyNGは、この系統のコアを使う選択肢の一つですが、クライアント名とプロトコル名は別物です。設定を移行する際は、プロトコル、トランスポート、各項目への対応状況を確認してください。別のコアでもすべての設定がそのまま動くとは限りません。
- Xrayプロキシコア · 接続とルーティングを実行
- XrayはV2Rayと技術的なつながりを持ち、プロトコルネゴシエーション、接続処理、ルーティングなどを担います。一部の機能はそれぞれ独自に発展しています。v2rayNはコアの設定を管理でき、v2rayNGはよく使われるAndroid向けGUIクライアントです。コアが起動しない場合は、画面が表示されているだけで接続を判断せず、起動ログに記録された項目やファイルのエラーを確認してください。
- コアとクライアント実行層と設定画面の違い
- クライアントはサブスクリプション管理、サーバー選択、ログ確認などの画面を提供し、コアは生成された設定に基づいてバックグラウンドで通信を処理します。画面に設定項目が表示されていても、現在選択中のコアがその項目を認識できるとは限りません。クライアントの更新、コアの更新、サブスクリプションの更新はそれぞれ別の操作です。問題が起きたら、どの層を変更したのか記録しておきましょう。
サブスクリプションとノード
サブスクリプションは設定の取得に使い、ノードは接続先を表します。共有やバックアップの際は、機密情報と移行できる設定の範囲にも注意が必要です。
- サブスクリプションURL複数の接続設定を取得するURL
- サブスクリプションURLは、クライアントが複数の接続設定を取得するために使います。返される内容はクライアントが認識できる形式でなければなりません。URLに認証情報が含まれる場合があるため、公開スクリーンショットやログ、掲示板への投稿に載せないでください。インポートに失敗したら、まずURLへのアクセス失敗と形式の解析失敗を区別しましょう。サブスクリプション変換は形式を合わせる処理であり、元データにない接続設定を自動で補うものではありません。
- ノードサーバー項目 · 接続設定
- ノードは通常、クライアントの一覧にある接続設定の1件を指し、サーバーアドレス、ポート、プロトコル、認証情報、トランスポートやセキュリティの設定を含みます。一覧に表示される名前はメモにすぎず、実際のサーバー所在地や接続品質を示すものではありません。ノードを選ぶと現在の接続候補になりますが、実際に使われるかどうかは、プロキシモード、ルーティングルール、コアの動作状況にも左右されます。
- サブスクリプションの更新設定一覧を更新 · プログラムのアップグレードではない
- サブスクリプションの更新では、サブスクリプションURLに再度アクセスし、クライアントの処理方法に従って設定一覧を更新します。クライアントやコアのアップグレードとは異なります。配信元の内容が変わると、既存の項目が変更または削除される場合があります。サブスクリプションの項目を長期保存用に手動編集するのは避けましょう。更新後は選択中の項目が残っているか確認してから接続テストを行い、選択内容の変化をネットワーク障害と取り違えないようにしてください。
ルーティングと振り分け
ルールで条件を判定し、アウトバウンドで接続を実行します。まずルールの順序とデータの出所を確認し、最後にどのルールが適用されたかを調べましょう。
- ルーティングルール照合条件 → 出力先ラベル
- ルーティングルールは、ドメイン、IPアドレス、ポート、プロセスなどの条件に基づいて出力先を選びます。利用できる条件はコアやクライアントによって異なります。通常は上から順に照合し、一致したルールの出力先を使います。そのため、条件が広すぎるルールが後続の細かなルールに先に適用されることがあります。問題を調べる際は、まずルールの順序を確認し、リクエストに照合可能なドメイン情報が含まれているかを確認してください。最終的なフォールバック設定は最後に検討しましょう。
- GeoIPIPアドレスの集合 · 地域や用途別に分類
- GeoIPはIPアドレスを地域や用途別に整理したルーティング用の集合です。たとえば
geoip:privateはプライベートIPアドレスの照合によく使われます。判定結果はデータの提供元や更新バージョンに左右され、IPアドレスの実際の所在地を絶対的に証明するものではありません。IP条件を使う際は、ドメインがいつ名前解決されるか、現在のルーティング設定が照合のためにIPアドレスを参照するかも確認してください。
- GeoSiteドメイン分類の集合 · ルールデータに依存
- GeoSiteはドメインをカテゴリ別に整理します。ルールでは
geosite:cnなどの分類を参照でき、ドメインを一つずつ登録する必要はありません。カテゴリの有無や含まれる項目は、現在読み込まれているデータファイルによって決まります。ログにカテゴリが見つからないと表示された場合は、データファイルとカテゴリ名を確認してください。ルールの順序を変えるだけでは、存在しないカテゴリは使えるようになりません。
- ルーティングとアウトバウンドリクエストの振り分けと実際の接続設定
- ルーティングはリクエストを異なる処理経路に振り分けることで、アウトバウンドは接続を実行するための設定です。画面では
direct、proxy、blockを、それぞれ直接接続、プロキシ、ブロックのラベルとして使うことがよくあります。ただし、ラベル名だけでは動作せず、正しい設定に紐付ける必要があります。直接接続にも端末から接続先へ到達できることが必要です。directを選んでも、通常のネットワーク条件が不要になるわけではありません。
クライアント機能
プロキシモードはクライアントに取り込む通信の範囲を決めます。一方、接続テストが確認するのは特定のテスト先だけです。どちらも適用範囲を把握しておきましょう。
- システムプロキシOSにローカルプロキシのアドレスを登録
- システムプロキシはローカルプロキシのアドレスをOSに登録します。主にその設定に従うアプリに適用され、すべてのネットワーク接続を自動で引き受けるわけではありません。v2rayNの「システムプロキシを自動設定」と「システムプロキシを解除」は、システム設定を変更する機能であり、リモート接続のパラメーターを変えるものではありません。クライアント終了後も無効なプロキシアドレスが残っていると、ブラウザーが停止済みのローカルポートに接続しようとする場合があります。
- TUNモード仮想ネットワークインターフェース · より広範囲の通信を処理
- TUNモードは仮想ネットワークインターフェースを通じて通信を受け取り、システムプロキシに従わない一部のアプリの通信も処理できます。通常、管理者権限または適切なネットワーク権限が必要です。実際に処理される範囲は、システムルート、除外ルール、IPv6設定、実装方法によって決まり、スイッチがオンというだけで全通信が対象になるわけではありません。有効にする前に権限とDNS設定を確認し、ほかの仮想ネットワークアダプターとのルート競合にも注意しましょう。
- 遅延テストテスト方式が異なる結果は直接比較できない
- 遅延は、特定のテストにかかる時間です。TCP接続、HTTPリクエスト、その他の測定方式では、対象となる処理が異なります。TCPポートに接続できても、その接続段階に到達できたことを示すだけで、プロトコル認証や接続先へのアクセス成功を保証するものではありません。結果を比較するときは、同じ方式とテスト先を使ってください。遅延が短くても、継続的なダウンロード速度が速いとは限りません。
- 実接続遅延プロキシ設定を通じてリクエストを送信するテスト
- クライアントの実接続遅延テストでは通常、現在のプロキシ設定を使ってテスト先にリクエストを送信します。サーバーポートだけを調べるテストより多くの接続処理を確認できます。DNS、ハンドシェイク、リダイレクトを計測に含めるか、何を成功と判定するかは、クライアントの実装によって異なります。テストに失敗しても、テスト先自体やその宛先へのルーティングに原因がある可能性があり、すべてのアプリが接続できないことを単独で証明するものではありません。
ネットワークの基礎
ドメインの名前解決、アドレスのマッピング、ローカルポートはそれぞれ別の処理です。問題の発生箇所を特定してから設定を変更しましょう。
- DNSドメインの名前解決 · 接続前のアドレス検索
- DNSはドメイン名をIPアドレスなどのレコードに変換します。名前解決の結果は、その後の接続やIPアドレスに基づくルーティング判定に影響します。システム、ブラウザー、プロキシコアがそれぞれDNS設定を持つ場合があり、どれか一つを変更しても、すべてのクエリ経路が変わるとは限りません。ドメインにアクセスできない場合は、名前解決の成否、取得したアドレスへの到達性、リクエストに使われたアウトバウンドを個別に確認してください。
- FakeDNS仮想アドレスとドメインのマッピング
- FakeDNSは特定のアドレスプールから仮想アドレスを返し、仮想アドレスと元のドメインとの対応を保持します。これにより後続の処理でもドメイン情報を維持できます。仮想アドレスは接続先サーバーの実アドレスではないため、対応関係を認識できるコンポーネントが接続を引き継ぐ必要があります。モードの切り替え後にアプリが古いアドレスをキャッシュしていると、アクセスに失敗する場合があります。DNSキャッシュと通信を引き継ぐ範囲は、クライアントの実装に応じて確認してください。
- DNSリークDNSクエリが想定経路から外れる状態
- DNSリークとは通常、ドメインの検索が想定した経路を通らず、システムやアプリから別のDNSサービスに送られる状態を指します。異常かどうかは、想定している振り分け方によって異なります。直接接続するドメインがローカルDNSで解決されても、それだけで問題とは言えません。調査時は、ブラウザーのセキュアDNS、システムの名前解決、コアのDNS、TUN設定をあわせて確認してください。単一のチェックサイトで分かるのは状況の一部です。
- ローカル待ち受けポートアプリがクライアントに接続する端末側の入口
- ローカル待ち受けポートは、端末上でクライアントが接続を受け付ける入口です。リモートサーバーのポートとは異なります。一部のv2rayN設定では、SOCKS/HTTP共通の待ち受けポートとして
10808を使いますが、実際の値は現在の設定を確認してください。アプリ側で指定するプロトコルとポートは、クライアントの待ち受け設定に合わせる必要があります。ほかのプログラムがポートを使用中だと、コアの起動や待ち受けに失敗することがあります。まずログで競合箇所を特定しましょう。