V2Rayクライアント比較：v2rayN、v2rayNG、v2flyNG

v2rayN：PCでのサブスクリプション管理とルーティング

v2rayNの大きな特長は、PCで管理しやすいことです。複数のサブスクリプションを個別のグループに分け、グループごとに更新したり、絞り込みでサーバー一覧を整理したりできます。スマートフォンで何度も設定画面を開くより、PCの一覧画面のほうがルールの順番や設定名を確認し、ログを参照しやすくなります。これは画面構成による利便性であり、サブスクリプションを増やせば接続品質が向上するという意味ではありません。

デスクトップ版と従来のWPF版、どちらを選ぶ？

Windows向けダウンロードには、デスクトップ版と従来のWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用しており、異なるPC環境でも似た操作感を求めるユーザーに向いています。WPF版は従来の画面を維持しているため、メニュー構成に慣れたWindowsユーザーに適しています。画面の違いは接続速度の順位を示すものではありません。OSの要件と使い慣れた設定方法を優先して選んでください。

macOSではプロセッサがApple SiliconかIntelかを、Linuxではプロセッサのアーキテクチャとディストリビューションのパッケージ形式を確認してください。拡張子が似ているというだけでインストールせず、ダウンロードページでOSとアーキテクチャに合った項目を選びましょう。

システムプロキシとTUNは分けて設定

使い始めはシステムプロキシでブラウザーの接続を確認し、サブスクリプション、サーバー、基本的なルーティング設定が有効だと確認してからTUNを検討しましょう。システムプロキシの影響を受けるのは、主にOSのプロキシ設定に従うアプリです。TUNはより広い範囲の通信を取り込むことが多く、既存のネットワークツール、DNS設定、権限と干渉しやすくなります。TUNを有効にしても、あらゆる接続問題が解決するわけではありません。

複数のサブスクリプションを管理したい、特定のドメインだけ別経路にしたい、PCアプリの通信状況を確認したい場合は、v2rayNを使うとトラブルの切り分けを進めやすくなります。応用設定を変更する前に、元に戻せる状態を保ち、一つずつ調整してください。ルーティングルールのマニュアルを見る →

v2flyNG：V2Fly設定向けのAndroidクライアント

v2flyNGはv2flyコアを採用しており、V2Fly設定を使った経験がある場合や、このコアの動作を確認する必要がある場合に適しています。古い端末向けのクライアントという位置付けでも、v2rayNGの軽量版でもありません。まず比べるべきなのは、名前の似ている度合いではなくコアの互換性です。

設定をコアが正しく解釈できることが前提

既存の設定がV2Flyに対応するプロトコルと通信方式を使っている場合は、v2flyNGにインポートして動作を確認できます。Xray専用の項目や機能を含む設定では、クライアントを替えるだけで同等の機能が得られるとは限りません。インポートに成功しただけでは設定の動作確認は完了していません。起動ログと実際の接続結果も確認してください。

サブスクリプションのグループ管理、ルールのメニュー、インポート画面は、クライアントの更新に伴い変わることがあります。手順を参照するときは、説明されているのがGUIの項目かコアの設定項目かを確認してください。前者はメニュー名が変わっただけの場合もありますが、後者は設定の有効性を左右することがあります。画面や項目が異なっても、別のクライアント用の設定一式でそのまま上書きしないでください。

目的がはっきりしている場合の選択肢

Androidで初めてサブスクリプションを使うなら、v2rayNGから始めると当サイトの入門手順を利用しやすくなります。既存の設定、調査したい内容、使い方からv2flyが必要だと分かっている場合に、v2flyNGを選びましょう。検証中はVPN接続を一つだけ動かし、OSのVPNサービスを切り替えた影響をコアの不具合と取り違えないようにしてください。

v2flyNGとv2rayNGのダウンロードページを見る →

クライアントを替える前の設定準備

クライアントの変更は、対応プラットフォームやコアの不一致を解決するのに役立ちますが、ネットワークや設定の確認に代わるものではありません。以前のクライアントが急に接続できなくなった場合は、サブスクリプションの期限、設定の更新、端末の時刻、ほかの通信を取り込むツールの有無を先に確認してください。原因が分からない場合は、エラーを記録してから移行すると、新しいクライアントに問題を持ち込まずに済みます。

提供元を記録し、再利用できる設定を移行

1. サブスクリプションの提供元を記録します。有効なサブスクリプションURLとグループ名を保存し、インポート済みの一覧だけを残さないようにしましょう。サブスクリプションURLに認証情報が含まれることがあるため、公開画像や質問文に載せないでください。
2. 共有リンクと完全な設定ファイルを区別します。共有リンクは通常、個別の接続設定を示します。完全なJSONには、ローカルの待ち受け設定、ルーティング、DNSなどが含まれる場合があります。クライアントが生成した完全な設定を、別のクライアントでそのまま再利用できるとは限りません。
3. コアに関係する項目を確認します。プロトコル、通信方式、セキュリティ層のすべてが移行先のコアでサポートされているか確認してください。認識できない項目がある場合は、意味を調べてから対応しましょう。設定を無理に起動させるために項目を適当に削除しないでください。
4. 機能は段階的に有効にします。まず基本的な接続を確認してから、ルーティング、DNS、通信の取り込み設定を戻します。段階ごとにテストし、正常に動作した状態を記録しておきましょう。

移行の完了を確認する方法

クライアントが動作中と表示されるのは、確認の第一歩にすぎません。PCでは、ブラウザーがシステムプロキシに従っているか、ネットワーク接続が必要なターミナルアプリに個別のプロキシ設定が必要かを確認します。Androidでは、対象アプリの通信が取り込み対象になっているか確認してください。その後、直接接続するサービスとプロキシ経由で接続するサービスの両方にアクセスし、接続アイコンだけでなくログからルールの適用先を確かめましょう。

ルーティングのラベル名は、すべてのクライアントで共通するボタン名ではありません。設定内のdirect、proxy、blockは、実際のアウトバウンド定義に対応している必要があります。ルールの記述だけで対応するアウトバウンドがなければ、設定としては不完全です。ルールの順序についてはルーティングルールの解説をご覧ください。