SECTION 01 / 構成の概要
GUIクライアントが接続パラメーターを管理し、通信の処理はコアが担います。リンクのインポートは設定の出発点にすぎません。プロトコルの項目でサーバーへの接続方式が決まり、プロキシモードでアプリの通信をクライアントに取り込めるかが決まります。さらにルーティングによって、通信の出口が決まります。複数の設定を一度に変更するより、この3層を分けて確認すると問題を特定しやすくなります。
v2rayNはGUIでサーバーの接続情報を管理し、選択したコアに処理を渡します。VMess、VLESS、Trojan、Shadowsocksでは設定項目が異なり、相互に置き換えることはできません。通信方式やTLSの設定もサーバー側と一致させる必要があります。インポート後は、プロトコル、アドレス、ポート、安全性に関する設定を確認し、選択したコアがその組み合わせに対応しているかを確かめてください。GUIなら複数の接続設定を保存しやすくなりますが、各項目の制約がなくなるわけではありません。REALITYは通信の安全性に関わる設定であり、単独のプロキシプロトコルとして安易に置き換えるものではありません。
サブスクリプションURLからは複数の接続設定を取得でき、共有リンクは通常、1つの接続情報を表します。継続して使う設定元は「サブスクリプショングループ」にURLを保存して更新し、1件だけ追加する場合はクリップボードからインポートする方法が便利です。base64は単なるエンコード形式であり、内部の内容をクライアントが必ず認識できるとは限りません。ネイティブJSONと共有リンクも同じものではなく、変換によってルーティングやDNSの設定が失われることがあります。更新前に対象のグループを確認し、更新後は項目を選択できるか確認してください。1回の通信エラーを、すべての接続が使えなくなったと誤解しないようにしましょう。
ルーティングでは、宛先に応じて通信を異なるアウトバウンドに振り分けます。主な選択肢はプロキシ、直接接続、ブロックです。ルールは通常、上から順に評価されるため、特定ドメインのルールは広い範囲に適用するルールより前に置きます。geositeはドメインの集合、geoipはIPアドレスの集合を対象とし、それぞれ対応するデータファイルが必要です。domainStrategyは照合時にドメインからIPアドレスを解決するかを制御するもので、システムDNS全体を切り替える設定ではありません。まず内容を説明できるプリセットを使い、必要に応じて例外を追加しましょう。把握できないルールを大量にコピーするより、管理やトラブル対応がしやすくなります。
システムプロキシは、OSの設定にローカルプロキシのアドレスを書き込みます。この設定を参照するアプリだけが利用できます。TUNモードは仮想ネットワークインターフェースを通じて通信を取り込むため、より広い範囲をカバーしますが、権限やルーティング、DNSの設定も関わります。初めて設定する場合は、まずシステムプロキシで接続を確認し、必要に応じてTUNを有効にしてください。接続パラメーターの誤りとインターフェースの問題を混同しにくくなります。他のプロキシツール、既存の仮想ネットワークインターフェース、アプリ独自のプロキシ設定が影響する場合もあります。モードを切り替えたら、スイッチの表示だけで判断せず、対象アプリで接続を再テストしてください。
デスクトップではv2rayN、Androidではv2rayNGをまず検討し、V2Flyコアが必要な場合はv2flyNGも選択肢になります。同じ共有リンクを複数のプラットフォームで使えるかどうかは、両方のコアがプロトコル、通信方式、安全性に関する設定に対応しているかで決まります。リンクの先頭部分だけでは判断できません。インストール前にプロセッサーのアーキテクチャとパッケージ形式を確認し、移行時にはサブスクリプションURLとカスタムルールをそれぞれ保存してください。GUIの名称が異なっても、まず接続をインポートし、通信の入口を選び、最後にルーティングと名前解決を確認する基本的な流れは同じです。
SECTION 02 / プラットフォーム別ダウンロード
インストールパッケージは、使用するデバイスに合ったものを選ぶ必要があります。デスクトップ向けでは、GUIの種類、プロセッサーのアーキテクチャ、配布パッケージの形式はそれぞれ別の選択項目です。ファイルサイズだけで判断する必要はありません。ダウンロードページでは各クライアントへのリンクと選び方をまとめています。このページのプラットフォーム別リンクから、該当する案内へ直接移動できます。
デスクトップではv2rayNがおすすめです。Desktop版は新世代のクロスプラットフォームUIを採用し、従来型のデスクトップUIを使いたい場合はクラシックなWPF版を選べます。画面構成は異なることがありますが、インポート、サーバー選択、システムプロキシの設定という基本的な手順は共通です。
インストール前にOSの種類を確認し、ダウンロードするパッケージの対象アーキテクチャを確かめてください。初回起動後は、コアが正常に動作するかを確認します。ウィンドウが開いても接続できない場合は、ログを確認してください。それだけでサーバーの設定に誤りがあると判断することはできません。
ダウンロードへ Windows クライアント →v2rayNを選び、「このMacについて」でチップ情報を確認してください。Apple SiliconとIntelでは適したパッケージが異なります。すべてのディスクイメージが共通で使えると考えず、デバイスのアーキテクチャに合ったものを選びましょう。
システムプロキシは、主にOSのネットワーク設定に従うアプリで利用されます。より広い範囲の通信を取り込む必要がある場合は、TUNの設定条件を確認してください。権限の確認と接続設定は別の手順です。まず起動とインポートを済ませてから、アプリで接続をテストしましょう。
ダウンロードへ macOS クライアント →まずはXrayコアを使用するv2rayNGを検討してください。V2Flyコアが必要な場合は、v2flyNGも選べます。比較的新しいデバイスの多くはarm64パッケージに対応しています。アーキテクチャがわからない場合は、端末情報を確認し、ダウンロードページにある汎用パッケージの説明も参照してください。
初回接続時は、システムのVPN利用許可を確認してください。バックグラウンドでの動作は、端末のバッテリー管理機能によって制限されることもあります。画面ロック後にだけ切断される場合は、すぐにプロトコルを変更せず、バックグラウンド動作の制限を確認しましょう。ネットワークを切り替えた後も、接続を再確認してください。
ダウンロードへ Android クライアント →デスクトップ環境ではv2rayNを選べます。まずディストリビューションに合ったdebまたはrpmを選び、次にx64またはarm64のアーキテクチャを確認してください。パッケージ形式はシステムのパッケージ管理方式に、プロセッサーアーキテクチャは実行環境に対応します。両方を一致させる必要があります。
アプリがシステムプロキシの設定を参照するかどうかは、デスクトップ環境やアプリの実装によって異なります。個別にプロキシ設定が必要なアプリには、クライアントが実際に待ち受けているアドレスとポートを入力してください。TUNを有効にする前に必要な権限を確認し、既存のネットワーク管理ルールとの競合を避けましょう。
ダウンロードへ Linux クライアント →SECTION 03 / 初回接続
クライアントには、利用可能なリモート接続先があらかじめ用意されていません。始める前に、利用権限のあるサブスクリプションURLまたは共有リンクを用意し、現在のネットワークからサブスクリプションを取得できることを確認してください。初回設定ではクライアントを1つだけ起動し、まず再現可能な基本接続を確立しましょう。その後、カスタムルーティングやTUNなどの設定を追加します。
STEP 01 / IMPORT
v2rayNの「サブスクリプショングループ」にURLを保存してから更新します。1件だけの共有リンクは、クリップボードからインポートできます。インポート後は、プロトコル、アドレス、ポート、通信方式が正しく設定されているか確認してください。項目が一覧に表示されても、クライアントが内容を認識したというだけで、リモートサーバーとの接続が確立したとは限りません。更新結果が空の場合は、URL、ネットワークアクセス、サブスクリプション形式を確認してください。すべてのグループを何度も削除する必要はありません。
サブスクリプションURLにはアクセス権限に関する情報が含まれている場合があります。アカウント情報と同様に慎重に保管してください。トラブル対応のために画面を共有する際は、URL全体、識別情報、個人用メモを隠しましょう。デバイスを移行する前に、サブスクリプションの取得元とローカルルールを個別にバックアップしてください。サーバー一覧をコピーしただけですべての設定が移行できるとは限りません。
STEP 02 / PROXY
使うサーバーをアクティブにし、「システムプロキシを自動設定」を選択します。最初のテストでは、対象を判断しやすいルーティングプリセットを使い、どの通信が直接接続され、どれがプロキシ経由になるか確認してください。ブラウザーのプロキシ拡張機能、手動のプロキシ設定、他のネットワークツールがシステム設定より優先される場合があります。テスト前に、こうした設定も確認しましょう。
アプリがシステムプロキシを使わない場合は、アプリ独自のプロキシ設定があるか確認してください。より広い範囲の通信を取り込む必要がある場合に限り、TUNを有効にして権限やDNSを設定します。一度に変更するのは1つの項目だけにし、再現できた直前の設定を残しておくと、問題がどこから始まったか判断しやすくなります。
STEP 03 / VERIFY
Tcpingでわかるのは、主に宛先ポートへのTCP接続性です。実接続テストでは、さらにプロキシのハンドシェイクやテスト用リクエストも確認されるため、両者は代用できません。結果はテスト対象やその時点のネットワーク状況にも左右されます。サーバーを選んだら、プロキシ経由にしたいページをブラウザーで開き、クライアントログの接続情報やルーティング結果と照らし合わせてください。
テストに成功してもアプリが使えない場合は、「アプリのプロキシ設定、本地の待ち受け、ルーティングの適用結果、リモートとのハンドシェイク」の順に確認してください。タスクバーのアイコンやスイッチの状態だけで、プロキシが有効だと判断しないようにしましょう。テスト後は、使用したモードと例外ルールを記録しておくと、次にネットワークを切り替えたときも同じ手順で確認できます。
SECTION 04 / オープンソースのエコシステム
Project Vは、V2Rayのエコシステムを理解する出発点です。V2Rayは、インバウンド、ルーティング、アウトバウンド、通信方式などの機能を組み合わせ、プロキシを単一プロトコルの接続プログラムにとどめません。ユーザーが日常的に操作するサーバー一覧やスイッチは、多くの場合、外側のGUIクライアントが提供します。「V2Rayクライアント」と言うときは、GUIアプリ、実行コア、接続に使うプロトコルのどれを指しているか確認しましょう。関連はありますが、同じ層のものではありません。
V2FlyはV2Rayのコミュニティ開発を引き継ぎ、Xrayは関連するコードを基盤に独自の機能を発展させています。共通する設定の背景がある一方、独自の実装や進化を遂げた部分もあります。そのため、一部の基本項目が似ていても、どの設定でもそのまま相互に使えるとは限りません。VLESS、REALITY、通信方式の拡張、特定のセキュリティ設定を使う場合は、クライアント名だけで判断せず、実際のコアが対応しているか確認してください。
v2rayNは、サーバー管理、サブスクリプションの更新、プロキシモード、ルーティング設定をGUIから行えるオープンソースのデスクトップクライアントです。v2rayNGはXrayコアを使用するAndroid向けのオープンソースクライアントです。v2flyNGもAndroid向けで、V2Flyコアを使う選択肢となります。クライアントを選ぶときは、まずOSを確認し、次に既存の接続で必要なプロトコル機能を確認しましょう。「インポートできる」ことと「すべての設定項目に対応している」ことは同じではありません。
GUIクライアントは画面上の設定をコアが実行する設定に変換するため、画面上の名称とネイティブJSONのフィールドが一対一で対応するとは限りません。また、コアが対応している項目でも、すべてがGUIの操作項目として公開されるとは限りません。高度な設定を行う場合は、使用中のクライアントの説明を確認してから、コアの各フィールドの意味を調べてください。他のクライアント向けの画面操作をそのまま当てはめると、似た名前の項目を同じ機能だと誤解することがあります。
オープンソースでは、各ライセンスに従ってコードを閲覧、使用、再配布できますが、関連するすべてのプロジェクトが同じライセンスを採用しているわけではありません。Xray-coreとV2FlyのV2Ray-coreはMPL-2.0を採用しています。クライアントのGUI、コア、同梱コンポーネントのライセンスは、それぞれ個別に確認してください。ソフトウェアを改変、配布、統合する場合は、該当プロジェクトのライセンス本文を参照し、エコシステム全体をまとめた呼び方だけで判断しないようにしましょう。
オープンソースであることは、設定の取得元を確認する必要がないという意味ではありません。接続パラメーターはサブスクリプションの提供元が決め、サービスの可用性はリモートサーバーに左右され、通信の入口や振り分けはローカルクライアントが担います。内容のわからない設定を使う場合は、ルーティングの宛先、DNS設定、待ち受け範囲を確認してください。特に、トラブル対応のためであっても、ローカルプロキシの待ち受けを他のデバイスからアクセスできるアドレスに安易に変更しないでください。
クライアントのGUI、コア、ルールデータの更新は、それぞれ異なる層に影響します。GUIの更新でメニューの位置が変わることがあり、コアの更新で対応フィールドや動作が変わることがあります。ルールデータの更新は、ドメインやIPアドレスの集合に対するマッチ結果に影響する場合があります。更新後の変化を調べるときは、まずどの層が変わったかを記録し、接続パラメーターとルーティング結果を比較しましょう。すべての不具合をサーバーのせいにしないことが大切です。
更新前に必要なローカル設定を保存し、更新後は以前に再現できたアプリの通信を使って確認してください。カスタムルールが多い場合は、具体的なルールが汎用ルールより前に並んでいるかも確認しましょう。ダウンロードページではクライアントへのリンクを案内し、プロトコルの参考ページでは設計上の違いを解説しています。個別フィールドの動作を確認する際は、実際に動作しているコアとログもあわせて参照してください。
SECTION 05 / 活用ガイド
以下の3記事では、プロトコルの選び方、ルーティングの優先順位、初回接続の確認方法を解説します。まずは安定して再現できるテスト手順を作り、その後カスタムルールを確認しましょう。既存の接続を移行する場合は、プロトコルと通信方式の組み合わせを把握しておくと、クライアント間の変換で設定を見落としにくくなります。
開発の背景、暗号化方式、ハンドシェイクの負荷、モバイル端末のバッテリー消費という4つの観点から各プロトコルを比較し、用途に合わせた選び方を紹介します。
domain、full、regexp、geosite、geoipなどのルール接頭辞の書き方を解説。ルールが上から順に評価される仕組みと、domainStrategyが結果に与える影響も説明します。
サブスクリプションを追加した後のサーバーの選び方、Tcpingと実接続による遅延テストの違い、システムプロキシの状態やブラウザーでのアクセスによる接続確認方法を解説します。