オープンソースクライアントの選び方から、サブスクリプション管理、ルーティングまで、実際の設定手順に沿って解説します。
ルール · グループ · 動作モード
サーバーに接続できることは、設定の出発点にすぎません。通信の振り分け、サブスクリプションの管理、システムへの接続方法を分けて設定すると、後から確認しやすくなります。
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}ルーティングで決めるのは「今回のリクエストをどこへ送るか」であり、すべての接続を同じ出口にまとめることではありません。図のルールでは、指定したドメインに一致するリクエストをdirectへ送ります。このタグは事前にアウトバウンド設定で定義し、関連するルールデータも利用できる状態にしておく必要があります。設定時は、まず使用中のクライアントのカーネルを確認し、具体的なルールを広範囲に一致するルールより先に記述します。グローバルモードを切り替えるだけの場合と比べ、ドメイン単位の振り分けならローカルサービスへのアクセスを維持しやすく、ログから誤判定も見つけやすくなります。これはルールの一部です。全体の構成は設定リファレンスをご覧ください。
複数のサブスクリプションを1つの一覧にまとめると、サーバー数よりも配信元が分かりにくいことや、名前が重複することが問題になりがちです。まず配信元ごとにグループを作り、更新方法とフィルター条件を設定すると、管理しやすい一覧に整理できます。サーバーを1つずつ手動で追加するより更新は簡単ですが、配信元の変更によってサーバー名や接続パラメーターが変わる場合があります。更新後は選択中のサーバーと所属グループを確認し、フィルターで除外されたサーバーを接続障害と誤認しないようにしましょう。サブスクリプションURLには認証情報が含まれることがあるため、スクリーンショットやトラブル報告ではURL全体を隠してください。
デスクトップの接続方式
システムプロキシとTUNはアプリの通信をクライアントに取り込む方法、ルーティングルールは取り込んだ通信の転送先を決める設定で、役割は異なります。一般的なブラウザーで試す場合は、まずシステムプロキシを使って確認しましょう。システムプロキシを参照しないアプリでは、必要に応じてTUNを検討します。最初から複数の接続方式を同時に有効にするより、1つずつ試すほうがポートや権限、DNSの競合を見つけやすくなります。Android版では通常、システムのVPN機能を使って接続するため、アプリごとの対象範囲も確認してください。クライアントによってメニュー名が異なる場合があるので、機能を基準に設定しましょう。
すべてのサイトに接続できない場合は、まずカーネルが起動しているか、サーバーが選択されているか、ローカルポートが正常に待ち受けているかを確認します。特定のドメインだけで問題が起きる場合は、ルールの優先順位、DNSの結果、転送先のアウトバウンドを調べましょう。ルーティング設定を一式そのままコピーすると、複数の条件が同時に変わってしまいがちです。接続できる基本設定を保存し、ルールを1グループずつ変更すれば、どの変更が影響したか判断できます。
GUIクライアントは、画面上の設定項目をカーネル用の設定に変換します。画面で「直接接続」と表示されていても、設定ファイル内のタグ名と一致するとは限りません。設定例を読むときは、メニューの場所を覚えるだけでなく、各フィールドの対応関係を確認しましょう。カスタム設定によってGUIの設定が一部反映されない場合もあります。トラブル対処の前に、どの設定ファイルが実際に使われているか確認し、設定ファイル総合リファレンスでインバウンド、アウトバウンド、ルーティングを照合してください。
OSに合ったパッケージを選び、アーキテクチャを確認
デスクトップではv2rayN、Androidではまずv2rayNGを検討し、V2Flyカーネルが必要な場合はv2flyNGを選びます。各OSのインストーラーはダウンロードページにまとめています。
デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のUIを引き継いでいます。使い慣れた画面に応じて選ぶもので、どちらかが必ず速く接続できるという意味ではありません。初めてインストールするときは、OSと動作環境の要件を確認してから1つのバージョンを選び、基本設定を行いましょう。クライアントを2つ同時に起動すると、待ち受けポートが競合することがあります。
展開して使うアプリは、書き込み権限のある固定の場所に配置してください。インストーラー版は画面の案内に従ってインストールします。初回起動後は、サブスクリプションを追加する前にカーネルが読み込まれているか確認しましょう。ポートが使用中と表示された場合は、該当するプロセスを調べてください。何度も再インストールする必要はありません。
「このMacについて」でチップの種類を確認します。Appleシリコン搭載機はarm64、Intel搭載機はx64を選んでください。アーキテクチャを確認してからインストール形式を選び、ファイルサイズだけで判断しないようにしましょう。インストール後は、アプリを所定の場所から起動してください。一時的にマウントした場所から常用するのは避けましょう。
システムプロキシの影響を受けるのは、主にシステム設定に従うアプリです。ブラウザーは使えるのに特定のアプリが直接接続する場合は、そのアプリのプロキシ動作を確認しましょう。ネットワーク拡張機能や権限の許可を求められたら、システムに表示される用途を確かめ、必要な場合だけ有効にしてください。
v2rayNGはXrayカーネル、v2flyNGはV2Flyカーネルを使用します。選ぶ際は、サーバー側の設定と必要なプロトコルを確認してください。比較的新しいスマートフォンでは通常arm64を選びます。アーキテクチャが分からない場合は、端末情報またはダウンロードページの汎用パッケージの説明を確認しましょう。アプリをインストールできても、追加したすべての設定が現在のカーネルに対応するとは限りません。
初回接続時には、システムのVPN接続許可が表示されます。バックグラウンドに切り替えると接続が切れる場合は、バッテリー最適化、バックグラウンド制限、アプリごとのプロキシ対象を確認してください。バックグラウンド制限は安定して使える範囲で調整し、省電力設定をすべて一度に無効にする必要はありません。
まずディストリビューションで使われているパッケージ管理方式を確認し、debまたはrpmを選びます。CPUアーキテクチャも確認してください。x64とarm64は互換性がありません。インストール後に画面が開いてもネットワーク機能が動かない場合は、画面が起動しただけで接続できたと判断せず、カーネルのプロセス、デスクトップのプロキシ設定、必要な権限を個別に確認しましょう。
デスクトップ環境によって、システムプロキシの参照方法が異なる場合があります。コマンドラインのプログラムも、独自にプロキシを設定することがよくあります。まずプロキシに対応していることが明確なアプリで動作を確認し、その後ほかのプログラムにも広げると、原因を絞り込みやすくなります。
クライアントは設定を実行するためのツールで、サブスクリプションにはサーバーの接続情報が含まれます。それぞれ別に準備しましょう。クライアントをダウンロードしたら、まず初回起動を済ませ、設定画面から手元のサブスクリプションURLを追加します。入手元が分からないURLは、普段使うグループにすぐ追加しないでください。サーバー一覧が表示されたら1つ選び、実際のWebサイトへのアクセスとログの両方で接続を確認します。レイテンシテストは特定の条件で応答時間を比較するもので、ダウンロード速度とは異なり、アプリでの接続確認の代わりにもなりません。
すでに使える環境がある場合は、更新前にサブスクリプショングループ、カスタムルール、手動登録したサーバーをバックアップしてください。クライアントのバージョンによってメニューの場所やカーネルの既定値が異なることがあるため、更新後にシステムプロキシ、ルーティングモード、選択中のサーバーを再確認しましょう。最初から設定する場合は、初回インストールと接続の手順に沿って進めてください。インストーラーの形式と端末のアーキテクチャは、ダウンロードページで確認できます。
すべてのクライアントを見る →クライアントとカーネルを分けて理解する
「V2Ray」は、プロキシツールの総称として使われることがあります。選ぶ際は、GUIクライアントの役割と、基盤となるカーネルの対応機能を分けて考えるとよいでしょう。
Project Vの基本的な考え方は、インバウンド、アウトバウンド、ルーティング、通信方式を組み合わせ可能な設定モジュールとして扱うことです。インバウンドはアプリからのリクエストを受け取り、ルーティングはルールに応じて送信先を決め、アウトバウンドは実際に通信を転送します。複雑なネットワーク要件を表現できる一方、JSONを直接読むのは初心者には少し難しい面があります。そのためGUIクライアントが、設定の追加、グループ分け、切り替え、パラメーター編集などを画面から行えるようにし、設定内容をカーネルに渡して実行します。
そのため、「画面に項目があること」と「現在の設定でその機能を使えること」は同じではありません。同じクライアントでも異なるカーネルを呼び出す場合があり、カスタム設定によって既定の動作が変わることもあります。クライアントを比較する際は、まずOS、カーネル、設定の入手元を確認したうえで、サブスクリプションを管理しやすいか、ルーティングを保守しやすいかを見ましょう。画面の見た目だけで比較すると、使い勝手を左右する互換性を見落とすことがあります。
V2FlyはV2Rayコミュニティのエコシステムを引き継いで開発され、Xrayは関連するコードを基盤とする別のカーネルブランチとして発展しました。共通する設定の考え方やプロトコルもありますが、その後の機能、既定の動作、対応範囲は完全には一致しません。サーバーからVLESS、Trojanなどのパラメーターが提示された場合も、プロトコル名だけで互換性を判断せず、通信方式、セキュリティ層、必要な拡張機能まで確認してください。
たとえばREALITYは、カーネルが対応しているか確認が必要なセキュリティ層関連の設定です。すべてのプロトコルと並ぶ、自由に置き換え可能な選択肢として扱うべきではありません。接続できている環境がある場合は、カーネルを切り替える前に元のパラメーターを記録しましょう。切り替え後は基本的な接続を確認してから、カスタムルーティングを戻します。設定の解析エラーが出たら、クライアントを次々と変えるのではなく、エラーが示すフィールドと現在のカーネルの対応範囲を確認してください。
v2rayN、v2rayNG、v2flyNGはいずれもオープンソースプロジェクトとして開発されています。v2rayNはデスクトップでのサーバー管理、サブスクリプション、ルーティング設定を中心とし、v2rayNGはAndroid端末向けでXrayカーネルを使用します。v2flyNGはV2Flyカーネルを使う選択肢です。オープンソースであれば実装やライセンス条件を確認できますが、あらゆるサーバー設定に対応するという意味ではなく、サーバーサービスがクライアントに付属するわけでもありません。
3つのクライアントと、それぞれが呼び出すカーネルは異なるレイヤーのプロジェクトです。画面上の問題、カーネルの設定解析エラー、接続先サーバーの障害は、それぞれ切り分けて調べる必要があります。そのため、レビュー記事では一律の点数ではなく、発生条件や設定手順を記録しています。まずは端末と必要なプロトコルに合うクライアントを1つ選び、安定してから移行を検討するほうが、似た環境を複数管理するより手間を抑えられます。
V2Rayのコア関連プロジェクトにはMPL 2.0などのオープンソースライセンスが適用されています。クライアントにもそれぞれ独自のライセンス条件があります。具体的な義務は、利用するプロジェクトと付属のライセンス文書に基づいて確認してください。1つのカーネルのライセンスを、ツールチェーン全体にそのまま当てはめることはできません。通常の利用と、コードの改変・再配布は別の扱いです。改変版を公開する場合は、著作権表示の保持、変更内容の明記、対応するソースコードの提供義務などを確認しましょう。
このサイトではクライアントの選び方や設定の読み方を紹介しており、サブスクリプションやサーバーサービスは提供していません。クライアントは無料で利用できますが、サーバーの料金、プライバシーポリシー、稼働状況は各サービス提供元によって異なります。設定ファイルにはサーバーアドレス、ユーザーID、サブスクリプションの認証情報が含まれる場合があります。ログやスクリーンショット、トラブル報告を共有する前に、これらの情報を削除してください。職場のネットワークや管理対象端末を使う場合は、所属組織のネットワーク利用規則にも従いましょう。
GUIクライアント、カーネル、ルールデータの更新時期はそれぞれ異なります。GUIの更新でメニューや設定生成の方法が変わることがあり、カーネルの更新で対応パラメーターに影響が出る場合もあります。ルールデータの更新では、ドメインの振り分け先が変わることがあります。更新後に動作が変わった場合は、どのレイヤーが更新されたかを記録して、現在の動作状況を確認しましょう。すべてを漠然と「サーバーが不安定」と片付けないことが大切です。トップページには特定のメンテナンスバージョンを固定表示せず、インストーラーの情報はダウンロードページにまとめています。
トラブルを調べるときは、同じネットワーク、同じサーバー、同じテスト対象で変更前後を比べるのがおすすめです。設定は一度に1項目だけ変え、ログに記録されたエラーの種類と発生時刻を残しましょう。レイテンシ、スループット、接続成功率はそれぞれ異なる問題を示すため、1回の測定結果だけで長期的な性能を断定することはできません。このサイトでは、後から検証できる判断手順を重視し、インストール、サブスクリプション、ルーティング、トラブル対処を一連の流れで確認できるようにしています。
使い始める方はクライアントのインストールとサブスクリプション追加の手順をご覧ください。設定項目を理解したい場合は、JSON構造、インバウンド、アウトバウンド、DNSのリファレンスをご確認ください。まず今の操作で困っている点を解決し、必要に応じてルールを追加していくほうが、すべての機能を一度に有効にするより設定を整理しやすくなります。
設定の記録と段階的なトラブル対処
バッテリー消費、サブスクリプションの混乱、通信速度の低下を、確認しやすい小さな問題に分けます。まず影響範囲を把握し、システム、クライアント、接続先サービスの順に調べましょう。
モバイル端末のバッテリー消費が増える原因として、バックグラウンドでの頻繁な再起動、バッテリー最適化との競合、アプリごとの設定などが考えられます。OSとクライアントの設定を1つずつ確認し、通信を続けることによる消費とバックグラウンド動作の異常を切り分けてから、常時動作と省電力のバランスを調整しましょう。
バッテリー消費の対処手順を読む →複数のサブスクリプションを管理する場合は、まず配信元ごとにグループを作り、キーワードで必要なサーバーだけを絞り込みます。並べ替えや更新方法も設定し、選択中のサーバーが想定したグループに属しているか確認しましょう。重複サーバーや名前の変更、更新による混乱を減らせます。
グループの整理方法を読む →速度の問題を、サーバーとプロトコル・通信方式、ネットワーク回線、端末側のルーティングとDNSの3段階に分けて調べます。テスト条件をそろえて1つずつ原因を除外し、その後でMuxなどの設定を調整しましょう。サーバー、ルール、名前解決の方法を同時に変えると、どの設定が影響したのか分からなくなります。
通信速度を段階的に診断する方法を読む →ログに明確なエラーが出た場合は、まずエラーの原文を保存し、どの段階で発生したかを確認します。特定のアプリだけに問題がある場合は、まずそのアプリがプロキシの対象になっているか調べましょう。症状ごとにまとめた記事から次の操作を確認できるため、環境全体を設定し直す必要はありません。
すべての記事を見る →