V2Rayのインストール・設定ガイド｜Windows・macOS・Linux・Android

事前準備

クライアント・コア・接続情報の違い

クライアントは画面操作、サブスクリプション管理、システム設定を担当し、コアは接続の確立、プロトコル処理、ルーティングを担当します。デスクトップでは v2rayN、Androidでは Xrayコアを使用する v2rayNG が基本です。V2Flyコアとの互換性が必要な場合は、v2flyNGを検討してください。クライアントをインストールしても、接続先サーバーが用意されるわけではありません。利用前に、使用権限のあるサブスクリプションURL、個別の共有リンク、または完全な設定ファイルと、サービス提供元が指定するプロトコルや通信方式を準備してください。

まず、手元の接続情報の種類を確認します。プロトコル名で始まる共有リンクは、通常、サーバー1件分の情報です。一般的なWeb URLはサブスクリプション用のURLの場合も、管理ページの場合もあり、両者は使い分ける必要があります。完全なJSON設定には、インバウンド、アウトバウンド、ルーティング、DNSが含まれることがあり、サブスクリプションURL欄に貼り付けるものではありません。更新を何度も試すより、先に形式を確認しましょう。入力場所や形式の違いは、サブスクリプションURLのインポート方法をご覧ください。

サブスクリプションURLにはアクセス用の認証情報が含まれることがあるため、アカウント情報と同様に管理してください。URL全体を公開画像に載せたり、形式変換のために出所不明のWebサイトへ送信したりしないでください。問題を共有するときは、プロトコル、通信方式、エラーメッセージだけを残し、URLのクエリパラメーター、ユーザーID、パスワードは伏せてください。端末を移行する場合は、クライアントのエクスポート機能を使い、保存される内容がサーバー一覧のみか、ローカル設定を含む完全なバックアップかを確認しましょう。

アーキテクチャ・ネットワーク・権限を確認

システムのデバイス情報を開き、OS、プロセッサーのアーキテクチャ、インストーラーの種類を確認してください。デスクトップ版のx64とarm64は命令セットを表します。PCのメーカーだけで判断せず、macOSでは「このMacについて」でチップを確認し、Linuxではシステム設定の「情報」を確認してください。Androidのarm64版は比較的新しい多くの端末で利用できます。アーキテクチャがわからない場合は、汎用版を選んでください。インストーラーはクライアントのダウンロードページから入手できます。このガイドでは個別ファイルへのリンクを重複して掲載しません。

トラブル対処を始める前に、ほかのプロキシやトンネルアプリを終了し、通信を取り込む仕組みは1つだけにしてください。通常のインターネット接続が使えること、ブラウザーで必要なネットワーク認証が済んでいること、システムの日付・時刻・タイムゾーンが正しいことを確認します。時刻のずれはTLS証明書の検証エラーにつながることがあります。ネットワーク認証が未完了だと、サブスクリプションへのリクエストがログインページに転送される場合もあります。設定ミスに見えても、まずクライアント以外の環境を確認してください。

通常のプロキシとTUNは分けてテストします。通常のプロキシはシステムプロキシ設定を変更するか、ローカルの待ち受けポートを提供します。TUNは仮想ネットワークインターフェース、ルーティング、DNSにも関わり、管理者権限や補助サービスが必要な場合があります。まず通常のプロキシを確認し、その後TUNを有効にすると、「サーバーに接続できない」問題と「システムの通信を取り込めない」問題を切り分けられます。最初からコア、DNS、ルーティング、権限を同時に変更すると、接続が戻っても原因を特定しにくくなります。

元に戻せる状態を作る

ローカルの待ち受けアドレスとポートを記録してください。例として、SOCKSは127.0.0.1:10808、HTTPは127.0.0.1:10809がよく使われますが、実際の設定画面と起動ログを優先してください。ビルドによっては混合ポートを使い、2種類の待ち受けを個別に開かない場合があります。ループバックアドレスはこの端末からのみアクセスでき、初期設定に適しています。明確な必要がない限り、すべてのネットワークインターフェースで待ち受ける設定に変更したり、ファイアウォールの受信ルールを開放したりしないでください。

インストール後は、正常に動作する設定を1つ保存してから、サブスクリプションの更新やルールの変更を行います。基準となる設定には、現在のサーバー、コアの種類、ローカルポート、システムプロキシの状態、ルーティングモード、TUNの有効・無効を含めてください。バックアップはアクセスを管理できる場所に保存します。復元する際は、クライアントを終了してからバックアップ機能で読み込み、実行中のプログラムが古い状態を書き戻さないようにしてください。別の端末へ移すときは、設定ディレクトリ、権限、絶対パスが同じとは限りません。

ボタンの色が変わったかどうかだけで判断しないでください。ログに起動エラーがないこと、アプリが現在のローカルポートを使っていること、対象のリクエストが接続ログに記録されること、終了後にネットワークが元どおり使えることを順に確認します。クライアントの接続テストで確認できるのは、特定の方法による疎通だけです。ブラウザーや実際に使うアプリでの確認も必要です。一連の確認を終えたら、該当するプラットフォームの章に進みましょう。問題が起きたときに、インストール、インポート、コア、通信の取り込みのどこで発生したかを判断しやすくなります。

Windowsのインストール・設定

デスクトップ版と従来のWPF版を選ぶ

Windowsのダウンロードページでv2rayNを選択します。デスクトップ版はクロスプラットフォームのUIを採用し、従来のWPF版はWindowsのUI技術を使用しています。メニュー構成、設定ディレクトリ、機能への入口が異なる場合があるため、同じポートを比較する目的で両方を同時に起動しないでください。画面の違いを確認したい場合は、Desktop版とWPF版の選び方をご覧ください。まず一方を選んで基本設定を済ませ、正常に動作してから移行を検討しましょう。

インストーラーの案内に従い、保存先とショートカットを選びます。既存のインストールを更新する前に、通知領域のクライアントを終了して、サブスクリプションとローカル設定をバックアップしてください。メインウィンドウを閉じただけでは、バックグラウンドのプロセスが終了しない場合があります。インストール後はスタートメニューから起動し、実行環境、コアファイル、ルール用リソースの不足がログに表示されないか確認します。セキュリティ警告が出た場合は、ファイルの入手元と発行元を確認してください。起動の問題を解決するために、システムの保護機能をすべて無効にしないでください。

設定ディレクトリとプログラムのインストール先は、同じとは限りません。インストール先だけをバックアップ対象にしないでください。画面に設定ディレクトリを開く項目や設定のバックアップ機能がある場合は、そちらを使いましょう。「設定を書き込めない」と表示されたら、現在のユーザーに書き込み権限があるか、同期ソフトやフォルダーアクセス制御に妨げられていないか確認します。普段の使用で管理者権限を常用する必要はありません。サービスのインストールやTUNの権限変更が明確に必要な場合に限り、画面の案内に従って権限を昇格してください。

サブスクリプションを追加して接続先を選ぶ

v2rayNの「サブスクリプショングループ設定」でグループを追加し、見分けやすい名前を付けて、該当欄にサブスクリプションURLを貼り付けます。初回は「フィルターキーワード」を空欄にして保存し、メイン画面に戻って対象グループのサブスクリプションを更新します。更新に成功しても、情報の取得と解析が完了しただけです。サーバー一覧から接続先を選び、現在のサーバーとして設定してください。レコードをダブルクリックして編集画面を開いただけの場合は、画面を閉じて、接続先の選択状態が変わったか確認します。

メニューに「プロキシ経由で更新」と「プロキシを使わずに更新」がある場合、利用できる接続がまだなければ、まずプロキシを使わずに更新してください。接続がすでに使え、サブスクリプション側がその経路を必要とする場合は、プロキシ経由に切り替えます。更新失敗をすぐにクライアントの問題と決めつけず、タイムアウト、Webページの応答、認証切れ、解析エラーを区別してください。ブラウザーで管理ページが開けても、サブスクリプション用URLがクライアントの認識できるデータを返すとは限りません。

サーバーを手動で追加する場合、プロトコル、アドレス、ポート、ユーザーID、通信方式、TLS設定は、すべて同じ接続情報を参照してください。別々の設定例から通信パスとサーバーのポートを組み合わせないでください。保存後は、選択中のコアがその設定の組み合わせに対応しているか確認します。特にREALITYなどの機能を使う場合は注意が必要です。サブスクリプション更新でレコードが再作成されることがあります。ローカルでの一時的な修正は、次回更新で上書きされないよう、別グループにコピーしてから行いましょう。

システムプロキシ・TUN・終了時の復元

コアの起動を確認してから、「システムプロキシ」を「システムプロキシを自動設定」にします。通常はWindowsのプロキシ先をクライアントのローカル待ち受けに設定しますが、すべてのアプリがそれに従うとは限りません。ブラウザーは通常システムプロキシを参照しますが、コマンドラインツールや独自のネットワーク処理を行うソフトでは個別設定が必要な場合があります。アプリでSOCKSアドレスを指定する場合は、実際のSOCKS待ち受けポートを入力してください。ポート番号が近いからといって、HTTPとSOCKSを取り違えないようにしましょう。

システムプロキシを参照しないアプリの通信も取り込みたい場合は、「TUNモードを有効にする」を検討します。利用できるかどうかは、選択したビルド、対応するバックエンド、必要な権限によって異なります。チェックを入れるだけで、すべてのコアが同じ機能を使えるわけではありません。画面の案内に従って必要なサービスをインストールまたは起動し、仮想ネットワークアダプター、ルーティング、DNSが正しく設定されたかログで確認します。初回テストではデフォルトの取り込み設定を維持してください。企業ネットワーク、仮想マシン、ほかのトンネルアプリに固有のルートがある場合は、先に記録してから競合を1つずつ確認します。

Windowsでは、終了後もプロキシ設定が残っているだけのケースがよくあります。クライアントを終了する前に「システムプロキシを解除」を選び、通知領域のプロセスを通常の手順で終了してください。異常終了した場合は、「設定 → ネットワークとインターネット → プロキシ」を開き、手動プロキシが停止済みのローカルポートを指していないか確認します。TUNを無効にした後も、ネットワークが復旧したことを確認してください。ブラウザーは使えるのに特定のサービスプロセスだけ失敗する場合、すぐにクライアントを再インストールしないでください。サービスアカウントのプロキシ設定は、現在のデスクトップユーザーと異なる可能性があるため、該当アプリ側の設定を確認します。

最終確認では、正常な起動、サーバーの切り替え、サブスクリプションの更新、終了後のネットワーク復元をテストします。スタートアップ設定は、手動で安定して使えることを確認してから行いましょう。起動時にネットワークがまだ使えない場合、更新に失敗してもサブスクリプションが無効になったとは限りません。ネットワーク接続を待ってから手動で更新し、ログを確認してください。スリープ復帰後に接続できない場合は、設定を削除するのではなく、まずコアを再起動し、スリープ前のネットワークインターフェースやDNSの状態が残っていないか確認します。

macOSのインストール・設定

チップに合ったインストーラーを選ぶ

Appleメニューから「このMacについて」を開き、チップ名またはIntelプロセッサーのどちらが表示されるか確認します。その後、macOSのダウンロードページで対応するv2rayNのインストーラーを選択してください。Apple Siliconはarm64、Intelはx64です。システムの見た目や本体のサイズで判断しないでください。ダウンロード後、ディスクイメージを開き、アプリを「アプリケーション」フォルダーにドラッグしてから、そのフォルダー内のアプリを起動します。イメージ内のアプリを使い続けると、更新、権限、アプリの場所を判断しにくくなることがあります。

初回起動時にシステムのセキュリティ機能でブロックされた場合は、ダウンロード元を確認したうえで、「システム設定 → プライバシーとセキュリティ」に表示される方法で、このアプリの起動を許可してください。システムのセキュリティ機能を一括して無効にしたり、出所不明のターミナルコマンドをそのまま実行したりしないでください。アプリを実行できないというメッセージが出た場合は、まずアーキテクチャとシステム要件を確認し、ダウンロードの中断やインストール不備がないか調べます。権限、アーキテクチャ、設定の問題はそれぞれ異なるため、順番に切り分けてください。

更新前に、メニューバーやバックグラウンドで動作している古いインスタンスを終了し、設定をバックアップしてから「アプリケーション」内のアプリを置き換えます。「ダウンロード」フォルダー、ディスクイメージ、アプリケーションフォルダーに複数のコピーがあると、ログイン項目から古いアプリが起動することがあります。起動後にサブスクリプションが表示されない場合は、すべてを再インポートする前に、実行中のアプリの場所とユーザーアカウントを確認してください。設定ファイルは通常、現在のユーザーに属します。別のアカウントで実行しても、同じ設定が自動的に共有されるわけではありません。

サブスクリプションの追加とシステムネットワークプロキシ

v2rayNでサブスクリプショングループ設定を開き、内容がわかる名前のグループを追加します。サブスクリプションURLを貼り付けて保存し、更新を実行してください。個別の共有リンクをインポートする場合は、サーバーのインポート機能を使い、サブスクリプションURL欄には入力しないでください。リストの更新後、接続先を選び、プロトコルとコアが対応しているか確認します。初回テストではフィルターキーワードを同時に有効にしないでください。リストが空の場合、取得の失敗とフィルターによる除外を区別できなくなります。

システムプロキシを有効にした後、「システム設定 → ネットワーク」で現在使っているネットワークサービスを選び、「詳細 → プロキシ」を開いて設定を確認します。システム設定の画面構成はバージョンによって異なりますが、確認対象は現在有効なネットワークサービスです。Wi-Fiと有線ネットワークでプロキシ設定が別々に保存されることがあります。接続方法を切り替えたら、プロキシのアドレスとポートを再確認してください。Wi-Fiで使えたからといって、有線ネットワークにも同じ設定が適用されているとは限りません。

ブラウザーは通常システムプロキシに従いますが、拡張機能やブラウザー独自のプロキシ設定が優先されることもあります。トラブル対処では、まずプロキシ系の拡張機能を無効にし、アプリ側で独自のプロキシを指定していないか確認してください。HTTPプロキシのみ対応するアプリには、実際のHTTP待ち受けポートを入力します。SOCKSのみ対応する場合は、SOCKSポートを指定してください。サーバーのリモートアドレスをシステムプロキシ欄に直接入力しないでください。システムプロキシはローカルのクライアントに接続し、その後クライアントがプロトコルのハンドシェイクとルーティングを処理します。

TUNの権限・スリープ・ネットワーク切り替え

TUNによる通信の取り込みには、使用中のビルドが提供する補助機能とシステムの許可が必要です。Windowsのサービスのインストール方法を、そのままmacOSに当てはめないでください。まず通常のプロキシで接続を確認し、その後v2rayNの実際の案内に従って必要な権限を設定します。許可ダイアログが、直前に行った操作に対応していることを確認してください。権限を拒否した場合は、システム設定を確認して該当機能を再起動します。画面に通信の取り込み機能がない場合、無関係なコア設定を変更して機能を模倣しようとしないでください。

スリープからの復帰、ホットスポットの切り替え、Wi-Fiから有線ネットワークへの切り替え後は、以前の接続が使えなくなることがあります。まず通信の取り込みをいったん無効にして再度有効にし、現在のネットワークに再接続したかログで確認してください。必要に応じてコアを再起動します。既存の接続は使えるのにドメイン名だけでアクセスできない場合は、サーバーをすぐに変更せず、DNSとネットワークサービスの切り替えを重点的に確認してください。企業ネットワークの自動プロキシ設定がシステム設定を書き換えることもあります。ネットワーク管理者の要件に従い、2つの仕組みが互いに上書きし続けないようにしましょう。

通常の終了前にTUNを無効にし、クライアントが設定したシステムプロキシを解除してください。異常終了後、すべてのブラウザーで通信できなくなった場合は、現在のネットワークサービスのプロキシ設定を開き、ループバックアドレスを指すプロキシが有効なままになっていないか確認します。コアを停止しても、すべてのネットワークサービスが自動的に初期状態へ戻るとは限りません。残ったプロキシを直すために、ネットワークサービスをむやみに削除しないでください。まずクライアントが追加した設定だけを解除し、既存のDNS、自動設定URL、ネットワーク認証情報は残します。

インストール先や権限を調べる際は、メインアプリと補助プロセスを分けて考えてください。アクティビティモニタにプロセスが残っていても、メイン画面が終了していないとは限りません。逆に画面が正常でも、必要な補助コンポーネントが動作しているとは限りません。待ち受けの成功、ルートの設定、リクエストの処理結果をログで確認してください。最後に、通常のプロキシ、必要なTUNによる通信の取り込み、終了後の直接接続への復帰をそれぞれ検証してから、ログイン時の起動設定を追加します。権限設定が未完了の状態を、毎回のログインで繰り返す設定にしないようにしましょう。

Linuxのインストール・設定

ディストリビューションとパッケージのアーキテクチャを合わせる

デスクトップ環境ではv2rayNの使用をおすすめします。Linuxのダウンロードページで、ディストリビューションに合ったdebまたはrpmを選び、プロセッサーがx64かarm64か確認してください。パッケージ形式がインストーラーに対応していても、各デスクトップ環境で同じようにシステムプロキシが設定されるとは限りません。インストール前にディストリビューションのシステム情報を確認し、ファイルはグラフィカルなソフトウェアインストーラーで開いてください。依存関係の警告が出た場合は、ディストリビューションのパッケージ管理ツールで解決することを優先し、出所不明のスクリプトを汎用のインストール手順として使わないでください。

インストール後はアプリメニューから起動し、グラフィカルクライアント全体をスーパーユーザーとして実行しないでください。高い権限で実行すると別のユーザーディレクトリに設定が保存され、通常の起動時にサブスクリプションが表示されなかったり、書き込みができなくなったりすることがあります。すでにその方法で起動した場合は、終了してから実際の設定場所とファイルの所有者を確認し、ディストリビューションの管理方法に従って修正します。一度起動させるために設定ディレクトリを全ユーザーが書き込める状態にすると、ローカルデータが広く公開されるおそれがあります。

グラフィカル画面が開かない場合は、デスクトップセッションの問題とコアの問題を切り分けます。表示環境、グラフィック依存関係、セッション変数が不足していると、メインウィンドウを作成できません。この段階ではサーバーへの接続処理は始まっていません。画面が開く一方でログにコアが見つからないと表示される場合は、インストールが完了しているか、セキュリティポリシーが実行をブロックしていないか確認します。コンテナ、リモートセッション、軽量デスクトップ環境では、システムプロキシとの連携が不足する場合があります。このガイドの画面操作だけで、そうした環境への個別導入設計を代替することはできません。

サブスクリプションとアプリのプロキシ設定を分ける

サブスクリプショングループ設定にURLを追加して保存し、サブスクリプションを更新した後、接続先を選びます。URLに特殊文字が含まれる場合は、クエリパラメーターを削除せず、そのまま貼り付けてください。改行、先頭や末尾の空白、WebページからコピーされたHTMLなどが解析エラーの原因になることがあります。初回の更新に失敗したら、システムルートを変更する前に、ネットワーク認証とURLの応答を確認します。接続が使えるようになってからプロキシ経由の更新を試せば、まだ確立していないプロキシ経路に更新処理が依存するのを避けられます。

GNOME、KDEなどのデスクトップ環境は、それぞれ異なるシステムプロキシ設定の仕組みを持ちます。アプリが参照する設定元も異なる場合があります。v2rayNでシステムプロキシの設定を行った後も、デスクトップのネットワーク設定を開いて確認し、実際のアプリで動作を検証してください。ブラウザーがシステム設定を参照しても、パッケージ管理ツールやターミナルのツールも同様とは限りません。個別設定が必要なアプリには、アプリのネットワーク設定でローカルプロキシの種類、アドレス、ポートを指定します。「グローバルモード」は、OSが全プロセスの通信を強制的に取り込むという意味ではありません。

ターミナルのプロキシ環境変数には適用範囲があります。特定のターミナルセッションだけで設定しても、アプリメニューから起動したプログラムには自動的に適用されません。ログイン環境に追加しても、すでに実行中のプロセスにはすぐ反映されない場合があります。初期設定時に複数の起動ファイルへ同時に書き込むことはおすすめしません。まず対象アプリでプロキシが使えるか確認してから、設定を永続化するか決めてください。設定を取り消すときは同じファイルから削除し、クライアント終了後も古い変数が停止中のローカルポートを参照し続けないようにします。

権限・ポート・DNSを確認

TUNを使う場合は、現在のビルドの権限設定ガイドに従って、補助サービスや必要な機能を準備してください。ディストリビューションによってサービス管理やセキュリティポリシーは異なります。他のプラットフォーム用のコマンドをそのまま使わないでください。仮想インターフェースが作成されているか、ルーティングが想定したインターフェースを指しているか、DNSリクエストが想定した経路に入っているかを確認します。デスクトップのネットワーク管理ツールとクライアントが両方ともDNSを変更しようとすると、接続はできても名前解決が不安定になる場合があります。まず通常のプロキシに戻して基本の接続を確認し、その後で通信の取り込み機能を1つずつ戻してください。

ローカルポートの使用状況は、システムツールで確認できます。以下の2つのコマンドは待ち受け状態を調べるだけで、ネットワーク設定は変更しません。ポート番号は現在の設定画面に表示されている値に置き換えてください。待ち受けが表示されても、今回起動したコアのものとは限りません。プロセス情報とクライアントのログを合わせて確認します。プロセス名が表示されない場合は権限が原因の可能性があるため、プロセス一覧が空でもポートが使用中でないとは判断できません。

ss -lntp 'sport = :10808'
ss -lntp 'sport = :10809'

サブスクリプションは更新できるのにアプリが通信できない場合は、まずアプリが参照するプロキシ設定元とプロトコルを確認します。通常のプロキシは使えるのにTUNが動作しない場合は、権限、ルーティング、DNSを優先して確認してください。コアが待ち受けていない場合は、インストール、設定ファイルの構文、ファイルへのアクセス権限に戻って調べます。この順番なら、ディストリビューションの設定を何度も切り替えずに、問題が起きた状態を保ちやすくなります。セキュリティポリシーによる実行やアクセスの拒否があった場合は、システムログで該当する拒否項目を確認し、セキュリティ機能全体を無効にしないでください。

終了時の確認も重要です。まずTUNを無効にし、システムプロキシを解除してからクライアントを終了し、デスクトップのネットワーク設定とアプリ独自の設定が元に戻ったか確認します。ノートPCでネットワークを切り替えた場合、スリープから復帰した場合、有線アダプターを接続した場合は、現在のインターフェースをあらためて確認してください。システム起動時とユーザーログイン時では、実行環境が異なります。グラフィカルクライアントは通常、ユーザーセッションが利用できる状態になってから起動する必要があります。安定した基準設定ができるまでは、バックグラウンドでの自動起動や重複するサービスを追加しないでください。ポート競合や設定ディレクトリの分岐につながるおそれがあります。

Androidのインストール・設定

v2rayNGとv2flyNGを選ぶ

Androidのダウンロードページで、まずv2rayNGを選んでください。V2Flyコアの環境が必要な場合は、v2flyNGを選びます。2つは別のアプリです。一方をインストールすれば、もう一方のコアに切り替わるわけではありません。比較的新しい多くの端末ではarm64版を選べます。アーキテクチャがわからない場合は汎用版を使用してください。インストール前に、ブラウザーやファイル管理アプリからのインストールが許可されていることを確認します。許可はインストールファイルを開くアプリにだけ与え、完了後は端末の管理方法に応じて無効にできます。

インストールや更新時に、パッケージ競合、上書き失敗、署名不一致が発生した場合は、何度もやり直す前に、既存アプリの識別情報と入手元を確認してください。アンインストールするとサーバー一覧やローカル設定も削除されることがあるため、すぐに削除しないでください。まず現在のアプリのエクスポート機能で必要なデータを保存し、別のアプリをインストールしているのか、パッケージが端末に合っていないのか、古いアプリを現在のパッケージで直接上書きできないのかを判断します。端末の空き容量不足でもインストールに失敗するため、アーキテクチャの問題とは分けて確認してください。

初回起動時は、出所不明の完全な設定をすぐにインポートせず、まずデフォルト設定を確認してください。完全な設定にはカスタムDNS、ルーティング、ローカル待ち受けアドレスが含まれ、アプリの標準動作が変わる場合があります。接続情報が一般的なサブスクリプションなら、サブスクリプション用の画面から追加します。サーバーを手動で追加する場合は、プロトコル、通信方式、TLSをそれぞれ確認してください。v2flyNGは、あらゆるXrayの機能を代替できる環境ではありません。対応機能はアイコンやアプリ名ではなく、実際に使用するコアによって決まります。

サブスクリプションの設定と接続の許可

v2rayNGのメニューから「サブスクリプション設定」を開き、名前とURLを追加して保存します。その後、メイン画面に戻ってサブスクリプションを更新してください。追加ボタンの位置は画面のビルドによって異なる場合がありますが、まずサブスクリプションを保存し、その後サーバー一覧を更新する手順は同じです。個別のリンクはクリップボードからのインポート機能で追加し、共有内容を読み取る場合は対応するスキャン機能を使います。QRコード内のサブスクリプションURLを通常のサーバー情報と取り違えたり、サーバー1件分のリンクをサブスクリプションとして何度も追加したりしないでください。

更新後、サーバーを1件選び、選択状態を確認してから接続を開始します。初回はAndroidからVPN接続の許可を求められます。これはAndroidが提供する通信取り込み用の仕組みであり、別のVPNアプリをインストールする必要があるという意味ではありません。許可した後、ステータスバーとアプリのログでサービスが実際に起動したか確認してください。同じ機能を使うほかのネットワークアプリを同時に動かすと、システムがどちらかを切り替えたり停止したりする場合があります。トラブル対処では、まず現在のクライアントだけを動かし、複数のアプリが通信の取り込み権限を取り合わないようにしてください。

v2flyNGでも、まずサブスクリプションと個別設定を区別し、選択したサーバーとコアの互換性を確認します。サーバーが一覧に表示されたからといって、通信パラメーターを現在のコアが実行できるとは限りません。接続に失敗した場合は、設定を次々と切り替えるのではなく、最初に出たハンドシェイク関連のエラーを記録してください。特定のXray機能が必要な接続情報を使う場合は、サービス提供元のパラメーター説明とアプリの選択を確認します。セキュリティ項目を削除して、見かけ上起動させようとしないでください。

アプリごとの通信取り込み・バックグラウンド・DNS

Androidでは、アプリが作成するVPNインターフェースが主な通信取り込み手段です。デスクトップの「システムプロキシを自動設定」とは仕組みが異なり、デスクトップと同じローカルプロキシのスイッチを設定する必要はありません。一部のアプリだけをプロキシ経由にしたい場合は、クライアントのアプリ別設定で、通信を取り込む対象または除外対象を選択します。保存後、接続を再確立する必要がある場合があります。一覧が許可リストなのか除外リストなのかを確認してください。同じアプリにチェックを入れても、モードによって結果が逆になります。テストでは対象アプリを1つだけ選んで確認しましょう。

しばらくバックグラウンドにすると切断される場合は、バッテリー最適化、バックグラウンド動作の制限、端末メーカー独自の省電力設定を確認してください。必要なバックグラウンド動作と通知を許可すると、システムが接続サービスを維持しやすくなります。ただし、トラブル対処のためにすべてのアプリの権限を一括で許可しないでください。画面ロック後だけ失敗する場合は、バックグラウンドサービスが停止されていないかを優先して確認します。Wi-Fiとモバイルネットワークの切り替え時に失敗する場合は、再接続してネットワーク変更のログを確認してください。どちらもサーバーの不安定さだけで説明できるとは限りません。

システムの「プライベートDNS」、クライアントのDNS設定、ブラウザーの暗号化DNSが、いずれも名前解決に影響する可能性があります。ドメインにアクセスできない場合は、まずDNSの経路を1つに定め、その後カスタム設定を少しずつ追加してください。複数の場所で特殊なDNSを同時に有効にした状態では、ルーティングの結果を正しく判断できません。一部メーカーのデュアルアプリ、仕事用プロファイル、独立した領域では、追加の分離機能が使われます。対象アプリとクライアントが同じ利用環境にあるか確認し、アプリ別リストでも正しいアプリを選んでください。

接続を停止した後、通知領域の状態と実際のネットワークが復旧したか確認します。システムで「VPNを常時接続」や「VPN未接続時の通信をブロック」が有効になっていると、クライアント停止後の動作は通常の終了時と異なる場合があります。システムのネットワーク設定で該当項目を確認してください。認証が必要な公共ネットワークでは、ネットワークの案内に従ってログインを完了してから接続します。最後に、前面表示中、バックグラウンド、画面ロック中、ネットワーク切り替え時の4つの場面でテストし、安定した設定を維持してからアプリ別ルールを追加します。バックグラウンド制限をサブスクリプションやプロトコルの問題と取り違えないようにしましょう。

ルーティングと通信の取り込み

独立した2つの問題を切り分ける

通信の取り込みはリクエストがクライアントに入るかどうかを決め、ルーティングは取り込んだ後にどのアウトバウンドを使うかを決めます。システムプロキシ、アプリ独自のプロキシ、TUNは通信の取り込み側です。ドメイン、IP、ポート、アウトバウンドのタグはルーティング側です。ルーティングモードをグローバルにしても、システムプロキシを無視するアプリの通信を強制的にクライアントへ送れるわけではありません。トラブル対処では、まず対象アプリのリクエストがログに記録されているか確認してください。記録がなければ、ドメインルールを増やすのではなく通信の取り込み経路を確認します。

ルーティングルールは通常、上から順に照合し、最初に一致したルールでアウトバウンドを選択します。そのため、具体的なルールを広い範囲のルールより前に置いてください。広告のブロック、LANへの直接接続、特定ドメインへの直接接続、その他の通信のプロキシ経由を組み合わせると、わかりやすい基本方針になります。すべてのルールに明確な目的を持たせてください。1つのルール内で各フィールドがどのように組み合わされるかにも注意が必要です。「ドメインまたはIPのどちらかが一致すればよい」という条件を、安易に同じルールオブジェクトへ詰め込まないでください。別々に判定したい場合はルールを分けると、ログで検証しやすく、後から管理しやすくなります。

geositeはドメイン分類ルール、geoipはIP分類ルールです。どちらも対応するリソースファイルとタグに依存します。タグ名は自由なメモではありません。名前の誤りやリソースの不足によって、起動に失敗する場合があります。クライアントのルーティングエディターから組み込みルールを選ぶと、リソースのパスを合わせやすくなります。設定の一部をコピーする前に、該当するリソースが端末にあるか、起動時にクライアントが設定を再生成して手動の変更を上書きしないか確認してください。

ローカルインバウンドと各フィールドの意味

以下は、ローカルインバウンドを説明するための完全なV2Ray設定例です。ループバックアドレスでSOCKSとHTTPの入口を提供し、デフォルトのアウトバウンドは直接接続に設定しています。待ち受けとルーティングの構造を理解するための例であり、リモートのプロキシサーバー情報は含まれていません。サブスクリプションの代わりにはなりません。クライアントは通常、実行用の設定を独自に生成します。この例を使用中の設定ディレクトリに直接上書きしないでください。テストする場合は独立した設定環境を使い、例のポートが現在のインスタンスと競合しないことを確認してください。

{
  "log": {
    "loglevel": "warning"
  },
  "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": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

listenは待ち受けるインターフェース、portはローカルポート、tagはインバウンドまたはアウトバウンドの名前を指定します。ルールのoutboundTagには、実在するアウトバウンドのタグを指定する必要があります。存在しない名前を入力しても、プロキシ用のアウトバウンドが自動作成されることはありません。上記の例では、ルールに一致しない場合、最初のアウトバウンドである直接接続が使われます。クライアント画面の「最終ルール」は通常、具体的な設定へ変換されます。画面上の文言をコアのJSONフィールドとして、そのままコピーしないでください。

domainStrategyは、ルーティング時にドメインとIPのどちらをどのように照合するかを設定します。AsIsはドメイン名をそのまま使って判定します。IPIfNonMatchはドメインルールに一致しなかった場合に名前を解決し、IPルールで判定します。IPOnDemandは、IPによる判定が必要になった時点で名前を解決します。これはリモートDNSを個別に有効化する設定ではなく、すべてのドメインが同じ経路で解決されることを保証するものでもありません。DNS設定、アウトバウンドの動作、クライアントの実装と合わせて確認してください。

最小限のルールで動作を確認

ルールを追加する前に、繰り返しテストできる対象を1つ選び、想定するアウトバウンドを記録してから、ログで実際の選択を確認してください。ドメインルールには通常、Webページ全体のURLではなくホスト名を指定します。サブドメイン、完全一致、サフィックス一致も区別してください。アプリがIPアドレスへ直接接続する場合、暗号化DNSを使う場合、接続を再利用する場合は、ログに想定したドメインが残らないことがあります。その場合は実際のリクエスト情報を確認します。似たドメインを次々に追加して、重複し意図も説明できないルールを増やさないでください。

システムプロキシはシステム設定に従うアプリに適しています。TUNはより広範囲の通信を取り込みたい場合に使いますが、TUN自体がルーティング方針を決めるわけではありません。有効にした後は、コア自身のアウトバウンドが再びトンネルに入り込まないようにし、DNSやLAN宛て通信も適切に処理する必要があります。初回はクライアントのデフォルトのループ防止機能を使い、インターフェースのバインドや除外ルートをむやみに変更しないでください。LANプリンター、ファイル共有、仮想マシンとの通信に問題がある場合は、プライベートアドレスへの経路を先に確認し、その後で必要に応じて個別の直接接続ルールを追加します。

設定項目	対象となるレイヤー	最初に確認すること
システムプロキシ	アプリをローカルの接続先へ誘導	アプリがシステム設定を参照しているか
TUN	仮想インターフェースと通信の取り込み	権限、ルーティング、DNS、ループ防止
`domainStrategy`	ルーティング時のドメイン・IP判定	名前解決のタイミングとルール順
`outboundTag`	ルール一致後のアウトバウンド選択	指定したタグが存在するか

ルーティングルールの管理とサブスクリプションの管理は分けてください。サブスクリプションの更新でサーバー情報が再作成されることはありますが、任意のルーティングエラーを修正するための手段ではありません。ルーティング用リソースを更新しても、サーバー設定が更新されるわけではありません。変更するたびに古いルールを保存し、対象のアプリとLANの動作をテストしてから、終了後の復元も確認してください。コアの機能互換性を確認するには、XrayコアとV2Flyコアの違いを参照し、非対応のコアで設定項目を何度も削除・変更して解決しようとしないでください。

設定のよくある問題

失敗した段階ごとにログを確認

まず「どの操作に失敗したか」を記録し、次に「どんなエラーが出たか」を確認します。起動失敗、サブスクリプションの更新失敗、特定アプリの接続失敗、スリープ後の切断は、それぞれ別に対処してください。ログ画面を開いて古い記録を消すか目印を付け、問題を一度だけ再現して、最初に出たエラーとその前後を確認します。最後に表示される「起動失敗」は要約にすぎず、原因はその前に記録されていることがあります。詳しい分類は、コア起動失敗ログの診断方法をご覧ください。

ログにaddress already in useのようなメッセージが出た場合は、まずローカルポートを使用しているプロセスを確認します。古いクライアントやバックグラウンドのインスタンスを終了し、待ち受けが解放されたか確認してください。ポートを変更する場合は、システムプロキシとアプリ独自のプロキシ設定も合わせて変更します。設定の解析エラーなら、JSONのカンマ、括弧、フィールドの型、コアがそのフィールドに対応しているかを確認します。JSONの構文が正しくても、現在のコアがすべてのフィールドをサポートしているとは限りません。参照先のファイルやタグが存在するとも限りません。

ログにリソースファイルが見つからないと表示された場合は、ルールファイルのパス、インストール状態、アクセス権限を確認してください。すべてのルーティングルールを削除してはいけません。不明なプロトコルや非対応の通信方式が示された場合は、現在のコアと接続情報の組み合わせを確認します。コアを切り替える前に、特定の機能に依存する設定を無効にし、新しいコアが同じプロトコルに対応しているか確認してください。「起動できること」だけを目標にしないでください。TLS、認証、検証の項目を削除すると接続の意味が変わる場合があり、エラーが見えなくなっても設定が正しいとは限りません。

サブスクリプションが空・接続タイムアウト・証明書エラー

更新後に一覧が空の場合は、選択中のグループ、フィルターキーワード、URLの応答、サブスクリプションの認証状態を順に確認してください。Webページや空の内容が返ってきても、サーバー情報を取得できたとは限りません。いったんフィルターを空にして、1つのグループだけを個別に更新すると、取得失敗と表示条件の影響を切り分けられます。複数の情報元を管理する方法は、サブスクリプショングループとサーバーフィルターをご覧ください。グループの関係がわかりにくいからといって、同じ情報を何度もインポートしないでください。

接続タイムアウトは、ある段階の処理が想定時間内に完了しなかったことを示します。このメッセージだけでサーバーの障害とは判断できません。まずローカルポートが使えるか、次にリモートアドレスを名前解決できるか、実際の接続が接続確立とプロトコルのハンドシェイクのどちらで止まっているかを確認します。connection refusedが出た場合は、対象のアドレス、ポート、サービスの状態を確認してください。接続先がループバックアドレスなら、ローカルのコアが起動しているか確認します。別のサーバーへの切り替えは比較テストとして有効ですが、元のエラーと設定も残し、比較できる状態にしてください。

TLS証明書のエラーが出た場合は、まずシステム時刻、サーバー名、接続情報のセキュリティ設定を確認します。証明書の名前と接続先のアドレスが異なる場合もありますが、その設定はサービス提供元が明示したものである必要があります。証明書検証の無効化を一般的な解決策として使わないでください。サブスクリプションに含まれる情報が古い場合は、情報を更新するか、サービス提供元に確認します。ネットワーク認証ページ、企業プロキシ、セキュリティソフトが証明書チェーンに影響する場合もあるため、現在のネットワーク環境と合わせて判断してください。

問題を比較し、元に戻す手順を決める

ブラウザーは使えるのにほかのアプリが使えない場合は、まずプロキシ設定元を比べます。ブラウザーに拡張機能があるか、対象アプリがシステムプロキシを参照しているか、プロトコルとポートが合っているかを確認してください。通常のプロキシが使えてTUNが使えない場合は、権限、仮想インターフェース、ルーティング、DNSを調べます。ドメインでは失敗しIPアドレスでは接続できる場合は、名前解決の経路が原因の可能性があります。ただし、IPアドレスへの直接接続はTLSの名前や仮想ホストの制限で失敗することがあります。一度のテストだけで、ほかの原因まで除外しないでください。

特定のWebサイトだけ使えず、ほかの通信は正常な場合は、そのリクエストのアウトバウンド、ドメインルール、アプリのキャッシュを確認します。ルーティングを変更しても、既存の接続が以前の経路を使い続けることがあります。対象の接続を張り直して再テストしてください。必要なら最小限のルールセットに一時的に切り替えて比較しますが、先に元の設定をバックアップします。最小限のルールで使える場合は、カスタムルールを1つずつ戻します。それでも使えない場合は、リモート側の接続情報とアプリの通信取り込み設定に戻って確認します。リクエストの記録がない状態でドメイン分類を変更し続けないでください。多くの場合、確認するレイヤーが異なっています。

ネットワーク切り替えやバックグラウンドの問題では、「たまに失敗する」と記録するより、発生条件を具体的に記録してください。画面ロック、スリープ、Wi-Fiの切り替え、別のトンネルアプリの起動、サブスクリプションの更新のうち、どの後に起きたかを明確にして、関連するログを確認します。Androidではサービスがシステムに停止されていないか、デスクトップでは現在のネットワークインターフェースと残ったプロキシ設定を重点的に調べます。再起動で一時的に状態が解消されても、毎回同じ操作の後に再発するなら、その操作を条件に比較してください。再起動を恒常的な対処法にしないでください。

問題を報告するときは、OS、クライアント名、選択したコア、再現手順、エラーメッセージの原文、実施済みの比較テストを記載してください。サブスクリプションやアカウント情報全体を添付する必要はありません。ログを共有する前に、サーバーアドレス、クエリパラメーター、認証情報が含まれていないか確認し、機密情報を削除してください。基本的な接続手順を最初から確認したい場合はクイックスタートへ、別のプラットフォーム用インストーラーが必要な場合はクライアントのダウンロードページへ戻ってください。元に戻せる基準設定を保つほうが、すべての設定を何度も削除するより原因を特定しやすくなります。