Project V#
Project V は V2Ray シリーズツールの総称で、同一の JSON 設定仕様を中心に発展してきたオープンソースのプロキシソフトウェア群を指します。クライアントは画面とプロセス管理を担当し、実際の転送はコアが行います。現在のエコシステムには主に V2Fly と Xray の2つのコアブランチがあり、設定ファイルの構造はほぼ共通です。
Project V · Xray · V2Fly
V2Ray 用語集と用語解説
6つの分類で V2Ray のクライアントと設定ファイルに繰り返し出てくる用語を整理しました。各項目はひとつのことだけを説明します。このフィールド、このスイッチ、このプロトコル名が v2rayN、v2rayNG、あるいは設定ファイルで具体的に何を指すのかを。
- 6つの分類
- 35 の用語
- フィールド名は設定ファイルと一致
- v2rayN · v2rayNG · v2flyNG
全 35 用語
全用語クイック一覧（35 件）
ルーティングと振り分け
トランスポートとセキュリティ
プロトコルとコア
8 件設定ファイルに登場するプロトコル名と、それらを動かす2つのコアブランチ。
Xray#
Xray は Project V エコシステムの中で開発が活発なコアブランチで、従来のプロトコルに加えて VLESS、XTLS、REALITY などの機能を拡張しています。v2rayNG は既定で Xray コアを使用し、v2rayN も設定からコアの種類を切り替えられます。設定フィールドは V2Ray とほぼ同じで、多くのノードパラメータはそのまま流用できます。
V2Fly#
V2Fly は元のリポジトリがアーカイブされた後、コミュニティが引き継いで保守しているコアブランチで、従来の V2Ray 設定フォーマットとの互換性を維持しています。v2flyNG はこの V2Fly コアでビルドされた Android クライアントで、サーバー側も同じブランチを使っている場面に向いています。更新のペースは穏やかで、設定フィールドは Xray と大部分が重なります。
VMess#
VMess は Project V が初期に独自開発したプロキシプロトコルで、クライアントとサーバーは UUID と alterId で識別を行います。時刻を基に接続の検証値を生成するため、両端のシステム時刻が大きくずれていると、テストは通るのに接続できない状態になります。新しいコアでは alterId の役割は弱まっており、設定時は既定値のままか 0 を入れておけば問題ありません。
VLESS#
VLESS は VMess の軽量な代替プロトコルで、内蔵の暗号化レイヤーを廃止し、暗号化は TLS や REALITY に任せます。識別子は UUID ひとつだけで、設定フィールドも少なく、ハンドシェイクの負荷も低くなります。クライアントとサーバーの両方が対応している必要があり、コアのバージョンが古いとこのプロトコルを認識できません。
Trojan#
Trojan はプロキシ通信をトランスポート層で通常の HTTPS リクエストと見分けがつかないようにする設計で、そのため TLS との併用が必須です。設定にはサーバーアドレス、ポート、パスワードを入力し、パスワードがそのまま認証情報を兼ねます。V2Ray 系コアはこれを出站プロトコルとしてサポートしており、VMess や VLESS のノードと同じサブスクに混在させられます。
REALITY#
REALITY は Xray が導入したトランスポートセキュリティ方式で、自己署名証明書の代わりに実在サイトの TLS ハンドシェイク特性を使うため、クライアント側に証明書ファイルを用意する必要がありません。設定には publicKey、shortId、serverName の3種類のフィールドが現れ、サーバー側と完全に一致させる必要があります。扱うのはトランスポート層のハンドシェイク特性だけで、上位プロトコルの選択には影響しません。
Shadowsocks#
Shadowsocks は比較的早くからある軽量なプロキシプロトコルで、V2Ray 系コアはこれを出站プロトコルのひとつとしてサポートしています。設定フィールドはサーバーアドレス、ポート、暗号化方式、パスワードで、暗号化方式はサーバー側と同じ値にする必要があります。サブスクにこのプロトコルが含まれる場合、クライアントの一覧には通常、暗号化方式だけが表示され、トランスポート層の項目は出ません。
クライアントとUI
6 件3つのクライアントの役割の違いと、画面にある全体設定に関わるスイッチ。
v2rayN#
v2rayN は Windows、macOS、Linux 向けのデスクトップクライアントで、サブスク管理、ノードの速度測定、コアプロセスの制御を担当します。画面の左側はサブスクのグループとサーバー一覧、右側には選択中のノードの設定フィールドとスイッチが表示されます。本体は画面とプロセス管理のみを行い、実際の転送はローカルのコアが行います。
v2rayNG#
v2rayNG は Android 向けの GUI クライアントで、既定で Xray コアを使用します。システムの VpnService で通信を引き受け、初回接続時にはシステムの許可ダイアログが表示されます。サブスク、ルーティングルール、アプリごとのプロキシはいずれも同じ画面で設定します。
v2flyNG#
v2flyNG は v2rayNG とほぼ同じ画面で、内蔵コアが V2Fly ブランチである点だけが異なります。サーバー側が V2Fly コアで、両端を揃えたい場面に向いています。2つは同時にインストールでき、サブスクのデータはそれぞれ別に保存されます。
システムプロキシ#
システムプロキシとは、クライアントが OS のプロキシ設定を書き換え、ブラウザのリクエストをローカルの待ち受けポートへ転送する方式です。システムプロキシ設定に従うプログラムだけが対象で、一部のアプリは独自にこれを迂回します。クライアントを終了したら設定が元に戻っているか確認してください。戻っていないと、ブラウザがネットワークに接続できなくなることがあります。
TUN モード#
TUN モードは仮想ネットワークアダプタを作成して、システム全体の通信を引き受けます。システムプロキシ設定を参照しないプログラムも対象になります。有効にするには通常、管理者権限かシステムの許可が必要で、通信の経路はコアがルーティングルールに従って処理します。デスクトップと Android では実装方法が異なりますが、対応する設定フィールドはほぼ同じです。
アプリごとのプロキシ#
アプリごとのプロキシは Android クライアントのアプリ単位の振り分け機能で、どのアプリをプロキシ経由にし、どれを直結にするかを指定できます。VpnService の層で動作し、同じアプリ内の通信すべてに適用されます。よくある使い方は、ブラウザや外部リソースへアクセスするアプリをプロキシ経由、ローカルサービス系のアプリを直結に設定する方法です。
サブスクとノード
7 件1本のサブスク URL から一覧の1行のサーバーになるまでに、どんな工程を経るのか。
サブスクリプション#
サブスクリプションとは、サーバー側が管理するノード一覧の URL で、クライアントは一定間隔で取得してローカルのサーバー一覧を更新します。中身は base64 でエンコードした共有リンクの集合でも、完全な JSON 設定でもかまいません。サブスクを使えばノードの追加や削除はサーバー側で完結し、ローカルで1件ずつ手作業で追加する必要はありません。
サブスク変換#
サブスク変換とは、あるサブスク形式を別の形式に翻訳する作業です。たとえば base64 のリンク集合を、クライアントがそのまま読める JSON に変換します。変換時に最も失われやすいのはトランスポート層のフィールドと TLS 関連のパラメータです。変換後はノード数が合っているかを見るだけでなく、実際に一度接続してみてください。
共有リンク#
共有リンクは、1つのノードのプロトコル、アドレス、ポート、識別子、トランスポートパラメータを1本の URI に圧縮したものです。よく使われる接頭辞は vmess:// と vless:// です。単体ノードを一時的に共有するのに向いており、グループやルーティングの情報は含まれません。リンク中央の base64 部分をデコードすると JSON になり、フィールド名は設定ファイルと一対一で対応します。
ノード#
ノードとは、接続可能なサーバーとそれに対応するプロトコルパラメータの組み合わせで、クライアントの一覧では1行のレコードとして表示されます。1本のサブスクには通常、複数の地域のノードが含まれ、名前はサーバー側が定義します。ノード自体にクライアント側のロジックはなく、ノードを切り替えることは出站の宛先を変えることだけを意味します。
レイテンシ#
レイテンシとは、クライアントがテストを送ってから応答を受け取るまでの時間で、単位は通常ミリ秒です。数値が小さいほど往復が速いことを意味します。一覧の数値は能動的なテストによるもので、ローカルのネットワーク状態やサーバー負荷によって変動します。示すのは接続の速さだけで、実際のダウンロード速度や長期的な安定性を表すものではありません。
実接続レイテンシ#
実接続レイテンシは、テスト時に TCP の疎通確認だけでなく、実際にプロトコルのハンドシェイクまで完了させる測定です。結果は実際の使用感に近くなりますが、所要時間が長く、サーバーへの負荷も大きくなります。ノード数が多い場合は、まず通常のレイテンシで候補を絞り、少数のノードに対してこのテストを行うのがおすすめです。
倍率#
倍率は通信量の集計におけるノードの重み係数で、1倍のノードは実際の使用量どおり、2倍のノードは2倍として計算されます。倍率はサーバー側が設定するもので、ノードの速度とは直接関係ありません。ノードを選ぶときは、まず倍率で高倍率のものを外し、そのうえでレイテンシと地域を比べるとよいでしょう。
ルーティングと振り分け
5 件通信の経路を決めるルール体系と、ルールが参照する2種類のデータファイル。
ルーティングルール#
ルーティングルールは1本の接続がどの出站を通るかを決めるもので、ドメイン、IP、ポートなどの条件と送信先の出站で構成されます。ルールは上から順に照合し、最初に一致した時点で止まるため、具体的なルールは汎用的なルールより前に書く必要があります。設定ファイルでは routing.rules 配列に対応し、クライアントの画面ではチェックできる項目として表示されます。
振り分け#
振り分けとは、宛先アドレスに応じて通信を別々の出站に振り分けることです。たとえばローカルアドレスは直結、特定ドメインはプロキシ経由、広告ドメインは遮断といった具合です。適切に振り分ければ不要なプロキシ通信を減らせ、社内ネットワークのサービスが迂回されるのも防げます。振り分けの結果はルールセットとドメイン解決の結果の両方に左右され、設定を誤ると互いに干渉します。
GeoIP#
GeoIP は IP アドレス帯の地域別帰属から生成されたデータファイルで、ルーティングルールでは geoip:cn のような書き方で参照します。判定するのは接続先の IP の帰属なので、ドメインは先に IP へ解決しないと照合できません。データファイルは定期的に更新する必要があり、更新しないと新しく割り当てられたアドレス帯が照合できないことがあります。
GeoSite#
GeoSite はドメイン単位で分類して生成されたデータファイルで、ルーティングルールでは geosite:category-ads のような書き方で参照します。GeoIP との違いは、解決結果を待たずにドメインを直接照合できる点です。通常は両者を組み合わせて使い、ドメインのルールを先に、IP のルールを最後の受け皿にします。
インバウンドとアウトバウンド#
インバウンド（inbounds）はどのポートでどのプロトコルとして接続を受け入れるかを記述し、アウトバウンド（outbounds）は接続を最終的にどこへ送るかを記述します。デスクトップクライアントのインバウンドは通常ローカルの待ち受けポートで、アウトバウンドはサブスク内のノードです。設定ファイルのこの2つのトップレベル配列が、設定全体の出発点になります。
トランスポートとセキュリティ
5 件出站プロトコルの下の層で、ハンドシェイク、暗号化、接続の再利用を担う。
TLS#
TLS はトランスポート層の暗号化プロトコルで、VLESS や Trojan などの設定で暗号化と証明書検証を担います。クライアントはサーバーの指示に従って serverName、allowInsecure などのフィールドを入力します。証明書のドメインと実際の接続先アドレスが一致しない場合、ハンドシェイクはそのまま失敗します。
WebSocket#
WebSocket は1本の TCP 接続上で双方向にデータを送受信できるプロトコルで、プロキシ通信のトランスポート層としてよく使われます。設定には path と host を入力し、サーバー側と一致させる必要があります。リバースプロキシ経由で転送する構成に向いています。
gRPC#
gRPC は HTTP/2 ベースのリモート呼び出しフレームワークで、V2Ray 系の設定ではトランスポート方式のひとつとして使われます。主要なフィールドは serviceName で、両側の値を完全に一致させる必要があります。多重化の扱いに優れますが、サーバー側でも対応する設定を有効にする必要があります。
uTLS フィンガープリント#
uTLS を使うと、クライアントは TLS ハンドシェイク時に指定したブラウザのフィンガープリント特性を使えます。設定では fingerprint フィールドで選択します。影響するのはハンドシェイク特性の識別されやすさで、暗号化の強度は変わりません。フィールドを空にするとコアの既定のフィンガープリントが使われます。
mux 多重化#
mux は複数の接続を1本の下位接続にまとめて転送し、ハンドシェイクの繰り返しによるオーバーヘッドを減らします。ノードのレイテンシが高く、同時接続数が多いときに効果がはっきり出ます。一部のサーバーは mux に対応していないため、有効にして接続が不安定になったら、まずこの項目を切って切り分けてください。
トラブルシューティングとログ
4 件接続に問題が出たとき、最初に確認したいフィールドとスイッチ。
ログレベル#
ログレベルはクライアントが記録する動作情報の量を制御し、よく使う値は warning、info、debug です。普段は warning のままでよく、接続の問題を調べるときだけ一時的に debug に切り替えます。debug は大量の内容を書き出すため、原因を特定できたら元のレベルに戻してください。
DNS リーク#
DNS リークとは、ドメイン解決のリクエストがプロキシ経路を通らず、ローカルネットワークから直接送信されてしまうことです。プロキシ自体が使えなくなるわけではありませんが、解決結果と実際の出口が食い違い、一部のサイトで異常と判定される原因になります。名前解決をプロキシ側で処理するか、設定で信頼できる DNS サーバーを指定すると、こうした状況を減らせます。
FakeDNS#
FakeDNS は、コアがまず仮のアドレスを返し、接続が実際に確立する段階で本当の宛先に置き換える仕組みで、解決の往復を1回分省けます。TUN モードと組み合わせて使うことが多く、クライアントとコアの両方で対応するスイッチを有効にする必要があります。無効にした後は、古いマッピングが残らないようローカルキャッシュを消すとよいでしょう。
時刻のずれ#
時刻のずれとは、端末の時刻とサーバー時刻の差のことです。VMess プロトコルはこれを使って接続の検証値を生成します。ずれが許容範囲を超えると、ノードのテストは通るのに接続がすぐ失敗する、という症状が出ます。システム時刻を自動同期に設定しておけば、たいていは解決します。
一致する用語がありません。キーワードを変えるか、入力欄を空にして全 35 件を表示してください。
用語を設定ファイルに戻す
用語解説はあくまで索引です。各フィールドが設定ファイルのどこにあり、どんな値を取るかは、以下のページから追えます。