Windows
v2rayNにはデスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来の操作感を維持しています。まず動作要件を確認し、使い方に合う方を選びましょう。
ダウンロードページへ →OSに合ったクライアントを選び、サブスクリプションを取り込んで設定を作成します。次にルーティングで直結とプロキシを振り分け、必要に応じてコア、Tun、DNSを調整します。
CLIENT SELECTION
まずOSとCPUアーキテクチャを確認し、対応するインストーラーを選びます。デスクトップではv2rayN、Androidではv2rayNGが基本です。V2Flyの設定を使う場合はv2flyNGも検討できます。クライアントは設定を管理するもので、接続には有効なサーバー情報が別途必要です。
v2rayNにはデスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来の操作感を維持しています。まず動作要件を確認し、使い方に合う方を選びましょう。
ダウンロードページへ →v2rayNデスクトップ版を選びます。「このMacについて」でチップの種類を確認してください。Apple SiliconとIntelではインストーラーが異なるため、外観だけで判断しないようにしましょう。
ダウンロードページへ →まずはXrayコアを採用したv2rayNGがおすすめです。V2Flyコアのv2flyNGは代替候補になります。通常はarm64版を確認し、アーキテクチャが不明な場合はユニバーサル版の説明を参照してください。
ダウンロードページへ →v2rayNデスクトップ版を使い、ディストリビューションに合わせてdebまたはrpmを選びます。さらにx64とarm64を区別してください。パッケージ形式とCPUアーキテクチャの両方を一致させる必要があります。
ダウンロードページへ →インストーラーで決まるのは、クライアントがその端末で動作するかどうかです。サーバー側のプロトコルは決まりません。サブスクリプションがある場合は、まず指定されたコアとプロトコルを確認してからインストーラーを選びましょう。別のデスクトップ向けアーキテクチャ用インストーラーで失敗しても、サブスクリプションが無効とは限りません。
すべてのクライアントを見る →CONFIGURATION WORKSPACE
サブスクリプションはサーバー情報の取得元、ルーティングは通信の転送先、コアは設定の実行を担います。まず役割を整理してから個別の設定を調整しましょう。以下の例は設定項目の説明用で、既存の設定ファイルをそのまま置き換えるものではありません。GUIのメニュー名はクライアントの更新により変わる場合があります。
サブスクリプションURLはサーバー設定を取得するためのもので、個別サーバーの共有リンクとは異なります。クライアントで取得元ごとにグループを作り、サブスクリプションURLを入力して更新し、取得結果を確認してください。サーバー情報を1件ずつ手動登録するより、接続設定をまとめて管理できます。ただし、ローカルで変更した項目は次回更新時に作り直される場合があります。取得元が分かるグループ名を付け、まず手動で更新してから自動更新を設定しましょう。サブスクリプションには接続情報が含まれるため、問題を調べる際はURL全体を隠し、公開スクリーンショットに載せないでください。
{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
},
{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}
]
}
サブスクリプションはクライアントで管理するもので、汎用コアの設定項目ではありません。ここでは、取り込み後に利用できるローカルインバウンドの構成を示しています。ポート番号は実際の設定に合わせてください。
取り込み手順を見る →ルーティングルールは上から順に照合され、一致すると指定した出力先に転送されます。まずLANや特定ドメインのルールを置き、次に対象範囲の広いルール、最後に残りの通信を処理するルールを置きます。全体モードを切り替えるだけの場合と比べ、ルーティングを使えば直結・プロキシ・ブロックを個別に設定でき、互いの影響を抑えられます。設定時は出力先のタグが実際に存在することを確認し、ドメインルールセットとIPルールセットが利用可能かもチェックしてください。同じルール内の複数条件は通常すべて満たす必要があります。別々に一致させたい条件を1つのルールにまとめないようにしましょう。変更後はログで一致したルールを確認してください。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
この例では、directとproxyの出力先、および対応するルールデータがすでに設定されている必要があります。フォールバックルールは個別ルールの後に配置してください。
ルーティングの解説を見る →コアはプロトコルの処理と接続の実行を担い、クライアントは画面と設定を管理します。コアを選ぶときは名前だけでなく、サーバーが指定するプロトコルと通信方式を確認してください。REALITYやXTLS Visionを使う場合は、必要な機能に対応するXrayの設定環境が必要です。既存のV2Fly設定を使う場合は、移行先コアの設定項目を確認しましょう。共通する設定概念はありますが、すべての項目を相互に置き換えられるわけではありません。切り替え前に元の設定を保存し、切り替え後は起動ログと実際の接続を確認して、設定項目の非互換をサーバー障害と誤認しないようにしてください。
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}
これは2種類のコアでよく使われる基本的な出力先の構成例です。コアの切り替え指示ではなく、プロキシサーバーへの出力設定も含みません。
コアの違いを比較する →システムプロキシは、OSのプロキシ設定に従うアプリに適しています。Tunモードは仮想ネットワークインターフェースを使って通信を取り込み、システムプロキシを参照しない一部のアプリにも適用できます。ただし、ルーティングルールの代わりではありません。取り込んだ通信を直結させるかプロキシへ送るかは、別途設定が必要です。有効にする前に通常のプロキシ接続が使えることを確認し、必要な権限を許可したうえで、ほかの仮想ネットワークインターフェースやプロキシアプリが同時に動作していないか確認してください。Androidクライアントは通常、OSのVPN機能を使って通信を取り込みます。デスクトップ版の仕組みと同一ではありません。問題が起きたら、まず通信の取り込みを停止して基本接続を復旧し、順番に原因を調べましょう。
{
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["socks-in", "http-in"],
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
この例は通信の取り込み層とルーティング層の違いを示すもので、仮想ネットワークインターフェースを作成する設定ではありません。Tunの具体的な設定はクライアントと関連コンポーネントによって異なります。
プロキシモードの選び方を見る →DNS名前解決はドメイン名をIPアドレスに変換します。名前解決の経路と接続経路はあわせて考える必要があります。直結するドメインには現在のネットワークから到達できるDNSを使い、プロキシ経由のドメインではリモート側の名前解決が通るか確認してください。DNSサーバーのアドレスを1つ変えただけで、すべてのアプリが同じ方法で名前解決するとは限りません。ブラウザーのセキュアDNS、OSのキャッシュ、クライアント内蔵DNSがそれぞれ使われる場合があります。まず動作している基本設定を維持し、ドメインの名前解決と接続先への通信を分けてテストしましょう。暗号化DNSを使う場合は、DNSサーバー自身のドメインを最初に解決する際の問題にも注意してください。
{
"dns": {
"servers": [
{
"address": "223.5.5.5",
"domains": ["geosite:cn"]
},
"https://1.1.1.1/dns-query"
]
}
}
DNSサーバーのアドレスは例です。この設定例だけではDNSリクエストの出力経路は指定されません。ルーティング設定と現在のコアの動作をあわせて確認してください。
DNS設定の解説を見る →FIRST CONNECTION
まず接続を確認できる基本設定を作り、その後にルーティングと通信の取り込みを追加します。デスクトップでは主にv2rayN、Androidでは主にv2rayNGを使用します。画面上のボタン位置は異なりますが、取り込み、選択、接続、確認の流れは共通です。
STEP 01
サブスクリプション管理でグループを作り、URL全体を貼り付けて保存した後、手動で更新します。個別の共有リンクを受け取った場合は、サブスクリプション欄ではなく、クリップボードからの取り込みや対応する共有リンクの取り込み機能を使ってください。
更新が終わったら、まず選択可能な設定が一覧に表示されているか確認し、次にプロトコルの種類、ポート、通信方式の項目が揃っているかをチェックします。一覧が空の場合は、URLをすべてコピーできているか、サブスクリプションが有効か、現在のネットワークから配信元にアクセスできるかを確認してください。クライアントを何度も再インストールしても、配信元URLの問題は解決しないことがほとんどです。
STEP 02
使うサーバー設定を選択し、プロトコルが現在のコアに対応していることを確認します。デスクトップで初めて使う場合は、まずシステムプロキシを有効にし、用途に合ったルーティングモードを選びましょう。AndroidではOSの案内に従ってVPN接続を許可してください。
システムプロキシのスイッチは、どのアプリがリクエストをクライアントに渡すかを決めます。ルーティングモードは、受け取ったリクエストをクライアントがどう転送するかを決めます。両者は代替できません。まず分かりやすい初期設定を使い、接続を確認してから独自のドメインルールを追加しましょう。複数の設定を同時に変更すると、原因を特定しにくくなります。
STEP 03
接続を開始したら、直結する想定のサイトとプロキシ経由の想定のサイトをそれぞれ開き、クライアントのログで実際の出力先を確認します。1回の接続テストで分かるのは、そのテストが成功したことだけです。ブラウザー、ダウンロードアプリ、ほかのアプリが同じ経路を使うとは限りません。
ブラウザーは使えるのにほかのアプリで失敗する場合は、そのアプリがシステムプロキシに従うかをまず確認してください。使用を終える際は、システムプロキシまたは仮想ネットワークインターフェースによる通信の取り込みを停止してから、クライアントを終了します。終了後にネットワーク異常が起きたら、ネットワーク設定をすべて変更する前に、停止したローカルポートがシステムプロキシに残っていないか確認しましょう。
サブスクリプションの更新失敗、コアの起動失敗、アプリの接続失敗は、それぞれ異なる段階の問題です。問題が起きた段階を記録し、その段階に関係する設定を1つだけ変更して、同じテストを繰り返してください。有効な設定を維持しながら、DNS、権限、サーバー情報の問題を切り分けられます。
PROJECT V ECOSYSTEM
V2Rayは広く使われるエコシステムの呼称であり、すべて同じ画面の単一アプリを指すものではありません。クライアント、コア、プロトコルの関係を理解すれば、インストーラーを変えるべきか、設定を見直すべきか、サーバー側の要件を確認すべきか判断しやすくなります。
Project Vは、モジュール式のネットワークプロキシツールを中心とするプロジェクトです。設定には通常、インバウンド、アウトバウンド、ルーティング、DNSなどが含まれます。V2FlyはV2Ray関連コアのコミュニティ開発を引き継ぎ、Xrayは関連コードを基盤に独自のプロトコルや通信機能を発展させています。共通の背景を持つ一方、それぞれ設定の進化は異なります。常に同じ実行プログラムとして扱うことはできません。
実際の選定はサーバーの要件から始めましょう。まずプロトコル、次に通信方式とセキュリティ層、最後にコアの対応状況を確認します。たとえばVLESS、REALITY、Visionはそれぞれ異なる設定概念に関わります。名称を1つ見ただけで、接続全体に互換性があるとは判断できません。クライアントに項目が表示されても、サーバー側でその機能が有効とは限りません。
コアの名称は速度ランキングではありません。接続品質はサーバー回線、接続先サイト、名前解決の結果、ローカルネットワークにも左右されます。問題が起きた場合は、動作している構成を残し、同じ条件で設定変更の前後を比較しましょう。すべてのコンポーネントを一度に変更するより、原因を確実に判断できます。
v2rayNはデスクトップ向けの設定管理画面を提供し、サーバー情報、サブスクリプショングループ、ルーティング設定をまとめて、連携するコアに処理を引き継ぎます。v2rayNGはAndroid向けでXrayコアを採用し、v2flyNGはAndroid向けでV2Flyコアを採用しています。いずれもオープンソースプロジェクトですが、画面の機能、コアの組み合わせ、OSとの連携方法はそれぞれ異なります。
デスクトップ版が複数のOSに対応していても、システム権限や通信の取り込み方法まで同じとは限りません。OSごとにプロキシ設定、仮想ネットワークインターフェースの権限、パッケージ形式が異なります。設定を移行するときは、まずサーバー情報やサブスクリプションの取得元など明確な項目を移し、その後でローカルポート、ファイルパス、OS固有の設定を確認してください。
クライアントはサーバーサービスそのものではありません。インストール後も有効な接続情報を取り込む必要があります。サブスクリプションの有効期限、サーバーへの接続性、クライアントの動作状態は分けて確認しましょう。このサイトではクライアントの導入と設定を中心に解説し、ダウンロード先と初期設定の手順はそれぞれのページにまとめています。
オープンソースとは、ライセンス条件のもとでソースコードが公開され、コミュニティによる閲覧、研究、保守への参加が可能であることを意味します。V2FlyコアはMITライセンス、Xray-coreはMPL 2.0ライセンスを採用しています。GUIクライアントや依存コンポーネントには、それぞれ別のライセンス条件があります。利用、改変、再配布の際は、対象プロジェクトと依存コンポーネントのライセンスを個別に確認してください。エコシステム名だけで、すべての利用条件を一括りにはできません。
オープンソースであることと、サーバーサービスの料金も別の話です。クライアントは無料で使えても、外部サービスの料金体系、接続制限、有効期間はサービス提供者が決めます。クライアントをインストールできたからといってサブスクリプションが必ず使えるとは限りません。サブスクリプションの制限をクライアントの機能制限と混同しないようにしましょう。
接続情報は機密性の高い設定です。ログを共有する際は、サブスクリプションURL全体、ユーザー識別情報、認証情報を削除し、エラーの種類、関係する設定層、再現手順だけを残してください。設定全体を公開するより、問題の内容を明確に伝える方が原因の特定に役立ちます。
GUIの更新、コアの更新、ルールデータの更新、サブスクリプションの更新は、それぞれ異なる操作です。GUIの更新ではメニューや初期動作が変わる場合があります。コアの更新はプロトコル実装や設定項目の互換性に関わり、ルールデータの更新はドメインやIPアドレスの集合に影響します。サブスクリプションの更新ではサーバー情報を再取得します。問題を調べるときは、直近でどの層を変更したかをまず確認しましょう。
更新前にサブスクリプショングループ、必要なカスタムルール、動作中の設定を保存してください。更新後はまず従来の基本接続を確認し、その後で新機能を有効にします。自動生成される実行時設定は再起動や保存時に上書きされる場合があります。長期的に使うルールは、一時生成ファイルを直接編集するのではなく、クライアントが用意する永続設定の画面で管理しましょう。
設定を保守する際は、使用中のコアの系統、通信の取り込み方法、DNSポリシー、カスタム出力先タグを簡潔に記録しておくと便利です。接続情報を含める必要はありません。「設定が上書きされた」「ルールに一致しない」「サーバーに到達できない」を切り分けやすくなり、応用ガイドに沿って段階的に調整できます。
まずインバウンドがアプリのリクエストをどう受け取るかを確認し、次にルーティングが出力先をどう選ぶか、最後に出力先のプロトコルと名前解決経路を確認します。例を読むときは、完全な設定と一部分の設定を区別してください。対応する出力先タグがない状態でルーティングルールだけをコピーしても、接続設定としては動作しません。
プロトコルと応用設定へ →CONFIGURATION NOTES
初回の接続ができたら、実際に困っている内容に合わせて詳しく読み進めましょう。プロキシモード、デスクトップ版の画面の違い、サーバー設定の選び方はそれぞれ別の判断事項です。分けて理解すれば、初回のインストール時にすべてを把握する必要はありません。
システムプロキシのスイッチとルーティングモードは別の設定です。グローバルと大陸をバイパスするモードの振り分け方を説明し、Tunモードで全通信を取り込むべき場面も紹介します。
「ブラウザーは使えるのに、ほかのアプリは変わらない」といった問題の解決に役立ちます。通信がクライアントに届いているか、届いた後にどのルールに一致したかを順に確認しましょう。モード名を何度も切り替えるだけでは原因を特定できません。
記事を読む →2種類のUIフレームワークで構築されたv2rayNについて、デスクトップOSごとの対応状況、外観、依存関係を比較し、OSに合ったダウンロード版を案内します。
ダウンロード前にインストーラーを確認したい方におすすめです。UIフレームワークは操作感や対応OSに影響しますが、プロトコルの種類を表すものではありません。画面を選んだ後も、対応するコアとサーバーの要件を確認してください。
記事を読む →クライアントの遅延測定で分かることと限界、通信量倍率の計算方法を解説。用途に合わせた地域とプロトコルの選び方も順に紹介し、初めての方の試行錯誤を減らします。
サブスクリプションを取り込んだものの、どの設定を選ぶか迷っている方におすすめです。テスト結果は特定の条件での測定にすぎません。実際の接続先、接続の安定性、サービスの説明も踏まえて判断し、単一の結果だけに頼らないようにしましょう。
記事を読む →各設定ガイドでは、個別の設定判断を解説します。複数の操作を連続して行う手順は入門ガイドから始めてください。複数のサブスクリプション管理、カスタム出力先、より複雑な名前解決ポリシーが必要な場合は、応用設定ガイドに進み、項目ごとに動作を確認してから保存しましょう。
すべての記事を見る →