プロトコルと伝送方式
プロトコル、伝送方式、安全層はそれぞれ別の設定項目です。接続設定では通常、この3つを決める必要があり、プロトコル名だけからほかのパラメーターを判断することはできません。
- プロトコルと伝送方式VMess
- Project Vエコシステムで使われるプロキシプロトコルで、ユーザーIDなどのパラメーターを使って認証します。VMessは特定の伝送方式を指すものではなく、複数の伝送方式やセキュリティ設定と組み合わせられます。インポート後は、サーバーアドレス、ポート、ユーザーID、伝送パラメーターを確認してください。システム時刻が大きくずれていると認証に失敗することもあります。
- プロトコルと伝送方式VLESS
- 軽量なプロキシプロトコルで、プロトコル自体に通信内容を暗号化する機能はありません。通常はTLSやREALITYなどのセキュリティ機構と組み合わせます。ユーザーID、伝送方式、フロー制御のパラメーターをサーバー側と一致させてください。VLESSに対応していても設定が使えるとは限らず、選択したコアがその組み合わせをサポートしているか確認が必要です。
- プロトコルと伝送方式Trojan
- 通常はTLSを使い、パスワードで認証するプロキシプロトコルです。サーバーとポートのほか、パスワード、サーバー名、証明書の検証設定も必要です。接続できない場合は、認証情報と安全層を分けて確認し、すべてのエラーをパスワードの誤りと決めつけないでください。
- プロトコルと伝送方式TLS
- 通信を暗号化し、接続先を認証するセキュリティプロトコルで、HTTPSの基盤技術の一つでもあります。サーバー名、証明書チェーン、システム時刻は検証結果に影響します。証明書エラーが発生した場合は、まずサーバー名と時刻を確認してください。「証明書の検証をスキップ」を恒久的な対処として使うのは避けましょう。
- プロトコルと伝送方式REALITY
- Xrayエコシステムの伝送セキュリティ機構で、独立したノードプロトコルではありません。一般的な設定ではサーバー名、公開鍵、shortIdを確認します。どれか一つが欠けてもハンドシェイクに失敗することがあります。対応状況はコアやバージョンによって異なるため、クライアントに同名の項目があるだけで互換性を判断しないでください。
- プロトコルと伝送方式WebSocket
- プロキシプロトコルのデータを運べる双方向通信方式で、VMessやVLESSそのものではありません。設定時は通常、パス、Host、TLSの有効・無効を確認します。パスは大文字と小文字を区別するのが一般的で、コピー時に先頭のスラッシュが抜けても接続先が変わることがあります。
コアとエコシステム
「設定画面に項目がある」ことと「コアが使える」ことは別です。プロトコルの対応状況を確認するときは、現在の設定で実際に呼び出されているコアを確認してください。
- コアとエコシステムProject V
- モジュール型のネットワークプロキシツールを中心とするプロジェクト群で、V2Rayはその中でも広く知られたプロジェクトです。日常会話では「V2Ray」がエコシステム全体を指すこともありますが、実際の設定は使用するコアとクライアントに合わせる必要があります。手順が異なるプロジェクト間で混同しないよう、ガイドに記載されたソフトウェア名を確認してください。
- コアとエコシステムV2Fly
- V2Rayを中心にコミュニティで開発・保守されているプロジェクトで、コアの実装や関連ドキュメントを提供します。v2flyNGは、このコアファミリーを利用するAndroid向けGUIクライアントです。設定を選ぶ際は現在のコアの対応機能を確認し、ほかのコア固有のパラメーターもそのまま使えるとは考えないでください。
- コアとエコシステムXray
- V2Rayから派生したオープンソースのプロキシコアプロジェクトです。プロトコル実装や機能は独自の方針で発展しています。v2rayNGはXrayコアを使用し、v2rayNも対応するコア設定を管理できます。新機能が使えない場合は、クライアントと実際に使われているコアの両方のバージョンを確認してください。
- コアとエコシステムコアとクライアント
- コアはプロトコル処理、接続、DNS、ルーティングを担い、クライアントは設定のインポートやサブスクリプション管理、GUIを提供します。クライアントを更新しても、独立したコアのコンポーネントがすべて更新されるとは限りません。ソフトウェアを選ぶときは、まず3つのクライアントを比較し、目的の設定に必要なコアを確認してください。
サブスクリプションとノード
まず、受け取ったものが「更新可能なURL」なのか「単独の接続設定」なのかを確認しましょう。種類に応じてサブスクリプションの追加またはクリップボードからのインポートを選べば、操作を間違えずに済みます。
- サブスクリプションとノードサブスクリプションURL
- 複数の接続設定を取得するためのURLで、更新すると内容を再取得して解析します。たとえば、解説用の
https://example.com/your-subのようなHTTPS形式が一般的ですが、URLの形式だけで取得データとの互換性は判断できません。実際のURLには認証情報が含まれる場合があるため、スクリーンショットの共有や問い合わせ、ログの公開前にURL全体を隠してください。
- サブスクリプションとノードノード
- クライアントで選択できる接続設定を指す一般的な呼び方です。通常、サーバーアドレス、ポート、プロトコル、認証情報が含まれます。ノード名は単なるメモであり、実際の設置場所、利用可否、接続品質を保証しません。同じ名前の項目がある場合は、表示名だけでなく、所属するサブスクリプショングループと設定内容で見分けてください。
- サブスクリプションとノード実接続の遅延
- 選択した設定で接続し、テスト対象にアクセスするまでの時間です。測定方法はクライアントによって異なります。DNSによる名前解決、ハンドシェイク、接続先の応答、ネットワーク状況に左右され、ダウンロード速度とは異なります。1回タイムアウトしただけで設定が無効とは限らないため、まずテスト対象とプロキシ設定を確認してください。
ルーティングと振り分け
通信を取り込む設定でクライアントに入る接続が決まり、ルーティング設定で取り込んだ接続の処理先が決まります。振り分けルール、ルールデータ、アウトバウンドタグをあわせて確認してください。
- ルーティングと振り分けルーティングルール
- ドメイン、接続先IP、ポート、インバウンドなどの条件で接続を判定し、指定したアウトバウンドに振り分ける設定です。ルールは通常、上から順に判定されます。範囲の広いルールが先にあると、後続の詳細な条件が適用されない場合があります。変更時は対象を明確にし、指定したアウトバウンドタグの存在と、どのルールにも一致しない通信の処理方法を確認してください。
- ルーティングと振り分けルーティングによる振り分け
- ルールに応じて接続ごとに異なる経路で処理する仕組みです。たとえば、LAN内の接続は直接接続にし、別の接続先にはプロキシを使います。システムプロキシやTUNは通信を取り込む入口を担い、振り分けは通信がコアに入った後に行われます。アプリの通信がクライアントに入っていない場合、ルーティングルールを変えるだけでは解決できません。
- ルーティングと振り分けGeoIP
- IPアドレスの集合を使って接続先を判定するルールデータで、地域や特定用途のアドレス範囲を表すためによく使われます。対象は現在のデータファイルと参照する項目に依存し、接続先のIPアドレスが項目のアドレス範囲に含まれるかどうかを判定します。ドメインが事前に名前解決されるかどうかも、IPルールの判定に影響します。
- ルーティングと振り分けGeoSite
- ドメインの集合を使って接続先を判定するルールデータです。
geosite:cnはよく使われる指定方法です。含まれるドメインやカテゴリは、名前だけで決まるのではなく、ローカルで使用するルールデータによって異なります。存在しない集合を指定すると設定の読み込みに失敗する場合があるため、ルールを更新する前に配布元と互換性を確認してください。
- ルーティングと振り分けアウトバウンドとoutboundTag
- アウトバウンドは、コアから接続を送出するときの処理方法を表します。たとえば直接接続、プロキシ、ブロックなどです。ルーティング内の
outboundTagは、定義済みのアウトバウンドタグを指定します。directという名前のタグも、直接接続のアウトバウンドに紐づいて初めて直接接続を意味します。ルールをコピーするときは、マッチ条件だけでなくタグも確認してください。
- ルーティングと振り分けDNSリーク
- ドメインの問い合わせが想定した経路で名前解決されず、別のリゾルバーやネットワーク経路で処理される現象です。アプリ独自の暗号化DNS、システムDNS、コアのDNSが併用される場合があるため、順に確認してください。原因を判断する前に、どのDNSで名前解決し、どのアウトバウンドを通す想定なのかを明確にしましょう。リゾルバー名だけでは判断できません。
クライアントとシステム設定
必要な通信の取り込み方式で接続できる状態にしてから、DNS、仮想ネットワークインターフェース、LANアクセスを順に調整してください。一度に変更する項目を一つに絞ると、問題を特定しやすくなります。
- クライアントとシステム設定システムプロキシ
- OSにローカルプロキシのアドレスとポートを登録し、システム設定に従うアプリでプロキシを使えるようにします。すべてのアプリがこの設定を読み取るわけではないため、有効にしてもアプリによっては直接接続されます。これは通信を取り込む入口の設定であり、コアに入った後の直接接続またはプロキシの選択はルーティングルールで決まります。
- クライアントとシステム設定TUNモード
- 仮想ネットワークインターフェースで対象の通信を受け取り、コアに処理させるモードです。通常はシステム権限、ルーティング、DNSの設定が必要で、ほかの仮想NICと同時に使うと競合することがあります。有効にするかどうかは、対象アプリがどの方法でプロキシに対応しているかに応じて判断してください。設定を増やせばよいとは限りません。
- クライアントとシステム設定FakeDNS
- ドメインに内部処理用の合成アドレスを返し、ドメインとアドレスの対応関係を保存する仕組みです。後続の接続を元のドメインに紐づけやすくします。対応する名前解決と通信の取り込みが必要なため、全体の構成から切り離して有効にするのは避けてください。設定を無効化または切り替えた後も古いDNSキャッシュが残る場合があるため、クライアントの案内に従って対処してください。
- クライアントとシステム設定ローカル待ち受けポート
- クライアントがローカルでHTTPやSOCKSなどのプロキシ接続を受け付けるためのポートです。リモートサーバーのポートとは異なります。アプリにプロキシを手動設定する場合は、実際の待ち受けアドレス、ポート、プロトコルを指定してください。同じアドレスとポートを別のプログラムが使用していると、コアが待ち受け口を起動できない場合があります。
- クライアントとシステム設定LANからの接続を許可
- LAN内のほかのデバイスから、ローカルのプロキシ待ち受け口に接続できるようにする設定です。有効にしても、すべてのデバイスが自動的にプロキシを使うわけではありません。接続可能かどうかは、待ち受けアドレス、ファイアウォール、ネットワーク分離の設定にも左右されます。ローカルだけで使う場合は通常、有効にする必要はありません。共有する場合は、アクセス範囲を制限し、信頼できるネットワークであることを確認してください。