DESKTOP · V2RAYN
Windows
デスクトップ版と従来のWPF版を用意しています。新規インストールでは、まずクロスプラットフォームのデスクトップ版を選ぶとよいでしょう。従来のウィンドウ構成やサーバー一覧、トレイメニューに慣れている場合は、クラシック版も確認できます。インストール前にシステムのアーキテクチャを確認し、クライアント設定フォルダーの読み書き権限を確保してください。
ダウンロードへ進むV2RAY CLIENTS · CONFIGURATION GUIDE
Windows、macOS、Android、Linux向けのクライアントと設定ドキュメントを案内し、サブスクリプションのインポート、システムプロキシ、TUNモード、ルーティングルールの実際の操作をまとめています。
PLATFORM ENTRY
ダウンロードページでは、プラットフォーム別に利用可能なクライアント、パッケージ形式、選び方を案内しています。デスクトップでは v2rayN を使用し、Androidでは必要なカーネルに応じて v2rayNG または v2flyNG を選択できます。
DESKTOP · V2RAYN
デスクトップ版と従来のWPF版を用意しています。新規インストールでは、まずクロスプラットフォームのデスクトップ版を選ぶとよいでしょう。従来のウィンドウ構成やサーバー一覧、トレイメニューに慣れている場合は、クラシック版も確認できます。インストール前にシステムのアーキテクチャを確認し、クライアント設定フォルダーの読み書き権限を確保してください。
ダウンロードへ進むDESKTOP · V2RAYN
インストールパッケージはApple SiliconとIntelプロセッサー別に分かれています。システム情報でチップ名を確認してから、該当する入口へ進んでください。初回起動時は、システムの案内に従ってネットワーク設定の権限を許可する必要があります。サブスクリプションのインポートや使用するサーバーの選択手順は、他のデスクトップ環境と同じです。
ダウンロードへ進むMOBILE · V2RAYNG / V2FLYNG
v2rayNGはXrayカーネルを使用し、一般的なプロトコルやルーティング設定に適しています。v2flyNGはV2Flyカーネルを使用する別の選択肢です。近年の多くの端末ではarm64パッケージを利用できます。アーキテクチャが不明な場合は、ユニバーサルパッケージを確認してください。接続時には、システムにネットワーク接続の許可が表示されます。
ダウンロードへ進むDESKTOP · V2RAYN
v2rayNでは、主要なディストリビューションのパッケージ管理に対応したインストールパッケージを提供しています。Debian・Ubuntu系は通常deb、Fedora・RHEL系は通常rpmを選びます。x64とarm64もプロセッサーのアーキテクチャに合わせて選択してください。インストール後はデスクトップメニューから起動し、サブスクリプションとプロキシモードを設定します。
ダウンロードへ進むLINK INSPECTION
設定の取得元から出口の検証まで、各段階を順番に確認します。左側で現在の段階を選ぶと、右側にその段階で解決する問題、操作場所、確認すべきパラメータが表示されます。
SOURCE / UPDATE
サブスクリプションURLはクライアントが生成するものではなく、設定の提供元から渡されるサーバー情報です。正しいグループにURLを追加して更新すると、クライアントがプロトコル、アドレス、ポート、トランスポート、セキュリティの各パラメータを解析し、選択可能なサーバー一覧を作成します。更新後は、グループ名とノード数が変化しているかを確認してから、使用するサーバーを選択してください。一覧が空の場合は、URLの欠落、グループの選択ミス、更新ログを確認します。プロキシモードを何度も切り替えるだけでは解決しません。
複数のサブスクリプションを使う場合は、提供元ごとにグループを作成し、分かりやすいメモを付けることをおすすめします。個別に更新、絞り込み、並べ替えができ、同名サーバーが一つの一覧に混在するのを防げます。サブスクリプションの内容が変わっても、ユーザーが作成したローカル設定が自動で置き換わるわけではありません。手動項目とリモート項目は分けて管理してください。
source: subscription · action: update · result: server list
INBOUND / SYSTEM
システムプロキシモードでは、OSのプロキシアドレスをクライアントのローカル待受ポートへ向けます。ブラウザーや、システム設定に従う大半のデスクトップアプリは、それに従って通信を送信します。動作範囲が明確で、オン・オフも簡単なため、初回接続時の基本設定に適しています。クライアントが起動中なのにアプリが直接接続する場合は、システムプロキシが実際に有効か、アプリが独自のプロキシ設定を使っていないか、ローカル待受ポートを他のプログラムが使用していないかを確認してください。
クライアントを終了する前にシステムプロキシを元に戻すと、OSに無効になったローカルアドレスが残るのを防げます。一部のコマンドラインツールはシステムプロキシを読み取らないため、環境変数を個別に設定するか、TUNへ切り替える必要があります。これはサーバー障害ではなく、アプリごとに接続経路が異なるためです。
inbound: local socks/http · scope: system-aware applications
VIRTUAL INTERFACE / ROUTE
TUNは仮想ネットワークインターフェースで通信を受け取り、ゲームランチャー、コマンドラインプログラム、システムプロキシ設定に従わないアプリにも適用できます。システムプロキシより対象範囲が広い一方、仮想NIC、ルーティングテーブル、DNS、権限の設定に依存します。有効にする前に、仮想ネットワークインターフェースを作成する他のツールを終了し、クライアントがネットワーク設定を変更するための権限を持っていることを確認してください。有効化後にLANへ接続できない場合は、まずプライベートアドレスを迂回するルールを確認します。
TUNを有効にしたからといって、すべての接続を同じ出口へ送る必要はありません。最終的に直接接続、プロキシ、ブロックのどれになるかは、ルーティングルールで決まります。切り分けでは、「通信がクライアントに入っているか」と「入った後にどのルールに一致したか」を分けて考えてください。
capture: virtual interface · decision: routing rules · dns: coordinated
RULESET / OUTBOUND
ルーティングルールは、ドメイン、アドレス、ポート、プロトコル、プロセスなどの条件に基づいて出口を選択します。一般的には、LANやローカルサービスを直接接続にし、特定の通信をプロキシへ送り、不要な接続をブロックします。ルールは通常、上から順に評価されるため、より具体的な条件を一般的な条件より前に置いてください。変更後はクライアントが接続済みかだけでなく、対象のリクエストが実際にどのルールへ一致したかも確認します。
プリセットルールは基本構成を作るのに便利ですが、継続して使うならdirect、proxy、blockという3種類の出口の意味を理解しておきましょう。ルールが多いほど正確になるわけではありません。重複条件、順序の競合、広すぎるマッチングは、かえって切り分けの負担を増やします。
match: domain / ip / port / process · outbound: direct / proxy / block
EVENT / DIAGNOSIS
ログは、問題がどこで止まっているかを判断する最初の手掛かりです。カーネルが起動しない場合は、まず設定の解析失敗、フィールド不足、ポートの競合を確認します。起動するものの接続を確立できない場合は、名前解決、TLSハンドシェイク、タイムアウト、ルーティング一致の情報を確認してください。エラーが発生した時刻と操作を記録すると、起動時の問題と特定の宛先へアクセスした時の問題を分けられます。複数の設定を一度に変更して、どれが効いたのか分からなくなる事態も避けられます。
切り分けは、ローカル待受、システム接続、ルール一致、リモート接続の順に進めます。変更は毎回一つだけにし、変更後は同じリクエストを再実行してください。闇雲に再インストールするより、この順序のほうが有効な設定を残しながら、実際の故障箇所を見つけやすくなります。
order: startup → inbound → dns → routing → outbound
QUICK START
初回設定は、正しいパッケージを選び、利用可能な設定をインポートし、システムプロキシで基本接続を一度確認するという簡単な流れにします。基本経路を確認してから、TUNや複雑なルーティングに進んでください。
Windows、macOS、Linuxでは v2rayN を使用します。Androidでは v2rayNG または v2flyNG を選択できます。ダウンロード前にプロセッサーのアーキテクチャとパッケージ形式を確認してください。デスクトップでは、現在のアカウントが設定フォルダーへ書き込めることと、クライアントがローカル待受ポートを作成できることも確認します。インストール後はまず通常どおり一度起動し、メイン画面が表示される前にファイアウォール、DNS、ルーティングを同時に変更しないでください。
サブスクリプション管理で完全なURLを入力し、提供元が分かるグループ名を設定して更新します。サーバー一覧が表示されたら、項目を一つ選んで使用中のサーバーに設定してください。この時点で、プロトコル、アドレス、ポート、トランスポートの各フィールドが正しく解析されているか確認します。サブスクリプションURLは設定を届け、クライアントはそれを読み込んで実行します。更新に失敗した場合は、カーネルが使えないと判断する前に、サブスクリプション操作のログを確認してください。
まずカーネルを起動し、次にシステムプロキシを有効にして、システムプロキシ設定に従うブラウザーからテストリクエストを送ります。アクセスできない場合は、ローカルポート、システムプロキシ、DNS、ルーティングルール、リモート接続の順に確認してください。基本モードで接続できた後、アプリの対応範囲に応じてTUNを有効にします。これにより、仮想NICの問題とサーバー設定の問題を分離し、相互干渉を減らせます。
OPEN ECOSYSTEM
クライアント、カーネル、設定の提供元は、それぞれ異なる3つの層です。境界を理解しておくと、更新、互換性、障害がどの層で発生したのかを正しく判断できます。
Project Vは、プロキシプロトコル、トランスポート方式、ルーティングルール、ローカルインバウンドを軸としたツールエコシステムを形成しました。グラフィカルクライアントはプロトコルそのものではありません。サブスクリプション、サーバー一覧、システムプロキシ、ルーティング、ログを操作しやすい画面にまとめ、生成した設定をカーネルへ渡して実行します。画面でサーバーを選択したりモードを切り替えたりすると、実際にはクライアントが設定を組み直し、カーネルプロセスを制御しています。
この区別は、切り分け方法に直結します。サブスクリプションを更新できない場合は、設定の提供元またはクライアントのネットワークリクエストに問題があることが多く、カーネル起動直後に終了する場合は、設定フィールド、ポート、実行環境が原因になりがちです。特定の宛先だけにアクセスできない場合は、DNS、ルーティングの一致、トランスポートパラメータ、リモート側の状態が関係している可能性が高くなります。すべてを「クライアントが壊れた」と決めつけると、本当の問題箇所を見失います。
V2FlyはProject Vエコシステムの中核実装と設定体系を受け継ぎ、Xrayは既存の概念との互換性を保ちながら、一部のプロトコル、トランスポート、基盤機能を拡張しています。どちらもインバウンド、アウトバウンド、ルーティング、DNS、ポリシーなどの構造で設定を組み立てますが、対応フィールドや動作は実装によって異なる場合があります。設定をインポートするときは、クライアントがサブスクリプションの内容を現在のカーネルが認識できる形式に変換します。
v2rayNはデスクトップ環境の関連カーネルと設定手順を管理できます。v2rayNGは主にXrayカーネルを採用し、v2flyNGはV2Flyカーネルに対応します。クライアントを選ぶ際は、グラフィカルインターフェースとカーネルを同一視しないことが大切です。画面は操作方法を、カーネルは設定の実行とプロトコル処理を、サブスクリプションはサーバーパラメータを担います。3つの層に互換性があって、初めて接続経路が正常に確立されます。
この3つのクライアントはいずれもオープンソースで保守されており、機能変更、設定形式の調整、問題修正はメンテナーとコミュニティによって継続的に進められています。オープンソースの実際の意義は、抽象的なラベルで安全性を判断するのではなく、実装や変更を技術コミュニティが確認、議論、再現できる点にあります。新しいビルドをインストールした後も変更内容を読み、設定フォルダー、カーネルの選択、権限要件、システムプロキシの動作に変更がないか確認してください。
クライアントの更新とサブスクリプションの更新は別のものです。クライアント更新ではプログラム本体と対応機能が変わり、サブスクリプション更新ではサーバー設定だけが更新されます。プロトコルフィールドを認識できない場合は、サブスクリプションの内容に誤りがあるのか、クライアントの解析能力が不足しているのか、現在のカーネルが該当パラメータに対応していないのかを判断する必要があります。層ごとに確認するほうが、すべての設定を頻繁に削除するより安全です。
COMMON QUESTIONS
初回利用時に混同しやすい設定の境界を、よくある質問としてまとめています。詳しい分類と切り分け手順はトラブル対処ページに掲載しています。
いいえ。v2rayNはグラフィカルクライアントで、サブスクリプション、サーバー一覧、プロキシモード、ルーティング、ログを管理します。カーネルは設定を解析し、実際の接続を処理します。クライアントは設定とプラットフォームに応じて適切なカーネルを呼び出すため、画面の起動に成功してもカーネルが正常に動作しているとは限りません。接続に問題がある場合は、メイン画面の状態とカーネルログを併せて確認してください。
サブスクリプションの更新は、リモート設定をサーバー一覧へ変換するだけで、現在どの項目を使うべきかを自動判断するものではありません。更新後は正しいグループから使用するサーバーを選び、カーネルを起動する必要があります。自動選択機能がある場合でも、まず一度は手動接続で設定が正常に動作することを確認してください。
初回設定では、接続範囲と問題の切り分けが分かりやすいシステムプロキシから始めることをおすすめします。ブラウザーなど一般的なアプリで接続できることを確認してから、コマンドラインツール、ゲーム、その他のアプリの必要に応じてTUNを有効にします。TUNでは仮想ネットワークインターフェース、ルーティング、DNSを使うため、問題が起きた場合は権限とネットワークインターフェースの競合を確認してください。
まず使用するサーバーを選択しているか確認し、次にシステムプロキシが有効か、ローカル待受ポートが存在するか、ブラウザーが独自のプロキシを使っていないかを確認します。その後、DNS、ルーティングの一致、リモート接続のログを確認してください。接続経路に沿って順番に確認すれば、リクエストがクライアントに入っていない場合、誤った出口が選ばれた場合、リモート接続に失敗した場合を区別できます。
TECHNICAL NOTES
操作上の問題ごとに記事を整理し、再現可能な確認手順、ログのキーワード、設定の境界を重点的にまとめています。
サブスクリプションURLの入手先、カーネルの役割、システムプロキシとTUNの違い、サーバー選択、トレイの状態など、初回利用時の疑問をまとめて解説し、それぞれの具体的な操作手順を示します。
記事を読む →ポートの競合、設定形式、フィールド不足、実行権限を確認し、カーネル起動直後に終了する問題をログの発生順に沿って特定する方法を解説します。
記事を読む →複数のサブスクリプションを併用する場合のグループ分け、キーワードフィルター、別名メモ、並べ替えを紹介し、提供元や用途の異なるサーバーを明確に整理します。
記事を読む →