クライアント一覧
デスクトップではv2rayN、Androidではv2rayNGが第一候補です。OSとCPUアーキテクチャを確認して、該当するダウンロード項目を選びましょう。
クライアントはサブスクリプションやサーバー設定を管理し、コアを起動するソフトです。インストーラーだけでリモート接続できるわけではありません。サブスクリプションURLまたは個別の設定情報を用意してから、使い方ガイドに沿って読み込みます。別の端末へ移行する場合、互換性のある接続情報は引き継げますが、ローカルポートやシステムプロキシ、アプリの権限は新しい端末で確認し直してください。
ダウンロードページではデスクトップ版と従来のWPF版を選べます。デスクトップ版は複数のデスクトップOSで共通の操作感を求める方に向いています。従来のデスクトップ画面に慣れている場合はWPF版を選ぶとよいでしょう。設定項目の場所は画面によって異なる場合がありますが、ガイドに記載された項目の意味は共通です。
インストール前に、システム設定の「システム → システム情報」でOSの種類を確認してください。初回起動後は、パラメーター設定でローカル待ち受けポートを確認してからシステムプロキシを設定します。複数のクライアントで同じシステムプロキシを同時に制御したり、同じポートを使ったりしないでください。サブスクリプションを読み込めても、アプリの通信が別の設定へ送られることがあります。
ダウンロードへ Windowsクライアント「このMacについて」に表示されるチップ情報を確認し、Apple SiliconまたはIntel向けのインストーラーを選びます。チップの種類で決まるのはプログラムのアーキテクチャであり、サブスクリプションで使うVMess、VLESS、Trojanとは関係ありません。インストール後はクライアントを起動し、設定ディレクトリと動作状態を確認してから既存の接続設定を読み込んでください。
デスクトップアプリの通信がプロキシ経由になるかは、システムプロキシ設定に従うアプリかどうかにも左右されます。ブラウザーでアクセスできても、ターミナルのプログラムが同じ経路を使うとは限りません。まずシステムプロキシに対応したアプリで確認し、その後ほかのアプリ固有のプロキシ設定を調べましょう。インストール権限に関する警告が出た場合は、表示された理由を確認してください。セキュリティ設定全体を無効にして対処するのは避けましょう。
ダウンロードへ macOSクライアントv2rayNGはXrayコアを使用します。V2Flyコアが必要な場合は、代替としてv2flyNGを確認してください。比較的新しいスマートフォンの多くはarm64ですが、判別できない場合は汎用版の説明を参照しましょう。対応プロトコルはそれぞれのコアによって異なります。名前が似ているだけで、すべての設定をそのまま使えるとは限りません。
初回接続時、システムからVPN接続の許可を求められます。これはクライアントが端末のネットワーク通信を受け取るためのもので、リモートサーバーが利用可能かどうかとは別の問題です。画面ロック後に接続が頻繁に切れる場合は、バッテリー最適化やバックグラウンド実行の制限を確認してください。ほかのアプリがVPN接続を使用していないかも確認しましょう。サブスクリプション、接続権限、バックグラウンド動作の設定を個別に調べることで、原因を変えないまま再インストールを繰り返すのを防げます。
ダウンロードへ Androidクライアントディストリビューションのパッケージ管理方式に合わせてdebまたはrpmを選び、さらにx64とarm64を区別します。ディストリビューション名とCPUアーキテクチャは別々に確認する項目です。同じdeb形式でも、必要なアーキテクチャが異なる場合があります。ダウンロードページで各パッケージを選べます。インストール前にシステム情報を確認し、アーキテクチャの不一致をソフトの不具合と誤認しないようにしましょう。
デスクトップ環境のシステムプロキシ設定は、通常、その設定に従うアプリにだけ適用されます。各プログラムの環境変数まで自動で設定されるわけではありません。初めて使うときはループバックアドレスで待ち受け、デスクトップブラウザーで接続を確認しましょう。ほかのプログラムにも個別にプロキシを設定する場合は、実際に使うプロトコルとポートを指定します。サービスが起動しないときは、ポート競合、権限、設定エラーに関するログを先に確認し、待ち受け範囲をむやみに広げないでください。
ダウンロードへ Linuxクライアントすべてのクライアントを見る → コアや操作方法を比較するには、選び方ガイドをご覧ください。
設定項目別リーダー
inboundsがリクエストを受け取り、routingが経路を選び、outboundsが接続を実行します。まずtagによる連携を確認してから、DNSやポリシーを調整しましょう。
以下は設定の一部を示す例であり、リモートサービスへそのまま接続できる完全なファイルではありません。一般的なV2Ray設定の構造を使っています。特定のプロトコルや拡張フィールドを使う場合は、実際に動作するコアの仕様も確認してください。画面内のfinalはデフォルトの処理方針を表すもので、ここで追加したJSONのトップレベル項目ではありません。
inboundsでは、リクエストを受け付けるアドレスとポート、使用するプロキシプロトコルを定義します。端末内のアプリから接続する場合は、通常ループバックアドレスを使い、プロキシポートをLANに公開しないようにします。例ではSOCKSとHTTPを別々のポートで待ち受けています。アプリ側でも対応するプロトコルを指定してください。ポートに固定の標準値はないため、クライアント設定に表示された実際の値を使います。システムプロキシとは異なり、inboundsを設定しただけではブラウザーにプロキシの使用を通知できません。両方を正しく設定して初めてリクエストがコアに届きます。
{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "auth": "noauth", "udp": true }
},
{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}
]
}outboundsは、受け取ったリクエストを宛先へ送ります。直接接続にはfreedom、遮断にはblackholeを使います。プロキシ経由のアウトバウンドには、対応するプロトコルのリモート接続情報が必要です。tagは設定内で参照する名前であり、プロトコル名ではありません。routingのoutboundTagは、ここで定義したtagと完全に一致させる必要があります。この例に含まれるのは直接接続と遮断だけで、リモートプロキシはありません。一般的な設定では、ルールに一致しない場合に配列の先頭のアウトバウンドが使われることがあります。ルールだけでなく、配列の順序も確認してください。
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}ルーティングルールは上から順に判定され、一致すると対応するアウトバウンドが選択されます。前の広い条件が先にリクエストを処理してしまわないよう、より具体的なドメインやアドレスのルールを先に配置してください。この例では、プライベートアドレスをdirectへ送ります。このアウトバウンドが定義済みであることが前提です。IPIfNonMatchは、ドメインルールに一致しないときにアドレスを解決して判定することを示します。すべてのアプリが組み込みDNSを一律に使うという意味ではありません。geoipやgeositeが参照するデータセットも利用可能である必要があり、ルールの記述自体にデータは含まれません。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}dnsモジュールでは、コア内蔵リゾルバーが使用するサーバーを設定します。DNSが使われるタイミングは、ルーティングポリシーやアウトバウンド設定、アプリがドメイン名とIPアドレスのどちらを渡すかによっても変わります。この例ではhostsによる静的な対応付けと、DNSサーバーの基本構造を示しています。これらの項目を追加するだけで、すべてのDNS通信を処理できるわけではありません。ブラウザーの暗号化DNS、システムのリゾルバー、コアのリゾルバーが同時に使われる場合もあります。名前解決の経路を調べるときは、リクエストの発生元と使用されたアウトバウンドをそれぞれ確認し、想定どおりか判断してください。
{
"dns": {
"hosts": {
"domain:example.com": "192.0.2.1"
},
"servers": [
"https://1.1.1.1/dns-query"
],
"queryStrategy": "UseIPv4"
}
}policyでは、ユーザーレベルに応じた接続ポリシーを設定します。たとえば、ハンドシェイクの待ち時間やアイドル接続のタイムアウトを指定できます。levelsの数値キーはレベルを表し、サーバー番号ではありません。関連するユーザー設定で対応するlevelを指定すると、ポリシーが適用されます。例の時間単位は秒で、数値は構造を示すためのものです。あらゆるネットワークに適した推奨値ではありません。タイムアウトを短くしすぎると、遅いハンドシェイクや長時間接続が切れることがあります。接続が途切れる場合は、ログとネットワーク状態を確認してから、一度に一つの値だけを変更して比較してください。
{
"policy": {
"levels": {
"0": {
"handshake": 4,
"connIdle": 300,
"uplinkOnly": 2,
"downlinkOnly": 5
}
}
}
}サブスクリプションはクライアントが管理するもので、V2RayコアのJSONトップレベルキーではありません。クライアントはサブスクリプションの内容を読み込み、接続情報を実行可能な設定に変換します。サブスクリプションの更新は、コアのアップデートとは別です。サブスクリプションURLにアクセス用の認証情報が含まれる場合があるため、スクリーンショットや公開ログに表示しないよう注意してください。以下は有効なコア設定の一部で、最終的な設定におけるoutboundsの位置を示しています。サブスクリプション形式ではありません。directしか含まれていないため、サブスクリプションの読み込みの代わりにはなりません。実際のプロキシ情報は、利用可能な接続設定から生成してください。
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}クイックスタート
まず通信経路を一つ確実に検証してから、振り分けルールを追加します。各手順に確認ポイントを設けましょう。
v2rayNのサブスクリプショングループに既存のサブスクリプションURLを追加し、見分けやすい名前を付けてから更新します。共有リンクを1件だけ使う場合は、クライアントのクリップボードから読み込む機能を使ってください。個別リンクをサブスクリプションURLとして何度も更新する必要はありません。v2rayNGではサブスクリプショングループの設定とメイン画面のメニューから操作します。基本の流れは同じで、接続情報の保存、取得、読み込み結果の確認の順です。
読み込み後、選択できる設定が一覧に表示されていることと、プロトコルの種類が想定どおりであることを確認します。サブスクリプションの一覧が空、形式エラー、アクセス失敗といった場合は、まず内容を取得できるようにしてください。すぐにローカルのルーティングを変更する必要はありません。サブスクリプションには認証情報が含まれる場合があります。調査用のスクリーンショットでは、URL全体、ユーザーID、認証情報を隠してください。問題を共有する場合は、エラーの種類と操作手順が分かれば十分です。
接続に使う設定を一つ選択します。設定が一覧にあるだけでは有効とは限らず、更新に成功しても接続先に到達できるとは限りません。「設定情報を読み込んだこと」と「現在の接続設定として選択したこと」を分けて確認すると、その後の接続テストの対象が明確になります。
デスクトップ版では、パラメーター設定で待ち受けアドレスとポートを確認し、「システムプロキシを自動設定」を選びます。これにより、システムプロキシに従うアプリのリクエストがローカルクライアントへ送られます。リクエストがコアに届いた後、どのアウトバウンドを使うかはルーティングモードで決まります。両者は異なる階層の設定です。「グローバル」という言葉だけで同一視しないでください。ルーティングを変更しても、システムプロキシを使わないアプリが自動的にプロキシ経由になるわけではありません。
普段の通信振り分けには、まずクライアントのプリセットモードを使い、基本接続を確認してからカスタムルールを追加しましょう。ブラウザーのプロキシ拡張機能を使う場合は、拡張機能のプロトコルとポートをクライアントに合わせ、拡張機能とシステム設定が互いに上書きしないようにします。Androidでは、まずシステムの接続許可を確認し、アプリごとの振り分け範囲にテスト対象のアプリが含まれているか確認してください。
パソコンに別のプロキシソフトがある場合は、いったん終了するか、異なるポートを割り当てます。ポートが使用中だと、画面に設定が表示されていてもコアが正常に待ち受けできない場合があります。サブスクリプションを変更するのではなく、起動ログで原因を調べてください。
接続を開始したら、まずブラウザーで利用可能と分かっているページを開き、名前解決と読み込みができるか確認してから、クライアントのログで接続エラーを調べます。遅延テストの結果は、特定のテスト先と測定方法を反映するだけで、実際のアプリでの動作確認に代わるものではありません。ページを開けない場合は、「アプリのプロキシ設定 → ローカル待ち受け → ルーティングの一致 → リモート接続 → DNS名前解決」の順に確認し、複数の設定を同時に変更しないようにしましょう。
一部のサイトだけで問題が起きる場合は、そのサイトに適用されるドメインルールとアドレスルールを確認します。すべてのアプリで問題がある場合は、まずコアの起動状態とシステムプロキシを調べてください。認証やハンドシェイクの失敗では、端末の時刻と接続情報を確認します。ログには宛先ドメインや設定の識別情報が含まれる場合があります。公開して質問する前に、トラブルと無関係な機密情報を削除してください。
検証が済んだら、動作したモードとポートを記録し、以降は一度に一種類の設定だけを変更します。デスクトップクライアントを終了する前に、必要に応じてシステムプロキシを解除してください。解除しないと、アプリが停止済みのローカルポートへリクエストを送り続けることがあります。詳しい手順は完全版ガイドで各確認ポイントごとに解説しています。
Project V · V2Fly · Xray
Project Vは、ネットワークプロキシツールを中心とするオープンソースのエコシステムです。V2Rayはその主要な構成要素の一つです。V2FlyコミュニティはV2Rayの保守と発展を引き継いでいます。Xrayも関連技術を基盤に開発され、独自のプロトコル実装や機能拡張を備えています。共通する設定概念はありますが、同じ実行プログラムではありません。コアの名前を自由に置き換えられるラベルとして扱わないでください。
設定を読むときは、まずどのコアが実行されているかを確認し、そのコアが対応する項目やプロトコルの組み合わせを調べます。たとえばVLESSはプロキシプロトコル、REALITYは接続のセキュリティに関する設定で、同じ階層の代替項目ではありません。共有リンクをクライアントが認識できても、選択中のコアがすべてのパラメーターに対応しているとは限りません。生成された設定と起動結果も確認してください。
v2rayN、v2rayNG、v2flyNGはいずれもソースコードを公開しています。v2rayNはデスクトップ向けで、サブスクリプション、サーバー選択、ルーティング、システムプロキシをGUIで管理できます。v2rayNGはAndroid向けで、Xrayコアを採用しています。v2flyNGはV2FlyコアをベースにしたAndroid向けの選択肢です。オープンソースであることは、各クライアントの機能が完全に同じという意味ではありません。
GUIクライアントは操作や設定の管理を担い、コアはプロトコル処理と接続の転送を行います。画面操作の問題はまずクライアントの設定を確認し、未知の項目やプロトコル非対応の問題はコアの機能を調べましょう。この2つの役割を区別すると、サブスクリプション形式、画面上の項目、コアの構文を混同しにくくなります。同じ接続情報でもクライアントによって表示が異なる理由も理解しやすくなります。
V2FlyのV2RayコアとXrayコアはMPL 2.0ライセンスを採用しています。クライアントプロジェクトにはそれぞれ別のオープンソースライセンスがあるため、配布、改変、組み合わせて利用する場合は、各ライセンスの条文を確認してください。コアのライセンスをクライアントのライセンスの代わりにすることはできません。一般ユーザーにとっては、機能説明やリリース履歴、実際の端末での互換性がより直接的な判断材料になります。
コミュニティによる保守には、OSへの対応、プロトコルの互換性、問題の修正などが含まれます。更新のたびに既存設定を変更する必要があるわけではありません。変更内容を読むときは、デフォルト値の変更、旧項目の削除、読み込み動作の変更に注目しましょう。安定して使えている設定がある場合は、復元できるように控えを残してから新機能を試してください。項目を一括置換する方法を、汎用的な更新手順として使わないでください。
クライアントを更新するとGUIや設定管理機能が変わり、コアを更新するとプロトコル処理機能が変わります。サブスクリプションを更新すると、接続先から新しい接続情報を取得できます。それぞれ更新方法やタイミングが異なる場合があります。サブスクリプションの更新に成功しても、ローカルのポート競合は解消されません。クライアントを更新しても、期限切れの認証情報が再び使えるようにはなりません。
このガイドは、特定の画面のスクリーンショットではなく、設定項目とJSONキー名に沿って構成しています。画面が変わっても、待ち受けアドレス、アウトバウンドのtag、ルーティング条件、DNSサーバーなどの概念を手がかりに設定を探せます。インストーラーが必要ならダウンロードページへ、設定項目の関係を知りたい場合はJSONガイドへ進んでください。起動できてもアクセスできない場合は、チュートリアルの手順に沿って段階的に原因を絞り込みます。
利用メモとトラブル対処
一覧に表示される項目からアプリの通信経路まで、症状ごとに設定を見直し、すべての問題を一つの設定のせいにしないようにします。
接続先一覧にある遅延、通信量倍率、地域表示、プロトコルの意味を解説し、普段のブラウジング、動画視聴、ゲームなど用途別の選び方を紹介します。測定条件を確認してから実際のアプリで試し、数値一つだけで順位を決めないようにしましょう。
接続先の選び方を読む →URLの期限切れ、プロキシ経由での更新、証明書や形式のエラーなど、更新に失敗する原因をまとめ、2つのクライアントで定期的に自動更新する設定を紹介します。URLにアクセスできない場合と、取得した内容を解析できない場合を区別し、エラーが起きた段階に合った設定を確認しましょう。
サブスクリプション更新ガイドを読む →システムプロキシのモード、ローカルポートの競合、時刻同期、ルーティングルール、接続先の状態を順番に確認し、接続済みなのに通信できない問題を段階的に切り分けます。複数の項目を同時に変更するより、再現できるテスト条件を保つほうが原因を特定しやすくなります。
接続トラブルの確認リストを読む →