platform.outbounds

デバイスに合うクライアントを選ぶ

プラットフォームによってインストールパッケージの種類が決まり、ノードのプロトコルによってコアの機能要件が決まります。まずデバイスを選び、サブスクリプションのプロトコルにXrayまたはV2Flyが必要か確認してください。ダウンロードページでは、アーキテクチャ、チップ、インストール形式についても案内しています。

デスクトップの第一候補

Windows · v2rayN

システムプロキシ、サブスクリプショングループ、ルーティングルール、ログ確認をしっかり管理したいデスクトップユーザー向けです。ダウンロードページには、新しいクロスプラットフォームUIと従来のWPF UIの2つの入口があります。一般的な新しいデバイスではデスクトップ版から始め、既存の設定手順に慣れている場合は使い慣れたUIを選べます。

ダウンロードへ

デスクトップクライアント

macOS · v2rayN

デスクトップ版はv2rayNの設定ロジックを引き継ぎ、サブスクリプション、アウトバウンド、ルーティングルールを管理できます。ダウンロード前にデバイスのチップ種別を確認してください。Apple Silicon搭載デバイスはarm64、Intel搭載デバイスはx64のパッケージを選びます。チップ種別はシステム情報で確認でき、購入年だけで判断するべきではありません。

ダウンロードへ

モバイルの第一候補

Android · v2rayNG

v2rayNGはXrayコアを採用しており、VLESSやREALITYなどXrayの機能が必要なサブスクリプションに適しています。多くのモバイルデバイスでは、まずarm64パッケージを選びます。プロセッサのアーキテクチャを確認できない場合や、より広い互換性が必要な場合は、ダウンロードページで汎用パッケージを選択できます。

ダウンロードへ

パッケージインストール

Linux · v2rayN

GUIでサブスクリプション、システムプロキシ、ルーティングルールを管理したいデスクトップLinuxユーザー向けです。インストール形式はディストリビューションのパッケージ体系に合わせます。Debian、Ubuntu系は通常deb、Fedora、Rocky Linuxなどは通常rpmを使い、x64とarm64のアーキテクチャも確認します。

ダウンロードへ

すべてのクライアントを見る →

routing.console

ルール一覧と設定パネル

V2Rayクライアントの重要な機能は、ノードへの接続だけではありません。サブスクリプション、コア、DNS、ルーティングが接続結果を左右します。以下の設定パネルでは問題の種類ごとに分けて説明し、そのまま理解できる設定例を示します。

JSON 設定ビュー config/routing

プロキシ · 直接接続 · ブロック

ルーティングルールは上から順に適用

ルーティング設定は、通信を異なるアウトバウンドに振り分けます。プロキシが必要なドメインはプロキシへ、ローカルネットワークや指定範囲のアドレスは直接接続へ、アクセス不要と明示した種類はブロックへ送ります。ルールは上から確認され、マッチすると後続の判定を停止します。そのため、具体的なルールを前に、広い範囲を受けるフォールバックルールを後ろに置くのが一般的です。全体プロキシのオン・オフだけを提供する簡易ツールと違い、V2Rayのルールオブジェクトはドメイン、アドレス、ポート、ネットワーク種別、インバウンドタグを組み合わせられ、用途を保守しやすい一覧として管理できます。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

ルールを変更したら、まずタグがoutbounds内のアウトバウンド名と一致しているか確認し、次にクライアントログで実際に適用された結果を確認します。

ノード一覧

サブスクリプションURLと共有リンクは分けて管理

サブスクリプションURLは更新可能なノード一覧を指します。一方、vmess://やvless://の共有リンクは通常、1つのノードだけを記述します。サブスクリプションをクライアントにインポートしたら、まず更新を実行し、該当グループからノードを選択してください。共有リンクを直接インポートしても、継続的に更新されるサブスクリプションソースにはなりません。異なる提供元を別々のグループに分けると、更新失敗の原因となったURLを特定しやすく、同名ノードの混在も防げます。更新前に現在のグループを残し、更新成功後に遅延テストや接続確認を行うと、切り分けが明確になります。

サブスクリプショングループ
├─ 作業用設定
│  ├─ 手動更新
│  └─ 自動更新
└─ 一時共有
   └─ 単一ノードのインポート

サブスクリプションの内容はサービス提供者が生成します。クライアントは読み込み、更新、表示を担当しますが、単一ノードのリンクをリモートサブスクリプションへ自動変換することはありません。

Xray · V2Fly

プロトコルの機能でコアを選ぶ

v2rayNはデスクトップ向けGUIクライアントで、対応するコアと組み合わせて複数のノードを管理できます。v2rayNGはXrayコアを採用し、v2flyNGはV2Flyコアの系統に対応します。選択時はUIの細かな違いを先に比べるのではなく、ノードのプロトコル、通信方式、安全性パラメータを確認してください。REALITYなどXrayの拡張機能が必要なら対応するコアを選び、V2Flyの対応範囲に収まる標準設定ならV2Fly系統も選択できます。クライアントは設定の入口であり、プロトコル項目を解釈して接続を確立するのはコアです。

選択の順序
1. ノードのプロトコルと安全性パラメータを確認
2. コアの対応範囲を確認
3. 対応するGUIクライアントを選択
4. インポート後にログを確認

コアとクライアントは分けて判断する必要があります。クライアント名が似ていても、内部で同じコアの開発系統を使っているとは限りません。

名前解決の戦略

DNSとルーティングの判定を一致させる

接続は成功と表示されるのにWebページを開けない場合、DNSは確認すべき項目の1つです。ルーティングルールはドメインで直接マッチすることもあれば、ドメインルールに該当しない場合にアドレスへ解決してから判定を続けることもあります。この動作にはdomainStrategyなどの設定が関わります。DNSサーバー、問い合わせ経路、ルーティング戦略が互いに矛盾すると、名前解決は成功しているのに想定外のアウトバウンドが選ばれたり、ログに名前解決失敗が繰り返し出たりします。切り分けでは、まず簡潔な設定で基本接続を確認し、その後にカスタムDNSや複雑なルールを1つずつ戻してください。

{
  "dns": {
    "servers": [
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

DNS設定はシステムのネットワーク環境から切り離して判断すべきではありません。まずシステム時刻、基本ネットワーク、ノードの状態を確認し、その後で名前解決の戦略を確認します。

setup.sequence

3ステップで基本接続を完了

初回設定で多数の高度な項目を同時に変更しないでください。まずサブスクリプションのインポートと基本接続を完了し、実際の要件に応じてルーティングやDNSルールを追加します。こうすれば、変更ごとの結果を明確に対応付けられます。

詳しいガイドを見る →

01

サブスクリプションまたは共有リンクをインポート

完全なサブスクリプションURLをコピーし、クライアントのサブスクリプショングループに新しいソースを追加して更新を実行します。vmess://やvless://の単一リンクを受け取った場合は、「クリップボードからインポート」などの入口を使います。インポート後は、一覧にノード名、プロトコル、アドレスが表示されていることを確認してください。一覧が空の場合は、コピー内容が完全か、サブスクリプションにまだアクセスできるか、更新時にエラーが表示されていないかを優先して確認します。
02

ノードとプロキシモードを選択

サブスクリプショングループからノードを1つ選び、クライアントのシステムプロキシまたは対応する接続モードを有効にします。初回テストでは、カスタムブロック、複雑なDNS、多段アウトバウンドが同時に結果へ影響しないよう、シンプルなルールセットを使うのがおすすめです。ノードの可用性やネットワーク環境は変化するため、遅延値は参考にとどめます。実際の判断基準は、対象への接続を確立できるか、ログにハンドシェイク・名前解決・ルーティングのエラーが出ていないかです。
03

接続を確認してルールを1つずつ追加

基本接続が確立したら、一般的なWebページ、直接接続するアドレス、特定のアウトバウンドが必要な対象を個別にテストし、プロキシと直接接続の経路が想定どおりか確認します。その後、プライベートアドレスの直接接続や特定ドメインのプロキシなどを追加します。変更は毎回1つの設定グループだけにし、元に戻せる設定を保存してください。異常が起きたら「ノード、DNS、ルーティング、システムプロキシ」の順に確認すると、クライアントを何度も再インストールするより原因を特定しやすくなります。

project.v / ecosystem

Project V、コア、クライアントの関係

エコシステムの階層を理解することは、1つのクライアント名だけを覚えるより重要です。設定が使えるかどうかは、GUIクライアント、コア、プロトコル項目、サブスクリプションの内容が正しく連携できるかで決まります。

Project V プロトコルとプロキシツールのエコシステム

コアファミリー

V2Fly

V2FlyはProject Vのコミュニティによる保守系統を引き継ぎ、設定の解釈、プロトコルの実装、インバウンド、アウトバウンド、DNS、ルーティングなどの低レイヤー機能を担います。設定ファイルのinbounds、outbounds、routing、dnsなどのオブジェクトはコア層の概念であり、特定GUIクライアントの画面項目と同じものではありません。

コアファミリー

Xray

Xrayは近いエコシステムを基盤に独自の保守系統へ発展し、VLESSやREALITYなどの機能を拡張しました。サブスクリプションのノードに特定の拡張フィールドが含まれる場合、それを解釈できるコアが必要です。Xrayを選ぶ中心的な理由は、プロトコルと設定機能が合っていることであり、すべてのクライアント名を同じ実装と考えることではありません。

エコシステムの歴史：コア機能からGUIへ

Project Vは当初、プロトコル実装、設定構造、プロキシ機能の集合として形成されました。デスクトップやモバイルでの利用が増えるにつれ、コミュニティは各システム向けのGUIクライアントを開発しました。GUIクライアントはサブスクリプション管理、ノード選択、システムプロキシ、ログ表示、設定編集を担い、コアは接続の確立、ルーティングの実行、プロトコルの詳細処理を担います。両者を分離することで、UIは各プラットフォームの慣習に合わせて進化し、基盤機能もそれぞれの保守系統で継続的に更新できます。

そのため、「V2Rayクライアント」は通常、単一のインストールプログラムではなく、エコシステムを指す呼び方です。v2rayNはデスクトップシステム向け、v2rayNGとv2flyNGはAndroid向けで、UI、コアの系統、適した用途は完全には同じではありません。ダウンロード前にデバイスのプラットフォームを確認し、次にノードのプロトコルを確認すると、アーキテクチャやコアの選択ミスによるインポート失敗を減らせます。

オープンソースライセンス：コード、文書、変更履歴を追跡可能に

Project V関連のコアとクライアントはオープンソースとして保守され、各プロジェクトが定めるオープンソースライセンスに基づいてコードを公開しています。オープンソースライセンスには、コピー、改変、配布、ライセンス表示の保持に関する条件が定められています。一般ユーザーにとって重要なのは、機能の変更をリリース記録、ドキュメント、コミュニティの議論を通じて継続的に確認できることです。二次開発者は、配布前に該当プロジェクトのライセンス本文を読む必要があります。

オープンソースであることは、すべてのクライアントが同じチームによって同じペースでリリースされるという意味ではありません。v2rayN、v2rayNG、v2flyNGはそれぞれUI対応とリリースプロセスを独自に保守し、基盤となるコアにも別々の変更周期があります。設定の違いに遭遇したら、まずクライアント名、コアファミリー、プロトコルパラメータを確認し、現在の組み合わせに対応する説明を読んでください。

3つのクライアント：プラットフォームとコア系統で使い分け

v2rayNはデスクトップ向けの主要なGUIクライアントで、Windows、macOS、Linuxに対応し、複数のサブスクリプション管理、ルーティング編集、システムプロキシの切り替え、実行ログの確認に適しています。v2rayNGはAndroidで広く使われるXray系統のクライアントで、Xrayのプロトコル拡張機能が必要なノードに向いています。v2flyNGはV2Flyコアを採用し、V2Fly系統のモバイル向け選択肢になります。

3つとも似たノード設定やサブスクリプションの利用場面を想定していますが、名前だけで機能が完全に同じだと判断することはできません。対応フィールドはコアのサポート範囲に左右され、操作の一部はシステム権限やGUIの実装に依存します。最も確実な選択順は、デバイスのプラットフォーム、ノードのプロトコル、プロセッサのアーキテクチャ、クライアントUIの順に確認することです。

更新の仕組み：クライアント、コア、サブスクリプションは別々に変化

更新は通常、3つの層に分かれます。クライアントの更新はUI、システム対応、設定管理の方法を変えます。コアの更新はプロトコル実装、ルーティング動作、基盤の互換性を調整します。サブスクリプションの更新は、提供元から新しいノード一覧を取得します。これら3種類の更新は互いに独立しているため、サブスクリプションの更新失敗はクライアントの再インストールを意味せず、クライアントUIの更新でノード設定が自動的に変わることもありません。

更新の問題を調べるときは、現在の設定を記録してログを確認します。サブスクリプションの失敗ではURLとネットワーク経路、プロトコルエラーではコアの対応、システムプロキシが効かない場合はクライアントのモードとシステム設定を重点的に確認します。問題を正しい層に分類するほうが、すべての設定を一度に置き換えるより効果的です。

quick.checklist

よくある質問

初回利用時に特に混乱しやすいポイントをまとめています。詳しい操作手順とトラブルシューティングの順序はガイドページで解説しています。

v2rayNでサブスクリプションをインポートしたのにノードが表示されないのはなぜ？

まず、途中で切れたテキストではなく完全なサブスクリプションURLをインポートしたか確認します。次に該当するサブスクリプショングループを手動で更新し、更新メッセージやログを確認してください。URLにアクセスできるのに一覧が空の場合は、返された内容がクライアント対応のサブスクリプション形式か確認します。すべての設定を急いで削除せず、グループを残しておくと、原因がURL、ネットワーク経路、名前解決のどこにあるか判断しやすくなります。サブスクリプションのインポート手順を見る →

vmess://、vless://リンクとサブスクリプションURLの違いは？

共有リンクは通常1つのノードに対応し、アドレス、ポート、識別情報、通信パラメータを含みます。サブスクリプションURLは更新可能なノード一覧を返します。共有リンクは単一ノードのインポートに、サブスクリプションは複数ノードの継続的な管理に適しています。クライアント内の入口は異なる場合があり、単一ノードのリンクをサブスクリプション更新欄に入力して、リモート一覧が自動生成されると期待してはいけません。インポート方法を見る →

クライアントは接続済みなのにWebページを開けない場合、まず何を確認する？

ノード、DNS、ルーティング、システムプロキシの順に確認します。まず動作確認済みのノードへ切り替え、次にドメインの名前解決でエラーが出ていないか確認します。その後、一時的にシンプルなルーティングへ切り替えて、ルールによる誤ブロックを除外します。最後にシステムプロキシモードが実際に有効か確認してください。設定は毎回1項目だけ変更し、ログの変化を観察すると、障害の層を特定できます。接続確認の手順を見る →

v2rayNGとv2flyNGはどう選ぶ？

まずサブスクリプションのノードが求めるプロトコルを確認します。Xrayの拡張機能が必要なら、Xrayコアを採用するv2rayNGを選びます。設定がV2Flyの対応範囲にあり、V2Flyコアの系統を使いたい場合はv2flyNGを選択できます。UIが似ていても基盤機能が同じとは限らないため、インポート前にプロトコル、安全性パラメータ、通信方式を確認するほうが確実です。クライアントの選び方を見る →

technical.notes