Windows
Windowsでは、デスクトップ版と従来のWPF版から選択できます。デスクトップ版はクロスプラットフォームのUI方針を採用しており、操作方法を統一したいユーザーに適しています。WPF版は従来のWindowsインターフェースと使い慣れた操作感を引き継いでいます。インストール後はサブスクリプションを登録してグループを更新し、使用するサーバーを選んでシステムプロキシを有効にしてください。
Windowsのダウンロードへv2rayNデスクトップクライアント、v2rayNG Androidクライアント、サブスクリプション設定ガイドをまとめています。サーバー設定を各プラットフォームへ取り込み、システムプロキシ、TUNによるトラフィック制御、ルーティングルールを個別に設定できます。
クライアント設定は単一のスイッチではありません。サブスクリプション更新、プロトコルパラメータ、プロキシモード、ルーティングルールが一連の流れを構成します。実際の接続順に沿って各要素を理解すれば、トラブル発生時にも原因を正確に切り分けられます。
サブスクリプションURLはサーバー項目を配信し、クライアントはその項目をローカルグループへ登録します。初回登録後はサブスクリプションを手動で更新し、サーバー一覧に選択可能なノードが表示されるか確認してください。グループ名、更新結果、ログのメッセージをまとめて確認し、画面に1行表示されたことだけで成功と判断しないことが重要です。継続利用では、提供元ごとにグループを分けると、複数のサブスクリプションにある同名ノードの混在を避けられます。更新前に手動設定を保存しておけば、上書きによる判断の難しさも軽減できます。
この手順は v2rayN と v2rayNG の両方で利用できますが、メニューの位置とシステム権限は異なります。デスクトップ版は複数の設定グループをまとめて管理するのに適しており、Android版ではバックグラウンド動作とネットワーク制御の権限も確認する必要があります。
VLESS、VMess、Trojanなどのプロトコルが定義するのは、接続経路の一部にすぎません。アドレス、ポート、ユーザー識別子、セキュリティ層、トランスポート方式、サーバー名、flowパラメータは、サーバー側と一つずつ一致させる必要があります。VLESSとREALITYを組み合わせる場合は、公開鍵、短いID、フィンガープリント、ターゲット名も確認します。いずれかの項目にずれがあると、ハンドシェイク失敗や、接続後にデータを交換できない状態につながります。サブスクリプションから登録すれば手入力を減らせますが、ログの確認や設定移行のためにも、各項目の関係は理解しておきましょう。
当サイトのドキュメントでは、設定構造を実際の項目名に基づいて説明し、重要なパラメータを不明な略語で置き換えません。機密性のある認証情報については、項目の用途と入力ルールのみを説明します。
ルーティングモジュールは、リクエストをプロキシ、直接接続、遮断のどれに振り分けるかを決めます。ルールは通常、上から順に照合されるため、プライベートアドレス、指定ドメイン、地理データセット、フォールバックルールを明確な順序で配置する必要があります。ドメイン戦略は、ドメインとアドレスの変換方法にも影響するため、DNS設定から切り離して調整することはできません。一般的な用途では、まずクライアント標準の基本分岐テンプレートを使い、固定されたサービスにだけ少数の高優先度ルールを追加する方が、未知のルールを大量に一括登録するより管理しやすくなります。
アクセス結果が想定と異なる場合は、対象ドメイン、適用されたルール、最終的な出口を記録してください。これにより、ノード接続、DNS名前解決、ルールの順序のどこに問題があるかを切り分けられます。
システムプロキシは、OSのプロキシ設定に従うアプリを主に制御します。設定が簡単で、ブラウザーや一般的なデスクトップソフトに適しています。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のトラフィックを処理します。システムプロキシを参照しないプログラムに向いていますが、追加の権限が必要で、ローカルファイアウォール、仮想NIC、DNS構成との調整も求められます。両方を有効にすればよいわけではありません。まず一方で接続を確認し、対象アプリの範囲に応じて切り替えることで、二重制御やループ経路を減らせます。
クライアントを終了する前に、対応するシステム設定を元に戻してください。再起動後にネットワーク異常が起きた場合は、システムプロキシが残っていないか、TUNインターフェースが有効なままになっていないか、ローカルポートを別のプログラムが使用していないかを確認します。
デスクトッププラットフォームでは v2rayN を共通して使用し、Androidでは v2rayNG を主な選択肢とします。異なるカーネル系統の代替として v2flyNG も利用できます。プラットフォームの入口から、対応するタブを開いたダウンロードページへ直接移動できます。
Windowsでは、デスクトップ版と従来のWPF版から選択できます。デスクトップ版はクロスプラットフォームのUI方針を採用しており、操作方法を統一したいユーザーに適しています。WPF版は従来のWindowsインターフェースと使い慣れた操作感を引き継いでいます。インストール後はサブスクリプションを登録してグループを更新し、使用するサーバーを選んでシステムプロキシを有効にしてください。
WindowsのダウンロードへmacOSのインストーラーはプロセッサアーキテクチャごとに分かれています。Apple Silicon搭載デバイスはarm64、Intelプロセッサ搭載デバイスはx64を選択します。初回起動時にはシステム権限の確認が必要です。TUNを有効にする場合は、ネットワーク拡張に関する操作も許可してください。まずシステムプロキシでサブスクリプションとノードを確認し、アプリの対象範囲に応じて、より包括的なトラフィック制御を有効にするか判断することをおすすめします。
macOSのダウンロードへAndroidでは主に v2rayNG を使用し、Xrayカーネル系統で一般的なVLESS、REALITY、VMess、Trojan設定に対応します。多くの最新デバイスではarm64ビルドを選べます。アーキテクチャを確認できない場合は汎用ビルドを使用してください。サブスクリプション登録後、システムの接続確認画面でネットワーク制御権限を許可し、バッテリー最適化設定に応じてバックグラウンド動作の制限を調整します。
AndroidのダウンロードへLinuxデスクトップでは v2rayN を使用します。ディストリビューションのパッケージ体系に合わせてdebまたはrpmを選び、x64とarm64のアーキテクチャも確認してください。GUIクライアントはサブスクリプション、サーバー一覧、ルーティング設定を管理しますが、システムトレイやデスクトップ環境によって動作に多少の違いがあります。システムプロキシを有効にする前に、デスクトップ環境が参照するプロキシの設定元を確認し、一つの設定層だけを変更してしまう事態を避けてください。
Linuxのダウンロードへクライアントのインターフェースとネットワークカーネルは、それぞれ異なる役割を担います。この関係を理解すると、プロトコル機能がどこから提供されるのか、設定ミスをどの層で調べるべきか、クライアントによって機能差が生じる理由を判断しやすくなります。
Project Vは、プロキシプロトコル、トランスポート方式、ルーティングルール、設定モデルを軸とするオープンな技術エコシステムを形成しています。特定のGUIの名称でも、単一のネットワークカーネルそのものでもありません。クライアントで表示されるサーバー一覧、サブスクリプショングループ、システムプロキシのスイッチ、ログ画面はインターフェース層に属します。一方、接続確立、プロトコルハンドシェイク、データ転送、ルール照合を実行するのは下位のカーネルです。
この階層構造により、インターフェース開発とプロトコル実装は個別に進化できます。GUIクライアントはプラットフォーム対応、設定管理、操作手順を改善し、カーネルプロジェクトはプロトコル互換性、トランスポートの詳細、DNSの動作、ルーティング処理を継続的に扱います。問題が起きたときは、サブスクリプションデータ、クライアントUI、OSによる制御、カーネル接続層のどこに原因があるかを先に判断する方が、ノードを何度も切り替えるより効果的です。
V2FlyはV2Rayの設定モデルとプロトコルエコシステムを引き継ぎ、プロキシのインバウンド、アウトバウンド、トランスポート、DNS、ルーティングなどの基盤モジュールを主にカバーします。v2flyNGはこのカーネル系統を採用し、Android向けの代替クライアントとして利用できます。選択時はクライアント名だけで互換性を判断せず、サーバー側で実際に使われているプロトコルとパラメータを基準にしてください。
XrayはProject Vエコシステムと多くの設定概念を共有しながら、VLESS、REALITY、XTLS Visionなどの機能を発展させています。v2rayNとv2rayNGはXray設定の管理によく使われます。GUIは複雑な項目をフォームに整理しますが、最終的に反映されるのはプロトコル、セキュリティ層、トランスポート、ルーティングパラメータの組み合わせです。そのため、サーバー側とクライアント側の設定を一致させる必要があります。
v2rayN、v2rayNG、v2flyNGはいずれもオープンソースとして開発・保守されており、各クライアントは明示されたオープンソースライセンスに従って公開されています。オープンな開発方式により、UIのロジック、設定処理、カーネル呼び出しの関係を継続的に確認できます。また、各プラットフォームが同じプロトコル概念をもとに、それぞれの操作方法を発展させることも可能です。利用時は、クライアントのライセンス、カーネルのライセンス、サードパーティコンポーネントのライセンスを区別してください。
クライアントの更新には通常、UIの変更、プラットフォーム互換性への対応、設定構造の適応、カーネル呼び出しの変更が含まれます。サブスクリプションの内容はサービス提供者が管理するため、クライアントを更新してもサーバー側のパラメータは自動修正されません。端末を移行する際は、サブスクリプションの提供元、手動で追加したルーティングルール、DNS方式、ローカル設定を優先的に保存し、新しいプラットフォームで権限とシステムプロキシの状態を再確認してください。端末内の設定がすべてそのまま再利用できるとは限りません。
実際の画面、接続経路、高度な設定を中心にまとめた特集記事です。各記事は一つの明確な問題に焦点を当て、再利用できる判断手順とパラメータの背景を解説します。
FakeDNSが予約アドレス範囲を使って実際の名前解決結果を置き換える処理を解説します。TUN、ドメインスニッフィング、ルール照合との関係を整理し、有効化に適した場面と無効化が必要な典型例を紹介します。
記事を読む →メインウィンドウの実際の情報構成に沿って、サーバー一覧の項目、サブスクリプショングループ管理、ログペイン、主要設定への入口を解説します。初めてインストールしたユーザーが画面の全体像を把握してから、設定の登録を始められるようにします。
記事を読む →端末の時刻、サブスクリプションの状態、ポートの使用状況、プロトコルパラメータから確認を始め、システムプロキシとログのキーワードを順に調べます。手順を固定することで、設定を繰り返し変更して新たな問題を招くのを防げます。
記事を読む →