v2rayN
デスクトップ3プラットフォーム対応のグラフィカルクライアント
Windows、macOS、Linux 向けの V2Ray グラフィカルクライアントで、サブスクリプション管理、ノード選択、ルーティング設定、ローカル待受ポートを担当する。自身はプロキシプロトコルを実装せず、実際の転送は Xray または V2Fly コアが行い、画面側は設定の生成とコアプロセスの管理のみを担う。デスクトップ版とクラシック WPF 版の2種類の画面形態がある。
GLOSSARY
V2Ray 用語解説と用語対応
クライアントとコア、プロトコルと転送、サブスクリプションとノード、ルーティングと振り分け、ネットワークとポート、ログと診断の6分類で 29 項目の用語を整理。各項目はまず一言で性質を示し、続いて設定上の位置と利用場面を説明する。
このページの使い方
まず分類インデックスで章を探し、次に用語カード下の関連リンクから隣接する概念へ移動する。用語と設定ファイルのフィールドの対応は、ページ末尾の対応表にまとめている。
CLIENTS & KERNELS · 5 項目
クライアントとコア
3つのグラフィカルクライアントが画面と設定管理を担当し、実際の転送は Xray または V2Fly コアが実行する。両者は代替ではなく役割分担の関係にある。
v2rayNG
Android グラフィカルクライアント
Android 上で動作する V2Ray グラフィカルクライアントで、既定で Xray コアを組み合わせる。システムの VPN サービスとして通信を引き受け、root 権限は不要。サブスクリプション、ルーティング、DNS などの設定項目はデスクトップ版と同じ設定セマンティクスを使う。
v2flyNG
Android 代替クライアント
同じく Android 向けのグラフィカルクライアントで、実行時は V2Fly コアを使用し、画面構成は v2rayNG に近い。ノードが古い VMess パラメータを使う場合や、V2Fly 固有の転送構成が必要な場合の代替入口として使える。
Xray コア
実際の転送を担う中核
Project V エコシステムのコア分支のひとつで、プロトコル解析、暗号化、ルーティング照合、アウトバウンド接続を担当する。クライアントは設定を JSON として渡して実行させ、コアを更新すれば画面を変えずに新しいプロトコルへ対応できる。
V2Fly コア
コミュニティが保守するもう一つのコア
Project V のコミュニティ保守分支で、v2flyNG と一部のデスクトップクライアントが実行コアとして採用している。Xray とは設定構造がほぼ互換だが、対応するプロトコル群と転送オプションは完全には一致しないため、問題調査の際はどちらが動作しているかを先に確認する。
PROTOCOLS & TRANSPORT · 5 項目
プロトコルと転送
このグループの用語は設定ファイルの前半2段に現れる。プロトコルは身元をどう認証するかを、転送層はパケットがどんな形になるかを決める。
VMess
タイムスタンプ検証付きのプロトコル
V2Ray 初期の主力プロトコルで、クライアントとサーバーが UUID とタイムスタンプで認証を行うため、両端のシステム時刻がほぼ同期している必要がある。設定には通常 alterId パラメータも付き、新しいコアでは互換オプションとして扱われる。
VLESS
ステートレスな軽量プロトコル
VMess と比べて余分な暗号化層とタイムスタンプ検証を省き、認証は UUID のみに依存するため、ハンドシェイクが短くオーバーヘッドも小さい。VLESS 自体は暗号化を提供せず、通常は TLS や REALITY と組み合わせ、機密性は転送層が担う。
Trojan
標準 TLS を使うプロトコル
プロキシ通信を標準の TLS 接続に載せる方式で、サーバー側は通常の HTTPS サイトとして振る舞い、パスワードが一致しない場合は実在サイトの内容にフォールバックする。設定項目は少なく、主にドメインと証明書に依存するため、証明書をすでに持っている場面に向く。
REALITY
対象サイトの証明書を借りるハンドシェイク方式
クライアントはハンドシェイク段階で実在の対象サイトと直接 TLS ネゴシエーションを行い、自分でドメインや証明書を用意する必要がない。サーバーはハンドシェイクを転送して秘密鍵を保持するだけで、証明書チェーンは元から信頼される。代わりに、対象サイトが長期的に安定して到達可能でなければならない。
XTLS Vision
転送層のトラフィック整形
TLS レコード層の特徴に対するトラフィック整形技術群で、分割とパディングを制御して暗号化通信の長さ分布を通常の Web 閲覧に近づける。TLS または REALITY と併用する必要があり、単独で有効にしても意味はない。
SUBSCRIPTION & NODES · 4 項目
サブスクリプションとノード
ノードがどこから来て、どう更新され、1件の設定がどんな形をしているか。このグループの用語はインポートの段階を扱う。
サブスクリプションリンク
ノード設定の配布アドレス
ノード一覧を返す URL で、クライアントがリクエストすると返却内容を複数のノードに解析する。リンクには通常ユーザー識別用のトークンパラメータが付くため、アカウント認証情報と同じ扱いで、公開共有は避ける。
サブスクリプション更新
ノード一覧の再取得
クライアントがサブスクリプションリンクからノード一覧を再取得し、新しい結果でローカルの古い項目を置き換える処理。多くのクライアントは手動更新と定期更新に対応しており、ノードを切り替える前に一度更新しておくと、すでに停止したアドレスへ接続するのを避けられる。
ノード
アウトバウンド接続の宛先
1件のノードの完全な記述には、サーバーアドレス、ポート、プロトコル、転送方式、認証パラメータが含まれる。クライアントはノードを一覧として整理し、接続時にどの通信をどのノードへ送るかをルーティングルールが決める。
共有リンク
1件の設定を表すテキスト符号
1件のノードのパラメータをプロトコル接頭辞付きのテキストに符号化したもの。一般的な接頭辞は vmess://、vless://、trojan:// で、インポートするとクライアントがノード項目に復元する。サブスクリプションとの違いは、ノードを1件しか含まず自動更新もされない点。
ROUTING & SPLIT · 5 項目
ルーティングと振り分け
通信をプロキシ経由にするか直結にするかを決める一連の照合機構で、順序と照合対象が理解の2つの鍵になる。
ルーティングルール
通信の行き先を決める照合表
順番に照合される条件の集合で、各ルールは照合対象(ドメイン、IP、ポート、プロセス)とヒット時の動作(プロキシ経由、直結、ブロック)を記述する。照合は上から下へ進み、最初にヒットした時点で停止するため、ルールの順序が結果を直接左右する。
振り分け
宛先ごとに経路を選ぶ
一部の通信をプロキシ経由、それ以外を直接接続にする処理方式。中国本土のドメインと IP 帯を直結にし、残りをプロキシ経由にするのが一般的で、ノードの負荷を抑えつつローカルサービスが迂回されるのを防げる。
GeoIP
IP の帰属で照合
コアに内蔵または外部から読み込む IP 地理位置データベースで、ルーティングルールでは geoip:cn のような記法で参照する。ある IP がどの地域に属するかに答えるもので、IP 直指定の宛先には有効だが、ドメイン宛ては先にアドレスを解決しないとヒットしない。
GeoSite
サイトのドメイン集合で照合
サイト単位で分類されたドメインリストで、ルールでは geosite:category-ads のような形式で書く。ドメインサフィックスを1件ずつ並べるより、よく使うサイト群をまとめて処理するのに向いており、データベースはコアと一緒に更新できる。
インバウンドとアウトバウンド
通信の両端
インバウンドは通信がどこからコアに入るか(ローカルの SOCKS ポートや TUN 仮想アダプタなど)を、アウトバウンドは通信がどのように出ていくか(特定のノードや直結など)を表す。ルーティングルールの役割は、このインバウンドとアウトバウンドの間で選択を行うことにある。
NETWORK & PORTS · 6 項目
ネットワークとポート
コアがローカルに開く入口、通信を引き受ける2つの方式、そして名前解決の要求をどこへ送るか。
ローカル待受ポート
コアがローカルに開く入口
コアがローカルで待ち受けるポートで、一般的な組み合わせは SOCKS 10808 と HTTP 10809。ブラウザや OS がこのポートへ通信を向け、コアがルーティングルールに従って転送する。ポートが他のプログラムに占有されていると、クライアントは起動に失敗し、原因をログに書き出す。
SOCKS5
汎用プロキシプロトコル
TCP と UDP の転送に対応するプロキシプロトコルで、通信をプロキシ側へ渡すことだけを担い、上位が HTTP かその他かを問わない。デスクトップクライアントのローカル入口は SOCKS5 が中心で、互換性が最も高い。
システムプロキシ
OS に通信を転送させる
クライアントが OS のプロキシ設定を変更し、HTTP と SOCKS のリクエストをローカル待受ポートへ向ける。システムプロキシに従うプログラムだけが対象で、ネットワーク設定を独自に読むアプリは直結のままになる。その場合は TUN モードへ切り替える。
TUN モード
仮想アダプタが全体の通信を引き受ける
コアが仮想ネットワークアダプタを作成して既定ルートをそこへ向け、アプリの通信をネットワーク層で一括して引き受ける。各アプリのプロキシ設定に依存しなくなる代わりに、より高いシステム権限が必要で、DNS も個別に設定しないと名前解決の異常が起きやすい。
FakeDNS
偽アドレスでドメイン情報を得る
コアはまずドメインに対して予約アドレス帯の偽 IP を返し、アプリが実際に接続を開始した時点でマッピングに従ってドメインを復元し、ルーティングルールに渡す。これにより IP ベースで開始される接続でもドメイン単位の振り分けを利用できるが、ローカルの DNS キャッシュを合わせて消す必要がある。
DNS リーク
名前解決がプロキシ経路を迂回する
アプリは接続を確立する前に DNS クエリを行うが、このクエリがプロキシ経路ではなくローカルネットワークを通ると、宛先ドメインがローカルのリゾルバに露出する。一般的な対策は、コアで DNS サーバーを明示的に指定するか、TUN モードに DNS 通信を引き受けさせること。
LOGS & DIAGNOSIS · 4 項目
ログと診断
問題が起きたとき最初に何を見るか、どの数値を比べるか。このグループの用語は調査手順の出発点になる。
実行ログ
コアが出力する実行記録
コアが起動、設定読み込み、接続確立、エラー情報を時系列で記録したもので、問題調査の一次資料になる。ログ内のタイムスタンプ、アウトバウンドのタグ、エラーキーワードから、問題を具体的な箇所まで絞り込める。
ログレベル
記録の詳細度を制御する
一般的な値は warning、info、debug で、レベルが詳細になるほど記録が増え、ログファイルの増加も速くなる。普段は info のままでよく、特定の問題を再現するときだけ一時的に debug に上げ、調査が終わったら戻す。
実接続遅延
エンドツーエンドの可用性指標
クライアントが実際にノードへ接続を1回開始し、応答を待って測る往復時間で、ハンドシェイクと認証を含む。ping より実体験に近いが、テストのたびに接続のオーバーヘッドが発生し、ノードが利用できない場合はタイムアウトとして現れる。
ハンドシェイク
接続確立前のネゴシエーション
データ転送の前にクライアントとサーバーが身元を交換し、暗号化パラメータをネゴシエーションする過程。ハンドシェイクの所要時間は初回接続速度にそのまま現れ、TLS、REALITY、XTLS といった技術が重点的に最適化している部分でもある。
CONFIG MAP
用語と設定フィールドの対応
画面で見る用語は、設定ファイルでは通常以下のフィールドに対応する。フィールド名はコアのドキュメントに準拠しており、バージョンによって細かな差異がある場合がある。
| 用語 | 設定ファイル上の位置 | 画面上の一般的な場所 |
|---|---|---|
| ローカル待受ポート | inbounds[].port |
パラメータ設定 → ローカル待受ポート |
| ルーティングルール | routing.rules |
ルーティング設定 → ルール一覧 |
| インバウンドとアウトバウンド | inbounds / outbounds |
ノード一覧とルーティング設定 |
| GeoIP と GeoSite | routing.rules の domain、ip フィールド |
ルーティング設定 → ルール一覧 |
| FakeDNS と DNS | dns.servers、dns.fakeDns |
DNS 設定 → サーバー |
| ログレベル | log.loglevel |
パラメータ設定 → ログレベル |
| TUN モード | inbound の tun プロトコル | パラメータ設定 → TUN モード |
| サブスクリプション更新 | クライアント側のローカル管理で、コアの設定には書き込まない | サブスクリプション → サブスクリプション更新 |
NEXT
さらに読み進める
用語に対応する具体的な操作は、チュートリアルと問題診断の2ページに分かれている。実際にエラーが出たときは、診断手順へ直接進むとよい。