Project V
V2Rayエコシステムの背景エコシステムの背景：Project Vは、V2Rayを中心とするオープンソースのプロキシ技術体系を理解する出発点であり、特定のGUIクライアントの名称ではありません。「V2Rayの設定」は関連するプロトコルやツールを広く指すことがありますが、プロジェクトごとに対応する設定項目は異なります。解説を読む際は、エコシステムの名称と実際に動作するコアの名称を分けて確認しましょう。
設定リファレンス
6つのテーマ · 25用語
V2Ray用語集
コア、プロトコル、設定
用語を設定のレイヤー別に確認し、問題の原因を切り分けましょう。まずクライアントとコアを区別し、プロトコル、セキュリティ層、トランスポート方式を確認します。サブスクリプション管理、ルーティング、DNSは、設定の更新方法やリクエストの処理方法に関わります。
コアとエコシステム
選び方の目安：デスクトップではv2rayN、Androidではv2rayNGから検討しましょう。V2Flyのコアが必要な場合はv2flyNGも選択肢です。クライアント名だけでは、実際のコアの対応機能は判断できません。
V2Fly
V2Rayのコミュニティプロジェクトとコアの系統コアの系統：V2FlyはV2Rayのコミュニティ開発を引き継ぎ、関連するコアプログラムや設定機能を発展させています。当サイトで紹介するv2flyNGは、この系統のコアを採用したAndroid向け代替クライアントです。設定名にV2Rayが含まれていても、他のコアがすべての拡張項目に対応するとは限りません。
Xray
プロトコル処理と接続を担うコアコアの機能：XrayはV2Rayの技術体系から派生した、独立して開発が続くコアプロジェクトです。v2rayNやv2rayNGで使われることも多くあります。REALITYなどの機能は、クライアントに入力欄が表示されるかではなく、実際に使うコアとバージョンで対応状況を確認してください。クライアントを更新した後は、選択中のコアがインポートした設定に対応しているかも確認しましょう。
クライアントとコア
管理画面 / 接続処理プログラム役割の違い：クライアントはノード一覧、サブスクリプション管理、モード切り替え、ログ表示を提供し、コアは設定の解析、接続の確立、ルーティングを実行します。クライアントにリンクをインポートできても、現在のコアがすべてのパラメーターに対応しているとは限りません。互換性を調べるときは、クライアント名、実際のコア、エラーが出た項目を記録し、画面側の変換とコアの処理のどちらに問題があるかを確認しましょう。
トランスポートプロトコル
レイヤーの違い：VMess、VLESS、Trojanはプロキシ通信のルールを定め、TCPやWebSocketなどはデータの運び方を定めます。名称が似ていても、互いに置き換えられるわけではありません。
VMess
プロキシプロトコルプロトコルの設定：VMessはV2Rayエコシステムのプロキシプロトコルです。接続するには、ユーザーID、アドレス、ポート、対応するトランスポート設定を一致させる必要があります。認証処理ではシステム時刻も重要で、時刻のずれが接続失敗につながることがあります。古い解説の設定をそのまま現在の環境に適用せず、サーバーから提供された一式の設定を優先してください。
VLESS
軽量なプロキシプロトコルセキュリティの組み合わせ：VLESS単体では通信全体を暗号化しないため、実際の環境では通常、TLSやREALITYなどのセキュリティ層と組み合わせます。ノードのユーザーID、フロー制御、トランスポート方式、セキュリティ設定をまとめて一致させる必要があり、プロトコルの選択だけを変更しても接続できません。インポート後に未対応の項目が表示された場合は、セキュリティ設定を消すのではなく、まずコアの対応状況を確認しましょう。
Trojan
通常TLSと組み合わせるプロキシプロトコル接続の仕組み：Trojanは通常、TLS接続上でプロキシリクエストを転送します。認証情報とTLS設定はサーバー側に合わせる必要があります。パスワードが正しくても、サーバー名が違えばハンドシェイクに失敗することがあります。トラブル時は認証エラーと証明書エラーを区別し、証明書検証を無効にするのではなく、ドメイン名、システム時刻、証明書チェーンを確認してください。
トランスポート方式
TCP / WebSocket / gRPCデータの運び方：トランスポート方式はプロキシデータの構成と転送方法を定め、プロキシプロトコルとは別のレイヤーに属します。WebSocketのパスやリクエストのホスト名、gRPCのサービス名はそれぞれ意味が異なるため、別の項目の値をそのまま流用しないでください。トランスポート設定の変更には通常サーバー側の対応も必要で、クライアントだけ切り替えても互換性は得られません。
セキュリティと暗号化
確認する項目：接続先アドレス、サーバー名、認証情報はそれぞれ役割が異なります。ハンドシェイクエラーが起きたら、各項目の意味に沿って確認し、検証の無効化を常用設定にしないでください。
TLS
トランスポート層セキュリティプロトコル安全な接続：TLSは通信を暗号化し、相手の認証を行います。証明書の検証は通信相手を確認する重要な手順です。信頼できる証明書チェーン、名前の一致、正確なシステム時刻が検証結果に影響します。証明書エラーが出た場合は、まず時刻とサーバー名を確認し、その後サーバー証明書の状態を調べましょう。暗号化接続を確立できても、相手の身元が正しく検証されたとは限りません。
REALITY
Xrayエコシステムのトランスポートセキュリティ機構パラメーターの対応：REALITYはXrayエコシステムのトランスポートセキュリティ機構で、VLESSと組み合わせて使われることが多く、ノードのプロトコル名を置き換える独立したスイッチではありません。クライアントに必要な公開鍵情報、サーバー名、ショートIDなどは、サーバー側の設定と一つずつ照合してください。バージョンによって画面上の項目名が異なる場合は、名前だけで判断せずパラメーターの意味を確認し、別のノードの設定をつなぎ合わせないようにしましょう。
SNI
Server Name Indicationサーバー名：SNIはTLSハンドシェイクで接続先のサーバー名を示す拡張情報で、サーバーが対応する設定を選ぶために使われます。ノードの接続先がIPアドレスでも、サーバー名にはドメインを指定する場合があり、両者が一致するとは限りません。クライアント画面では「サーバー名」と表示されることもあります。サーバーが指定した値を使い、ノードのメモ名や任意のWebサイトのドメインを入力しないでください。
暗号化と認証
通信内容の保護 / 相手の確認用語の違い：暗号化は通信内容を保護し、認証は接続相手を確認します。役割が異なるため、一方で他方を代用することはできません。ある層でプロトコル独自の暗号化が使われていなくても、接続全体にセキュリティ層がないとは限りません。TLSなどの組み合わせも確認し、暗号化の選択欄だけで設定全体を判断しないようにしましょう。
サブスクリプションとノード
管理のポイント：サブスクリプションは設定の取得、ノードは接続先、グループは設定の整理を担います。更新できることとノードに接続できることは、別々に確認してください。
サブスクリプションURL
設定の取得・更新先設定の取得元：サブスクリプションURLを使うと、クライアントが複数のノード設定を取得し、その後の更新で変更を同期できます。URLにアクセス情報が含まれる場合があるため、機密情報として保存し、スクリーンショットやログ、掲示板に公開しないでください。サブスクリプションの更新は設定の取得であり、サーバー側の障害を自動で修復するものではありません。更新に失敗した場合は、URLの無効化、ネットワーク接続、形式の解析を切り分けて確認しましょう。
ノード
1つの接続先を定義する設定一式接続先：ノードには通常、サーバーアドレス、ポート、プロキシプロトコル、認証情報、トランスポート、セキュリティの各設定が含まれます。サーバーのIPアドレスだけを指すものではありません。ノード名は識別用のメモであり、実際の所在地や接続品質を示すものではありません。ノードをコピーするときは設定全体を保持してください。アドレスとポートだけを手入力しても、元の接続設定を再現できない場合があります。
サブスクリプショングループ
提供元や用途別に設定を整理管理の範囲：サブスクリプショングループは設定の提供元を区別し、ノードの絞り込み、サブスクリプションの更新、メモの管理に役立ちます。グループ名だけで、リクエストがプロキシ経由か直接接続かは決まりません。実際の経路は、選択中のノード、動作モード、ルーティングルールによって決まります。自動更新やサーバーのフィルタリングを使う場合は、どのグループに設定が適用されるか確認し、フィルター結果をサブスクリプションの内容が消えたものと誤解しないようにしましょう。
実接続遅延
ノード経由でテスト先にアクセスした所要時間測定内容：実接続遅延は通常、指定ノード経由でテスト先にアクセスした際の所要時間を指します。どの処理段階を含むかは、クライアントのテスト方法によって異なります。サーバーポートへのTCP接続時間だけを測るテストとは異なり、ダウンロード速度を直接示すものでもありません。比較する際は、テスト先、ネットワーク環境、測定方法をそろえてください。1回のタイムアウトだけで判断せず、実際のアクセス状況やログも確認しましょう。
ルーティングとDNS
通信経路の確認：リクエストにドメインとIPアドレスのどちらが含まれるかを見てから、ルールと名前解決の設定を確認します。実際の通信経路とDNS問い合わせの経路は、別々に検証する必要があります。
ルーティングルールと振り分け
条件に一致 → 出力先を選択経路の選択：ルーティングルールは、ドメイン、IP、ポート、インバウンドなどの条件に応じて、リクエストを直接接続、プロキシ、ブロックなどの出力先に振り分けます。一般にルールは上から順に判定されるため、広すぎるルールを先に置くと、後続の詳細なルールが適用されないことがあります。いわゆる通信振り分けは独立したプロトコルではなく、ルール、デフォルトの出力先、名前解決、トラフィックの取り込みによって実現されます。
GeoIP
IPアドレス分類データアドレスの集合：GeoIPはIPアドレスを地域やカテゴリ別に整理したデータです。対応するコアは、指定のタグを使ってルールからデータを参照できます。判定結果はデータの提供元や更新時期、接続先の実際のIPアドレスによって変わるため、地域タグを正確な位置情報として扱わないでください。共有インフラやIPアドレスの変更がある場合は、ログで実際の接続先IPを確認してから、より具体的なルールを追加しましょう。
GeoSite
ドメイン分類データドメインの集合：GeoSiteはドメインルールをカテゴリ別に整理し、タグを使ってサイト群の振り分け方針を管理しやすくします。GeoIPとは照合対象が異なり、ドメインの集合がサイトの現在の全IPアドレスを示すわけではありません。ルールが適用されるかどうかは、コアがドメイン情報を取得できるか、データファイルに該当するタグが含まれているかにも左右されます。
FakeDNS
ドメインと仮想IPの対応付けアドレスの対応付け：FakeDNSは予約済みアドレス範囲の仮想IPを使ってドメインの問い合わせに応答し、IPアドレスとドメインの対応関係を保存します。その後の通信から元のドメインを復元するための仕組みです。TUNなどのトラフィック取り込み経路や対応関係の復元機能と組み合わせる必要があり、パブリックDNSのアドレスを変更するだけの設定ではありません。この方式に対応しないアプリもあるため、切り替え前後は古い名前解決キャッシュにも注意してください。
DNS漏えい
想定した名前解決経路から外れる問い合わせ名前解決の範囲：DNS漏えいとは通常、ドメインの問い合わせが想定した経路を通らず、OS、アプリ、別のリゾルバーによって直接処理されることです。実際の通信がプロキシ経由でも、DNS問い合わせも同じ経路を通るとは限りません。確認する際は、ブラウザー独自の名前解決、システムキャッシュ、クライアントのDNSルールも考慮してください。出口IPや特定のリゾルバー名だけで判断しないようにしましょう。
クライアント機能
機能の範囲：システムプロキシとTUNでは通信を取り込む範囲が異なり、ローカルインバウンドはアプリの接続方法を決めます。問題が起きたら、ログでリクエストがどの段階で止まっているか確認しましょう。
システムプロキシ
システムにプロキシの接続先を登録取り込み範囲：システムプロキシは、ローカルのプロキシアドレスをOSの設定に登録します。この設定に従うアプリのみがプロキシを利用します。独自のネットワーク設定を使うアプリもあるため、システムプロキシを有効にしてもすべての通信が取り込まれるとは限りません。v2rayNを終了した後に通常のネット接続に問題がある場合は、停止したポートを指すプロキシ設定がOSに残っていないか確認してください。
TUNモード
仮想ネットワークインターフェースで通信を取り込むトラフィックの取り込み：TUNは仮想ネットワークインターフェースを通じて通信をクライアントに渡します。システムプロキシより多くのアプリをカバーできますが、システムのルーティング設定や除外ルールの影響を受けます。有効にする際は追加の権限が必要な場合があり、DNSやループバック対策の設定も必要です。初めて調整するときは、まずノード単体の動作を確認してからTUNを有効にし、複数の設定を同時に変えて切り分けの基準を失わないようにしましょう。
ローカルインバウンド
アプリからコアへ接続する待ち受け口待ち受け口：ローカルインバウンドは、コアがアプリからのリクエストを受け付ける場所です。HTTP、SOCKS、混合プロキシのポートなどが一般的です。アプリ側のプロキシ種別、アドレス、ポートを実際の待ち受け設定と一致させてください。ポートが開いているだけでプロトコルも対応しているとは限りません。ループバックアドレスでの待ち受けと全インターフェースでの待ち受けでは、接続可能な範囲が異なります。LANからの接続が本当に必要か確認してから設定を変更しましょう。
実行ログ
設定と接続の段階を切り分けトラブルシューティングの手がかり：実行ログには、設定の読み込み、解析、ハンドシェイク、接続などのイベントが記録されます。ローカル設定の誤りとリモート接続の失敗を切り分けるのに役立ちます。明確なアクセス操作を1つ行い、その時刻のログを確認して、過去のエラーと現在のリクエストを混同しないようにしましょう。ログを共有する前に、サブスクリプションURL、ユーザーID、認証情報などの機密情報を削除してください。必要な場合は、エラーの種類と関連する項目名だけを残しましょう。