設定用語インデックス

V2Ray用語集

サブスクリプション、プロトコル、コア、通信の振り分け、DNSの用語を解説します。設定場面から用語を調べ、クライアントの該当項目を確認できます。

各用語には個別のアンカーがあり、説明へのリンクをコピーできます。初めて設定する場合は、まずサブスクリプションの追加と接続方法をご覧ください。具体的な症状がある場合は、トラブル対処で順に確認できます。

01 / 接続設定

プロトコルとトランスポート

プロトコル、トランスポート方式、セキュリティ層はそれぞれ別の設定項目です。プロトコル名が分かっても、ほかのパラメーターを省略したり、任意に置き換えたりはできません。

VMess: プロトコルとトランスポートProject Vエコシステムのプロキシプロトコルで、ユーザーIDによる認証を行い、さまざまなトランスポート方式と組み合わせられます。認証処理の一部はシステム時刻に依存するため、端末の時計が大きくずれていると接続に失敗することがあります。インポート後は、元の設定にあるトランスポートとセキュリティ層のパラメーターを保持してください。VMessとWebSocketなどのトランスポート名を混同しないようにしましょう。

VLESS: プロトコルとトランスポート軽量なプロキシプロトコルです。一般的な設定では通信を暗号化しないため、通常はTLSやREALITYなどのセキュリティ層と組み合わせます。実際の接続には、トランスポート方式やフロー制御の設定が必要な場合もあり、アドレスとユーザーIDだけでは不十分です。インポートできても接続できない場合は、プロトコル名だけでなく、使用中のコアが設定一式に対応しているか確認してください。

Trojan: プロトコルとトランスポート通常はTLS接続上で動作し、パスワードで認証するプロキシプロトコルです。パスワードが正しくても、接続条件がすべて揃っているとは限りません。サーバー名、証明書の検証、トランスポート設定もサーバー側の内容に合わせる必要があります。証明書エラーが発生した場合は、端末の時刻とサーバー設定を確認してください。証明書の検証を無効にしたまま使い続けるのは避けましょう。

REALITY: プロトコルとトランスポートXrayエコシステムのトランスポートセキュリティ機能で、独立したノードプロトコルではありません。VLESSと組み合わせて使われることが多く、公開鍵、サーバー名、短いIDなどの項目が設定に含まれる場合があります。サーバーから指定されたパラメーターをすべてインポートしてください。セキュリティ層の名前をREALITYに変えただけでは、元の設定に対応する接続機能は追加されません。

02 / クライアントとコア

コアとクライアント

GUIは操作に使い、コアは接続処理を実行します。画面に項目が表示されていても、実行中のコアがその項目に対応しているとは限りません。

v2rayN: コアとクライアントWindows、macOS、Linux向けのデスクトップGUIクライアントです。サブスクリプション、接続設定、ルーティング、コアのプロセスを管理します。クライアントはGUIの設定をコアが実行できる形式にまとめます。実際に利用できるプロトコルは、選択したコアとそのバージョンによって異なります。問題を調べる際は、クライアントのバージョン、使用中のコア、具体的なエラーを記録してください。これらは別々の情報です。

v2rayNG: コアとクライアントAndroid向けのGUIクライアントで、Xrayコアを使ってプロキシ接続を処理し、通常はOSのVPNサービスを通じてアプリの通信を取り込みます。システムに接続中の表示が出ても、通信を取り込むサービスが起動したことを示すだけで、接続先ノードが利用可能とは限りません。初回利用時はOSの許可を確認してください。接続が切れる場合は、バックグラウンド動作の制限、アプリごとの振り分け、ネットワークの切り替えも確認しましょう。

Xray: コアとクライアントプロキシ接続、プロトコル処理、ルーティング、DNSなどを担うコアです。メニューを表示するGUIクライアントとは別の層にあたります。コアを切り替えると、対応プロトコル、設定項目、ログの内容が変わる場合があります。名称だけで選ばないようにしてください。クライアントを更新した後も、実際に起動するコアのバージョンと、既存の設定が引き続き対応しているか確認しましょう。

V2Fly: コアとクライアントProject Vの技術エコシステムを引き継ぐコミュニティプロジェクトで、V2Rayコアや関連コンポーネントを保守しています。プロジェクト名とクライアント名は同じではありません。v2flyNGはこのコアを使うAndroidクライアントの選択肢で、Xrayを採用したクライアントとは対応する設定が異なる場合があります。移行時はプロトコルとトランスポートの対応状況を項目ごとに確認し、すべての設定をそのまま使えると思い込まないでください。

03 / 設定の取得と接続テスト

サブスクリプションとノード

サブスクリプションは設定を取得するためのもの、ノードは個々の接続設定です。テスト結果は、特定の測定条件での状態を示します。

サブスクリプション: サブスクリプションとノード1つのURLから接続設定をまとめて取得するための更新窓口です。ノードそのものではなく、クライアントがサービスの利用権限を自動で得られるという意味でもありません。URLを追加して保存した後、通常は「サブスクリプションをすべて更新」を実行し、設定一覧を取得します。URLには認証情報が含まれる場合があるため、機密情報として管理してください。ログやスクリーンショットを共有する前に、URL全体を削除しましょう。

ノード: サブスクリプションとノードクライアントに登録する接続先の設定一式を指す一般的な呼び名です。通常はサーバーアドレス、ポート、プロトコル、認証、トランスポートの設定が含まれます。一覧に表示される名前はメモであり、実際の場所、利用可能かどうか、性能は名前だけでは判断できません。ノードを選ぶ操作は出口の設定を選択することです。アプリの通信がそのノードを通るかどうかは、通信の取り込み方とルーティングルールにも左右されます。

遅延: サブスクリプションとノード1回の測定にかかる時間です。測定方法に応じて判断してください。TCP接続テスト、HTTPリクエストテストなどでは測定対象が異なります。テスト先、現在のネットワーク、接続の再利用なども結果に影響します。遅延が小さくてもダウンロード速度が速いとは限りません。ノードを比較する際は、できるだけ同じ測定方法、テスト先、時間帯で測定してください。

実接続遅延: サブスクリプションとノードプロキシ経由で指定したテスト先にリクエストを送り、所要時間を測定した値です。単純なポート疎通確認より実際のアクセスに近い指標ですが、テストサイト、DNS、ルーティング、コアの測定方法にも左右されます。すべてのアプリに共通する評価ではありません。テストに失敗した場合は、テスト先にアクセスできるかも確認し、単一の接続先の障害をノード全体の問題と誤認しないようにしましょう。

04 / 通信の出口

ルーティングと通信の振り分け

まず通信をコアに取り込み、ルールで出口を決めます。ルールを変更する前に、対象のアドレス、照合条件、適用したい動作を明確にしてください。

ルーティングルール: ルーティングと通信の振り分けドメイン名、IPアドレス、ポート、プロトコルなどの条件に応じて、接続の出口をプロキシ、直接接続、ブロックなどから選ぶルールです。通常は上から順に照合されます。広い条件を先に置くと、後続のより具体的なルールが適用されない場合があります。どのルールにも一致しない通信の扱いは、個別のルールだけでなく、デフォルトの出口とクライアントが生成する設定を確認してください。

通信の振り分け: ルーティングと通信の振り分け通信の種類に応じて異なる出口を使い分ける方針です。ルーティングルールが代表的な実現方法で、たとえばLAN内のアドレスは直接接続し、特定のサービスはプロキシ経由にできます。振り分けで処理できるのは、すでに取り込まれた通信です。クライアントの接続窓口を使っていないアプリが自動的に対象になるわけではありません。確認する際は、直接接続させる宛先とプロキシを通す宛先をそれぞれテストしてください。

GeoIP: ルーティングと通信の振り分けルーティングの照合に使うIPアドレスの集合です。ラベルの具体的な意味と範囲は、ルールデータによって決まります。一般的なgeoip:privateは、プライベートアドレスなどインターネット上で公開されていない範囲を判定します。直接接続の出口と組み合わせると、LANへの接続に利用できます。GeoIPが判定するのはアドレスの集合であり、Webサイトの内容ではありません。ドメインルールの代わりにもなりません。

GeoSite: ルーティングと通信の振り分けサイトやカテゴリごとにまとめたドメイン名の集合です。ルーティングで関連ドメインをまとめて照合できるため、1件ずつ管理する手間を減らせます。利用できるラベルや収録内容は、実際に使うルールデータによって異なります。他の提供元のラベルをそのまま使っても有効とは限りません。ドメイン名で照合するにはコアがドメイン情報を取得する必要があるため、接続先IPアドレスしか分からない場合は、想定したルールに一致しないことがあります。

05 / ドメイン名の解決

DNSとネットワーク

接続先にアクセスする前に、ドメイン名の名前解決が必要になることがあります。OS、ブラウザー、プロキシコアで異なる経路を使う場合があるため、それぞれ確認してください。

DNS: DNSとネットワークアプリが接続先を見つけられるように、ドメイン名をIPアドレスなどに変換するシステムです。DNSリクエストはOS、ブラウザー、プロキシコアから送信される場合があるため、DNS設定を1か所変更してもすべてのアプリに反映されるとは限りません。接続先には到達できるのにドメイン名でアクセスできない場合は、ノードをすぐに変更せず、名前解決サービス、問い合わせ経路、キャッシュをそれぞれ確認してください。

リモートDNS: DNSとネットワーククライアント設定で特定の名前解決経路に使うDNSサーバーです。通常のアドレスや暗号化DNSのアドレスを指定する場合があります。「リモート」という名前でも、問い合わせが必ずプロキシを通るとは限りません。実際の出口は、コア、DNSルーティング、関連するオプションによって決まります。変更後はDNSサーバーに到達できるか、起動時の名前解決に依存する設定がないかも確認してください。

FakeDNS: DNSとネットワークアプリに仮想IPアドレスを返し、コア内で仮想IPとドメイン名の対応を管理する仕組みです。後続の接続でもドメイン情報を保持しやすくなります。DNSの制御、アドレスのマッピング、通信の取り込みを連携させる必要があり、一般的なパブリックDNSのアドレスとして設定するものではありません。有効・無効を切り替えた後もアプリが古いアドレスを使う場合は、キャッシュと接続状態を確認し、無効になった対応情報を使い続けないようにしてください。

DNSリーク: DNSとネットワークDNSリクエストが想定した名前解決方針どおりに送信されない状態です。たとえばプロキシ経由にするつもりでも、実際にはOSから別の経路で送信される場合があります。まず想定する経路を明確にし、ブラウザーのセキュアDNS、OSの名前解決、コアのDNS設定を確認してください。オンライン検査は状況を把握するための手がかりにすぎず、表示されたDNSサーバー名だけで全通信の経路を判断することはできません。

06 / 通信の取り込み

システムプロキシとTUN

プロキシの接続窓口は、アプリからクライアントへの接続方法を決めます。リモートノードは、クライアントからサーバーへの接続先を決めます。この2つのアドレスとポートを取り違えないでください。

システムプロキシ: システムプロキシとTUNOSがシステムプロキシ設定に従うアプリに提供する接続窓口で、すべてのプログラムを自動的に対象にするものではありません。「システムプロキシを自動設定」は該当する接続先を設定し、「システムプロキシを解除」は設定を削除します。「システムプロキシを変更しない」は現在の状態を維持します。ターミナルや独自のネットワーク設定を使うアプリには個別設定が必要な場合があるため、ブラウザーが使えてもほかのプログラムが接続できるとは限りません。

TUNモード: システムプロキシとTUN仮想ネットワークインターフェースを通じて通信をプロキシコアに取り込む方式です。通常、システムプロキシの設定に従わないアプリも対象にできます。デスクトップでは管理者権限が必要な場合があり、ルーティングとDNSの設定も必要です。有効にしただけですべての通信がリモートプロキシを通るとは限りません。ほかの仮想ネットワークソフトと併用する場合は、インターフェース、ルーティング、名前解決の競合を確認してください。

HTTPプロキシ: システムプロキシとTUNアプリがHTTPプロキシの接続窓口にリクエストを送信する方式です。HTTPS通信では通常、CONNECTを使ってトンネルを確立します。ローカルのプロキシ接続先アドレスとポートは、クライアントの設定で確認してください。サブスクリプションに記載されたリモートサーバーの情報ではありません。自分の端末だけで使う場合はループバックアドレスを優先してください。他の端末から接続できるようにする場合は、接続範囲とファイアウォールのルールを確認しましょう。

SOCKSプロキシ: システムプロキシとTUNアプリケーション層で広く使われるプロキシ接続窓口です。SOCKS5は接続先をドメイン名またはIPアドレスで指定でき、実装によってはUDPにも対応します。ドメイン名をプロキシ側で名前解決するかどうかは、アプリの実装と設定によって異なります。SOCKS接続を使っているだけでは、DNSの経路を判断できません。入力時はクライアントが実際に待ち受けているポートを確認し、HTTPプロキシのポートと取り違えないようにしてください。