オープンソースクライアントのインストール先、サブスクリプションのインポート、JSON設定リファレンスを紹介。システムプロキシからルーティングまで、通信の流れに沿って解説します。
まずOSを確認し、次にCPUアーキテクチャを選びます。デスクトップではv2rayN、Androidではv2rayNGが候補です。V2Flyの設定を使う場合は、v2flyNGとの互換性も確認してください。
Windows版v2rayNには、クロスプラットフォームのUIと、従来のデスクトップ操作を維持したWPF版があります。メニューの場所は異なる場合がありますが、サブスクリプションのインポート、サーバーの選択、システムプロキシの設定という基本的な流れは共通です。初めて使うときはどちらか一方を選び、複数のインスタンス間でポートやシステムプロキシを変更しないようにしましょう。インストール前に動作要件を確認してください。設定を移行する場合は、先に元の設定をエクスポートし、新しいインスタンスで使用するカーネルと作業ディレクトリを確認します。
macOSでは「このMacについて」からチップの種類を確認できます。Apple SiliconとIntelではダウンロード先が異なります。Linuxではディストリビューションのパッケージ形式とデバイスのアーキテクチャをそれぞれ確認してください。DebianやUbuntu系ではdeb、Fedoraなどではrpmが一般的です。パッケージ形式とCPUアーキテクチャは別の条件なので、ファイルの拡張子だけで適合性を判断しないでください。デスクトップでの起動方法や依存関係は、プラットフォーム別のインストールガイドをご覧ください。
Android版v2rayNGはXrayカーネルを使用するため、接続パラメーターはXrayの項目説明を参考にできます。v2flyNGはV2Flyカーネルを使う選択肢です。比較的新しい端末の多くはarm64を選べますが、アーキテクチャが不明な場合は汎用パッケージの説明を確認してください。クライアント名が似ていても、対応するトランスポートの組み合わせまで同じとは限りません。既存の設定をインポートする前に、プロトコル、トランスポート層、安全性の設定を確認しましょう。特定カーネルの拡張フィールドが、すべてのクライアントで使える共通項目だと思い込まないよう注意してください。
インストールが完了しても、プログラムが起動できる状態になっただけで、接続に使えるリモート設定が用意されたわけではありません。サブスクリプションURL、サーバーアドレス、認証情報は利用者自身で準備する必要があります。初回インポート後は設定一覧に有効な項目が表示されているか確認し、続いてカーネルログを確認してください。複数のプロキシクライアントを同時に起動しないようにしましょう。一覧が空の場合、ルーティングルールを変更する前に、インポート形式やサブスクリプションの応答を確認します。クライアントごとの詳しい違いは3つのクライアントを比較をご覧ください。
通信の流れに沿って設定項目を確認できます。アプリはまずinboundに接続し、routingが出口を選び、outboundが接続を確立します。サブスクリプションとシステムプロキシはクライアント側の管理機能であり、JSONのルートオブジェクトに必ず同名の項目があるわけではありません。
inboundは、カーネルが接続を受け付ける方法を定義します。アプリからSOCKSプロキシを使う場合は、接続先のアドレスとポートを該当するinboundに設定します。カーネルを起動しただけでは、すべてのアプリが自動的にこの入口を使うわけではありません。例ではループバックアドレスで待ち受けるため、接続できるのは同じ端末上のアプリだけです。tagを付けると、後続のルーティングから参照できます。接続拒否を調べる際は、まずポートが待ち受け中か、他のプロセスに使われていないかを確認し、その後アプリ側のプロキシ種別を確認してください。クライアントが使うポートは環境によって異なるため、実際の設定を参照し、例の数値をそのまま使わないでください。
{
"inbounds": [{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}]
}outboundは、カーネルが宛先への接続を確立する方法を定義します。リモートプロキシへの接続のほか、直接接続やブロックも指定できます。routingのoutboundTagは、定義済みのtagと綴り・大文字小文字まで一致させてください。この例が示すのはdirectとblockのみで、リモート接続のパラメーターは含まれていません。完全なプロキシ設定の代わりにはなりません。問題を調べるときは、サーバーアドレス、認証情報、トランスポート層、安全性の設定を分けて確認してください。GUIクライアントでは通常、サーバー設定からリモートoutboundが生成されます。元のJSONを編集する前に、次回の保存で手動の変更が上書きされないか確認しましょう。
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}routingは、カーネルに届いた通信をoutboundに振り分けます。ルールは上から順に評価されるため、広い条件を先に置くと、後続の細かいルールに到達しないことがあります。この例ではプライベートアドレスをdirect outboundに送ります。対応するoutboundのtagと地理データファイルが必要です。domainStrategyはルーティング判定時にドメイン名を解決するかを決めるもので、システムのDNS設定とは異なります。ルールを確認するときは、まずアプリの通信がクライアントに届いていることを確かめ、その後、適用されたルールと出口を調べてください。inboundに届いていない通信は、ここで設定したルールの対象になりません。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}]
}
}dnsセクションではカーネルが使うリゾルバーを設定しますが、すべてのアプリの名前解決経路が自動的に置き換わるわけではありません。ブラウザー内蔵の暗号化DNS、システムのDNSキャッシュ、アプリが直接送信するクエリは、それぞれ異なる経路を使う場合があります。この例はservers配列の構造を示すもので、すべてのネットワーク環境に適した設定ではありません。ドメインごとにリゾルバーを選ぶルールを追加する場合は、domains、expectIPs、routingの関係も理解しておく必要があります。ドメインにアクセスできないときは、リゾルバーだけを変えて誤ったルーティング条件を見落とさないよう、名前解決の結果、接続先、実際の出口を比較してください。
{
"dns": {
"servers": [
"1.1.1.1",
"8.8.8.8"
]
}
}サブスクリプショングループはクライアントが管理する機能で、設定の配信元や更新範囲を分けるために使います。汎用的なカーネルJSONにサブスクリプション用の項目があるわけではありません。更新に失敗した場合は、まずURLが有効か、応答が対応形式かを確認し、更新リクエストに既存のプロキシが必要かを調べてください。サブスクリプションの更新で通常変わるのはサーバー項目です。ルーティングやDNS設定まで自動修復されるわけではありません。以下のJSONはインポート後の起動状況を確認するためのカーネルログ例であり、サブスクリプション設定ではありません。ログやスクリーンショットを共有する前に、サブスクリプションURLと認証情報を削除してください。
{
"log": {
"loglevel": "warning"
}
}システムプロキシは、システム設定に従うアプリにローカルプロキシのアドレスを通知する機能です。カーネルのルーティングモードとは異なり、すべてのアプリの通信を取り込めるとは限りません。クライアントの「システムプロキシを設定」「システムプロキシを解除」はシステム側の入口に作用し、ルーティングルールは通信が入った後の行き先を決めます。この例はHTTPプロキシリクエストを受け付けるローカルinboundを示すもので、このJSONだけではシステム設定を変更できません。ブラウザーではアクセスできるのに他のアプリで失敗する場合は、サーバーをすぐに変更せず、アプリがシステムプロキシを参照するか、アドレスを個別に設定する必要があるかを確認してください。
{
"inbounds": [{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}]
}ここで紹介する設定例は各項目の役割を確認するためのもので、つなぎ合わせればリモート接続できる設定一式になるわけではありません。完全な設定ファイルには、有効なリモートoutbound、対応するtag、使用中のカーネルに適合したパラメーターが必要です。同じルート項目は一つのオブジェクトまたは配列にまとめてください。複数のJSONオブジェクトをそのまま連結することはできません。標準JSONではコメントと末尾のカンマは使えません。エディター上で整った書式に見えても、カーネルが項目を認識できるとは限りません。
GUIクライアントを使う場合は、まず該当する設定画面でよく使う項目を変更し、生成結果を確認してください。実行ディレクトリの設定ファイルを直接編集しても、その起動中しか反映されず、サーバーの切り替えや設定保存で再生成される場合があります。カスタム設定を使うときは、どのプログラムがファイルを管理し、いつ読み込み、エラーをどこに記録するかを把握しておきましょう。設定リファレンスでは、全体構造、inbound、outbound、routing、DNS、ポリシーの順に解説します。初回接続後の確認にお役立てください。
JSON設定リファレンスを開くまずは最小限の設定で接続し、分岐条件を一つずつ追加します。接続に影響する設定は一度に一つだけ変更し、元に戻せる設定のバックアップを残してください。
有効なサブスクリプションURL、またはクライアント対応の共有リンクを用意します。v2rayNの「サブスクリプショングループ設定」で配信元を追加して保存し、サブスクリプションを更新してください。共有リンクはクリップボードから個別にインポートできます。メニューの場所は実際の画面で確認してください。インポート後はサーバー一覧を開き、空の応答や通常のWebページが取り込まれていないか確認しましょう。
v2rayNGでは、追加メニューからクリップボードの設定をインポートしたり、サブスクリプションを管理したりできます。設定に含まれるアドレス、ポート、ユーザーID、トランスポートのパラメーターは、同じ有効な情報に基づいている必要があります。複数のガイドから設定を部分的に抜き出して組み合わせても接続できるとは限りません。サブスクリプションURLにはアクセス情報が含まれることが多いため、公開スクリーンショットや質問文に載せないでください。
一覧から使用するサーバーを選び、カーネルが起動できることを確認してください。デスクトップではアプリの用途に合わせてシステムプロキシを設定し、ルーティングにはまず内容が分かりやすいプリセットを使います。システムプロキシはアプリからクライアントへの入口を制御し、ルーティングモードは通信が入った後の出口を制御します。名前の似た設定を同じスイッチだと思わず、別々に確認してください。
Androidで初回接続するときは、システムのVPN接続許可を確認してください。この許可は、クライアントが端末内に通信の入口を作ることを認めるもので、リモート接続の成功を示すものではありません。端末ですでに別のVPN接続を使っている場合は、先に競合を解消してください。初回の動作確認では、原因を絞り込めるよう複雑なカスタムルールを同時に追加しないことをおすすめします。
実際に使うアプリからリクエストを送りながら、クライアントのログを確認してください。カーネルの起動、サーバーへの接続、特定アプリの通信がプロキシを経由することは、それぞれ別の確認項目です。該当するリクエストがログにない場合は、まずアプリ側の入口を確認してください。リクエストが記録されていて接続に失敗する場合は、サーバーの設定、名前解決の結果、ネットワーク到達性を調べます。
一覧に表示されるテスト結果だけで、すべてのアプリが正常に動作すると判断しないでください。リクエストによってプロトコルや名前解決の経路が異なる場合があります。基本接続を確認してから、ドメイン別ルーティング、アプリ別ルール、自動更新を一つずつ有効にしましょう。デスクトップクライアントを終了する前にシステムプロキシが解除されているか確認してください。解除されていないと、待ち受けを停止したローカルポートにアプリが接続し続けることがあります。
設定をインポートできるか、カーネルが起動するか、リクエストが届くか、宛先への接続が成功するかの順で確認します。この順序で調べると、形式、プロセス、入口、リモート側の問題を切り分けられます。たとえば「ポートが使用中」はローカルの起動に関する問題で、サブスクリプションを更新しても解決しません。証明書関連のエラーでは、システム時刻、サーバー名、該当するセキュリティ設定を確認してください。ルーティングの問題だと決めつけないようにしましょう。「使えない」とだけ伝えるより、エラーの全文を残しておくと原因を特定しやすくなります。
変更後に問題が発生したら、まず直近の正常な設定に戻し、変更した項目を一つずつ再現してください。ログにはサーバーアドレスやアクセス履歴が含まれる場合があります。問い合わせの前に機密情報を隠しましょう。よくあるエラーや設定の範囲はよくある質問を、プロトコルやカーネル、トランスポートの用語は用語集をご覧ください。クライアントの画面に表示される名称と、基盤となるプロトコル名を混同しないようにしましょう。
プロジェクト、カーネル、GUIクライアントはそれぞれ異なる層にあります。必要なプロトコルと設定を確認したうえで、OSや管理方法に合うものを選びましょう。
Project Vは、ネットワーク通信向けのツールやコンポーネントを開発するプロジェクトの総称です。V2Rayはその中で広く使われているコアの名称です。カーネルは接続の受け付け、プロトコルの解析、ルーティングの判定、outboundの確立を担います。GUIクライアントは、これらの機能を操作しやすい設定画面にまとめます。そのため「V2Rayをインストールする」と言うと、実際にはカーネルを管理するクライアントをインストールする意味で使われることがよくあります。特定のメニューやサブスクリプション操作で困ったときは、V2Rayという総称だけでボタンを探さず、まず使用中のクライアントを確認してください。
この階層を理解すると、同じ技術資料でもクライアントごとの画面に合わせた説明が必要な理由が分かります。カーネルのドキュメントは項目が有効かどうかを扱い、クライアントのドキュメントは画面から項目をどう生成するかを扱います。両者が解決する問題は異なります。クライアントでカーネルを選び、設定を生成してプロセスを起動できても、異なるカーネルの機能がすべて共通になるわけではありません。当サイトでは初回インストールと基本操作を使い方ガイドに、JSON項目の構造や依存関係を設定リファレンスにまとめ、問題のある階層に合わせて参照できるようにしています。
V2FlyはV2Rayコミュニティが保守する主要なプロジェクトの一つです。Xrayは関連コードを基に発展したカーネルの派生系です。共通する歴史や設定の概念がある一方で、プロトコルの実装、トランスポート機能、項目の制約はそれぞれ進化しています。JSONの例を読むときは、まずinbounds、outbounds、routingなどの共通構造から役割を把握し、各項目が使用中のカーネルでサポートされているかを確認してください。ルート項目の名前が同じでも、内部の設定を自由に置き換えられるとは限りません。
カーネルは派生名や一般的な性能評価だけで選ばず、既存の設定要件を基準にしてください。サーバーが要求するプロトコル、安全性の層、トランスポートの組み合わせが、クライアント側のカーネルでサポートされている必要があります。どれか一つでも対応していなければ、画面上で設定を保存できても接続できません。派生系固有の拡張機能を使う場合は、対応する説明を確認し、実行中のカーネル情報を記録しておきましょう。互換性の問題では、「項目が認識されない」のか「項目は認識されるが接続できない」のかを切り分けると、無関係な設定変更を減らせます。
v2rayNはWindows、macOS、Linuxのデスクトップ向けで、サーバー管理、サブスクリプショングループ、システムプロキシ、ルーティングなどの操作機能を提供します。選べるカーネルはクライアントの機能によって異なります。v2rayNGはAndroid向けでXrayカーネルを使用し、v2flyNGはAndroid向けでV2Fly系のカーネルを使用します。いずれもオープンソースですが、GUI、権限の仕組み、設定の保存方法は異なります。デスクトップ版の画面をAndroidのメニュー位置の参考にしないでください。設定を移行する際は、作業ディレクトリをそのままコピーするより、接続パラメーターを確認しましょう。
オープンソースであることは、実装やライセンス条件を確認できることを意味しますが、設定の妥当性を保証するものではありません。クライアント、カーネルの実行ファイル、実行時に使うデータファイルは、それぞれ異なるオープンソースライセンスが適用される場合があります。V2Flyのv2ray-coreはMITライセンス、Xray-coreはMPL-2.0ライセンスです。クライアントや依存コンポーネントの再配布条件は、それぞれのライセンス文書を確認してください。利用時は、単にオープンソースかどうかだけで判断せず、配布元、機能の範囲、設定の互換性を確認しましょう。
クライアントの更新では画面や設定生成の仕組みが変わり、カーネルの更新ではプロトコルの実装や必要な項目が変わる場合があります。サブスクリプションの更新で主に取得するのはリモートサーバー情報です。対象の異なる更新を混同しないでください。「サブスクリプションを更新した」からといってプログラム自体も更新されたわけではなく、クライアントを更新しても無効なサブスクリプションURLが自動修復されるとは限りません。更新前に使用中の設定を記録し、必要な設定をエクスポートしてください。更新後は起動ログ、カーネルの選択、ルーティング用データの読み込み状況を確認し、実際のアプリからリクエストを送って動作を検証します。
ダウンロードページではOS別の入手先とインストール方法を案内し、トップページでは基本的な使い方を紹介します。ここではクライアントのバージョンを固定していません。設定の問題は、実際にインストールしたクライアント、現在動作しているカーネル、サーバー側の要件を照らし合わせて判断してください。ドキュメントのJSON例は構造を説明するためのもので、実行環境の既定値や生成方法、対応範囲は個別に確認が必要です。こうした前提を理解しておくと、インストール、移行、トラブル対処の対象を絞って確認でき、設定画面を行き来しながら試行錯誤せずに済みます。
デスクトップへの導入、サブスクリプションの管理、DNSの振り分けに関する手順を紹介します。まず基本接続を完了し、具体的な問題に応じて記事をご覧ください。
Ubuntu、Debian、Fedoraなどのディストリビューションにdebまたはrpmパッケージでv2rayNをインストールする方法を解説。依存関係と権限を設定し、デスクトップの自動起動項目からログイン後に起動できるようにします。
記事を読む →サブスクリプションの更新に失敗する主な原因を解説します。期限切れのリンク、プロキシを経由しない更新、証明書と時刻のずれを確認し、v2rayNとv2rayNGで自動更新を設定する方法を紹介します。
記事を読む →dnsセクションのservers、domains、expectIPsを解説。geositeルールと組み合わせて日本国内・海外のドメインを別々に名前解決し、誤った応答を減らす方法を紹介します。
記事を読む →