デスクトップでは v2rayN、Androidの日常利用では Xray コアを搭載した v2rayNG が第一候補です。v2fly のノード環境を使っている、2種類のコアの動作を比較したい、または VMess 互換性を重視する場合は、v2flyNG を Android の候補に加えます。以下では、対応プラットフォーム、プロトコル、サブスクリプション、ルーティング、リソース使用量を順に判断します。
まずプラットフォームで絞り、プロトコル名から選び始めない
最も簡単な結論は、Windows、macOS、Linux などのデスクトップではまず v2rayN、Android では v2rayNG と v2flyNG から選ぶことです。3つは同じ画面を別バージョンにしたものではなく、異なるプラットフォームとコア系統を対象にした独立したクライアントです。
v2rayN 7.x はクロスプラットフォームのデスクトップ画面を採用しており、Windows、macOS、Linux でノード、サブスクリプション、システムプロキシ、ルーティングルールを管理できます。Windows ではデスクトップ版のビルド形式が異なる場合もありますが、いずれも v2rayN なので、画面の違いだけでノードのサブスクリプションを変更する必要はありません。
v2rayNG と v2flyNG はどちらも Android 向けです。単一ノードのリンクやサブスクリプションURLを読み込め、システムの VPN インターフェースを通じてアプリの通信を処理できます。主な違いは接続できるかどうかではなく、搭載コア、プロトコルの対応状況、ルーティングの細部、問題の切り分け方法にあります。
| クライアント | 対応プラットフォーム | 主なコア | おすすめの用途 |
|---|---|---|---|
| v2rayN 7.x | Windows、macOS、Linux | Xray、v2fly などのデスクトップコアを管理 | デスクトップの中心、サブスクリプション管理、ルール調整 |
| v2rayNG 1.10.x | Android | Xray | Androidの中心、VLESS、細かなルーティング |
| v2flyNG 1.9.x | Android | v2fly | VMess 互換、v2fly 設定の検証 |
コアの系統がプロトコル対応と設定の解釈を左右する
クライアントは画面、サブスクリプション、システム連携を担当し、VMess、VLESS、トランスポート層、ルーティングの処理を実際に行うのはコアです。v2rayNG は Xray、v2flyNG は v2fly をコアに採用しています。v2rayN は設定済みのコアを呼び出せるデスクトップ管理ツールに近く、対応できる運用方法がより幅広いのが特徴です。
サブスクリプションの中心が VLESS で、Reality や XTLS Vision などのパラメータを含む場合は、Xray 系を選ぶ方が手間が少なくなります。クライアントでいえば、デスクトップは v2rayN で Xray コアを選び、Android は v2rayNG を使う構成です。ノード共有リンクの重要な項目は省略せず、特にトランスポート方式、サービス名、サーバー名、フィンガープリントのパラメータを保持してください。
既存のノードが主に VMess と WebSocket、HTTP/2、TCP の組み合わせで、サーバー側が長く v2fly ベースなら、v2flyNG にも明確な用途があります。「サブスクリプションは正常なのに2つのコアで挙動が違う」といった問題の切り分けにも役立ちます。同じノードをそれぞれでテストすれば、コア設定、ルーティングルール、システムのネットワーク層のどこに原因があるか絞り込めます。
Xray コア系
おすすめVLESS、Reality、XTLS Vision に直接対応しやすく、現在主流のノード環境における標準的な選択肢です。
向いている用途：デスクトップの中心、Androidの中心、VLESS ノード
v2fly コア系
既存の VMess 設定、標準的なトランスポート構成、v2fly の動作を比較するトラブル対処環境に向いています。
向いている用途：VMess の旧設定、互換性比較、コアのテスト
複数コアを扱うデスクトップ管理
v2rayN はノードや設定に応じてコアを切り替えられ、ログ、ポート、ルーティングルールもまとめて確認しやすいクライアントです。
向いている用途：複数サブスクリプション、複数プロトコル、デスクトップでの調整
名前が似ていても設定をそのまま共用できるとは限らない
VMess の一般的な項目は2つのコアで比較的安定していますが、完全な JSON 設定をそのまま交換できるとは限りません。ルーティングオブジェクト、DNS オブジェクト、アウトバウンドのタグ、実験的機能には差がある場合があります。サブスクリプションURLは通常クライアントがローカル設定に変換するため、JSON 全体を手作業でコピーするより安全です。
- 共有リンクが1つだけなら、まずクライアントの「クリップボードからインポート」機能を使います。
- サービス提供者からサブスクリプションURLを受け取ったら、専用のサブスクリプショングループを作成し、サーバーアドレス欄に貼り付けないでください。
- 設定を手書きする場合は、まず対象コアを確認し、プロトコル項目とルーティングタグを照合します。
- ノードには接続できるのに通信できない場合は、サブスクリプションを何度も削除せず、まずコアのログを確認します。
サブスクリプション管理の違い：入口は異なるが処理の流れはほぼ同じ
3つのクライアントはいずれも、サブスクリプションURLを保存し、内容を取得し、ノードを解析してローカルグループに登録し、ユーザーが利用するノードを選ぶという流れです。使い勝手を左右するのは、URLそのものではなく、入口の場所、更新方法、失敗時の表示です。
v2rayN 7.x では、「サブスクリプショングループ」→「サブスクリプショングループ設定」からURLを追加できます。保存後、「サブスクリプショングループ」→「すべてのサブスクリプションを更新」でノードを取得します。現在のネットワークでは既存ノード経由でしか配信元にアクセスできない場合は、「プロキシ経由」の意味を持つ更新項目を選びます。更新後はグループ名、ノード数、最終更新時刻を確認してください。
v2rayNG 1.10.x では、メインメニューの「サブスクリプショングループ設定」を開き、右上の追加ボタンからメモとサブスクリプションURLを入力して保存します。ノード一覧に戻ったら「サブスクリプションを更新」を実行します。v2flyNG 1.9.x も近い手順ですが、メニュー名はマイナーバージョンによって変わる場合があります。追加と更新は引き続きサブスクリプション設定画面から行います。
- サブスクリプションURL全体をコピーし、先頭や末尾に空白や改行がないことを確認します。
- 「仕事用ノード」や「予備回線」など、見分けやすいメモをサブスクリプションに付けます。
- 初回更新後にノード数を記録します。たとえばサーバー側に12個表示されるなら、クライアントでも12件に解析されるはずです。
- ノードを1つ選んで遅延を測定してから接続を開始します。遅延テストの結果を実際のダウンロード速度と混同しないでください。
- サブスクリプションの更新に失敗した場合は元のグループを残し、更新方法と現在のネットワークを切り替えて確認します。同名グループを繰り返し作成するのは避けてください。
おすすめ構成：デスクトップとAndroidで同じサブスクリプションを使う
デスクトップ（v2rayN）
- まず Xray コアを使う
- サブスクリプショングループでノードを管理
- まずシステムプロキシを有効にしてブラウザーをテスト
Android（v2rayNG）
- 同じサブスクリプションURLをインポート
- 必要に応じてアプリごとのプロキシを有効化
- モバイルネットワークと Wi-Fi を分けてテスト
両方で同じサブスクリプションを使えばノード一覧は統一できますが、速度テストの結果、現在のノード、ルーティング設定は各デバイスに個別保存されます。
ルーティング：デスクトップはシステムプロキシ、Androidは適用範囲を確認
ルーティングで決めるのは、「どの通信を直接接続し、どの通信をノード経由にし、どの通信を拒否するか」です。同じサブスクリプションを3つのクライアントに読み込んでも、ノードのパラメータは一致しますが、ローカルのルールは自動同期されません。クライアントを替えるときは、ノード数だけでなくルールの考え方も個別に移行してください。
v2rayN では「設定」→「ルーティング設定」から始めるのが一般的です。日常利用では内蔵の基本ルールを使い、必要に応じてドメイン、IP、プロセス単位の項目を追加します。システムプロキシを有効にすると、プロキシ設定に従うデスクトップアプリがクライアントを経由します。より多くのアプリを対象にする場合は TUN を検討し、最初からシステムプロキシ、TUN、DNS、ファイアウォールを同時に変更しないでください。
Android では通常、システムの VPN インターフェースで通信を処理します。v2rayNG と v2flyNG では、アプリごとのプロキシ設定が重要です。指定したアプリだけをプロキシに通すことも、ローカルサービス、銀行アプリ、LAN 接続だけを許可するアプリを除外することもできます。方向を逆に設定すると、ブラウザーだけ使えて他のアプリがつながらない、またはすべてのアプリがノードを迂回するといった問題が起こります。
| 目的 | v2rayN の設定ポイント | Android の設定ポイント |
|---|---|---|
| まずブラウザーを接続 | コアを起動してシステムプロキシを有効化 | システム VPN を起動して通信を処理 |
| LAN を直接接続 | プライベートアドレスのルールをプロキシルールより前に置く | LAN バイパスのルールを残す |
| 指定アプリをプロキシ経由にする | プロセス単位または TUN ルールで処理 | アプリごとのプロキシ設定で対象アプリにチェックを入れる |
| ルールの適用状況を確認 | ルーティングとコアのログを確認 | 実行ログを確認し、カスタムルールを一時的に無効化 |
ポートも区別して設定する必要があります。手動テスト用の構成例では、ローカル SOCKS リスナーを 127.0.0.1:10808、HTTP リスナーを 127.0.0.1:10809 に設定できます。アプリでプロトコルやポートを間違えると、コアは正常に動作していても接続を確立できません。実際のポートは、クライアントの現在のパラメータ画面とログを確認してください。
デスクトップのトラブル対処手順
1. コアの状態：実行中
2. SOCKS の入口：127.0.0.1:10808
3. HTTP の入口：127.0.0.1:10809
4. システムプロキシ：有効
5. ルーティングルール：LAN の直接接続をプロキシルールより前に配置
6. ログ確認：ポート競合や設定の解析エラーがない機能とリソース使用量：差はネットワーク環境より小さいことが多い
クライアント選びでは速度測定のスクリーンショットだけを見ないでください。同じノードでも時間帯や接続ネットワークによる変動の方が、2つの Android クライアント自体の処理差より大きいことが一般的です。起動が安定するか、サブスクリプションが完全に読み込まれるか、ルールが意図どおり適用されるか、スリープ後に接続を復元できるかの方が参考になります。
この記事では再現可能な方法で観察しました。デスクトップには100個のノード、Androidには同じサブスクリプションを読み込み、他のダウンロードを停止してコアを10回連続起動します。その後、直接接続用ドメイン、プロキシ用ドメイン、LANアドレスへそれぞれアクセスします。テスト対象は v2rayN 7.x、v2rayNG 1.10.x、v2flyNG 1.9.x です。数値は規模感を示すもので、すべての端末に当てはまる固定値ではありません。
8コアのデスクトップ端末では、v2rayN が通常の VMess と VLESS ノード100件を解析するのに約0.7～1.1秒かかりました。メモリ8GBの Android 端末では、v2rayNG と v2flyNG の解析時間は約1.0～1.6秒でした。実際の差は1秒未満で、サブスクリプションサーバーの応答速度による影響の方がはるかに目立ちます。
端末の電池消費が明らかに増えたり、バックグラウンドで接続が切れたりする場合は、まずシステムのバックグラウンド制限、常時接続 VPN の設定、ネットワーク切り替えの挙動を確認します。クライアント名だけで電池消費を判断しないでください。詳細ログの継続出力、全ノードの頻繁な速度測定、多数の接続を長時間維持する処理は、いずれもプロセッサの復帰回数を増やします。
- 普段は必要なサブスクリプショングループだけを残し、重複したグループや期限切れのグループは無効にします。
- 300個のノードをすべて自動速度測定の対象にせず、まず地域や用途で範囲を絞ります。
- トラブル対処時は詳細ログを有効にし、解決後は通常のログレベルに戻します。
- Wi-Fi とモバイルネットワークを切り替えた後は、まず現在のノードが再接続を完了したことを確認します。
最終的な選び方：端末の役割ごとにシンプルなルールを作る
多くのユーザーは、デスクトップなら v2rayN、Android なら v2rayNG と覚えれば十分です。v2fly コアとの互換性、VMess の旧設定の検証、比較トラブル対処が必要な場合だけ v2flyNG を使います。これにより重複設定を減らし、どのコアのログなのかも把握しやすくなります。
デスクトップと Android で同じサブスクリプションを使う場合でも、両方の設定を完全に一致させる必要はありません。サブスクリプションはノードを届け、ローカルクライアントはシステム連携、DNS、ルーティングを担当します。デスクトップではシステムプロキシやプロセスルール、Android ではシステム VPN、アプリごとのプロキシ、バックグラウンド復帰が重視されます。もともと異なる実行環境だからです。
VMess ノードしかない場合、Androidではどれを選ぶ？
まず v2rayNG にインポートしてテストします。ノードが明確な v2fly 設定環境から提供されている場合や、2つのコアのログとルーティング結果を比較したい場合は、v2flyNG も入れて2つ目のテストを行います。
v2rayN にはノードがあるのに、Androidでは一覧が空になる？
Android クライアントで「サブスクリプショングループ設定」を開き、URLに改行がないことを確認してから、メイン画面で「サブスクリプションを更新」を実行します。それでも空の場合は、ログのレスポンス状態と解析エラーを確認してください。サブスクリプションURLを手動ノード画面に入力してはいけません。
v2rayNG は接続できるのに、特定のアプリがノードを経由しない？
「設定」にあるアプリごとのプロキシのスイッチと対象方向を確認します。いったんアプリごとのルールを無効にして再テストし、正常に戻ったらプロキシ経由またはバイパスが必要なアプリを1つずつ追加します。
v2rayN のコアは正常に動作しているのに、ブラウザーでWebページを開けない？
まずシステムプロキシが有効になっていることを確認し、次にパラメータ画面のリスナーのプロトコルとポートを照合します。手動設定が SOCKS 10808、HTTP 10809 の場合、ブラウザー拡張機能も同じプロトコルと対応するポートを選ぶ必要があります。
v2rayNG と v2flyNG を両方残す必要はある？
通常の利用では必要ありません。中心となるクライアントを1つに絞る方が、サブスクリプションやルールを管理しやすくなります。コアの互換性をテストするときだけ、同じノードを2つのクライアントで個別に接続してください。テスト中に同時起動してはいけません。
実行しやすい選択チェックリスト
- Windows、macOS、Linux：v2rayN をダウンロードし、まずシステムプロキシで基本接続を確認します。
- Androidでノードの中心が VLESS、Reality：v2rayNG をダウンロードします。
- Androidで v2fly コアが必須、または VMess の旧設定を検証：v2flyNG を選びます。
- 複数のプロトコルを含むサブスクリプション：各ノードに必要なコアを先に確認し、グループ分けするか決めます。
- 接続異常：サブスクリプションの解析、コアの起動、ローカルポート、システム連携、ルールの適用の順に確認します。