V2Rayの
インストール・設定ガイド

01 / BEFORE INSTALLATION

事前準備：システム、サブスクリプション、通信経路

クライアント、コア、サーバー設定の違いを理解する

GUIクライアントはサーバー情報の保存、サブスクリプションの管理、設定の生成、コアの起動を担います。コアはプロトコル接続、トラフィック転送、ルーティングの判定を行います。デスクトップではv2rayN、AndroidではXrayコアを搭載したv2rayNGが基本です。V2Flyの設定が必要な場合はv2flyNGを検討してください。クライアントをインストールしただけでは、利用可能なサーバーは取得できません。また、サブスクリプション提供元のアカウントやサービスの代わりにもなりません。事前に、利用権限のあるサブスクリプションURLまたは単体サーバーの共有リンクを用意し、有効期限内であることを確認してください。

Project Vは各コンポーネントの背景を理解するためのもので、別途インストールが必要なデスクトップアプリではありません。V2FlyとXrayは関連するコアのエコシステムであり、対応範囲はコアの実装によって異なります。設定が利用できるかどうかは、プロトコル、トランスポート、セキュリティ設定と、実際に使うコアの機能の組み合わせで決まります。クライアント名だけでは判断できません。関係を整理したい場合は、Project V・V2Fly・Xrayのエコシステムと関係を確認してから、コアを変更する必要があるか検討してください。

システムのアーキテクチャとインストール先を確認する

プロセッサのアーキテクチャは、デバイスの製造年ではなくOSに表示される情報を基準に確認してください。Windowsでは「システム情報」のシステムの種類、macOSでは「このMacについて」のチップを確認します。Linuxでは下記のコマンドを実行できます。ダウンロードページには、実際に提供されているインストーラーが掲載されています。アーキテクチャが合わない場合、何度も起動を試して解決しようとしないでください。インストール先も事前に決めておきましょう。ポータブル版はユーザーが書き込める場所に置き、インストーラーで管理されるプログラム用ディレクトリには設定ファイルを手動で混在させないでください。

uname -m
cat /etc/os-release

Linuxの出力では、x86_64が一般的なx64パッケージ、aarch64がarm64パッケージに対応します。ディストリビューション情報はdebとrpmの選択に使いますが、デスクトップのプロキシがどう動作するかを判断する材料にはなりません。OS、デスクトップ環境、アプリにはそれぞれネットワーク設定があり、個別に確認が必要です。新規導入時は標準のディレクトリ構成を保ち、実行ファイルだけを別の場所に移動して、同梱リソースや実行コンポーネントを取り残さないようにしてください。

元に戻せるネットワークの基準状態を作る

インストール前に、通信を引き受けているほかのプロキシやトンネルソフトを終了し、システムプロキシの元の状態を記録してください。通常のネットワーク接続が使えることと、システムの日時・タイムゾーンが正確であることを確認します。時刻のずれは証明書の検証失敗につながる場合があります。また、古いプロキシ設定が残っていると、終了済みのローカルポートにサブスクリプション更新のリクエストが送られることがあります。クライアントの起動前に起きた問題でも、クライアントの障害のように見えることがあります。基準状態を確認せずに、ネットワークアダプター、名前解決、ルーティング設定を同時に変更しないでください。

最初の接続確認では、TUNではなくシステムプロキシを使うのがおすすめです。システムプロキシはOSのプロキシ設定に従うアプリが対象となるため、ブラウザーで通信経路を確認するのに適しています。TUNは仮想ネットワークインターフェースを通じて、より多くの通信を引き受けます。そのため追加の権限が必要で、DNS、LAN、ほかの仮想ネットワークに影響することがあります。これはサーバーのプロトコルが2種類あるという意味ではなく、TUNを有効にすれば接続が安定するということでもありません。基本の接続を確認してから、対象アプリがプロキシに従うかどうかに応じてTUNを有効にしてください。

バックアップとプライバシーに関する注意

すでに設定済みの場合は、まずクライアントのエクスポートまたはバックアップ機能で保存してください。データディレクトリを手動でコピーする場合は、書き込み中のファイルが不完全にならないよう、先にアプリを終了します。バックアップにはサブスクリプショングループ、ルーティング、カスタムDNS、必要なローカル設定を含めてください。サブスクリプションURLにはアカウント識別情報が含まれることがあり、共有リンクに認証情報が含まれる場合もあります。公開スクリーンショットや掲示板、誰でもアクセスできるオンラインストレージに載せないでください。トラブルの相談では、内容を伏せたエラーの種類と発生時刻を共有してください。

02 / WINDOWS

Windows：v2rayNのインストールとプロキシ設定

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

Windowsのダウンロードを開き、OSのアーキテクチャを確認してから、v2rayNデスクトップ版または従来のWPF版を選んでください。デスクトップ版は新世代のクロスプラットフォームUIを採用し、WPF版は従来のWindows向けUIを引き継いでいます。どちらも設定管理用のクライアントであり、サーバーへの接続品質に違いがあるわけではありません。既存の設定を移行する場合は、先にバックアップを取り、移行先のUIで元のデータを読み込めるか確認してください。2つのアプリから同じ設定ディレクトリに同時に書き込まないでください。

インストーラー版はウィザードに従って導入します。ポータブル版はファイルをすべて展開してから起動してください。圧縮ファイルのプレビュー画面から直接実行したり、実行ファイルだけをコピーしたりしないでください。設定の消失を防ぐため、展開先には固定の書き込み可能な場所を選び、テンポラリディレクトリは避けてください。起動時に実行コンポーネントが見つからないと表示された場合は、使用中のパッケージの説明とOSの案内に従って必要なものを追加してください。不明な配布元から個別のDLLをダウンロードして置き換えるのは避けましょう。エラーの文面を残しておけば、不足しているのが実行環境かアプリのリソースかを判断できます。

起動後にサブスクリプションを追加して一覧を確認する

初回起動時は、まずメイン画面が正常に表示されることを確認し、サブスクリプショングループの管理画面を開きます。グループを追加し、識別しやすい名前を付けて、サブスクリプションURL全体を入力欄に貼り付けて保存し、更新を実行してください。URLの登録と内容の更新は別の操作です。グループを追加しただけでは、サーバー情報を取得できたとは限りません。更新後、サーバー一覧に項目が表示され、プロトコル、アドレス、ポートなどの基本情報が入力されていることを確認します。メニューの名称は変更される場合があるため、現在の画面にあるサブスクリプション管理を利用してください。

クリップボードに単体サーバーの共有リンクがある場合は、リモートサブスクリプションURLとしてではなく、クライアントのクリップボードからのインポート機能を使ってください。WebページのURLがサブスクリプションURLとは限りません。アカウント管理画面、ログインページ、サーバー設定を返すAPIはそれぞれ用途が異なります。更新しても一覧が空の場合は、更新ログでリクエストの結果を確認し、URLの形式とアカウントの状態を提供元に問い合わせてください。一覧を表示させるために証明書検証を無効にしたり、認証パラメーターを安易に削除したりしないでください。

まずシステムプロキシを確認し、その後に対象範囲を広げる

使うサーバーを選んで現在の接続先に設定し、コアが起動できることを確認してから、システムプロキシの自動設定を選んでください。この操作により、Windowsのシステムプロキシに従うアプリはローカルの待ち受けアドレスを使用します。ポート番号はクライアントの設定画面で確認し、ほかの端末の値を流用しないでください。HTTPS接続が正常なことを確認できるWebページをブラウザーで開き、対応する接続ログが出るか確認します。ページが開かない場合は、まずコアが動作しているか確認し、次にサーバーへの接続を調べます。すぐにすべてのルーティング設定を切り替えないでください。

Windowsのシステムプロキシを設定しても、すべてのプログラムが従うわけではありません。一部のコマンドラインツール、サービスプロセス、独自のプロキシ設定を持つアプリでは個別設定が必要です。システム内のネットワークコンポーネントによって参照するプロキシ設定が異なることもあります。ブラウザーが使えて特定のアプリが失敗しても、サーバーが使えないとは限りません。対象アプリがHTTPまたはSOCKSプロキシに対応しているか確認し、クライアントで実際に有効になっているローカルの待ち受けアドレスを入力してください。端末内だけで使う場合はループバックアドレスで待ち受け、同じLANの端末に意図せず公開しないようにします。

TUNの権限と終了手順

基本の接続が使える状態になってから、対象アプリがシステムプロキシに従わない場合にTUNモードを検討してください。初回の有効化では、使用中のクライアントの実装によって、管理者権限、サービスコンポーネント、仮想インターフェースが必要になる場合があります。アプリの案内に従って許可し、起動ログでインターフェースとルートの作成が成功したことを確認してください。スイッチがオンになっているだけで通信が引き受けられたと判断しないでください。権限の拒否、インターフェースの作成失敗、ほかのトンネルとの競合により、スイッチの状態と実際の通信経路が異なることがあります。

仮想マシン、社内ネットワーク、ほかのトンネルツールを併用する環境では、まずLANへのアクセスを維持し、項目ごとにテストしてください。TUNを有効にした後、一部のリソースにしかアクセスできない場合は、まずルーティングとDNSを確認します。仮想アダプターを何度も再インストールしないでください。使用を終えるときは、先にTUNを無効にし、次にシステムプロキシを解除してからクライアントを終了します。異常終了後にブラウザーからネットワークへまったくアクセスできない場合は、Windowsのプロキシ設定を開き、停止中のローカルポートが指定されたままになっていないか確認して、元の設定に戻してください。

Windows起動時の自動起動と接続成功は別のものです。まず手動起動で安定して使えることを確認してから、クライアントの自動起動を有効にしてください。管理者権限が必要なTUNは、通常のログイン時起動とは異なる方法で開始される場合があります。設定後、実際にログアウトまたは再起動して動作を確認してください。メイン画面、通知領域、ログ、設定画面の関係はv2rayNのメイン画面と各機能の解説を参照し、ウィンドウを閉じただけでプロセスも終了したと思い込まないようにしましょう。

03 / MACOS

macOS：チップに合った選択、インストール、ネットワーク権限

チップに合ったパッケージをダウンロードしてアプリを導入する

システムの「このMacについて」を開き、Apple SiliconチップかIntelプロセッサかを確認してから、macOSのダウンロードで対応するv2rayNのインストーラーを選択してください。arm64とx64の違いは、UIの言語や機能のレベルではなくプロセッサのアーキテクチャです。互換レイヤーで起動できるからといって、適切なパッケージを選んだとは限りません。ネイティブのアーキテクチャに合ったパッケージを使えば、実行コンポーネントや権限のトラブルを調べる際の要因を減らせます。特に後からTUNを有効にする場合に役立ちます。

ダウンロード後、ディスクイメージを開き、パッケージの手順に従ってアプリを固定のアプリケーションフォルダに移動してから起動してください。マウントしたディスクイメージから長期間起動したり、アプリの実行中にプログラム全体を移動したりしないでください。初回起動時に、システムが配布元や実行権限を確認する場合があります。選択したダウンロード元から入手したパッケージであることを確認し、システムの具体的な案内を読んでから、許可された範囲で続行してください。システム全体のセキュリティチェックを無効にすることをインストール手順に含めないでください。

アプリが起動しない場合は、アーキテクチャの不一致、システム要件の未達、実行コンポーネントの不足、システムによる起動のブロックを切り分けてください。前の2つは許可を繰り返しても解決しません。後の2つも、アプリの名前を適当に変更して解決できるものではありません。ダイアログの文面とシステム情報を記録し、パッケージの説明と照らし合わせてください。ターミナルから拡張属性を削除するコマンドは、問題の原因を確かめずに回避する方法であり、誤ったディレクトリに作用する可能性もあるため、一般的な修復手段として使わないでください。

サブスクリプションを追加して接続先を確認する

v2rayNを起動し、サブスクリプショングループの管理画面を開いて、新しいグループを作成します。URL全体を保存してから更新してください。初回更新には、通常のネットワーク接続を利用するのがおすすめです。サブスクリプションAPIに既存のプロキシ経由でしかアクセスできない場合は、既存の接続が使えることを確認してから適切な更新方法を選びます。「サブスクリプション取得に接続が必要だが、接続にはサブスクリプション取得が必要」という循環を作らないようにしてください。更新後はサーバーを選んで現在の接続先に設定し、まずコアが正常に起動することを確認してからシステムプロキシを調整します。

macOSのネットワーク設定は、ネットワークサービスごとに管理されています。Wi-Fi、有線ネットワーク、その他のインターフェースでプロキシ設定が別々に保存される場合があるため、ネットワークを切り替えた後は現在のサービスの状態を確認してください。クライアントの自動設定は、使用中のサービスに反映される必要があります。ブラウザーが直接接続している場合は、まずシステム設定のネットワーク詳細にあるプロキシ設定を確認し、サーバー設定をすぐに変更しないでください。手動設定では、リモートサーバーのポートではなく、ローカルのループバックアドレスとクライアントに表示されたポートを入力します。

システムプロキシとアプリ独自の設定を区別する

システムプロキシに従うアプリは、自動設定された接続先を使えることが多い一方、ネットワーク設定を個別に持つツールはシステム設定を無視する場合があります。ターミナルのツールも、デスクトップのネットワークサービスにあるプロキシ設定を必ず読み込むわけではありません。個別のツールを設定する場合は、対応しているプロキシ方式と設定の適用範囲を確認してください。一時的なテスト用の設定を、すべてのログインセッションに書き込まないようにします。SOCKSに対応している場合は、ドメイン名をローカルとプロキシ側のどちらで解決するかも確認してください。同じサーバーなのに結果が異なる原因は、通信の失敗ではなく名前解決経路の違いであることもあります。

ブラウザーでは使えるのに開発ツールで失敗する場合は、そのツールに以前保存したプロキシアドレスを削除し、クライアントで現在有効な待ち受け設定と照らし合わせてください。ポートを変更しても、独自のプロキシ設定は自動で更新されません。ローカルサービスにアクセスするときは、ループバックとLANへの直接接続を維持し、開発用の通信をリモートの出口に送らないようにします。また、利便性だけを理由に不要なLAN共有を有効にしないでください。端末内で使うプロキシと、ほかの端末にプロキシを提供する構成は別のものです。

TUNとほかのネットワーク拡張機能を併用する

より多くのアプリの通信を引き受ける必要がある場合は、クライアントが実際に提供しているTUN機能を有効にしてください。OSから管理者権限や補助コンポーネントを求められる場合がありますが、必要な権限はクライアントの実装によって異なります。許可後はログとシステムのネットワーク状態を確認し、仮想インターフェースが作成されたことを確かめてください。社内トンネル、ネットワークフィルター、仮想マシン用ネットワークをすでに使っている場合は、一度に1つの通信経路だけを有効にして動作を確かめてから併用をテストします。複数のコンポーネントが同時にデフォルトルートを変更すると、接続が自分自身に戻ったり、LANの宛先に到達できなくなったりすることがあります。

スリープからの復帰、Wi-Fiの切り替え、有線接続後にTUNモードだけが動作しなくなった場合は、いったん無効にして再度有効にし、DNSが現在のネットワークに合わせて復旧したか確認してください。トンネルを止めずに複数のDNSサーバーを続けて変更しないでください。システムプロキシモードが使える場合は、いったんそちらに戻して接続を保ち、その状態でTUNの問題を調べます。アプリを終了する前に、アプリが設定したプロキシを解除してください。異常終了後にループバックアドレスがシステムに残っていないか、特に注意が必要です。

04 / LINUX

Linux：deb・rpmとデスクトップのプロキシ環境

パッケージ形式を選んでから依存関係を確認する

Linuxのデスクトップ環境ではv2rayNを使用します。ディストリビューションとアーキテクチャを確認してから、Linuxのダウンロードでdebまたはrpmを選択してください。DebianやUbuntu系では通常debを選びます。FedoraやopenSUSEなどはrpm形式を採用していますが、依存関係の解決方法はディストリビューションによって異なります。x64とarm64は、それぞれ対応するアーキテクチャのパッケージを選んでください。パッケージ形式が合っていても、アーキテクチャまで正しいとは限りません。ダウンロード後は、ディストリビューションのGUIソフトウェアインストーラーか、ローカルパッケージをインストールするコマンドで導入できます。

次の2つのコマンドは、それぞれ対応するパッケージ管理環境で使用します。OSに合った方だけを実行してください。インストーラーを保存したディレクトリでターミナルを開き、ファイルパスを実際にダウンロードしたファイル名に置き換えます。パッケージマネージャーを使ってローカルファイルをインストールすれば、依存関係も同時に処理できます。失敗した場合は、依存パッケージ名、アーキテクチャ、リポジトリのエラーを確認してください。依存関係を強制的に無視して、予測できない状態でアプリを動かさないでください。openSUSEでは専用のソフトウェア管理ツールを使い、Fedora向けのコマンドをそのまま流用しないでください。

sudo apt install ./ダウンロードしたファイル名.deb

sudo dnf install ./ダウンロードしたファイル名.rpm

インストール後は、デスクトップのアプリメニューから起動してください。GUIアプリは一般ユーザーとして実行し、設定はそのユーザーの環境に保存します。インストールしたアプリを起動するために、画面全体を常に管理者権限で実行しないでください。管理者の所有する設定ファイルが作成され、通常のユーザーで起動したときに書き込めなくなることがあります。仮想ネットワークインターフェースや補助サービスに実際に必要な場合だけ、クライアントの案内に従って権限を与えてください。システムプロキシの問題をすべて権限不足のせいにしないでください。

サブスクリプションの追加とデスクトップ環境の違い

サブスクリプショングループに新しいURLを追加し、保存して更新した後、現在のサーバーを選択してください。まずコアが起動し、ログにファイル不足や待ち受けの失敗が記録されていないことを確認してから、プロキシを設定します。GNOME、KDEなどではシステムプロキシの設定方法が異なり、アプリがデスクトップのプロキシ設定を読み込むかどうかもそれぞれ異なります。クライアントにシステムプロキシの設定済みと表示されても、それは該当の操作が実行されたことを示すだけで、すべてのプロセスがプロキシ経由になったとは限りません。ブラウザーと実際に使うツールをそれぞれテストしてください。

ブラウザーでは使えてもターミナルで使えない場合は、ターミナルプロセスの環境を確認してください。以下のコマンドは一般的なプロキシ環境変数を表示するだけで、ネットワーク設定を変更しません。変数名の大文字・小文字の扱いはツールによって異なります。また、以前のセッションに停止済みのポートが残っている場合もあります。特定のコマンドだけに一時的なプロキシを設定する場合は、まずそのツールが用意している一時オプションを使ってください。効果を確認してから永続化を検討し、すべてのユーザーが使う環境ファイルに直接書き込むのは避けてください。

env | grep -iE '^(http|https|all|no)_proxy='

デスクトップのプロキシ、環境変数、アプリ内のプロキシ設定は、それぞれ独立した経路です。同じローカルの待ち受け先を指定できますが、自動的に同期されるわけではありません。NO_PROXYを使うツールでは、特定の宛先がプロキシを迂回する場合があり、照合の書式もツールによって異なります。「特定のドメインだけ常に直接接続される」場合は、クライアントのルーティングだけでなく、ツール独自の除外リストも確認してください。GeoSiteのルールを誤った階層で繰り返し変更しないようにしましょう。

TUN、名前解決、コンテナネットワーク

TUNを使うには、仮想ネットワークインターフェースへアクセスし、ルートを設定するための権限が必要です。有効化に失敗した場合は、まずクライアントのログで権限やデバイスに関するエラーを確認し、現在のパッケージが案内する方法で補助コンポーネントを設定してください。インストールディレクトリ全体に再帰的な書き込み権限を与えたり、出所の分からないバイナリにシステム権限を追加したりしないでください。ディストリビューションのセキュリティポリシー、サービスの起動方法、パッケージの構成によって動作は異なります。他のOSの権限昇格コマンドをコピーするのではなく、実際のエラーに沿って対処してください。

LinuxのDNSは、ネットワークマネージャー、ローカルの名前解決サービス、その他のコンポーネントが管理している場合があります。TUNの有効化後、既知のアドレスには接続できてもドメイン名だけが使えない場合は、名前解決の経路とクライアントのDNS設定を確認してください。一時的に生成された名前解決用ファイルを唯一の設定元として何度も上書きしないでください。ネットワークの再接続でファイルが再生成されることがあります。コンテナ、仮想マシン、ブリッジにも独自のルートと名前解決設定があるため、該当するネットワークへのアクセスを維持したうえで、TUNに含める必要があるか検討してください。

ログイン時の自動起動とアップデート後の切り戻し

デスクトップクライアントは通常、ユーザーのログイン後、GUIセッションが利用できる状態で起動します。まずアプリの自動起動機能を使い、デスクトップのスタートアップアプリ一覧に重複登録されていないか確認してください。デスクトップの自動起動、ユーザーサービス、システムサービスから同じ設定を同時に起動すると、ポートの競合につながりやすくなります。自動起動後は、プロセスが存在するだけで通信が引き受けられたと判断せず、システムプロキシが現在のセッションに設定されたことも確認してください。

アップデート前にクライアントを終了してデータをバックアップし、できるだけ同じ入手元とパッケージ形式を使ってください。アップデート後、画面は正常でも接続できない場合は、コアのパス、設定の互換性、ルールリソースを確認し、すぐにユーザーディレクトリを削除しないでください。元に戻す場合に備えて、現在のログを残し、バックアップとの差を確認してください。インストーラー、デスクトップの起動項目、ログイン時の自動起動については、v2rayNのLinux導入と自動起動の設定もご覧ください。

05 / ANDROID

Android：クライアントのインストールとVPNの許可

v2rayNGまたはv2flyNGを選ぶ

Androidのダウンロードを開き、まずXrayコアを搭載したv2rayNGを選択してください。v2flyNGはV2Flyコアを使う選択肢で、設定がそのコアに対応していると確認できている場合に適しています。同じ設定に対して複数のクライアントを次々とインストールするのは、基本的なトラブルシューティングの方法ではありません。まずプロトコル、トランスポート、セキュリティ設定が現在のコアに対応しているか確認してください。2つのアプリはデータを個別に管理するため、もう一方をインストールしても、サブスクリプション、ルーティング、権限は自動で移行されません。

比較的新しい一般的なデバイスでは、通常arm64が使われます。アーキテクチャが不明な場合は、ダウンロードページにある汎用パッケージを検討してください。最終的な判断は、端末のシステム情報とパッケージの説明に基づいて行います。システムインストーラーが非対応と表示した場合は、まずアーキテクチャ、システム要件、ダウンロードの完了を確認してください。既存アプリとの競合が表示された場合は、パッケージの配布元と署名が一致しているか確認します。先にアンインストールしないでください。通常、アンインストールするとアプリ専用のデータも削除され、サブスクリプションやカスタム設定を復元できなくなることがあります。

外部からダウンロードしたアプリをインストールする際、Androidはインストールを開始したアプリごとに権限を管理します。使用中のファイル管理アプリまたはブラウザーに、必要な権限だけを付与し、インストール後は必要に応じて取り消してください。組織管理下のデバイスでは、インストールやVPNの権限がポリシーで制限される場合があります。デバイス管理のルールに従ってください。不明なツールでシステム制限を回避せず、まずインストール権限、アプリの互換性、端末のポリシーのどれが原因か確認してから対応します。

サブスクリプションを追加・更新して設定を選ぶ

アプリ内のサブスクリプション設定またはグループ管理を開き、名前とURL全体を追加して保存した後、メイン画面に戻って更新を実行してください。リモートサブスクリプションと、クリップボードから取り込む単体設定では、それぞれ対応する入口を使います。更新後は一覧に設定が表示されていることを確認し、接続に使う項目を選択してください。サービス提供元から異なるプロトコルの項目が提示されている場合は、案内に従って選びます。並び順で性能を判断したり、アドレスや認証情報を無関係な設定に連結したりしないでください。

QRコードからのインポートは単体の共有設定に便利ですが、コードに認証情報が含まれている場合があります。システムのスクリーンショット機能や別端末への画像転送を使うときは、画像の保存先と共有範囲に注意してください。サブスクリプションの更新に失敗した場合は、まずアプリのログを見て、リクエスト失敗、空の応答、解析失敗を切り分けます。アカウントのWebページをブラウザーで開けても、サブスクリプションAPIにアクセスできるとは限りません。APIにはパス全体やクエリパラメーターが必要な場合があり、URLの一部をコピーし損ねるだけで応答内容が変わります。

システムのVPN許可と対象アプリの範囲を理解する

初めて接続するとき、Androidでは通常、システムVPNインターフェースを通じて端末内の通信を引き受けます。システムに表示される接続許可を確認してください。これは端末の通信をクライアントに渡すための入口であり、リモートサーバーへの接続成功を意味するものではありません。許可後もログと実際のアクセス結果を確認してください。ステータスバーにVPNアイコンが表示されても、端末内のインターフェースが動作中であることを示すだけです。選択したサーバーに到達できることや、DNSが想定どおりに機能していることまでは証明しません。

Androidでは通常、同じユーザーのVPN経路を同時に利用できるアプリは1つです。ほかのトンネルアプリ、ネットワークフィルター、仕事用プロファイルのネットワークコンポーネントを使っている場合は、競合の有無を確認してから接続を試してください。アプリの振り分けリストによっても、通信を引き受ける範囲が変わります。許可リストと迂回リストは意味が異なり、保存後に再接続しないと反映されない場合があります。特定のアプリだけ直接接続される場合は、サーバーを変更したりサブスクリプションを再追加したりする前に、そのアプリが対象範囲に含まれているか確認してください。

バックグラウンド動作、ネットワーク切り替え、DNS

画面ロック後に接続が切れる場合は、バックグラウンド動作とバッテリー管理を確認してください。システム設定で必要なバックグラウンド動作を許可し、画面消灯後と復帰後の状態をテストします。設定メニューの名称は端末によって異なるため、他社製端末のスクリーンショットをそのまま当てはめないでください。接続を維持するために、端末全体の省電力機能を無効にする必要はありません。クライアントに関係する制限だけを調整してください。常時接続VPNを設定している場合は、「VPN未接続時に通信をブロック」の設定との関係も理解し、通常のネットワークまで壊れたと誤解しないようにします。

Wi-Fiとモバイルネットワークを切り替えると、ネットワーク上のアドレス、名前解決、接続経路が変わることがあります。まずアプリが接続を再確立するのを待ち、ログに具体的なエラーがないか確認してください。特定のネットワークだけで失敗する場合は、そのネットワークのログイン状態、DNS、サーバーへの到達性を比べます。設定をすべて削除しないでください。システムのプライベートDNS、クライアントのDNS、アプリ独自の暗号化DNSが同時に作用する場合もあります。名前解決の経路を一度に1つだけ変更し、どの変更が結果に影響したか記録してください。

新しい端末に移行した後は、システムVPNの許可、バックグラウンド実行の制限、対象アプリの範囲を改めて確認してください。これらのシステム設定は、設定ファイルと一緒に移行されないことがあります。移行後は標準ルートで接続を確認してから、カスタムルーティングとDNS設定を戻してください。インポート画面や更新操作の違いで迷った場合は、クイックスタートガイドに沿って確認してください。インストールや利用に関するその他の質問はヘルプセンターをご覧ください。

06 / CONFIGURATION LAYERS

サブスクリプションとトラフィックの振り分け：保存・マッチング・名前解決

サブスクリプションの更新ですべての設定が同期されるわけではない

サブスクリプションは通常、サーバー設定を配布するためのもので、端末のあらゆる設定を同期するわけではありません。システムプロキシ、ローカルポート、TUNの権限、アプリごとの振り分けは、一般に端末側で管理します。更新時にサブスクリプションの項目が置き換えられたり、再作成されたりする場合があります。上書きされる項目に長期的な手動変更を保存しないでください。固定の変更が必要な場合は、クライアントが対応する独立した設定やグループ機能を使い、変更理由も記録します。更新後、どの項目がサブスクリプション由来で、どれが手動変更か分からなくなるのを防げます。

サブスクリプションの更新とサーバー接続では、別のネットワーク経路が使われる場合があります。現在のプロキシが使えない状態でプロキシ経由の更新を選ぶと失敗することがあります。サブスクリプションAPIに通常のネットワークからアクセスできない場合は、直接接続での更新も失敗します。偶然成功するまで方式を切り替えるのではなく、実際に利用できる経路に合わせて選択してください。更新の前後でグループ、項目、選択中のサーバーを照合し、サーバーが置き換わっていないか確認してから再テストします。サブスクリプションに古い名前が残っていても、実際のアドレスが変わっていないとは限りません。

まず通信がコアに入っているか確認する

ルーティングルールが処理できるのは、すでにコアに届いている通信だけです。アプリがシステムプロキシに従わない場合、ドメインルールをいくら追加しても、そのアプリの通信が自動的にプロキシに入ることはありません。一方、TUN経由でコアに入った通信も、ルールによっては直接接続されます。通信を引き受ける範囲と、リモートの出口を選ぶ処理は別の階層です。トラブル時は、まず入口、次にルールの適用状況、最後に出口への接続を確認してください。3つを混同すると、ブラウザーは使えるのにほかのアプリは失敗する、といった状況を誤って判断しやすくなります。

以下は、プライベートアドレスと中国本土のドメイン分類のマッチング方法を示すルーティングルールの例です。クライアントの完全な設定ファイルとしてそのまま使うものではありません。利用する前に、選択したコアがこれらの項目に対応していること、ルールリソースが存在すること、出力タグが実際の設定で定義されていることを確認してください。クライアントによってタグの名前は異なる場合があり、例の名前だけでは動作しません。ルーティングの編集には、できるだけクライアントの設定画面を使い、手動編集の前にはバックアップを取ってください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

ルールの順序、リソースファイル、デフォルトの出口

一般的なルーティングの実装では、ルールを上から順に確認します。先にマッチしたルールによって、後続のルールが適用されないことがあります。ドメインを個別に振り分ける例外は、より広い分類より前に置き、クライアントのプリセットで別のルールが追加されていないか確認してください。上の例だけでは、どのルールにも一致しない通信の経路は決まりません。デフォルトの出口は完全な設定を見て判断してください。直接接続のルールが2つあるからといって、残りがすべてプロキシ経由になるとは限りません。また、画面上の「グローバル」を、端末内のすべてのアプリ設定を迂回する意味だと考えないでください。

geosite:cnにはドメイン分類データが必要です。geoip:privateには、対応するIPアドレス分類が必要です。ドメインルールはマッチングに使えるドメイン情報を必要とし、IPルールは宛先アドレスを判定します。両者を単純に置き換えることはできません。ルールデータがない場合やタグが定義されていない場合、コアの起動に失敗することがあります。ルールデータの内容が変われば、振り分け結果も変化する可能性があります。クライアントを更新した後は、リソース読み込みのログも確認してください。詳しくはGeoIP・GeoSiteルールデータの更新方法をご覧ください。

DNS設定とコア切り替えの注意点

DNSによる振り分けと接続の振り分けは連携しますが、同じ設定ではありません。ドメインが直接接続されるからといって、DNS問い合わせに必ずローカルの名前解決サービスが使われるとは限りません。リモートDNSサーバーのアドレス自体にも、到達可能な経路が必要です。FakeDNSを導入する場合は、仮想アドレスのマッピングと通信を引き受ける範囲も考慮してください。他の設定からスイッチだけをコピーして済ませないでください。まず通常のDNSで接続を確認し、その後少しずつ振り分けを追加します。設定の詳細はV2RayのDNS振り分け設定ガイドを読み、現在使用しているコアの設定項目と照らし合わせてください。

XrayとV2Flyを切り替える場合は、プロトコル、トランスポート、セキュリティ設定、クライアントが生成する設定を改めて確認してください。クライアントに選択肢が表示されていても、すべての組み合わせが互換性を持つわけではありません。切り替える前に元の設定とログを保存します。切り替えた後は、まずコアが正常に起動することを確認し、以前アクセスできた宛先をテストしてください。コアの切り替えと同時にDNS、ルーティング、サーバーも変更すると、結果が変わっても原因を特定できません。

07 / DIAGNOSTICS

設定でよくある問題：起動から接続まで段階的に確認

まず症状を記録し、確認する段階を決める

問題を報告するときは、プラットフォーム、クライアント、通信を引き受ける方式、発生した操作、エラーの種類を記録してください。「接続できない」という状況を、アプリが開かない、コアが起動しない、サブスクリプションを更新できない、ブラウザーでアクセスできない、特定のアプリだけ失敗する、といった形に分けると、適切な確認手順を選べます。現在の設定をまず保存し、すぐにデータを消去しないでください。障害が起きた時刻を基準にログを確認します。起動時の古いエラーが、その後のアクセス失敗とは無関係なこともあります。目立つエラーを1つ見つけただけで結論を出さないでください。

確認する順序は、端末のネットワーク、クライアントのプロセス、コアの起動、ローカルの待ち受け、サーバー接続、ドメイン名の解決、アプリの通信を引き受ける設定の順に固定してください。各段階で確認するのは1つの問題だけにし、結果を記録します。既知の正常なWebページは変更前後の比較に使えますが、1つのサイトを開けるかどうかだけで接続全体を判断しないでください。Webサイト自体の障害、アカウント制限、アプリのキャッシュも結果に影響します。目的は原因の範囲を絞ることであり、一時的に成功するまで設定を何度も変更することではありません。