Windows
v2rayN でサブスクリプション、システムプロキシ、ルーティングルール、TUN を管理できます。ダウンロードページには新しいデスクトップUIと従来の WPF 版を用意しているため、システム環境や使い方に合わせて選択できます。
ダウンロードするデスクトップ・Android クライアント、サブスクリプションのインポート手順、VMess、VLESS、REALITY の設定方法をまとめています。プラットフォーム別の入口から進み、システムプロキシとルーティングを設定できます。
主な機能
クライアントは、サブスクリプション、プロキシプロトコル、システム接続、振り分けルールをまとめて管理します。各レイヤーの役割を理解してから設定を調整すると、ノードを何度も切り替えるより問題を特定しやすくなります。
VMess と VLESS は主にクライアントとサーバー間の認証および接続構造を表します。TCP、WebSocket、gRPC などはトランスポート層に属し、TLS や REALITY はセキュリティ層に位置します。クライアントの画面ではこれらが同じ編集フォームに並ぶことがありますが、自由に置き換えられるものではありません。サブスクリプションをインポートしたら、通常は提供元のプロトコル、アドレス、ポート、トランスポート方式、セキュリティ設定を維持し、ローカルで変更できるシステムプロキシとルーティングモードだけを選択します。
手動で確認するときは、「プロトコルの種類—トランスポート方式—セキュリティ層—追加識別子」の順に点検するとよいでしょう。サブスクリプションの内容が不完全なのか、ローカルの接続入口が有効になっていないのかを素早く切り分けられます。VLESS は特定のトランスポート方式を意味するものではなく、REALITY も単独のクライアントではありません。このレイヤー構造を理解すれば、名前だけを変更して関連パラメータを見落とす事態を防げます。
ルーティングルールは、接続をプロキシ経由にするか、直接接続するか、遮断するかを決めます。ドメイン、宛先アドレス、ポート、ネットワーク種別などを条件にでき、クライアント内の並び順に従って適用されます。普段の利用では、最初から長大なルールセットを作る必要はありません。まずクライアントの基本モードでウェブサイトやアプリが正常に接続できることを確認し、必要なドメインだけをカスタムルールに追加すると、変更範囲を把握しやすくなります。
振り分けの異常は、一部のウェブサイトだけ利用できない、一部のアプリだけ接続できない、またはシステムプロキシを有効にするとローカルサービスに影響が出る、といった形で現れます。調査時はまずシンプルなモードに切り替えて比較し、ドメイン解決の方式とルールの優先順位を確認します。ルーティングが解決するのは「接続がどこから外へ出るか」であり、プロトコルパラメータの代わりになるものでも、ノード自体の回線品質を改善するものでもありません。両者を分けて考えると、効果のない調整を減らせます。
システムプロキシは、OSのプロキシ設定に従うブラウザやデスクトップアプリに適しています。クライアントがローカルでプロキシポートを待ち受け、システム設定をそのポートへ向けます。TUN モードは仮想ネットワークインターフェースを通じて、より広い範囲の接続を処理します。システムプロキシ設定を読み取らないプログラムにも適しています。両者は対象範囲が異なるため、動作させるのに同時有効化は必要ありません。実際に使うアプリに応じて、主な入口を一つ選びます。
初回設定では、まずシステムプロキシを使ってサブスクリプションとノードが有効か確認し、その後で TUN が必要か判断するのがおすすめです。TUN を有効にする前に、同種のネットワークツールを終了し、権限の確認、DNS の処理方式、LAN へのアクセス要件を確認してください。クライアントを終了するときは、システムプロキシが元に戻っていることも確認します。接続がループしたり、すべてのアプリがオフラインになったりした場合は、すぐにリモート側のプロトコルを変更するのではなく、複数のプログラムが同時に通信を処理していないかを優先して確認します。
サブスクリプションURLは、ノードと接続パラメータの一覧を取得するために使います。インポートするとクライアントがノード一覧をローカルに保存し、手動または定期更新の際に内容を再取得します。ノード名、サーバーアドレス、プロトコルパラメータは通常サブスクリプション側で管理されます。一方、ルーティングモード、ローカルの待受ポート、起動動作、画面設定はクライアント側の項目です。両者を区別しておけば、更新時にローカル設定まで上書きされたと誤解しにくくなります。
サブスクリプションの更新に失敗したら、まずURLが最初から最後まで正しくコピーされているか、システム時刻が正確か、現在のネットワークから配信元へアクセスできるかを確認します。更新に成功したのに一覧が空の場合は、返された形式が使用中のクライアントに対応していない可能性があります。手動で追加したノードを残す場合は、独立したグループに分け、サブスクリプションの内容と混在させないようにします。クライアントを変更する前に、ローカルのルーティングとポート設定を記録し、新しいクライアントが対応する方法で再インポートしてください。
プラットフォーム
デスクトップでは v2rayN を使用し、Android では Xray と V2Fly のカーネルを採用したクライアントから選べます。ダウンロードページでは、プロセッサアーキテクチャとパッケージ形式も分けて案内しています。
v2rayN でサブスクリプション、システムプロキシ、ルーティングルール、TUN を管理できます。ダウンロードページには新しいデスクトップUIと従来の WPF 版を用意しているため、システム環境や使い方に合わせて選択できます。
ダウンロードするv2rayN デスクトップ版はクロスプラットフォームUIを採用し、同じアプリでノード、サブスクリプション、ローカルプロキシを管理できます。ダウンロード前に、デバイスのプロセッサが Apple Silicon か Intel かを確認してください。
ダウンロードするv2rayNG は Xray カーネルを使用し、VLESS や REALITY などの機能が必要な設定に適しています。v2flyNG は V2Fly カーネルを使用する、対応エコシステム向けの選択肢です。ダウンロードページでは arm64 とユニバーサルパッケージを提供しています。
ダウンロードするv2rayN デスクトップ版は、一般的な Linux デスクトップ環境に対応しています。ダウンロードページでは deb、rpm、プロセッサアーキテクチャ別に入口を用意しており、GUIでサブスクリプションとルーティングを管理したいユーザーに適しています。
ダウンロードするクイックスタート
初回は設定をシンプルに保ちましょう。再現可能な接続手順を確立してから、自動起動、TUN、カスタムルーティングを調整します。
Windows、macOS、Linux では v2rayN を選択します。Android ではまず v2rayNG を確認し、カーネルの要件に応じて v2flyNG も選べます。デスクトップのインストーラーはOSとプロセッサアーキテクチャに対応したものを選び、Android端末では arm64 とユニバーサルパッケージから選択します。インストール後はクライアントを正常に起動し、メイン画面、トレイの入口、またはシステムステータス領域が利用できることを確認してから、設定をインポートしてください。
サブスクリプション管理でURLを追加し、保存後に手動更新を一度実行します。ノードが表示されたら、プロトコル、トランスポート方式、セキュリティ層のパラメータはすぐに変更しないでください。通常、これらはサブスクリプションに設定されています。ノードを一つ選んで接続をテストし、クライアントのログにアドレス解決、認証、タイムアウトのメッセージが出ていないか確認します。一覧が空の場合は、プロキシモードを何度も切り替える前に、サブスクリプションURLとシステム時刻を確認します。
デスクトップではまずシステムプロキシを有効にし、モバイルではOSの案内に従って接続を確立します。ブラウザと普段使うアプリを開いて確認し、国内サイト、LAN機器、業務ソフトが想定どおり動作するかも確認してください。基本接続が安定してから、TUN、自動起動、定期的なサブスクリプション更新、カスタムルーティングを使うか判断します。一度に変更する設定は一種類に絞ると、どのレイヤーが原因か特定しやすくなります。
オープンソースエコシステム
クライアント、カーネル、プロトコルはそれぞれ異なるレイヤーに属します。相互の関係を理解すると、アプリを選びやすくなり、トラブル対処も具体的なコンポーネントに戻って行えます。
プロキシプロトコル、トランスポート方式、ルーティング機能、クライアントツールを中心に形成されたオープンソースの技術エコシステムです。
VMess、VLESS、ルーティング、複数のトランスポート方式を維持しており、関連する設定概念は多くのクライアントで引き続き採用されています。
近い設定体系を基盤に、新しいプロトコルの組み合わせやトランスポート特性を継続的に追加しており、v2rayN や v2rayNG と併用されることが多くあります。
V2Ray は当初、Project V 体系の中核コンポーネントとして広く知られるようになりました。その後、コミュニティでの保守方針が徐々に分かれ、V2Fly と Xray という二つの主要なカーネル系統が形成されました。現在「V2Ray クライアント」と呼ばれるものは、通常、単一のプログラムではなく、これらのカーネル、サブスクリプション、プロトコル設定を管理できるGUIアプリを指します。v2rayN、v2rayNG、v2flyNG はいずれもクライアント層に位置し、画面、設定管理、システム連携を担当します。実際に接続とルーティングを処理するのは、内部で使用されるコアです。
このレイヤー構造があるため、異なるクライアントに似たプロトコル項目が表示されます。VMess、VLESS、トランスポート方式、TLS、REALITY、ルーティングルールはカーネルの設定体系に由来し、クライアントはデスクトップやモバイル端末に適した形で表示しているだけです。接続問題が起きたら、クライアントの画面、システム権限、コアの起動、サブスクリプション内容、リモート接続のどこに問題があるかを先に判断し、アプリ名だけで原因を推測しないでください。
V2Fly と Xray は似た設定概念を数多く受け継いでいるため、基本的な VMess、VLESS、アウトバウンド、インバウンド、ルーティングルールには高い共通理解があります。ただし、機能範囲と具体的な項目が常に一致するわけではありません。Xray で利用できるトランスポート機能が、同じ設定ファイルをそのまま V2Fly に渡して使えることを意味するわけではありません。サブスクリプション変換時に、クライアントが認識しないパラメータが省略される場合もあります。
カーネルを選ぶときは、サブスクリプションに実際に含まれるプロトコルとセキュリティ層を基準にするのが最も確実です。REALITY や特定の XTLS 構成が必要なら、通常は Xray カーネルを採用したクライアントを選びます。設定が明確に V2Fly 向けなら、対応するカーネルを使うのが直接的です。設定をより多く変更できるからといって、むやみに変換しないでください。画面に表示される項目数より、機能の適合性、ログの読みやすさ、更新の安定性が重要です。
これらのプロジェクトはオープンソースとしてコミュニティにより保守され、ソフトウェアの動作、設定構造、変更履歴を開発者が確認できます。オープンソースの価値は、技術的な過程を議論でき、実装を検証でき、異なるクライアントが近い設定形式を軸に連携できることにあります。ただし、ユーザー自身による設定判断に代わるものではありません。サブスクリプションの提供元、サーバー側の構成、システム環境、ローカルルーティングは、接続結果に直接影響します。
クライアントは無料で利用でき、プロトコルとカーネルのドキュメントもコミュニティによって長期的に蓄積されています。一般ユーザーは、安定したクライアントの入口から始め、アプリとコアを同じ保守系列にそろえ、異常があればログを読み、対応するプロトコルの説明を確認するのが現実的です。開発者にとっては、明確な設定モデルとレビュー可能な実装が互換性の差異の特定に役立ち、問題を適切なコンポーネントへ正確に報告しやすくします。
v2rayN は Windows、macOS、Linux のデスクトップ環境向けで、サブスクリプション、ノード、コア、システムプロキシ、ルーティングを一元管理します。v2rayNG は Android 向けで、Xray カーネルの機能を主軸とします。v2flyNG も Android 向けですが、V2Fly カーネルのエコシステムに対応します。三者は異なるプラットフォームやカーネルの選択に対応するもので、同じ端末で同種のクライアントを複数同時に動かす必要はありません。
クライアントの更新とカーネルの更新は、異なるペースで行われる場合があります。画面機能、システム互換性、インストール方法はクライアントの保守範囲です。一方、プロトコル対応、トランスポート実装、ルーティング動作は主にカーネルに依存します。更新後に違いが出た場合は、まずどのレイヤーに変化があったかを確認し、設定の移行状況を調べてください。サブスクリプションURL、よく使うルーティング方針、ローカルポートを記録しておくと、クライアント移行を整理して進められます。
技術ノート
接続構造と操作手順から、よくある問題を解説します。プロトコルの仕組み、クライアント設定、トラブル対処を中心に扱います。
TLS ハンドシェイクのレイヤーから REALITY の接続方式を理解し、XTLS Vision が転送経路で重複処理を減らす仕組みと、この構成が適する接続条件を解説します。
記事を読む動作環境の準備、初回起動時の確認、システムプロキシとポート設定を解説し、コアの通知、自動起動、ブラウザ接続の異常に対処する順序も説明します。
記事を読む速度の問題を、ノードの応答、回線の時間帯、ローカル設定の三つに分け、遅延結果、プロトコル変更、Mux、振り分けルールから分かることを解説します。
記事を読むよくある質問
初回接続の問題の多くは、サブスクリプション内容、システム時刻、ローカルの接続入口、ノードの状態、ルーティングルールの順に確認すると特定できます。
Windows、macOS、Linux のデスクトップ環境では v2rayN、Android では v2rayNG を選びます。画面やシステム連携の方法は異なりますが、どちらもサブスクリプション、ノード、プロキシプロトコル、ルーティングルールを中心に動作します。デスクトップ用クライアントのインストーラーをモバイル端末で使ったり、一方のプラットフォーム向けガイドを別の環境へそのまま当てはめたりしないでください。
まず手動更新を一度実行し、サブスクリプションURLが最初から最後まで完全にコピーされているか確認します。次に、システムの日付、時刻、タイムゾーンを確認してください。更新時にエラーが出ないのに一覧が空の場合は、返された内容が現在のクライアントの対応するサブスクリプション形式か確認します。URLを再登録する前に、両端に意図せず入った空白を削除してみてください。
システムプロキシは、主にOSのプロキシ設定を読み取るアプリに影響し、設定が簡単で初回確認に適しています。TUN は仮想ネットワークインターフェースを通じてより広い範囲の接続を引き受けますが、システム権限、DNS設定、ほかのネットワークツールの状態に左右されやすくなります。まずシステムプロキシでノードが有効か確認し、アプリの要件に応じて TUN を有効にするか判断してください。
遅延結果が示すのは、特定の探測方法に対して応答があったということだけで、ウェブページへの完全な接続成功を意味しません。現在のノードが選択されているか、システムプロキシが有効か、ブラウザが独自のプロキシを使っていないか、DNSが正しく解決できるか、ルーティングルールが対象接続を想定した出口へ送っているかを続けて確認します。詳しい手順はクイックスタートガイドをご覧ください。