Windows
v2rayNのデスクトップ版または従来のWPF版を使用できます。デスクトップ版はクロスプラットフォームUIで、新しい環境に適しています。WPF版は従来の操作構成を引き継ぎ、トレイメニュー、サーバー一覧、システムプロキシの入口がまとまっています。
デスクトップとAndroidクライアントの資料
v2rayN クライアントのダウンロード、サブスクリプションのインポート、ルーティングをまとめて解説。デスクトップとAndroidに対応し、設定名は各クライアントの画面表記に合わせています。
デスクトップではv2rayNを使い始め、Androidではコアの種類に応じてv2rayNGまたはv2flyNGを選択します。入口から、ダウンロードページの該当プラットフォームタブを開けます。
v2rayNのデスクトップ版または従来のWPF版を使用できます。デスクトップ版はクロスプラットフォームUIで、新しい環境に適しています。WPF版は従来の操作構成を引き継ぎ、トレイメニュー、サーバー一覧、システムプロキシの入口がまとまっています。
v2rayNのデスクトップクライアントを使用します。ダウンロード前にシステム情報でプロセッサーの種類を確認し、Apple SiliconまたはIntelのインストーラーを選択してください。初回起動後は、システムの案内に従ってアプリの確認とネットワーク権限を設定します。
Xrayコアを採用するv2rayNGを第一候補にします。V2Flyコアが必要な場合はv2flyNGを使用できます。近年の多くの端末ではarm64版が適しています。アーキテクチャを確認できない場合は汎用版を選択してください。
v2rayNのデスクトップクライアントを使用します。Debian、Ubuntuなどではdeb、Fedora、RHEL系ではrpmを選択し、端末のプロセッサーに合わせてx64またはarm64も確認してください。
機能一覧は、実際の設定手順に沿って構成しています。左側の項目を選ぶと、用途、操作範囲、対応する設定項目を確認できます。
サブスクリプションはサーバー設定をまとめて読み込み、複数のノードを切り替えるのに便利です。インポート時はリンクの入手元とグループ名を確認してから更新を実行し、クライアントに最新の内容を読み込ませます。更新後、サーバー一覧は購読元の名称に従って該当グループに登録されます。既存の手動設定は通常、そのまま個別に保持できます。インポート後に一覧が空の場合は、選択したグループとリンクの完全性を確認してください。システムプロキシを何度も切り替える必要はありません。
v2rayNでは定期更新の間隔を設定でき、グループ単位で手動更新することもできます。同じサブスクリプションを複数の端末で使う場合も、各クライアントで個別に更新が必要です。サブスクリプション自体が、クライアントのルーティングモード、システムプロキシの状態、画面設定を直接同期するわけではありません。サーバー設定とローカルポリシーを分けて管理できるため、一方を変更しても他方が上書きされません。
システムプロキシは、OSのプロキシ設定に従うアプリが現在のクライアントを経由するかを制御します。自動設定は、ブラウザーやシステムプロキシに対応するデスクトップアプリに適しています。有効にすると、クライアントがローカルのプロキシアドレスを書き込みます。無効にする際はシステムプロキシの状態も解除し、停止したポートをアプリが参照し続けないようにしてください。一部のプログラムは独自のネットワークスタックを使用してシステムプロキシを読み取らないため、プログラム側のプロキシ設定、またはクライアントが提供する別の取り込み方法を確認します。
ノードへの接続とシステムプロキシの有効化は別の操作です。前者はコアに利用可能な出力経路を確立させ、後者はシステムの通信をその出力経路へ送るかを決めます。切り分けでは、現在のサーバーが有効か、コアが正常に動作しているか、システムプロキシが切り替わっているかを順番に確認してください。個別に確認する方が、クライアントを何度も再起動するより原因を特定しやすくなります。
ルーティングルールは、コアに入ったリクエストを直接接続、プロキシ経由、またはブロックのどれにするか決定します。一般的なプリセットは、ドメイン、アドレス範囲、LAN内の宛先などで判定します。たとえば「LANと中国本土をバイパス」モードは、ローカル機器へのアクセスを維持し、プロキシ不要の接続を減らすのに適しています。ルールの判定は通信がクライアントに入った後に行われるため、ルーティングモードはシステムプロキシやTUNなどの通信入口の代わりにはなりません。両方を個別に設定してください。
カスタムルールは、範囲が明確な条件から組み立てます。まずLAN、特定ドメイン、アプリの要件を処理し、その後にデフォルトの出力先を設定します。ルールの順序は最終的な判定結果に影響するため、変更後は現在のノードに再接続し、対象サイトへ実際にアクセスして確認してください。ルールが多い場合は、いったんプリセットモードに戻し、原因がノード側かカスタム条件側かを切り分けます。
GUIクライアントは画面、サブスクリプション、システム連携を担当し、実際のプロトコル接続はコアが処理します。XrayとV2FlyはProject V関連エコシステムから派生しており、基本設定の考え方は近いものの、拡張機能とプロトコル対応は完全には一致しません。VLESS、REALITY、XTLS Visionなどを使う設定では、サーバー側の要件とクライアントのコア機能を確認してください。通常のVMess、VLESS、Trojanでも、トランスポート層のパラメーターを一致させる必要があります。
v2rayNはデスクトップ環境で複数のコア設定を管理できます。v2rayNGは主にXrayコア、v2flyNGはV2Flyコアを採用します。選択の基準はクライアント名ではなく、ノードのプロトコルとトランスポートパラメーターです。設定をインポートできても接続できない場合は、まずプロトコル、アドレス、ポート、トランスポート方式、安全設定を照合し、その後にコアが対象の拡張機能に対応しているか確認します。
ICMP ping、実接続の遅延、ダウンロード速度は、それぞれ異なる段階を測定します。pingは主にサーバーのネットワークインターフェースまでの往復時間を確認するもので、プロキシのハンドシェイク全体は含みません。実接続の遅延はプロトコルとトランスポートの確立を経るため、ページを開く前の待ち時間に近い指標です。ダウンロード速度は継続的なスループットを測り、サーバー負荷、中継回線、ローカルネットワークの状態に左右されます。3つの結果が一致しないのは珍しくなく、単一の数値だけで設定の品質を判断することはできません。
接続に失敗した場合は、まずクライアントのログでドメイン解決とプロトコルのハンドシェイクが完了しているか確認し、次にローカルポートが他のプログラムに使用されていないか調べます。速度が遅い場合は、ノード、中継回線、ローカル設定の3層で比較します。同じ対象に別のノードで接続し、時間帯を変えて混雑を確認し、最後にルーティング、コア、同時接続関連の設定を調べます。一度に1項目だけ変更すると、結果を再現しやすくなります。
クライアント、コア、プロトコルはそれぞれ異なる層にあります。3者の関係を理解すると、適切なインストーラーを選び、設定の互換性を判断し、更新後の変化の原因をすばやく特定できます。
Project Vは、設定駆動型のネットワークプロキシコアを中心とする技術エコシステムを形成しました。V2Rayのインバウンド、アウトバウンド、ルーティング、トランスポート層という考え方は、後続のクライアントに共通の設定基盤を提供しています。GUIクライアントがプロトコルを再定義するのではなく、JSON設定、サブスクリプション、システムプロキシ、プロセス管理を操作可能な画面に変換します。サーバー一覧でノードを切り替えると、選択項目に基づいてコアが読み込める実行設定を生成します。
V2FlyはV2Rayコアのコミュニティによる保守方針を引き継ぎ、汎用プロトコルとモジュール式設定を重視しています。Xrayは近い設定体系を基盤に独自の拡張機能を発展させ、XTLSやREALITYに関連する実装も含まれます。両者には多くの共通概念がありますが、機能の追加時期、パラメーター名、互換性の範囲は異なる場合があります。設定提供元が特定のコアを指定している場合は、その要件に従い、すべての拡張機能を相互利用できると考えないでください。
VMess、VLESS、Trojanはプロキシプロトコルの名称です。WebSocket、gRPC、TCPなどはトランスポート方式、TLSやREALITYなどは各層の安全性とハンドシェイクを担う設定です。サブスクリプションは設定を配布する形式にすぎず、プロトコル自体を変えるものではありません。これらの項目を層ごとに確認すれば、「サブスクリプションの更新失敗」「コアの非互換」「ルーティングが反映されない」といった問題を混同せずに済みます。
関連プロジェクトはオープンソース方式で保守され、コード変更、バグ修正、プロトコル実装はそれぞれのコミュニティによって継続的に進められています。オープンソースライセンスはコードの利用、変更、再配布の範囲を定め、異なるGUIクライアントが同じコア体系を基盤に画面やシステム連携を提供できるようにします。クライアントの更新には、画面変更、サブスクリプション解析、プラットフォーム対応、コア管理の変更などが含まれます。コアの更新は、プロトコル対応や接続動作により直接影響します。
実際の保守では、クライアントとコアが同時にリリースされるとは限りません。更新後に挙動が変わった場合は、まず変化がクライアントの画面、サブスクリプションの内容、基盤コアのどこで起きたかを確認し、そのうえで設定の見直しや構成変更を行います。現在使えるサブスクリプションの入手元とルーティング方針を記録しておくと、複数端末への移行時に同じ接続条件を再現しやすくなります。
Windows、macOS、Linux向けのGUIクライアントです。サブスクリプショングループ、サーバー切り替え、システムプロキシ、ルーティングルール、ログ確認、コア管理に対応します。デスクトップ設定を1つのワークスペースに集約でき、複数のサブスクリプション、手動ノード、カスタムルーティングを管理する環境に適しています。
Android向けのGUIクライアントで、主な実行コンポーネントにXrayコアを採用しています。サブスクリプションリンク、クリップボードの内容、QRコードから設定をインポートでき、システムのVPNサービスを通じて端末の通信を取り込みます。Xrayの拡張プロトコルと関連するトランスポートパラメーターを使う設定に適しています。
Android向けのV2Flyコアクライアントです。操作画面は一般的なAndroidプロキシクライアントに近く、V2Flyコアを明示的に要求する設定で利用できます。コアの種類で選ぶ際の候補になりますが、インポート前にプロトコル、トランスポート方式、安全設定を確認してください。
インストール、コア、速度テスト、複数端末の管理を扱い、設定同士の因果関係を重点的に解説します。
ノード自体、中継回線、ローカル設定の3層からボトルネックを特定します。ノードの変更、時間帯をずらした比較、ルーティングとコア設定の個別確認により、複数の変数を同時に変更して原因が分からなくなる事態を避けます。
記事を読むサブスクリプションの一元管理、設定ファイルの受け渡し、QRコード共有の3方式を比較し、デスクトップのv2rayNとAndroidクライアント間で同期できる項目と、端末ごとに設定が必要な項目を解説します。
記事を読む3種類のテストが確認するネットワーク区間を解説します。短い往復時間が高スループットを意味せず、プロキシのハンドシェイク成功も保証しない理由を説明し、問題の種類に応じたテスト方法の選び方を示します。
記事を読むまずクライアントをインストールしてサブスクリプションをインポートし、現在のサーバーを選択します。最後にシステムプロキシを有効化してアクセスを確認してください。問題が起きたら、ログに記録された時刻とエラー段階を残し、ガイドの手順に沿って確認します。