導入ガイド · プラットフォームと設定

V2Ray クライアントの
全プラットフォーム導入・設定ガイド

v2rayNのデスクトップ導入、Androidクライアントの設定、サブスクリプション管理、ルーティングのトラブルシューティング。

初回接続は、クイックスタートガイドに沿って設定をインポートし、接続先を選んで接続を確認してください。このページでは、OSごとの導入と権限設定に加え、サブスクリプション、ルーティング、症状別のトラブル対処をまとめています。デスクトップではv2rayN、Androidではv2rayNGを基本とし、v2flyNGはV2Flyコアを使う場合の選択肢です。

v2rayNをダウンロード 使い方を見る パッケージ形式とCPUアーキテクチャを確認してから、該当する章へ進んでください。

事前準備：OS・アーキテクチャ・設定の入手元

インストール対象とクライアントの役割を確認

V2Rayはプロキシ関連技術の名称であり、特定のGUIアプリを指すものではありません。クライアントはサーバー情報の保存、サブスクリプションの更新、設定の生成、コアの起動を担います。コアは実際のプロトコル通信、インバウンドの待ち受け、ルーティングを処理します。v2rayNはWindows、macOS、Linuxのデスクトップ向け、v2rayNGとv2flyNGはAndroid向けです。まずプラットフォームを選び、それに合ったパッケージを用意してください。デスクトップ用プログラムをスマートフォンに展開しても動作せず、Android版の画面にあるボタン名をデスクトップ版の操作手順に当てはめることもできません。

インストール前に、OS、CPUアーキテクチャ、使用するパッケージ形式を確認します。Windowsでは「設定 → システム → バージョン情報」でシステムの種類を確認できます。macOSでは「このMacについて」でチップを確認してください。Linuxでは以下のコマンドでアーキテクチャとディストリビューションを調べられます。Androidでは端末の仕様やインストール済みアプリのアーキテクチャ情報を確認します。特に互換レイヤーや古いOSを使う場合は、CPUの製品名よりOSが対応するアーキテクチャが重要です。ダウンロードページに表示される選択肢を基準にし、ファイル名の印象だけで決めないでください。

uname -m
cat /etc/os-release

Linuxでx86_64と表示された場合は通常x64、aarch64の場合は通常arm64を選びます。ディストリビューション情報はdebかrpmかを判断するためのもので、CPUアーキテクチャの判定には使いません。macOSではApple Siliconがarm64、Intelがx64に相当します。Androidのarm64パッケージは、該当するアプリのアーキテクチャに対応したOSでのみ使用できます。確認できない場合は、先にAndroid版のダウンロード案内を読み、必要に応じて汎用版を検討してください。

インポートする接続情報を用意

クライアントをインストールしただけでは、接続可能なサーバーは設定されません。信頼できる設定提供元から、単一の共有リンクまたはサブスクリプションURLを入手し、有効期限内であることを確認してください。共有リンクは1件の設定を示し、サブスクリプションURLは複数の設定を取得するためのものです。入力欄を取り違えないようにしましょう。アクセス情報を含む場合があるサブスクリプションURLは機密情報として管理してください。スクリーンショット、ログ、問い合わせ文にはURL全体、ユーザー識別情報、認証情報を載せないでください。

提供元から複数のプロトコルや通信方式が提示されている場合は、まずクライアントのコアに対応し、説明が十分なものを選びます。接続にはアドレス、ポート、プロトコル、認証情報、TLS設定、通信パラメーターが必要です。サーバーのドメイン名だけをコピーしても設定は完了しません。ブラウザーでドメインを開けても、プロキシ設定が正しいとは限りません。初めて使う場合は、内容が明確な単一の設定で接続を確認してからサブスクリプションを追加すると、取得時の問題と接続時の問題を切り分けやすくなります。

環境の基準状態を記録し、同時に変更しない

インストール前に、既存のプロキシアプリ、システムプロキシの状態、ネットワークインターフェース、仮想ネットワークツールの有無を記録してください。初回テストではクライアントを1つだけ起動し、複数のプログラムがシステムプロキシ、待ち受けポート、デフォルトルートを取り合わないようにします。会社支給端末のセキュリティポリシー、管理ネットワークのアクセス規則、ローカルファイアウォールが仮想インターフェースや待ち受けを制限している場合があります。事前に権限の範囲を確認し、保護機能をすべて無効にすることを導入手順にしないでください。

設定前に記録しておく情報
項目記録内容用途
プラットフォームとアーキテクチャOS名、x64またはarm64動作するパッケージを選ぶ
設定の入手元共有リンクまたはサブスクリプションURL適切なインポート方法を選ぶ
既存のプロキシ状態手動プロキシや自動設定スクリプトの有無終了時に元の設定へ戻す
ローカルの待ち受けクライアント設定に表示されるアドレスとポートアプリの通信がクライアントに届くか確認

システム時刻も接続条件の一つです。時刻がずれていると証明書の有効期限判定や一部の認証に影響するため、自動時刻合わせを有効にしてください。インストール前のネットワーク状態を記録し、設定のバックアップも用意します。変更前に元の値を控えてください。サーバー認証情報を含むバックアップは本人だけがアクセスできる場所に保存し、公開の添付ファイルとしてアップロードしないでください。準備ができたら該当プラットフォームの章へ進みます。システムプロキシとTUNを同時に有効にする必要はありません。

Windows：v2rayNのインストールとシステムプロキシ

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

Windows版のダウンロードを開き、v2rayNを選びます。デスクトップ版はクロスプラットフォームのUI技術を採用し、従来のWPF版はWindows向けです。ウィンドウ構成や設定項目の場所が異なることがあります。ダウンロードページのシステム要件とパッケージの説明を基準に選んでください。同じアプリ名でも、実行に必要な環境がまったく同じとは限りません。管理対象のPCでは、アプリのインストールとプロキシ設定を変更する権限も確認してください。

ダウンロード後は、パッケージの形式に応じて扱います。インストーラーはウィザードに従ってインストール先を選択してください。圧縮ファイルは書き込み可能な場所にすべて展開してから起動し、圧縮ファイルのプレビュー画面から直接実行しないでください。ダウンロード一時フォルダーや自動削除される場所に置くと、設定、ログ、同梱コアが失われることがあります。実行環境が不足していると表示された場合は、そのパッケージの要件に沿って依存環境を整えます。関係のないコアファイルを何度も入れ替えるのは避けてください。

初回起動時に、メイン画面が最後まで読み込まれるか、設定を保存できるか、再起動後に設定が復元されるかを確認します。通常のシステムプロキシ設定では、常に管理者として実行する必要はありません。まず一般ユーザー権限で基本動作を確認してください。ファイアウォールの通知が表示されたら、対象プログラムとネットワーク範囲を確認します。ローカルプロキシは主にPC内のアプリで使うため、ブラウザーのテストを理由にすべてのネットワーク機器へのアクセスを許可する必要はありません。OSに実行を阻止された場合は、すべてのセキュリティ警告を無視せず、表示された理由を確認してください。

サブスクリプションをインポートして設定を確認

単一の共有リンクはコピーし、「クリップボードからインポート」などの項目から読み込みます。サブスクリプションURLはサブスクリプショングループの設定に登録します。グループを作成してURLを入力・保存し、更新を実行してください。画面変更によりボタン名が異なる場合がありますが、手順は同じです。URLを保存し、一覧を取得してから、使用する設定を選びます。一覧に項目が表示されても、インポートが完了したことを示すだけで、コアの起動やサーバーへの接続を保証するものではありません。

更新後、設定の所属グループ、プロトコル、通信方式が提供元の案内と一致するか確認します。表示名だけでは設定が同一か判断できません。更新で項目が置き換わる場合があるため、手動で変更する前に別のグループへコピーしておくと、次回更新で上書きされません。接続情報が複数ある場合は、まず有効性が明確なものを1件選びます。プロトコル、ポート、TLSパラメーターを一度に変更しないでください。共有リンクとサブスクリプションの違いは、共有リンクとサブスクリプションの使い方を参照してください。

システムプロキシ、TUN、権限の設定順

コアの起動後、クライアントでシステムプロキシを有効にし、Windowsのプロキシ設定でアドレスとポートを確認します。システムプロキシは接続先をOSの設定に登録する機能です。その設定を参照するブラウザーやアプリだけが利用します。独自のプロキシ設定を持つアプリや、直接通信するアプリもあるため、ブラウザーが使えて他のプログラムが使えなくても、サーバーの障害とは限りません。自動設定スクリプト、手動プロキシ、ブラウザー拡張がクライアントの設定を上書きすることもあります。

TUNモードは仮想ネットワークインターフェースを使って通信を処理するため、システムプロキシとは適用範囲が異なり、通常は高い権限やルーティングの変更を伴います。使用中のバージョン、コア、システム環境が対応している場合にのみ有効にしてください。ほかのプロキシ機能を停止してから、画面の指示に従って権限を許可します。有効化後に通信できなくなった場合はTUNを無効にし、デフォルトルートが戻ったことを確認して、動作確認済みのシステムプロキシ方式に戻します。その後、ログ、インターフェースの状態、セキュリティソフトの通知を確認してください。

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

上記のPowerShellコマンドはローカルの待ち受け状態を確認するもので、接続を自動修復するものではありません。クライアント設定に表示される実際の待ち受けポートと結果を照合してください。ほかのプログラムがポートを使用中の場合は、クライアントのローカルポートを変更し、アプリ側のプロキシ設定も合わせて更新します。リモートサーバーのポートとローカルプロキシのポートを取り違えないでください。「LAN接続を許可」を有効にすると待ち受け範囲が変わります。1台だけで使う場合は通常、ループバックアドレスのままにします。

終了、自動起動、アップグレード時の注意

ウィンドウを閉じても通知領域に最小化されるだけの場合があります。使い終わったら、クライアントが設定したシステムプロキシを解除してから終了してください。停止したローカルポートへアプリが接続し続けるのを防げます。ログイン時の自動起動を有効にした場合は、再起動してクライアントとプロキシ設定が想定どおり復元されるか確認します。クライアントが自動起動しても、TUNが自動で権限を取得するとは限りません。アップグレード前に旧プロセスを終了して設定をバックアップし、更新後はサブスクリプショングループ、選択中の設定、待ち受けポート、ルーティング設定を確認します。メイン画面が開くかどうかだけで判断しないでください。

macOS：チップの確認、インストール、ネットワークの権限

チップに合ったv2rayNを選ぶ

「このMacについて」でチップを確認してから、macOS版のダウンロードへ進みます。Apple Siliconはarm64、Intelはx64を選んでください。画面サイズや購入年からアーキテクチャを推測しないでください。互換環境で異なるアーキテクチャのアプリが動く場合もありますが、ネイティブ対応版のほうが実行環境や権限の問題を切り分けやすくなります。ダウンロード後にdmgを開き、ウィンドウの案内に従ってアプリを「アプリケーション」フォルダーへ移動します。

コピーが終わったら、「アプリケーション」フォルダーからv2rayNを起動してください。ディスクイメージ内から使い続けないでください。ディスクイメージは配布用の媒体であり、マウントを解除するとその中のパスは使えなくなり、設定の保存や更新に影響することがあります。初回起動時にセキュリティ警告が表示されたら、ファイルの入手元と警告内容を確認し、OSが案内する方法で許可してください。アプリ1つのためにシステム全体のセキュリティチェックを無効にしたり、出所不明の権限変更コマンドを貼り付けたりしないでください。

アプリ起動後、設定を保存できるか、コアが正常に起動するかを確認します。画面は開いても、同梱の実行ファイルが権限やアーキテクチャの不一致で動かない場合、ログは起動段階で止まることがあります。まずローカルの実行問題を解決し、リモートサーバーの設定は変更しないでください。OSのアップデート後に以前の許可状態が変わった場合も、警告を改めて確認します。以前のMacの権限設定をそのままコピーしないでください。

設定のインポートとネットワークサービスのプロキシ

共有リンクをコピーし、クライアントのクリップボードからインポートするか、サブスクリプショングループにURLを保存して更新します。macOSのクリップボードに以前の内容が残っている場合があるため、インポートに失敗したら、リンク全体がコピーされ、説明文や改行が混ざっていないか確認してください。インポート後に使用する設定を選んでコアを起動します。テストにはシステムプロキシを参照することが明確なアプリを使い、独自プロキシ設定を持つブラウザー拡張は同時に有効にしないようにします。

システムプロキシは通常、ネットワークサービスごとに設定されます。Wi-Fiと有線ネットワークでプロキシの状態が異なることがあるため、ネットワークを切り替えたらクライアントのメニューだけでなく、現在使用中のサービスを確認してください。システムのネットワーク設定を開き、使用中のネットワークサービスのプロキシ項目で、アドレスとポートがクライアントの実際の待ち受け先を指しているか確認します。自動プロキシ設定スクリプトを使用している場合は、手動プロキシとの優先関係も確認してください。

プロキシ設定の変更にシステムの許可が必要な場合は、要求元が現在使用中のクライアントであることを確認してから許可します。許可を拒否してもコアのローカル待ち受けは可能な場合がありますが、アプリがその接続先を自動で使うことはありません。まずアプリ内にプロキシアドレスを明示して動作を確認し、接続できた後でシステム設定を調整できます。「システムプロキシを書き込めない」問題と「コアがサーバーに接続できない」問題を分けて調べられます。

TUN、DNS、スリープ復帰

TUNモードが使えるかどうかは、クライアントのビルド、コアの機能、システム権限によって異なります。有効にする前に、使用中のネットワークサービスとDNS設定を記録し、ほかの仮想ネットワークツールによる通信制御を停止してください。昇格権限や補助コンポーネントのインストールが必要な場合は、使用中のバージョンの案内に従います。他のプラットフォーム向けのドライバー手順をmacOSに流用しないでください。有効化後はドメインへのアクセスとローカルネットワークリソースの両方を確認し、直通が必要な通信経路が変わっていないか確認します。

DNSの問題が特定のアプリだけに起きることがあります。ブラウザーで独自のセキュアDNSが有効な場合、システムやクライアントで指定した名前解決経路を使うとは限りません。1つのブラウザーで失敗しても、すべてのDNSが停止したとは判断できません。別のアプリでも比較し、クライアントのログで名前解決と接続の各段階を確認してください。証明書が必要なサイトへIPアドレスでアクセスすると証明書の照合条件が変わるため、同等のTLSテストにはなりません。

scutil --proxy
scutil --dns

この2つの読み取り専用コマンドは、現在のプロキシとDNS情報を表示し、GUIの設定と照合するためのものです。出力に会社の設定やローカルネットワーク情報が含まれる場合があるので、共有前に機密情報を削除してください。スリープからの復帰、テザリングへの切り替え、ネットワークサービスの変更後は、既存の接続が一時的に使えなくなることがあります。まず接続をやり直してサービスの状態を確認し、その後コアを再起動してください。最初からアプリのデータフォルダー全体を削除する必要はありません。

終了時とアップグレード後の確認

終了前に、クライアントが変更したプロキシ設定を元に戻します。アプリが異常終了すると、現在のネットワークサービスにローカルプロキシが残り、ブラウザーが存在しない待ち受け先へ接続することがあります。クライアントを再起動して状態を復元するか、システム設定から今回追加したプロキシ項目だけを削除してください。既存の会社設定を上書きしないようにします。アップグレード後はアプリの場所、権限、現在の設定、ルーティングを確認します。チップのアーキテクチャも変更した場合は対応パッケージを再ダウンロードし、古い実行ファイルをそのまま移行しないでください。

Linux：deb・rpmのインストールとデスクトップ統合

ディストリビューションとアーキテクチャを別々に確認

Linuxデスクトップではv2rayNを使用します。Linux版のダウンロードを開き、Debian、Ubuntuおよび互換ディストリビューションでは通常deb、Fedoraおよび互換環境では通常rpmを選びます。パッケージ形式とCPUアーキテクチャは別の要素です。同じdebでもx64版とarm64版があります。まず/etc/os-releaseとuname -mで確認してから選んでください。ファイルをダウンロードできても、そのまま現在のPCにインストールできるとは限りません。

以下のコマンドは一時作業用ディレクトリを使って、インストール対象のパッケージを分けます。現在のディレクトリに該当するパッケージが1つだけある場合を想定しています。ファイル名はダウンロード時の実際の名前のままにしてください。選んだパッケージを作業用ディレクトリへコピーし、一覧を確認してからインストールします。古いパッケージが複数混在するダウンロードフォルダーで、ワイルドカードを使ったコマンドを直接実行しないでください。debとrpmのコマンドは、ディストリビューションに合うどちらか一方だけを使います。

# Debian / Ubuntu：現在のディレクトリにあるdebファイルを確認
ls -1 ./*.deb
sudo apt install ./*.deb

# Fedora：現在のディレクトリにあるrpmファイルを確認
ls -1 ./*.rpm
sudo dnf install ./*.rpm

システムのパッケージマネージャーを使うと、依存関係を処理し、アプリをシステムに登録できます。アーキテクチャが一致しないというエラーが出たら、適切なパッケージに切り替えてください。依存関係を解決できない場合は、ディストリビューションの対応状況とソフトウェアリポジトリを確認します。依存関係を無視する方法を常用しないでください。インストール後はデスクトップのアプリ一覧から起動し、通常のユーザーで設定を保存します。rootでGUIを起動すると設定ファイルの所有者が変わり、通常ユーザーで書き込めなくなることがあります。

サブスクリプションのインポートとデスクトップのシステムプロキシ

クライアントを起動したら、サブスクリプショングループにURLを保存して更新するか、クリップボードから単一の設定をインポートします。Linuxではリモートデスクトップ、異なるディスプレイセッション、端末のクリップボードツールによって選択バッファーが異なる場合があります。インポートに失敗したら、GUIクライアントが正しいテキストを受け取ったか確認してください。サブスクリプションURLを公開される端末履歴に直接貼り付けないでください。設定を選んでコアを起動し、ローカルの待ち受けと起動ログを確認してからシステムプロキシを有効にします。

Linuxの「システムプロキシ」は、すべてのプログラムに強制される共通の接続先ではありません。デスクトップ環境、ブラウザー、端末アプリ、バックグラウンドサービスが別々の設定を参照する場合があります。デスクトップのネットワーク設定が反映されても、シェルのコマンドが自動的にプロキシを使うとは限りません。逆に、端末だけに環境変数を設定しても、デスクトップアプリがそれを参照するとは限りません。まず明示的にプロキシを指定できるアプリで確認し、用途に応じてデスクトップ側を設定してください。

HTTPプロキシとSOCKSプロキシではプロトコルが異なるため、ポートを取り違えないでください。混合ポートを使う場合はクライアントの説明に従います。端末に古いプロキシ環境変数が残っていると、ブラウザーと異なる結果になることがあります。コマンド履歴や環境変数に認証情報が含まれる場合があるため、内容をそのまま公開しないでください。以下の読み取り専用コマンドで待ち受けを確認し、クライアントの設定と照合します。

ss -lntup
ip route
ip -6 route

TUNの権限とネットワーク管理ツールの競合

TUNモードは通常、仮想インターフェースの作成とルーティングの変更を必要とします。一般ユーザーでクライアントを起動できても、その操作に必要な権限があるとは限りません。まずクライアントが用意する権限昇格方法を使ってください。アプリのディレクトリ全体に広い書き込み権限を与えたり、出所不明のファイルに恒久的な特権を付与したりしないでください。有効化後は仮想インターフェース、デフォルトルート、DNSの状態を確認します。コアの起動に失敗した場合は、ルールを変更する前に、ログに明示された権限エラーを解決してください。

NetworkManager、ほかの仮想ネットワークツール、コンテナネットワーク、企業VPNが同時にルーティングを変更することがあります。競合したら、新たに有効にした通信制御を停止してネットワークを復旧し、1つずつ有効にして原因を特定してください。LANに接続できない場合は、すべての通信をプロキシへ送るのではなく、プライベートアドレスの直通ルールと仮想インターフェースの経路を確認します。IPv4は正常でもIPv6に問題がある場合、経路が別々である可能性があります。それぞれの結果を記録してください。

デスクトップへのログイン時の自動起動とアップグレード

まずクライアント内蔵のログイン時自動起動設定を使います。現在のバージョンに項目がない場合は、デスクトップ環境の自動起動アプリ管理でインストール済みのプログラムを選んでください。デスクトップへのログイン時の自動起動と、システム起動時のサービスは別のものです。GUIクライアントはユーザーセッションに依存するため、ヘッドレスサービスとして直接起動する用途には適しません。設定後にログアウトして再ログインし、複数のプロセスが起動していないか確認します。

アップグレード時は旧プロセスを終了し、同じパッケージ管理方式で新しいパッケージをインストールして、ユーザー設定のバックアップを残します。管理者権限で起動したことがあり設定を保存できなくなった場合は、設定ディレクトリの所有者を確認してください。クライアントのデータディレクトリであることが明確な範囲だけを修復し、ホームディレクトリ全体を再帰的に変更しないでください。パッケージの導入とログイン時の自動起動については、Linuxへのインストールと自動起動の設定を参照してください。

Android：v2rayNG・v2flyNGの設定

クライアント、アーキテクチャ、インストール許可を選ぶ

Androidではv2rayNGを基本とし、コアにはXray系を採用しています。V2Flyコアを使う設定が必要な場合はv2flyNGを検討してください。選ぶ際は、設定に必要な機能と普段の使い方を基準にし、名前だけを比べないようにします。2つのアプリは設定やデータをそれぞれ保存するため、片方をインストールしても、もう片方のデータは自動で移行されません。まずAndroid版のダウンロードでパッケージとシステム要件を確認してください。

arm64アプリに対応する端末では、通常arm64版を選びます。アーキテクチャが分からない場合やインストーラーに互換性エラーが表示された場合は、汎用版の説明を確認してください。パッケージの解析に失敗する原因は、ダウンロード未完了、OSバージョンの要件不足、既存アプリとの署名不一致なども考えられます。アーキテクチャだけが原因とは限りません。ダウンロード元からアプリをインストールする許可は、実際に使う入手元だけに与え、インストール後は必要に応じて取り消してください。

システムで署名の不一致が表示された場合、既存クライアントをすぐにアンインストールしないでください。まず古いアプリの入手元を確認し、復元できるよう設定をエクスポートします。アンインストールするとグループ、手動で追加した項目、アプリごとの振り分け設定が削除されることがあります。エクスポートファイルには接続情報が含まれるため、非公開の場所に保存してください。手当たり次第に上書きするより、同じ入手元から正しいパッケージを再ダウンロードするほうが原因を特定しやすくなります。異なる入手元のパッケージから直接更新できるかは、システムの表示に従ってください。

クリップボードとサブスクリプショングループからのインポート

単一の共有リンクはクリップボードからインポートし、サブスクリプションURLはサブスクリプション設定で項目を追加して保存後に更新します。Androidではクリップボードの内容が自動消去されることがあるため、コピー後すぐにクライアントを開き、空の内容やウェブページの説明文ではないことを確認してください。初回の更新に失敗した場合は、URL形式、接続、応答、解析のどの段階でエラーになったかを記録します。すでに動作する設定を使ってサブスクリプションを取得する必要があるかどうかも、その後に判断してください。

一覧から使う設定を1件選び、接続をタップします。ローカルVPN接続を初めて作成すると、Androidクライアントが通信を処理するためのシステム許可ダイアログが表示されます。許可した後、クライアントの接続状態とシステム通知を確認し、アプリを1つ使ってテストしてください。VPNアイコンが表示されても、VPN接続が確立したことを示すだけで、リモートサーバーへの接続や名前解決の成功までは保証されません。

サブスクリプションの更新では、提供元から返された内容に基づいて項目が更新されます。サブスクリプション内の設定を手動で変更しても、次回更新で消えることがあります。継続して使う変更は別の項目にコピーし、元の入手元を記録してください。同じ共有形式でも、クライアントによって対応状況が異なり、新しい通信パラメーターを含む設定では特に差が出ます。インポート後もプロトコル、TLS、通信方式、必要なパラメーターが揃っているか確認してください。

アプリごとの振り分けとバックグラウンド動作

Androidクライアントは主にシステムVPNインターフェースを使うため、デスクトップのシステムHTTPプロキシ設定をそのまま適用する必要はありません。通常、同じインターフェースを同時に使えるVPNサービスは1つだけです。同じインターフェースを使うほかのツールを起動すると、現在の接続が置き換わることがあります。接続ボタンが成功を示した直後に別のサービスへ切り替わらないよう、テスト中は通信を制御するアプリを1つだけにしてください。

アプリごとの振り分けを設定する前に、現在のモードが「選択したアプリのみをプロキシする」のか「選択したアプリを除外する」のかを確認してください。2つのリストは意味が反対で、同じアプリにチェックを入れても結果は異なります。まずアプリを1つだけ使って確認し、問題がなければ対象を増やします。リストを変更した後は、クライアントの案内に従って接続を再確立してください。アプリの振り分けとドメインルーティングは別の階層です。アプリを除外すると、その通信はコアのルール判定に届かないことがあります。

画面消灯後の切断は、バッテリー最適化、バックグラウンド制限、メーカー独自のタスク終了機能が原因の場合があります。まずクライアントの通知が残っているか、プロセスが終了していないかを確認し、必要なバックグラウンド動作をシステムのアプリ設定で許可してください。最初からサーバーのプロトコルを変更しないでください。モバイル通信とWi-Fiの切り替えでは接続が再確立されます。特定のネットワークだけで失敗する場合は、同じ設定を維持して比較し、接続先とDNSを同時に変更しないようにします。

DNS、テザリング、アップデート後の確認

システムのプライベートDNS、ブラウザー独自の名前解決、クライアントのDNS設定によって、異なる経路が使われる場合があります。ドメインへ接続できないときはログを確認し、VPN切断時の名前解決結果と比較してください。DNSアドレスを手当たり次第に置き換える方法を常用しないでください。テザリングで接続する別の端末が、スマートフォン上のクライアントの通信経路を自動で通るとは限りません。スマートフォンのアプリが使えても、テザリング先の端末が同じ経路を使っている証拠にはなりません。

クライアントを更新した後は、現在の設定、アプリごとの振り分けリスト、ルーティングモード、バックグラウンド権限を確認してください。OSの更新で一部の権限がリセットされる場合もあります。v2rayNGとv2flyNGでは設定名が異なることがあるため、移行時は機能ごとに対応関係を確認し、サブスクリプションをインポートしただけですべての動作が同じになると思わないでください。選び方は3種類のクライアント比較、初回接続の手順はクイックスタートガイドを参照してください。

サブスクリプション管理：グループ、更新、設定の移行

共有リンク、サブスクリプションURL、完全な設定ファイル

vmess://やvless://などの共有リンクは、通常1件のサーバー設定を表します。サブスクリプションURLは通常、HTTPリクエストで複数の項目を取得します。完全なJSONにはインバウンド、アウトバウンド、ルーティング、DNSが含まれる場合があります。3つは用途が異なります。サブスクリプションURLを単一サーバーの編集欄に貼り付けたり、完全な設定ファイルを共有リンクとして読み込んだりすると、形式を正しく認識できません。内容の種類を確認してから、クライアントに合った方法でインポートしてください。

サブスクリプションURLをブラウザーで開けても、クライアントが内容を解析できるとは限りません。ログインページ、アクセス案内、リダイレクト先、未対応形式が返されることがあります。ブラウザーにテキストが表示されても、すべての項目をクライアントが受け入れるとは限りません。解析エラーが発生したら、応答が本当にサブスクリプションの内容か確認し、クライアントの形式対応を調べてください。ページが表示できたという理由だけでクライアントを何度も再インストールしないでください。

サブスクリプションURLのアクセス情報はアカウント権限に関わる場合があります。URL全体を公開の変換サービスに送ったり、公開設定例に記載したり、ブラウザー履歴のスクリーンショットを問い合わせに添付したりしないでください。変換が必要な場合は、入力・出力形式、処理サービスの信頼性、変換時に失われる可能性のある項目を確認します。変換で変わるのは表現形式であり、無効なアカウント、接続できないサーバー、不足している認証情報は修復されません。

グループ名と更新結果の確認

入手元ごとに独立したグループを作り、提供元や用途を識別できる短い名前を付けます。テスト設定、手動設定、サブスクリプション項目を分けておくと、更新の影響範囲を確認しやすくなります。グループ内に重複項目があっても、すぐに削除する必要はありません。まずサーバーアドレス、プロトコル、ポート、通信パラメーターを比較してください。表示名が同じでも設定が異なることがあり、名前が違っても同じサーバーを指す場合があります。

初回更新は手動で実行し、応答と項目の変化を確認します。成功してから自動更新の頻度を設定してください。ネットワーク接続前やクライアント起動前の更新が繰り返し失敗するのを防げます。「プロキシ経由で更新」があるクライアントでは、既存の設定が正常に使える場合にのみ有効にします。最初の接続ができていない状態で有効にすると、まだ存在しない出口にサブスクリプション取得が依存することがあります。

更新後に現在選択中の項目が置き換わったり削除されたりする場合があるため、選択内容を改めて確認してください。項目数が変わった場合は、端末内のデータ破損と決めつけず、提供元がサブスクリプションの内容を変更したか確認します。手動で用意した基準設定で接続できるなら、調査対象をサブスクリプションの取得と解析に絞れます。更新に失敗したときは、すべての項目を消して再試行するより、以前の設定を残すほうが原因究明に役立ちます。

移行時は接続情報と実行設定を分けて考える

デバイス間の移行には、少なくともサーバー情報とローカルの実行設定が関係します。共有リンクやサブスクリプションが移行するのは通常、前者だけです。システムプロキシ、待ち受けポート、アプリごとの振り分け、TUNの権限、ログイン時の自動起動は自動で移行されません。WindowsのローカルパスやLinuxの権限設定をAndroidへそのままコピーすることもできません。移行後は移行先プラットフォームの章に沿って接続を確認し、振り分け設定を一つずつ戻してください。

移行できる設定とできない設定
内容一般的な移行方法移行後の確認項目
単一サーバー設定クライアントから共有リンクをエクスポートプロトコル、TLS、通信パラメーター
サブスクリプションの入手元URLを再登録して更新グループと選択中の設定
ローカルプロキシ新しい端末で再設定待ち受けアドレス、ポート、アプリの接続先
振り分けと権限移行先のプラットフォームで個別に設定ルールの順序、アプリ一覧、許可

エクスポートしたバックアップは、どこまで復元されるかを確認してください。サーバー情報だけを含むものもあれば、クライアントの設定を含むものもあります。いずれもOSレベルの許可設定まで含むとは限りません。バックアップの暗号化やアクセス制限は、端末の機能に合わせて設定します。サブスクリプションURLが漏えいした場合、ローカルファイルを削除するだけではリモートの権限を取り消せません。提供元が用意する方法でアクセス情報を変更してください。

コアとの互換性と設定項目の確認

V2FlyとXrayは関連するオープンソースエコシステムに属しますが、対応機能は同じではありません。コアを切り替えても、設定の意味が別の実装向けに自動変換されるわけではありません。未知の項目、未対応の通信方式、起動エラーがある場合は、まず具体的なエラーを確認し、提供元の要件と照合してください。REALITYなど、コアの機能要件が明確な設定では、要件を満たすクライアントの組み合わせを選びます。v2flyNGで、コアが対応していない項目をそのまま設定しないでください。

形式の詳しい見分け方は共有リンクとサブスクリプションURLの違いを参照してください。複雑な設定はconfig.jsonの構造解説を読み、クライアントが生成する項目と手動で追加した項目を区別します。画面上の表示名をコアのパラメーターと混同しないでください。

プロキシとルーティング：入口、出口、ルールの順序

まず通信がコアに届いているか確認

ルーティングルールが処理するのは、コアに届いた通信だけです。システムプロキシはアプリにローカルのプロキシ接続先を提供し、TUNは仮想インターフェースを使って条件に合う通信を処理します。Androidではアプリの対象リストによって、どのアプリがVPNに入るかを決める場合があります。アプリがクライアントを使っていないなら、routingを変更しても動作は変わりません。振り分けを調べる前に、アプリの接続先とローカルの待ち受け設定が一致していることを確認し、その後ルールの適用を確認してください。

クライアントの「全般」は通常、クライアントに届いた通信を共通の出口へ送る設定であり、端末上のすべてのプログラムを自動的に強制接続するものではありません。「中国本土を迂回」「ブラックリスト」「ホワイトリスト」などはクライアントのプリセット名です。実際の動作は生成されるルールと出口によって決まります。名前だけを見てすべてのドメインの経路を推測しないでください。同じ名称のプリセットでも、クライアントやバージョンによってルールが異なる場合があります。

ローカルのHTTP、SOCKS、または混合インバウンドからコアへ通信を渡します。outboundsは利用可能な出口を定義し、routing.rulesは条件に一致した通信を出口のタグへ振り分けます。タグは参照用の名前であり、特別な意味が予約されているわけではありません。ルール内のoutboundTagは、実際の出口に設定されたtagと一致させる必要があります。一致しないと、設定を起動できないか、想定どおりに転送されないことがあります。

ルールの判定とサンプルの範囲

ルールは通常、記述された順に確認され、先に一致したルールが後続のフォールバックより優先されます。範囲の広いルールを先に置きすぎると、より具体的なルールが適用されません。ドメインルールは対象サービスが明確な場合、IPルールはプライベートネットワークやアドレス範囲に適しています。アプリがドメイン名で接続するか、IPアドレスを直接使うかによって、判定に使える情報も変わります。スニッフィングで補える情報もありますが、すべての通信から信頼できるドメイン名を取得できるわけではありません。

以下は、設定の構造を学び、ローカルの待ち受けを確認するための完全なサンプルです。直通とブロックの出口だけを定義し、リモートプロキシサーバーは含みません。すべてのインバウンド通信を直通にし、ドキュメント用サンプルドメインへのアクセスをブロックします。実行前にポートが使用中でないことを確認してください。各項目の関係を理解するための例であり、動作中のサーバー設定を上書きする目的ではありません。完全な設定ファイルをインポートできるかどうかは、使用中のクライアントの画面で確認してください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "127.0.0.0/8"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domain:example.comはサンプルドメインとそのサブドメインに一致します。ホスト名を完全一致させる場合はfull:形式を使います。ルールに一致しない通信は通常、最初のアウトバウンドを使うため、この例では直通を先頭にしています。プロキシによる振り分けを行うには、別途、実際に使えるプロキシ出口を定義し、該当するルールからその出口を参照する必要があります。proxyというタグを追加するだけでプロキシ機能が得られるわけではありません。

ドメイン判定、データファイル、DNS

IPIfNonMatchは、ドメインルールに一致しなかった場合に対象ドメインを名前解決し、IPルールによる判定を試みる設定です。すべてのリクエストで先にIPアドレスを解決するという意味ではありません。AsIsとIPOnDemandでは名前解決のタイミングが異なり、選択によって判定情報やDNSリクエストが変わります。設定の意味に詳しくない場合は、まずクライアントのプリセットを維持し、ログで原因を確認してください。ドメイン判定方式を汎用的な高速化設定として使わないでください。

geosite:cn、geoip:cn、geoip:privateは、コアが参照できるデータと分類名に依存します。どの設定にも辞書が標準で含まれているわけではありません。データファイルや分類が見つからない場合は、クライアントが対応する方法でリソースを更新してください。上記の例では外部分類に依存しないようプライベートネットワークを明示していますが、直通が必要なすべてのアドレスを網羅しているわけではなく、IPv6のプライベート範囲も設定していません。そのまま本番用の完全な振り分け設定として使わないでください。

ルールの実際の動作を確認

ルールは一度に1つだけ追加します。再起動または再読み込み後にコアが正常に起動することを確認し、対象を1つに絞ってテストしてください。ウェブページが開くかどうかだけでなく、接続ログに記録された宛先、インバウンドタグ、アウトバウンドタグを確認します。ウェブサイトは複数のドメインへ同時にリクエストすることがあり、トップページが正常でもすべての通信が同じ経路とは限りません。確認後は、ルールの目的と順序を記録しておくと、プリセットの更新後も既存ルールの意図を追えます。

設定のよくある質問：原因の段階ごとに確認

まずローカルでの起動問題を確認

問題がどの段階で起きているかを特定します。アプリのインストール、コアの起動、ローカルの待ち受け、通信の振り分け、リモート接続、名前解決、対象アプリのいずれかです。同じネットワーク、同じアプリ、同じ接続先を使うなど、再現できるテスト条件を1つ決めてください。クライアント、設定、DNS、ルーティングを一度に変更しないでください。複数の変更を同時に行うと比較条件が失われ、接続が戻っても有効だった変更を特定できません。

クライアントが起動しない場合は、システム要件、パッケージのアーキテクチャ、実行に必要な依存環境を確認してください。画面は正常でも接続ボタンを押すとすぐエラーになる場合は、コアの起動ログを確認し、未知の設定項目、リソース不足、実行権限、ポート競合を優先して調べます。この段階ではまだリモートに接続していないため、サーバーアドレスを変えても通常は解決しません。設定を保存できない場合は、データディレクトリの書き込み権限、ディスクの空き容量、異なる権限での起動履歴を確認してください。

ローカルのプロキシポートが待ち受けていない場合、アプリは接続を拒否されたりタイムアウトしたりします。設定に表示されたポートを確認し、他の解説記事にある固定値を推測で使わないでください。ポートが使用中なら、使用しているプロセスを確認し、競合するアプリを通常の方法で終了するか、ローカルポートを変更します。システムプロセスをむやみに終了しないでください。変更後はアプリ内のプロキシ設定とシステム設定も更新します。そうしないとコアが復旧しても、アプリは古い接続先を使い続けます。

サブスクリプションが空のときとリモート接続に失敗するとき

サブスクリプション一覧が空の場合は、まず更新処理が実際に完了したか確認します。ネットワーク要求の失敗と内容の解析エラーでは、対処が異なります。前者はURLへの到達性、現在の取得経路、ネットワーク状態を確認し、後者は応答形式とクライアントの対応範囲を調べてください。URLのコピー漏れや、アカウントページをサブスクリプションURLと取り違えていないかも確認します。1回の失敗で既存の有効な項目を削除しないでください。

コアが起動しているのにすべてのリクエストが失敗する場合は、設定が正しく選択されているか、接続情報が有効か、システム時刻が正確かを確認してください。接続タイムアウトは、いずれかの段階が期限内に完了しなかったことを示しますが、それだけでサーバーの故障とは断定できません。認証エラーでは認証情報、アカウントの状態、パラメーターを優先して確認します。TLSエラーではサーバー名、証明書の条件、時刻を確認してください。証明書の検証を無効にする方法を恒久的な解決策にしないでください。

特定のネットワークだけで失敗する場合は、設定を変えずにネットワークを切り替えて比較します。Wi-Fi、モバイル通信、会社のネットワークでは、名前解決経路や接続条件が異なる場合があります。ネットワークを切り替えて復旧した場合は、失敗したネットワークでの段階とログを記録してください。その結果をすべてのクライアントに当てはめないでください。プロトコルのパラメーターは提供元の案内に従って設定し、似ているという理由だけで別の項目に置き換えないでください。

ブラウザーは使えるのに他のアプリが使えない

まず、失敗するアプリがシステムプロキシを参照するか、独自のプロキシ設定を持つか、Androidのアプリ一覧で除外されていないか、UDPが必要かを確認します。HTTPプロキシ、SOCKS、TUNで通信の適用範囲は異なり、リモート側のプロトコルが必要な通信に対応するかも別途確認が必要です。クライアントのテスト機能によって確認される接続の種類は限られる場合があります。テストが成功しても、対象アプリの機能全体が使えるとは限りません。

DNSに問題がある場合は、ドメインの名前解決と接続エラーを比較し、システムDNS、クライアントDNS、ブラウザー独自の名前解決、システムのプライベートDNSを切り分けます。1度ドメインに接続できなかっただけでIPv6を無効にしないでください。まずIPv4とIPv6のルーティングやログを比較してから、必要に応じて対象を絞って調整します。ローカルサービスに接続できない場合は、プライベートアドレスの振り分けとTUNのルートを優先して確認し、ローカル通信をリモート出口へ流さないようにしてください。

よくある症状と優先して確認する項目
症状まず確認すること次の対応
コアを起動できないログ、設定項目、リソース、権限最後に起動できた設定へ戻す
アプリの接続が拒否されるローカルの待ち受けとポートクライアントとアプリの接続先を統一
更新後にサブスクリプションが空になるリクエスト結果と応答形式URLと解析への対応を確認
特定のアプリだけ失敗するアプリのプロキシ設定と振り分けリスト明示的なプロキシ設定で比較
TUN有効化後にネットワークへ接続できない権限、仮想インターフェース、デフォルトルートTUNを無効にして基準状態へ戻す

通信制御の停止、ネットワークの復旧、ログの整理

通常のネットワーク接続に戻すには、まずTUNまたはAndroidのVPN接続を無効にし、次にクライアントが設定したシステムプロキシを解除してから、プログラムを終了します。異常終了した場合は、OSにローカルプロキシが残っていないか確認してください。会社の既存プロキシ設定は削除せず、今回追加・変更した設定だけを元に戻します。それでも復旧しない場合はデフォルトルートとDNSの状態を確認し、必要に応じて現在のネットワークサービスを再接続してから端末を再起動してください。

問い合わせには、プラットフォームとアーキテクチャ、クライアント名、失敗した段階、試した操作、機密情報を削除したエラーの抜粋を含めてください。サブスクリプションURL、認証情報、完全なユーザー識別情報、不要なネットワーク情報は削除し、問題の特定に必要な状況だけを残します。デバッグログにアクセス先が含まれる場合があります。記録後は通常のログレベルに戻してください。未整理の大量ログより、安定して再現できる手順のほうが役立ちます。

システムプロキシとTUNを同時に有効にすべきですか？

初回テストでは同時に有効にしないでください。まずどちらか一方の通信制御を検証し、使用中のコアとアプリの要件に応じて併用するか判断します。併用する場合は、通信の二重制御、ルーティング、DNSの動作を確認してください。両方を有効にすれば通信範囲が広がるとは限りません。

クライアントを変更しても解決しません。再インストールを続けるべきですか？

まずクライアントと設定を1つに固定し、起動、待ち受け、通信の取り込み、リモート接続、名前解決の順に確認してください。共通している設定の入手元、ネットワーク環境、システム設定が原因かもしれません。再インストールする前にバックアップを取り、どの段階まで正常と確認できたか記録してください。

このページでは、原因を調べる手順を段階ごとにまとめています。最小限の接続手順を最初から確認する場合はクイックスタートガイドへ戻ってください。アーキテクチャに合うパッケージをダウンロードする場合はクライアントのダウンロードを開きます。複雑な設定項目と出口の参照関係は設定ファイルの構造解説で確認し、プラットフォームの操作とコアの設定を混同しないようにしてください。