V
VMess
Project Vエコシステムで早くから使われてきたプロキシプロトコルです。ノード設定には通常、ユーザー識別子、サーバーアドレス、ポート、セキュリティオプション、トランスポート方式が含まれます。
v2rayNでVMessノードを編集すると、alterIdなどの互換フィールドが表示されることもあります。入力が必要かどうかはサーバー設定によって決まり、他のノードの値をそのまま流用することはできません。
設定用語インデックス
実際の設定場面に沿って、プロトコル、コア、サブスクリプション、ルーティング、ネットワーク用語を解説します。VLESS、GeoSite、TUN、FakeDNSなどの設定項目も、カテゴリからすぐに探せます。
読み進める順番
ノードに接続できないとき、プロトコルパラメータ、プロキシコア、ルーティングルール、システムネットワーク設定はそれぞれ異なるレイヤーに属します。まず問題の層を特定し、対応する項目を確認すると、関係のない設定を何度も変更せずに済みます。
プロトコルとトランスポート
プロトコルは、クライアントとサーバーが認証し、データを交換する方法を決めます。設定をインポートするときは、プロトコル、トランスポート方式、セキュリティ層の組み合わせを完全に保持し、サーバーアドレスとポートだけをコピーしないでください。
V
Project Vエコシステムで早くから使われてきたプロキシプロトコルです。ノード設定には通常、ユーザー識別子、サーバーアドレス、ポート、セキュリティオプション、トランスポート方式が含まれます。
v2rayNでVMessノードを編集すると、alterIdなどの互換フィールドが表示されることもあります。入力が必要かどうかはサーバー設定によって決まり、他のノードの値をそのまま流用することはできません。
V
簡略化された認証設計を採用するプロキシプロトコルで、単体では追加のデータ暗号化を担いません。実際の設定ではTLS、REALITY、TCP、WebSocket、gRPCなどのトランスポートやセキュリティ層と組み合わせます。
VLESS接続を切り分ける際は、ユーザー識別子、フロー制御、サーバー名、トランスポート種別、セキュリティオプションを同時に確認します。プロトコル名が一致しているだけでは接続できません。
T
TLSトンネル上で動作するプロキシプロトコルです。クライアント設定には通常、サーバーアドレス、ポート、認証情報、サーバー名、証明書関連のオプションが必要です。
アドレスにはアクセスできるのにプロトコル接続に失敗する場合は、サーバー名が正しいか、ローカル時刻、TLS設定、トランスポート方式がサーバー側と一致しているかを確認します。
R
Xrayエコシステムのトランスポートセキュリティ方式で、VLESS、TCP、REALITYの組み合わせが一般的です。クライアントには通常、公開鍵、短い識別子、サーバー名、フィンガープリントなどが必要です。
これらのフィールドは同じハンドシェイク設定に属しており、重要な値が一つでも一致しないと接続が中断することがあります。共有リンクやサブスクリプションには通常、必要なパラメータがまとめて含まれます。
コアとエコシステム
GUIクライアントはサブスクリプション管理、画面操作、システム設定を担い、プロキシコアはプロトコル接続、ルーティング、DNSを処理します。クライアントとコアを区別すると、更新履歴における機能の所属を理解しやすくなります。
P
ネットワークプロキシプロトコル、コアプログラム、設定ツールを中心に形成されたオープンソース技術エコシステムです。VMess、ルーティングルール、複数アウトバウンド設定などの概念も、このエコシステムの発展過程に対応する由来があります。
Project Vは特定のGUIクライアント名ではありません。v2rayNやv2rayNGなどのクライアントは、関連するコア機能を基盤に操作画面を提供する独立プロジェクトです。
V
Project Vの技術路線を受け継ぐコミュニティプロジェクトとコアファミリーです。プロトコル処理、ルーティング、DNS、インバウンド、アウトバウンドなどの基盤機能を提供します。
v2flyNGは関連コアを使ってAndroid端末上の接続を処理します。クライアント名、コア名、ノードプロトコルは別々の概念であり、設定を読む際は分けて識別する必要があります。
X
V2Ray設定体系と密接に関わるコアエコシステムで、VLESS、VMess、Trojan、REALITY、ルーティング、DNSなどに対応します。v2rayNとv2rayNGはXrayコアを使って接続設定を実行できます。
クライアントのアップグレードとコアのアップグレードは、必ずしも同じではありません。新しいプロトコルパラメータを認識できない場合は、クライアントとコアの対応状況を両方確認します。
C
プロトコルハンドシェイク、接続転送、DNSクエリ、ルーティング照合を担う低レイヤープログラムです。GUIクライアントが設定を生成してコアを起動し、ログと実行状態を読み取ります。
コアの起動に失敗しても、クライアント画面は正常に開くことがあります。その場合はサブスクリプションを再インポートする前に、ログの設定解析、ポート使用状況、権限に関するメッセージを確認します。
サブスクリプションとノード
サブスクリプションは設定をまとめて提供し、ノードは選択可能な接続記録、グループは取得元を管理します。更新、フィルタリング、遅延テストはそれぞれ異なる段階で行われます。
S
サーバー側が提供する設定セットのURLです。クライアントがサブスクリプションを更新すると、内容をダウンロードしてノードを解析し、該当グループに登録します。
サブスクリプションURLを正常に開けても、クライアントが必ずノードを解析できるとは限りません。更新結果が空の場合は、リンクが完全か、対応形式か、グループフィルタですべての記録が隠れていないかも確認します。
N
クライアント内の1件のサーバー接続設定です。通常、アドレス、ポート、プロトコル、認証パラメータ、トランスポート方式、セキュリティ設定が含まれます。
ノード名は主に識別用で、接続品質を決めるものではありません。ノードを選ぶ際は、実接続遅延、プロトコル互換性、対象地域、実際のアクセス状況を合わせて判断します。
G
複数のサブスクリプション元とノード一覧を分けて管理するコンテナです。各グループに個別のサブスクリプションURL、更新方式、フィルタ条件、現在選択中のノードを設定できます。
更新に成功したのにサーバー一覧が変わらない場合は、正しいグループを表示しているか確認します。キーワードフィルタや正規表現フィルタで新しいノードが除外されていないかも確認してください。
L
実際のプロトコル接続を確立して測定する応答時間で、基本的なネットワーク到達性だけを確認するテストより通常の接続状況に近い結果が得られます。ローカルネットワーク、プロトコルハンドシェイク、テスト対象の影響を受けます。
1回の測定値は、その時点の状態だけを示します。ノードを選ぶときは数回連続でテストし、Webページの表示やダウンロード中の安定性も合わせて判断するとよいでしょう。
ルーティングと振り分け
ルーティングルールは通常、上から下へ確認し、該当すると指定されたアウトバウンドに渡します。ルールの順序、照合範囲、最終的なアウトバウンド名をまとめて確認します。
R
ドメイン、IP、ポート、プロトコル、プロセスなどの条件に基づいてトラフィックのアウトバウンド方向を決める照合ルールです。一般的な結果にはdirect、proxy、blockがあります。
ルールは通常、一覧の順番に実行されます。範囲の広いルールを早く置くと、後続の細かなルールが上書きされることがあります。変更後は設定を再読み込みし、ログで照合結果を確認します。
S
異なる宛先のトラフィックを異なるアウトバウンドに渡す設定方式です。たとえばローカルネットワークにはdirect、特定のドメイン集合にはproxy、明示的に拒否する宛先にはblockを使います。
振り分けはプロトコルの種類ではなく、コア内で行われるトラフィックの判断処理です。同じノードでも、ルーティングモードによって実際に経由するトラフィックの範囲が変わることがあります。
G
IPアドレスの地域や定義済みカテゴリで照合するデータセットです。一般的なルールにはgeoip:cnやgeoip:privateがあります。
GeoIPの照合は対象IPを取得した後に行われ、結果はデータファイルとDNSの解決結果に左右されます。データが古いと、新しく割り当てられた一部のアドレスを想定どおり分類できないことがあります。
G
ドメインのカテゴリ別に整理されたルールセットで、一般的な記述にはgeosite:cnやgeosite:geolocation-!cnがあります。ドメインルールを一件ずつ管理する手間を減らせます。
GeoSiteとGeoIPでは照合対象が異なります。前者はドメイン、後者はIPを処理します。複雑な設定では併用でき、順序はDNSポリシーと連携させる必要があります。
クライアント機能
これらのオプションは、クライアントがシステムトラフィックをどのように受け取り、いつ設定を更新するかを決めます。複数の取り込み方式を有効にする前に、それぞれの対象範囲を理解してください。
S
OSがアプリに提供するプロキシ設定です。有効にすると、システムプロキシに対応したブラウザやデスクトップアプリが接続をクライアントのローカル待受ポートへ送信します。
一部のアプリはシステムプロキシを無視して独自に接続します。その場合はアプリ内部のネットワーク設定を確認するか、必要に応じてTUNモードの使用を検討します。
T
仮想ネットワークインターフェースでシステムトラフィックを取り込み、処理する動作方式です。システムプロキシ設定を読まないアプリにも対応し、より多くのTCPとUDPトラフィックを一元的に処理できます。
有効化には通常システム権限が必要で、他の仮想ネットワークツールとインターフェースやルーティングが競合する場合があります。ローカル機器にアクセスできないときは、LANとプライベートアドレスを迂回するルールを確認します。
F
ドメインに一時的な仮想IPを割り当て、後続の接続で元のドメイン情報を復元するDNS処理の仕組みです。TUNモードと組み合わせると、ドメイン単位のルーティングを維持できます。
FakeDNSのアドレスはクライアント内部のマッピングでのみ意味を持ちます。マッピング範囲、ルーティング、DNS設定が一致しないと、ドメインは解決できても接続が完了しないことがあります。
A
クライアントが設定した間隔でサブスクリプションを再取得し、グループを更新します。ノードの変更を同期する機能であり、無効なURLや形式エラーを自動修正するものではありません。
更新後の一覧は、グループのフィルタ、並べ替え、重複排除ルールの影響を受けます。重要な設定が変わったときは、まず手動更新を実行してクライアントログを確認できます。
ネットワークとシステム
プロキシ設定はOSのネットワーク機能を基盤とします。ドメイン解決が対象アドレスを決め、TCPとUDPは異なるデータ転送方式を表します。
D
ドメインをIPアドレスに変換する基本的なネットワークサービスです。クライアントでは問い合わせ先、ドメイン照合ルール、問い合わせ種別、DNSトラフィックのアウトバウンド経路を設定できます。
Webページを開けないのにIPアドレスへ直接アクセスできる場合、DNSは確認すべき項目の一つです。システムキャッシュ、クライアントログ、ブラウザ独自のDNS設定も確認してください。
D
ドメイン問い合わせが想定した経路で送信されず、問い合わせの流れと接続トラフィックのルーティング方針が一致しない状態です。システムDNS、ブラウザ独自のDNS、クライアントDNSが同時に動作すると起きやすくなります。
処理時はどの層が名前解決を担当するかを明確にし、システムプロキシ、TUN、DNSアウトバウンド、ブラウザ設定をまとめて確認します。DNSアドレスを一つ変更するだけでは経路の不一致が解消しないことがあります。
T
信頼性のある順序付きバイトストリームを提供するトランスポート層プロトコルです。Webアクセス、ファイル転送、多くのプロキシ構成でTCPが使われます。
設定内のTCPは、低レイヤーのトランスポート方式を指す場合と、ルーティングルールで照合するネットワーク種別を指す場合があります。フィールドの階層を確認して判断してください。
U
データグラム向けのトランスポート層プロトコルで、DNS、リアルタイム通信、一部のアプリトラフィックでUDPが使われます。TCPと同じ接続確認や再送の仕組みは提供しません。
特定のアプリ機能だけが異常で通常のWebページは正常な場合、ノード、コア、ルーティング、TUN設定でUDPが許可されているか確認します。クライアント画面のUDPオプションも現在の動作モードに合わせる必要があります。