設定用語インデックス

V2Ray用語集

プロトコル、コア、クライアント設定を、設定の階層ごとに確認できます。

見慣れない項目があれば、まずどの層に属するかを確認しましょう。プロトコルは通信相手とのやり取りを定め、トランスポート方式は通信の運び方を決めます。コアは接続処理を実行し、クライアントは設定を管理します。名前が似ていても、項目を置き換えられるとは限りません。このページで用語の違いを確認したら、具体的な手順は応用設定をご覧ください。

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

認証、通信の運び方、接続の安全性を分けて考えましょう。同じプロトコルでも、トランスポートの設定は異なる場合があります。

VMessプロキシプロトコル · ユーザーID認証: VMessはProject Vエコシステムのプロキシプロトコルで、ユーザーIDによる認証と独自のセキュリティ機構を備えています。現在の設定では通常AEADが使われるため、古い解説にある一部のパラメーターはそのまま使わないでください。インポート時はユーザーIDに加えて、ポート、トランスポート方式、TLS設定も確認しましょう。プロトコルを選んだだけでは接続設定は完了しません。

VLESSプロキシプロトコル · UUID: VLESSはUUIDでユーザーを識別します。プロトコル自体はペイロードを暗号化しないため、TLSやREALITYなどと組み合わせて接続の安全性を確保します。VMessの別名ではなく、両者の設定項目をそのまま置き換えることはできません。利用時はトランスポート方式やflowパラメーターにコアが対応しているかも確認してください。プロトコルの選択だけをVLESSに変えても接続できるとは限りません。

Trojanプロキシプロトコル · パスワード認証: Trojanは通常、TLSで接続を保護し、パスワードで認証するプロトコルです。同名のマルウェアとは別の意味です。パスワードが正しくても証明書の検証に失敗することがあり、サーバー名やシステム時刻もハンドシェイクに影響します。クライアントのアドレス、TLSサーバー名、トランスポート設定を個別に確認し、設定ミスを隠すために検証を無効にするのは避けてください。

REALITY接続セキュリティ機構 · Xrayエコシステム: REALITYはXrayエコシステムの接続セキュリティ機構で、通常はVLESSなどと組み合わせて使います。独立したノードプロトコルではありません。設定には公開鍵、サーバー名、shortIdなどが必要で、具体的な項目はコアやクライアントのバージョンによって異なります。アドレスとUUIDだけのコピーでは不十分なことが多いため、ノードの全設定を読み込み、選択したコアが各項目を解釈できるか確認してください。

WebSocketトランスポート方式 · WS: WebSocketは双方向通信方式の1つで、プロキシ通信を運ぶ層として使えます。VMessやVLESSなどのプロキシプロトコルとは別の層です。パスとHostはサーバー側の要件に合わせ、TLSサーバー名は別に設定します。パスの大文字・小文字や先頭のスラッシュ、Hostが一致しないと、トランスポート段階で接続に失敗することがあります。

コアとエコシステム

クライアントの画面は管理を、コアは処理を担います。クライアントを選ぶ際は、プロトコル対応と設定項目も確認しましょう。

Project Vオープンソースプロジェクト群: Project Vは、V2Rayや関連ネットワークツールを中心とするオープンソースプロジェクト群で、特定のデスクトップクライアントを指す名称ではありません。通信処理を行うコアのほか、設定管理を支援するGUIプログラムも含まれます。「V2Ray対応」と記載されていても、対応プロトコル、使用するコア、ノードに必要なパラメーターを設定できるかを確認してください。

V2FlyV2Rayコミュニティの開発プロジェクト: V2FlyはV2Rayコアと関連エコシステムを維持するコミュニティプロジェクトで、対応するコアの系統を指すこともあります。Xrayとは共通の背景がありますが、対応プロトコル、設定構造、バージョンの進化は同一とは限りません。設定を移行する前に項目の意味を確認しましょう。クライアントでリンクを読み込めても、必要な接続機能がすべてそろっているとは限りません。

Xray独立系コアプロジェクト: XrayはV2Rayエコシステムから派生した独立系コアプロジェクトで、プロトコル、トランスポート、設定が独自に進化しています。REALITYなどの機能が使えるかどうかは、コアのバージョンと、クライアントが必要な設定を生成できるかによります。コアの名称だけで速度は判断できません。ノードの技術要件を確認したうえで、クライアントの設定方法やメンテナンス状況も考慮して選びましょう。

コアCore · 設定を実行するプログラム: コアはプロトコル処理、ルーティング判定、DNS処理、ネットワーク接続を担います。通常、GUIはユーザーの設定をコアの設定形式に変換します。クライアント画面が開いても、コアが正常に起動したとは限りません。設定項目の誤りやポートの競合で起動できないことがあります。調査時はクライアントのログとコアの出力を分けて確認し、コアの対応状況で機能の範囲を確認してください。

GUIクライアントv2rayN / v2rayNG / v2flyNG: GUIクライアントはノード一覧、サブスクリプションの更新、設定生成、実行状態の管理を行い、コア設定を直接編集する手間を減らします。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けです。対応するコアや機能は個別に確認してください。クライアント名、コア名、プロキシプロトコルは別の概念です。画面の見た目だけでノードとの互換性を判断することはできません。

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

サブスクリプションは設定の取得元を管理し、ノードは接続パラメーターを保持します。更新、変換、絞り込みはそれぞれ役割が異なります。

サブスクリプションSubscription · 設定の配布URL: サブスクリプションは通常、ノード一覧を取得するためのURLです。クライアントが取得した内容を解析し、接続設定として保存します。更新で反映されるのは主にノードとそのパラメーターで、ローカルのルーティングやDNS設定まで同期されるわけではありません。URLにはアクセス用の認証情報が含まれる場合があるため、機密情報として扱いましょう。公開の場で問題を相談するときはURL全体を貼らず、まずサブスクリプションのインポート手順を確認してください。

ノードNode · サーバー接続設定: ノードはクライアントに保存されるサーバー接続設定で、通常はアドレス、ポート、認証情報、プロトコル、トランスポートの設定を含みます。ノード名は識別用の表示であり、サーバーの実際の所在地や回線の特性と一致するとは限りません。インポートできても接続できるとは限らないため、設定の不足がないか、サービスが利用できるかを確認し、実際のリクエストで接続状態を確かめましょう。

サブスクリプショングループクライアントの管理単位: サブスクリプショングループを使うと、取得元や用途別にノードを整理し、グループごとに更新、絞り込み、一覧の管理ができます。グループ名はクライアント上の管理情報で、コアのアウトバウンドtagとは異なり、ルーティングに直接使われるとも限りません。グループの削除、ノードの削除、更新の無効化は別の操作である場合があります。実行前にクライアントの確認画面を読み、一覧の整理とサーバー設定の変更を混同しないようにしましょう。

サブスクリプション変換Subscription conversion: サブスクリプション変換は、設定データを別のクライアントが読み込める形式に整える仕組みです。サーバー側にないパラメーターを補うものではありません。特殊なトランスポート項目が欠落したり、グループやルーティングの表現が変わったりすることがあるため、変換後も設定を確認してください。変換サービスにサブスクリプションURLやノードの認証情報が渡る場合があります。クライアント標準の形式を優先し、データの処理先を確認しましょう。

通信量倍率利用枠の換算係数: 通信量倍率は、サブスクリプションサービスがノードごとに設定する課金や利用枠の換算ルールで、クライアントやコアの性能指標ではありません。たとえば2倍の倍率では、実際に1単位の通信量を使うと利用枠が2単位分減るのが一般的ですが、詳しくはサービスの説明を確認してください。倍率が高くても速いとは限らず、低くても遅いとは限りません。安定性、用途、残りの利用枠とあわせて判断しましょう。

ルーティング

ルールが通信の経路を決め、分類データが照合条件を提供します。まずルールの順序を確認し、次にアウトバウンドの識別子を確認しましょう。

ルーティングルールrouting.rules: ルーティングルールはドメイン、IPアドレス、ポートなどの条件で通信を判定し、対応するアウトバウンドを選択します。通常は上から順に判定され、先に一致したルールによって、後続のルールが同じ接続を処理できるかどうかが変わります。具体的なルールを広い範囲のルールより前に置き、参照先のアウトバウンドが存在することを確認してください。複数条件の組み合わせ方は、使用するコアの設定構文に従って判断します。

ルーティング条件に応じたアウトバウンドの選択: ルーティングは通信の種類に応じて異なるアウトバウンドを使う設定方法です。たとえば、一部のリクエストは直接接続し、一部はプロキシ経由にし、別の通信はブロックできます。ルール、分類データ、通信の入口が必要で、モード切り替えボタンを押すだけではありません。DNSの結果や、コアがドメインを取得できるかどうかも照合に影響します。動作を確認するときは、ページが開くかだけでなく、実際に適用されたルールとアウトバウンドを確認しましょう。

GeoIPIPアドレスの集合 · geoip:private: 設定でGeoIPという場合、地域や用途ごとに分類されたIPアドレスの集合を指すことがよくあります。ルールでは、その分類を指定してアドレスを照合できます。たとえばgeoip:privateは通常、プライベートIPアドレスの範囲に使われますが、分類名が使えるかどうかは読み込まれたデータによります。実際の回線所在地をリアルタイムに測定するものではありません。データが古い場合やドメインの解析結果が変わった場合は、照合結果にも影響します。

GeoSiteドメインの集合 · geosite:cn: GeoSiteは、サービスや用途ごとにまとめられたドメインの集合を参照し、大量のドメインルールを個別に管理する手間を減らすために使われます。分類名と対象範囲はデータファイルによって決まり、同じ名称でもデータの提供元によって内容が異なる場合があります。コアが接続先のIPアドレスしか受け取らず、ドメイン情報がない場合、ドメイン集合で照合できないことがあります。DNS、スニッフィング、通信の入口をあわせて確認してください。

アウトバウンドOutbound · outboundTag: アウトバウンドはコアが外向きの通信を処理する単位で、プロキシ接続、直接接続、ブロックなどを担います。ルーティングでは通常、tagを使ってアウトバウンドを指定します。directやblockはよく使われる名前ですが、実際の設定に定義されている必要があります。クライアントのノード名がアウトバウンドtagと同じとは限りません。ルールを追加する前に、生成された設定にある識別子を確認してください。

DNSとネットワークスタック

名前解決の経路と実際の通信経路は別のものです。通信の取り込み、暗号化された問い合わせ、ドメインのマッピングを混同しないようにしましょう。

DNSDomain Name System: DNSはドメインをIPアドレスなどのレコードに変換します。クライアント内蔵のリゾルバーとシステムのリゾルバーが、別々の問い合わせを処理することがあります。実際の通信がプロキシ経由でも、その前のDNS問い合わせまでプロキシ経由とは限りません。設定時は、どのプロセスが問い合わせを開始し、どのリゾルバーに渡し、どのアウトバウンドを通るのかを個別に確認してください。名前解決とルーティングの連携はDNS設定ガイドを参照してください。

DNS over HTTPSDoH · HTTPS経由のDNS問い合わせ: DoHはDNS問い合わせをHTTPS接続で送信し、クライアントからリゾルバーまでの問い合わせ内容を保護する方式です。問い合わせが暗号化されても、自動的にプロキシ経由になるわけではなく、解析結果が現在の回線に適しているとも限りません。リゾルバーの接続先がドメイン名の場合は、その初回の名前解決方法も考慮が必要です。調査時は接続経路と初回の名前解決を確認し、アドレスがHTTPSで始まるかだけで判断しないでください。

FakeDNS合成IPアドレスとドメインのマッピング: FakeDNSはドメインに合成IPアドレスを返し、ローカルに対応関係を保持します。後続の接続でドメインを復元し、ルーティング判定に使えるようにします。実際のパブリックIPアドレスを返す一般的なDNSサービスではなく、通信の取り込みとマッピングの復元を組み合わせて使う必要があります。合成アドレスが取り込み範囲外に出たり、アプリに古いマッピングが残ったりすると、接続に失敗することがあります。有効化・無効化した後は、キャッシュとルーティングの整合性も確認しましょう。

DNSリーク想定した名前解決経路からの逸脱: DNSリークとは、問い合わせが想定外のリゾルバーに届いたり、意図しない経路を通ったりする現象です。まず、どの問い合わせをプロキシ経由にする想定なのかを明確にしましょう。システム、ブラウザー、アプリがそれぞれ独自に名前解決する場合があるため、クライアントのDNS設定だけではすべてを制御できないことがあります。テスト結果はログや設定とあわせて解釈してください。意図的に直接接続で名前解決する設定は、プロキシを通らないだけで異常とは限りません。

TUNモード仮想ネットワークインターフェース · IP通信の取り込み: TUNモードは仮想ネットワークインターフェースを使ってIP通信をクライアントのネットワークスタックに渡します。システムプロキシの変更だけの場合より広い範囲を扱えます。有効化には通常、管理者権限、システムルート、DNSの取り込みが関係し、ほかのネットワークツールの仮想インターフェースと競合することもあります。TUNを有効にしても、すべての通信が必ずプロキシを通るわけではありません。最終的な経路はルーティングルールで決まります。開始前にTUNモードの設定を確認してください。

クライアント設定

通信の取り込み範囲、待ち受けの入口、テスト指標はそれぞれ異なることを示します。まずテストの目的を定めてから結果を読み取りましょう。

システムプロキシOSのプロキシ設定: システムプロキシは、システムの設定に従うアプリにプロキシの接続先を提供します。通常はクライアントのローカル待ち受けアドレスとポートを指定します。独自のネットワーク設定を使うアプリは従わない場合があるため、有効にしてもすべての通信が取り込まれるわけではありません。システムプロキシの解除は関連するOS設定を元に戻す操作で、コアの終了やTUNの無効化とは別です。クライアントを終了するときは、それぞれの状態を確認してください。

ローカル待ち受けポートInbound · ローカル接続の入口: ローカル待ち受けポートは、アプリからクライアントへの接続を受け付けるポートで、リモートノードのポートとは異なります。アプリ側に設定したプロキシポートを、クライアントの実際の待ち受けポートに合わせてください。また、HTTPやSOCKSなど入口の種類も確認が必要です。同じ端末だけで使う場合は通常、ループバックアドレスにバインドします。他の端末に公開する前にアクセス制御とネットワーク境界を確認し、アクセス可能な範囲を不用意に広げないようにしましょう。

TcpingTCP接続の確立時間: Tcpingは通常、対象ポートへのTCP接続が確立するまでの時間を測り、ポートへの到達性やハンドシェイクにかかる時間を初歩的に確認できます。成功しても、この段階の接続ができたことを示すだけで、プロキシ認証、TLS、DNS、実際のリクエストがすべて正常とは限りません。ツールによって再試行や計測方法が異なるため、同じ条件で結果を比べましょう。ダウンロード速度の順位としてそのまま使うこともできません。

実接続遅延プロキシ経由のリクエスト所要時間: 実接続遅延は通常、選択したノードを通して指定されたテスト先にリクエストし、TCPハンドシェイクだけを測る場合より実際のプロキシ利用に近い時間を確認します。計測には名前解決、プロキシのハンドシェイク、接続先の応答が含まれることがありますが、具体的な計測範囲はクライアントの実装次第です。テスト先によって結果は変わり、タイムアウトしてもすべてのサービスが利用できないとは限りません。帯域速度の測定とは別の指標です。

ドメインスニッフィングSniffing · ドメイン情報の抽出: ドメインスニッフィングは、一部のHTTPリクエストやTLSハンドシェイク情報など、接続開始時に識別できる情報からドメインの手がかりを抽出し、ルーティングを補助します。通信内容を復号する機能ではなく、すべてのプロトコルや接続を識別できるわけでもありません。元の接続先アドレスを置き換える設定と、ルーティングだけに使う設定は別です。有効化後に動作が変わった場合は、各項目の意味を個別に確認してください。