V2Ray 全プラットフォーム
インストール・設定ガイド

事前準備：設定と接続経路を確認する

クライアント、コア、サーバー設定の違い

まず、3つの要素を分けて考えます。GUIクライアントはサーバー、サブスクリプション、ルーティング、システム接続を管理し、コアは接続と転送を実行します。サーバー設定には、接続先アドレス、ポート、プロトコル、認証情報が含まれます。クライアントをインストールしても接続先がなければ利用できず、設定をインポートしても接続先のサーバーが稼働しているとは限りません。切り分けでは3つを個別に確認しましょう。アドレスの誤りが原因なのにシステムプロキシを何度も変更したり、画面が起動しただけでコアも正常だと判断したりするのを防げます。

デスクトップではv2rayN、Androidではv2rayNGが主な選択肢です。V2Flyコアを使う設定が必要な場合はv2flyNGを検討してください。3つのクライアントは画面や設定機能が異なります。同じ共有リンクを読み込めても、それは構文を解析できたというだけで、すべての通信オプションに対応しているとは限りません。サーバー側のプロトコル、通信方式、必要なコア機能を確認してからクライアントを選びましょう。インポートできるように、内容が分からない項目を安易に削除しないでください。

クライアントのダウンロードページからプラットフォームを選ぶ前に、OSのバージョン、CPUアーキテクチャ、パッケージ形式を確認します。システム設定でOSやプロセッサーの情報を確認し、ブランド名ではなく実際の実行環境に合ったアーキテクチャを選んでください。デスクトップ版はインストーラー、ディスクイメージ、ディストリビューション用パッケージで導入方法が異なります。Androidも汎用パッケージとアーキテクチャ別パッケージがあり、ファイルサイズだけでは判断できません。ダウンロードページのプラットフォーム別カードで、アーキテクチャの説明を確認してからインストールしてください。

サブスクリプションを用意し、現在のネットワーク設定を記録する

有効なサブスクリプションURLまたは個別の共有リンクを用意します。サブスクリプションには更新可能なサーバー一覧が含まれるのが一般的ですが、共有リンクは1つの接続設定を表します。インポート画面が異なる場合があるため、どちらを使うか確認してください。コピー時に空白、引用符、改行が混ざっていないかを確認し、ページタイトルまで一緒にコピーしないようにします。サブスクリプションURLには個人用のアクセス情報が含まれることがあるため、パスワードと同様に扱ってください。スクリーンショット、ログ、公開の問い合わせにURL全体を載せたり、他人の設定をテストに使ったりしないでください。

現在のプロキシ、ほかのトンネルツール、手動DNS設定を記録し、あとで元に戻せるようにします。初回設定では接続方法を1つだけ有効にしてください。まずシステムプロキシでブラウザーを確認し、必要に応じてTUNを試します。複数のクライアントを同時に有効にすると、待ち受けポートの競合、システムプロキシの上書き、ルーティングループが起こることがあります。会社や学校の管理端末では、ネットワーク拡張や管理者権限が制限されている場合もあります。ポリシーで拒否された場合は許可範囲を確認し、セキュリティ設定を強制的に変更してインストールしないでください。

最小構成で動作を確認する

テストの前に、システムの日付とタイムゾーンを正しく設定してください。暗号化接続では証明書の有効期間が関係することがあり、時刻のずれがハンドシェイク失敗の原因になります。次に、通常のネットワーク接続が使えること、ブラウザーに個別のプロキシ拡張機能が設定されていないことを確認します。既知の方法でアクセスできるテストサイトを基準にし、テスト条件を変えずに確認してください。クライアントの接続テスト、ブラウザーのリクエスト、ほかのアプリの通信では経路が異なる場合があります。1つの結果だけで全体を判断しないでください。

ローカルの待ち受けアドレスとポートを確認します。個人用端末では通常、ループバックアドレスで待ち受ければ十分です。LANからの接続を許可するとアクセス範囲が広がるため、接続できない場合に常に有効な解決策とは限りません。混合ポートは、クライアントが対応する複数のプロキシリクエストを同じ入口で受け付けられますが、詳細は設定値を確認してください。ここに記載する10808はよくある例にすぎません。実際の値は現在の設定で確認し、例のままで待ち受けできると決めつけないでください。

最初に接続できた設定を基準として保存します。使用したクライアント、接続方法、ルーティングのプリセット、ローカルポートを記録すれば十分です。認証情報を記録する必要はありません。DNS、コア、TUNを変更するときは、一度に1項目だけ変更し、同じネットワークで再テストしてください。問題が起きたときに直前の状態へ戻せるため、複数の設定を同時に疑わずに済みます。初回接続だけが目的なら、クイックスタートの手順に戻り、準備、インポート、モード選択、接続確認の順に進めてください。

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

デスクトップ版またはWPF版を選ぶ

Windowsのダウンロードページを開き、v2rayNのカードからデスクトップ版または従来のWPF版を選びます。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版はWindows向けです。レイアウト、設定の場所、実行に必要な環境が異なる場合があります。一方の画面で見た位置を、もう一方でも同じだと考えないでください。インストールパッケージの説明を確認し、OSとアーキテクチャに合ったものを選びましょう。画面の違いを比較する場合は、デスクトップ版とWPF版の選び方を参照してください。

インストーラーはウィザードに従って実行します。圧縮形式で配布されている場合は、書き込み可能な専用フォルダーにすべて展開してから起動してください。圧縮ソフトのプレビューから実行したり、異なる配布パッケージのプログラムとコアのファイルを混在させたりしないでください。設定ファイルを一時削除される場所に置かず、フォルダーに十分な書き込み領域を確保します。初回起動時に実行環境の不足が表示されたら、配布元の説明に従って必要なものを追加してください。不明な配布元から同名のシステムファイルを個別にダウンロードして上書きしないでください。

起動後はメイン画面のログを確認し、コアがすぐに終了していないかを見ます。ウィンドウを閉じても、プログラムがタスクトレイで動作している場合があります。再度起動する前にトレイを確認し、複数のインスタンスを起動しないようにしてください。インストール先に個人ファイルがある場合は、アップグレード前に設定をエクスポートし、旧フォルダーも残します。クライアントの実行中に使用中のファイルを上書きしたり、同じ配布パッケージ内の関連ファイルを残して実行ファイルだけをコピーしたりしないでください。アップグレード後は、待ち受けポートとシステムプロキシの状態も再確認します。

サブスクリプションを登録し、プロキシ接続を1つ有効にする

サブスクリプション設定から新しいグループを作成し、識別しやすい名前とサブスクリプションURLを入力して保存したら、グループを更新します。個別の共有リンクを使う場合は、クリップボードからインポートする機能を選んでください。更新後、想定したサーバーが一覧に表示されることを確認し、そのうち1つを選択して現在のサーバーに設定します。インポートで一覧が更新されても、使用中のサーバーが自動的に切り替わるとは限りません。画面内の項目はv2rayNのメイン画面ガイドを参考に探してください。

初回確認では「システムプロキシを自動設定」を選び、TUNは無効のままにします。システムプロキシは、端末のプロキシ設定に従うアプリにローカルのプロキシアドレスを設定します。ブラウザーは最初の確認に使いやすい一方、ゲーム、更新プログラム、独自のネットワーク設定を持つアプリは従わない場合があります。ブラウザーにプロキシ拡張機能がある場合は、テスト前に無効にしてください。アプリごとに手動設定する場合は、クライアントが実際に待ち受けているループバックアドレスとポートを入力し、入口に合ったプロキシ方式を選びます。

より多くのアプリの通信を取り込みたい場合は、その後でTUNを試してください。TUNは仮想ネットワークインターフェースとルーティングを通じて通信を取り込みます。管理者権限が必要になる場合がありますが、クライアントやシステム環境によって異なります。まずシステムプロキシを解除してから、画面の案内に従ってTUNを有効にし、権限、インターフェースの作成、ルート設定に関するエラーがログにないか確認します。コアの動作と使用中のサーバーも確認してください。TUNを有効にできても、すべてのネットワークで適切に動作するとは限りません。ほかのトンネル、仮想NIC、管理ポリシーと競合する場合があります。

ポート競合と終了後のネットワーク切断に対処する

待ち受けに失敗した場合は、エラー行にアドレスの使用中を示す内容があるか確認します。以下のコマンドはローカルポートの診断用で、プロセスを自動終了するものではありません。例では10808を確認します。現在の設定値に置き換えてください。出力の最後の列に表示されるのはプロセスIDです。タスクマネージャーで対応するプロセスを確認できます。どのプログラムかを確認してから、重複したインスタンスを終了するかポートを変更するか判断してください。ポート番号だけを見てシステムプロセスを終了しないでください。

netstat -ano | findstr :10808

ポートを変更した場合は、手動設定したアプリの値も更新します。システムプロキシを自動設定している場合は、プロキシ設定を再適用し、システムが古いポートを参照していないか確認してください。詳しい切り分け方はローカルポートの競合対処ガイドを参照してください。ファイアウォールの確認画面では、実際の用途に合ったネットワーク範囲を選びます。個人用端末でローカル接続だけを使うなら、テストのためにLANからの待ち受けを許可する必要はありません。保護機能全体を無効にして、個別の原因調査に代えることもしないでください。

クライアントを終了する前にシステムプロキシを解除し、TUNを無効にしてから通常終了します。プログラムが異常終了したあとブラウザーがネットにつながらない場合は、システムプロキシ設定にループバックアドレスが残っていないか確認してください。クライアントが停止していることを確認してから残った設定を解除し、直接接続を試します。スリープ復帰後やWi-Fi切り替え後に問題が起きた場合は、現在のサーバーへ再接続して接続方法を再適用してください。プロキシ設定の残留は再インストールで直るとは限らないため、何度もインストールし直さないでください。

macOS：チップの選択とネットワーク権限

チップに合った版を選び、初回起動する

macOSのダウンロードページを開き、「このMacについて」に表示されたチップに合わせてv2rayNを選択します。Apple Siliconはarm64、Intelはx64です。外観や購入時期からアーキテクチャを推測したり、互換レイヤーですべてのネットワーク拡張の問題が解決すると考えたりしないでください。ダウンロード後にディスクイメージを開き、配布パッケージの手順に従ってアプリを「アプリケーション」フォルダーへ移動します。マウントしたイメージ内のアプリを使い続けず、移動先から起動してください。

初回起動時、ネットからダウンロードしたアプリであることを確認するようシステムに求められる場合があります。ファイルの配布元とアプリ名を確認し、システム設定に表示される案内に従ってください。アプリを起動するためにセキュリティチェックを全体的に無効にしたり、配布元が不明な制限解除コマンドを実行したりしないでください。アーキテクチャに対応していない、またはOSのバージョンが要件を満たさないと表示された場合は、ファイルのアクセス権を何度も変更せず、ダウンロード案内に戻って適切な版を選び直します。アプリが起動するまでは、サブスクリプションやDNSの問題を調べる必要はありません。

アプリが設定を保存でき、再起動後も値が保持されることを確認してから、設定をインポートします。アプリケーションの保存先とユーザー設定の保存先は役割が異なります。アップグレード時はクライアントのバックアップまたはエクスポート機能を使い、アプリのアイコンだけを残して設定も保存されたと思い込まないでください。システムバックアップは追加の復元手段になりますが、設定を復元した後もローカルポート、権限、ネットワークインターフェースを確認します。移行先の端末では異なる場合があるため、以前の値をそのまま使わないでください。

設定をインポートし、システムプロキシを確認する

サブスクリプショングループにURLを追加して保存・更新し、使用するサーバーを選択したら動作ログを確認します。個別の共有リンクをインポートする場合は、内容が欠けていないことを確かめてからクリップボードから読み込みます。ほかのデスクトップOSで使っていたリンクを入力に使える場合はありますが、生成された設定ファイル全体をコピーしてmacOS側の設定の代わりにすることはできません。設定に元の端末だけにある証明書、スクリプト、インターフェースのパスが含まれている場合は、画面から項目ごとに設定し直し、古いパスが起動時に使われないようにします。

まずシステムプロキシでブラウザーの接続を確認します。macOSのプロキシ設定はネットワークサービスごとに異なるため、Wi-Fiと有線のどちらを使っているかによって確認するサービスが変わります。自動設定後もブラウザーの動作が変わらない場合は、システム設定のネットワークで現在のサービスを選び、プロキシ設定を確認してください。アドレスが本機を指し、ポートがクライアントの設定と一致している必要があります。ネットワークサービスを切り替えた場合はもう一度確認します。使用していないサービスでプロキシが有効になっているだけでは、現在のネットワークが接続されたことにはなりません。

コマンドラインツールや独自のプロキシ設定を持つアプリは、システムプロキシに従わない場合があります。個別にテストする場合は、プロキシの入口を明示し、アプリ側の動作とシステム設定を切り分けます。以下のコマンドは、現在の混合ポートがHTTPプロキシリクエストを受け付ける場合に使えます。システムプロキシを変更せず、ローカルの入口経由で1回リクエストできるかを確認します。応答があればリクエストは完了していますが、意図したリモート出口を経由したかどうかは、ルーティングログや出口のテスト結果も確認してください。

curl -I --proxy http://127.0.0.1:10808 https://example.com

TUNを有効にし、ネットワーク切り替えに対処する

TUNを使う場合は、まず正常に動作しているシステムプロキシの状態を記録し、プロキシを解除してからTUNを有効にします。クライアントの案内に従って必要な権限を許可してください。許可画面の形式はOSや配布方法によって異なります。ログに操作の拒否、仮想インターフェースの作成失敗、ルート追加の失敗が表示された場合は、まず権限が許可されているか確認します。この段階では、サーバー側のプロトコル設定を変更しないでください。TUNが解決するのは通信をクライアントへ取り込む方法であり、サーバーアドレス、認証情報、通信方式の誤りは直せません。

ほかのトンネルツールと同時に動作させるときは、デフォルトルートとDNSの設定元に注意してください。テスト中はネットワークを制御するクライアントを1つだけにし、複数のプログラムが交互に設定を書き換えないようにします。会社のネットワーク、テザリング、公共Wi-Fiに接続した後は、ネットワーク自体のログインを先に済ませてからプロキシに再接続する必要がある場合があります。通常の直接接続もできないなら、まず基本ネットワークを確認してください。ログイン画面が開かない状況でサーバーを何度も変えても、解決しないことがあります。

スリープ復帰後に一部のサイトだけ使えない場合は、まず接続し直し、DNSエラーとルートが更新されているかを確認します。すぐにシステムのネットワーク設定をすべて消去しないでください。クライアントを終了してシステムプロキシが解除されていることを確認し、直接接続をテストしてから、接続方法を1つだけ有効にし直します。手動DNS、ブラウザーのセキュアDNS、クライアントコアのDNSはそれぞれ別の層です。複数の設定を残すと実際の問い合わせ経路が分かりにくくなるため、このページのルーティングの章に沿って段階ごとに確認してください。

通常終了する場合は、まずTUNを停止し、次にシステムプロキシを解除してからアプリを終了します。アンインストール前にも同じ手順を行ってください。アプリを削除しても、ネットワーク設定がすべて自動で消えるとは限りません。終了後もネットにつながらない場合は、現在のネットワークサービスのプロキシ設定が停止中のローカルポートを参照していないか確認します。正常に接続できているときの設定、特にローカルポートと接続方法を記録しておくと、OSの更新や端末の買い替え後にもスムーズに復元できます。各項目を推測し直す必要がありません。

Linux：パッケージとデスクトップのプロキシ接続

パッケージ形式とCPUアーキテクチャを選ぶ

Linuxのダウンロードページを開き、ディストリビューションに合ったv2rayNのdebまたはrpmパッケージを選び、x64またはarm64のアーキテクチャも確認します。デスクトップの見た目だけでパッケージ形式を判断することはできません。同じデスクトップ環境でも、パッケージ管理方式が異なるディストリビューションがあります。まずシステム情報でディストリビューションとアーキテクチャを確認してください。確認に使える読み取り専用コマンドは次のとおりです。一般にx86_64はx64、aarch64はarm64に対応します。

uname -m

ディストリビューションのGUIソフトウェアインストーラーで対応するパッケージを開き、依存関係を確認してからインストールします。依存関係を解決できないと表示された場合は、システムのディストリビューションとソフトウェアソースの状態を確認してください。依存関係を強制的に無視して、見かけ上だけインストールしないでください。完了したらデスクトップのアプリケーションメニューから起動し、画面とログを確認します。画面は表示されてもコアが終了する場合は、コアのログを調べてください。画面描画の問題とネットワークプロトコルのエラーを混同しないようにします。

ユーザー設定ディレクトリの所有者と権限を適切に保ちます。通常のプロキシ機能を使うだけなのに、GUIクライアント全体を常に最高権限で実行しないでください。一般ユーザーが書き込めない設定ファイルが作成される場合があります。その状態で通常のユーザーとして起動すると、保存やサブスクリプションの更新に失敗したり、ログを書き込めなくなったりします。実行ユーザーを変更したことがある場合は、影響を受けたディレクトリを特定し、ディストリビューションのドキュメントに従って権限を戻します。ホームディレクトリ全体のアクセス制限を再帰的に緩めないでください。

サブスクリプションを登録し、デスクトップ設定とアプリ設定を区別する

サブスクリプションの登録手順はほかのデスクトップOSと同じです。グループを作成し、URLを入力して保存・更新した後、使用するサーバーを選択します。更新に失敗した場合は、リクエストに既存のプロキシが必要かを先に確認してください。URLとネットワークモードを同時に変更しないでください。別の端末から移行する場合は、クライアントの共有リンクまたはエクスポート機能を優先します。ローカルパスを含む設定は作り直す必要があります。コアが起動していることを確認してからアプリの接続方法を設定し、待ち受けていないポートにアプリが接続し続けないようにしてください。

Linuxデスクトップのシステムプロキシ対応は、デスクトップ環境やアプリによって異なります。デスクトップのプロキシ設定を読むアプリ、環境変数を読むアプリ、独自設定だけを使うアプリがあります。クライアントにシステムプロキシが設定済みと表示されても、すべてのプログラムがその入口を使うとは限りません。まずブラウザーで基本接続を確認し、その後ほかのアプリを個別に調べます。トレイアイコンが表示されない場合も、すぐにプログラムが起動していないと判断しないでください。アプリの画面やプロセスを確認し、デスクトップのトレイ連携の違いかどうかを切り分けます。

プロキシを明示した単発リクエストは、接続層の問題を切り分けるのに役立ちます。以下のコマンドでは、ローカルポートがSOCKSリクエストを受け付ける必要があります。socks5hでは、接続先のホスト名をローカルで先に名前解決せず、プロキシの入口へ渡して処理します。これだけで、以降のすべてのDNS問い合わせが必ずリモートサーバー経由になるわけではありません。実際の動作はコアのルーティングとDNS設定によって決まります。ポートを置き換えて実行し、環境変数のグローバル設定には書き込まないでください。

curl -I --proxy socks5h://127.0.0.1:10808 https://example.com

初回のテストでは、システム全体に影響する環境ファイルを変更しないことをおすすめします。環境変数は新たに起動したプロセスにしか適用されない場合があり、起動済みのブラウザーには自動で反映されません。GUIから起動したアプリが端末の設定を読み込むとも限りません。コマンドラインアプリでプロキシが必要な場合は、まずそのアプリだけで確認してから、設定を永続化するか判断します。デスクトッププロキシ、アプリ個別のプロキシ、グローバル環境変数を同時に設定し、1つのアプリが接続できただけで全体が正しいと判断しないでください。

TUNの権限と待ち受け状態を確認する

TUNには仮想インターフェースとルートを管理する権限が必要です。有効化の方法はディストリビューション、カーネル、クライアントの配布方式によって異なります。現在のクライアントの案内に従って許可し、ほかのOSで使う権限操作を流用しないでください。有効化する前にルートを制御するほかのツールを停止し、有効化後はインターフェースが実際に作成され、ルールが適用されているかを確認します。画面のスイッチがオンでも、ログに権限不足が表示されている場合、通信がTUNに入っていない可能性があります。サーバーを変えても、この層の問題は解決しません。

ローカルの接続先に到達できない場合は、ss -lntpでTCPポートの待ち受けを確認できます。表示されるプロセス情報の範囲は、現在の権限によって異なります。目的のポートが見つからなければ、まずコアが終了していないか、設定が読み込まれているかを確認してください。別のプロセスがポートを使用している場合は、用途を確認してから重複したインスタンスを終了するか、待ち受けポートを変更します。リモート接続の失敗はDNS、認証、通信のログを引き続き確認してください。リモート側のエラーを直すために、待ち受けアドレスをすべてのインターフェースに変更しないでください。

ネットワークの切り替え、スリープ、クライアントの終了後は、デスクトッププロキシが残っていないか確認します。パッケージをアンインストールしても、アプリごとに手動設定したプロキシがすべて元に戻るとは限りません。端末の環境変数も個別に解除する必要があります。変更内容を明確に元に戻せる範囲にとどめ、操作前に記録してください。テスト完了後は、ブラウザー、必要なアプリ、直接接続への復帰をそれぞれ確認します。3つの動作が想定どおりなら、デスクトップ環境の導入と設定は完了です。

Android：インストール、権限、バックグラウンド動作

クライアントと対応アーキテクチャを選ぶ

Androidのダウンロードページを開き、まずXrayコアを使うv2rayNGを確認してください。V2Flyコアを使う設定が必要な場合は、代替としてv2flyNGを使用します。比較的新しい一般的な端末はarm64が主流ですが、最終的には端末が対応するアプリのアーキテクチャに合わせてください。判別できない場合は、異なるアーキテクチャのパッケージを次々に試さず、汎用パッケージを検討します。インストールに失敗する場合は、OSバージョン、アーキテクチャ、既存アプリとの署名の競合をそれぞれ確認してください。

ブラウザーやファイル管理アプリからインストールパッケージを開くと、そのアプリからのインストールを許可するよう求められる場合があります。許可の対象は通常、ファイルを開いたアプリです。インストール後、必要に応じて許可を取り消せます。システムが既存アプリとの競合を表示した場合は、先に現在のアプリの入手元を確認し、設定をエクスポートしてください。データを復元する方法を考えずにアンインストールしないでください。クライアントごとにアプリデータは独立しており、別のクライアントをインストールしても、サブスクリプション、サーバー、ルーティング設定は引き継がれません。

初回起動後は、通知とネットワークに関する案内を確認してから、サブスクリプションを設定します。AndroidクライアントはシステムのVPNサービス機能を使って通信の入口を作りますが、ここでのシステム許可はリモートサーバーへの接続を意味しません。許可されるのはアプリがネットワークトンネルを作成することです。その後、有効な設定と正常なコアが必要です。仕事用プロファイルや管理ポリシーで制御された端末では、利用できるVPNサービスが制限される場合があります。同じパッケージを何度もインストールするのではなく、管理上の要件を確認してください。

サブスクリプションを登録し、接続対象を確認する

サブスクリプション設定でグループを新規作成し、名前とURLを入力して保存した後、更新を実行します。個別の共有リンクしかない場合は、クリップボードからインポートする機能を使います。設定をスキャンする場合に限り、対応するスキャン機能でカメラ権限が必要です。インポート後はサーバー名、プロトコル、通信設定がそろっているか確認し、設定を1つ選んで接続します。無効になったサブスクリプションURLを個別の共有リンクとして何度も取り込まないでください。2つの入口は異なる内容を処理するため、繰り返してもURLが有効になるわけではありません。

接続をタップしたら、システムのVPN許可ダイアログを確認して承認します。常駐通知とクライアントのログを見て、サービスがすぐに停止していないか確認してください。Androidでは通常、同じユーザー環境で有効にできるVPNサービスは1つです。別のネットワークツールが現在の接続を置き換えることがあります。テスト時は、特に同じVPNインターフェースを使うフィルターアプリなど、ほかの同種のサービスを停止してください。システムにVPNアイコンが表示されても、トンネルが作られたことしか分かりません。リモート接続とルーティングの結果は実際の通信で確認します。

アプリごとのプロキシ設定を確認します。許可リストを有効にすると、選択されていないアプリはプロキシを経由しない場合があります。除外リストを有効にすると、一覧にあるアプリは直接接続する場合があります。意味が逆の設定なので、アプリ名が一覧にあるかどうかだけで判断しないでください。まず標準の接続範囲でブラウザーをテストし、その後必要なアプリを追加します。ブラウザー独自のセキュアDNS、キャッシュ、接続の再利用も結果に影響します。ルールを変更したら、開いているページを更新するだけでなく、新しいリクエストを送信してください。

バックグラウンド動作とバッテリー消費のバランスを取る

画面消灯後に接続が切れた場合は、システムがサービスを停止したのか、サービスは動作中でも通信に失敗しているのかを確認します。前者なら、アプリのバッテリー最適化、バックグラウンド動作、自動起動の制限を確認してください。後者なら、ログ、現在のネットワーク、サーバーの状態を確認します。設定画面の場所はメーカーや機種によって異なるため、現在のシステムで同じ機能を持つ項目を探してください。バックグラウンド制限を一度にすべて解除せず、動作に直接影響する項目を1つ変更し、画面消灯時と復帰後の挙動を確認します。

常駐通知はサービスの状態を知らせるものです。通知が消えたからといって、サービスが停止したと断定できませんが、切り分けの手がかりにはなります。接続を長時間維持する場合は、状態を確認できる通知を残すと便利です。バッテリー消費が多い場合は、頻繁な接続テスト、繰り返す再接続、ログレベルの高さ、バックグラウンドアプリの継続通信を確認してください。アプリをバッテリー最適化の対象外にすると継続動作しやすくなりますが、コアの消費電力が直接下がったり、リモート接続の不安定さが直ったりするわけではありません。

Wi-Fiからモバイルネットワークに切り替えると、既存の接続が使えなくなり、再接続が必要になる場合があります。特定のネットワークで接続できない場合は、まずそのネットワーク自体で通信できることを確認し、同じサーバーと設定で比較してください。公共ネットワークではログイン画面での認証が必要な場合があり、モバイルネットワークではデータセーバーやバックグラウンド通信の許可が影響することがあります。切り替え直後のリクエストがタイムアウトしても、すぐにサブスクリプション全体を作り直さないでください。まず再接続の結果とログを確認すると原因を特定しやすくなります。

使い終わったら、クライアント内で接続を切り、システムの接続アイコンと常駐通知の状態を確認します。別のクライアントに切り替える前に現在のサービスを停止してください。VPNの許可が切り替わっただけなのに、サーバー障害と誤認するのを防げます。バックグラウンド制限やバッテリーとのバランスを詳しく調整する場合は、v2rayNGのバックグラウンド動作と省電力設定を参照してください。必要なログを保存してからデータを消去します。アプリデータを消すとローカル設定も削除されるため、切断のたびに行う対処ではありません。

サブスクリプションと移行：復元できる設定を維持する

適切なインポート方法を選ぶ

サブスクリプションURL、共有リンク、完全な設定ファイルはそれぞれ用途が異なります。サブスクリプションURLは一覧を定期取得するため、共有リンクは単一の接続設定を共有するため、完全な設定ファイルにはローカルの入口、アウトバウンド、ルーティング、DNSなどが含まれる場合があります。ある形式を扱えるクライアントでも、残りの形式を同じ方法で読み込めるとは限りません。インポート前に内容を確認してください。通常のWebページURLをサブスクリプションと間違えたり、設定ファイル全体をリンク専用の入力欄に貼り付けたりしないでください。

サブスクリプションを用途や提供元で分かるようにグループ分けし、名前に認証情報を含めないでください。保存後はグループを1つずつ更新して結果を確認します。更新に成功しても一覧が空の場合は、空の内容が返された、形式に対応していない、フィルターで項目が隠れている可能性があります。更新後に同じ名前が重複しても、表示名だけを見てサーバーを削除しないでください。名前は一意の識別子ではありません。現在のサーバーとグループの関連を確認してから古い項目を整理し、必要な設定を誤って削除しないようにします。

サブスクリプションで管理される項目と、手動で追加した項目を区別します。サブスクリプション更新でサーバー側の設定が上書きされる場合があり、登録済みの項目で通信設定を直接変更しても、次回の更新で元に戻ることがあります。一時的なテストが必要なら、クライアントの複製機能または独立した設定を使い、テスト用と分かるようにして元の項目を残してください。一時的な修正を長期利用する設定の入手元にしないでください。サーバー側に変更があった場合は、まずサブスクリプションを更新するか、設定の提供元にパラメーターを確認します。

サブスクリプション更新に失敗した段階を特定する

まず更新リクエストが送信されているか確認します。URLが空、形式が不正、余分な文字が混入している場合は、接続前に失敗します。ドメインの名前解決失敗も接続確立前のエラーです。タイムアウト、証明書エラー、アクセス拒否はその後の段階で起こります。URLによってはログインページに転送されたり、エラーページが返されたりします。リクエストが成功しても、返された内容がサブスクリプションとは限りません。ログのステータスとエラー概要を確認し、期限切れ、アクセス制限、形式の問題をまとめて「クライアントが開けない」と扱わないでください。

「サブスクリプション更新時にプロキシを使用しない」設定が変えるのは更新リクエストの経路であり、通常のアプリ通信のルーティングではありません。現在のサーバーが使えず、そのサーバーを経由しないと更新できる場合は、直接更新を試せます。サブスクリプションURLにプロキシ経由でしかアクセスできない場合は、先に利用可能な接続を用意してから更新します。この設定だけを変更し、エラーの結果を比較してください。DNS、使用中のサーバー、更新方法を一度に変えると、更新に成功しても何が有効だったのか分からなくなります。

更新後は、使用中のサーバーが引き続き有効か確認します。サーバー側の一覧から古い項目が削除されたり、設定が変更されたりすることがあります。クライアントが現在の選択を自動で置き換えるかどうかは実装によって異なります。「更新完了」と表示されただけで画面を閉じず、接続をテストして、グループのフィルターで新しい項目が隠れていないかも確認してください。必要に応じてサーバーを選び直します。すべての項目で同時に失敗する場合は、ポートを1つずつ変更するより、サブスクリプションの内容、アカウントの状態、ローカルネットワークに共通する原因を優先して調べます。

設定を移行し、復元結果を確認する

移行前にクライアントのエクスポートまたはバックアップ機能を使い、何が出力されるか確認します。サーバーのリンクだけを書き出す機能もあれば、サブスクリプションや画面設定まで含む機能もあります。ファイル名だけで内容を判断しないでください。サブスクリプションの入手元と必要なカスタムルールは分けて記録し、保護された場所に保存します。移行のために設定フォルダー全体をLANで共有したり、認証情報を含むファイルを公開同期フォルダーに置いたりしないでください。元の端末がまだ使えるうちに、バックアップを復元できるか確認します。

プラットフォームをまたぐ移行では、共通して使えるサーバー情報とサブスクリプションURLを先に移し、移行先でローカルポート、システムプロキシ、TUN、ファイルパスを設定し直します。Windowsのパスやネットワークインターフェース名はLinuxやmacOSにそのまま使えません。Androidのアプリ別リストもデスクトップのアプリ設定とは異なります。コアが異なると、対応するプロトコル項目も変わる場合があります。インポート後は一部のパラメーターが読み飛ばされていないかを確認し、エラーが出なかっただけで全項目を移行できたと判断しないでください。

復元後は、まずサーバーを1つテストし、次にルーティングとDNSを戻し、最後に自動更新とバックグラウンド動作を設定します。各段階が成功したら記録を保存し、元に戻せるチェックポイントを作ってください。クライアントのアップグレードも同じ順序で進めます。エクスポート、終了、アップグレード、ポート確認、リクエストのテストを行います。復元可能なバックアップがない状態で古いフォルダーを削除しないでください。旧プログラムが生成した実行設定全体を、新しい画面で管理されるフォルダーへ強制的に上書きすることも避けます。

ルーティングとDNS：入口、ルール、出口を区別する

システム接続とルーティングの判断を分けて考える

システムプロキシとTUNは通信をクライアントに取り込む方法を決め、ルーティングは取り込んだ通信の出口を選びます。両者は同じ設定ではありません。システムプロキシを有効にしても、アプリがその設定に従わなければ通信はコアに入りません。TUNを有効にしても、ルールにより直接接続することがあります。クライアントの「全般プロキシ」は通常、デフォルトでプロキシ出口を選ぶ設定です。すべてのシステムプロセスが必ず制御されるという意味ではありません。結果を分析する前に、リクエストの入口、ルーティング、リモート接続の順に確認します。

初回はクライアントのルーティングプリセットを選び、動作する基準を作ります。その後、必要なルールを追加し、適用順を確認してください。一般的なルールは順番に評価されるため、条件の広いルールを先に置くと、後ろの細かいルールに適用されない場合があります。LANアドレスを直接接続にすると、ルーター、プリンター、ローカルサービスにアクセスしやすくなります。ただし、どこまでのローカル環境を対象にするかはプリセットによります。社内ドメインがプライベートアドレスに解決されることもあるため、公開ドメインのリストだけでは対応できません。

カスタムルールを編集する前に、何を条件にするのか明確にします。ドメイン、宛先アドレス、アプリはそれぞれ異なる条件で、相互に置き換えることはできません。アプリがIPアドレスへ直接接続する場合、ドメインルールだけでは適用されないことがあります。通信のスニッフィングを有効にすると追加のドメイン情報を得られる場合がありますが、すべての接続で機能するわけではありません。ルールが適用されない場合は、実際の宛先、適用順、デフォルトの出口を確認します。もともと正常だった振り分けまで失わないよう、ルールセット全体をすぐに消去しないでください。

ルール例と実際の出口を照らし合わせる

以下はXray/V2Fly形式のルーティングオブジェクトの例です。LANアドレスは直接接続し、例示したドメインとそのサブドメインはプロキシを使います。これは構文の参考であり、任意のクライアントの入力欄にそのまま貼り付けられる完全な設定ではありません。現在のコアが使用するフィールドに対応していることと、生成された設定にdirectおよびproxyという名前のアウトバウンドタグがあることを確認してください。GUIのルール編集画面を使う場合は、該当する条件を入力します。ドメイン一覧専用の欄にオブジェクト全体を貼り付けないでください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

例にあるプライベートアドレスのルールは、コアが利用できる地理データに依存します。データがないと設定の読み込みに失敗する場合があります。異なるコアのルール構文やデータの構成を混用しないでください。クライアントが生成した設定は、読み取り専用の調査資料として残すのが安全です。生成ファイルを直接編集すると、画面設定の保存や再起動で上書きされることがあります。変更後は、まず設定が読み込まれることを確認し、その後ルールの適用をテストします。コアの起動自体に失敗する場合は、Webアクセスの結果を調べる前に構文とデータのエラーを解決してください。

DNSと接続の再利用を段階ごとに確認する

DNSによる名前解決は、システム、ブラウザー、アプリ、コアの内部で行われる場合があります。クライアントのDNSを変更しても、すべてのアプリが独自の名前解決方法を使わなくなるわけではありません。ブラウザーのセキュアDNSやシステムのプライベートDNSによって、実際の問い合わせ経路が変わることもあります。切り分けでは、まず対象ドメインをどのコンポーネントが解決しているかを記録し、想定した出口を通っているか確認してください。公開DNSの特定アドレスがあらゆる問題に有効とは限りません。ネットワークごとの到達性、遅延、応答結果が異なるため、実際のリクエストで確認します。

サーバードメインの名前解決と、アクセス先サイトの名前解決も区別してください。リモート接続の確立前に、クライアントがまずサーバーのアドレスを見つける必要がある場合があります。この処理に、まだ確立していないプロキシ接続が必要だと、循環依存が起こる可能性があります。クライアントのプリセットでは、こうした接続開始時の名前解決が考慮されていることがあります。カスタマイズ時に関連設定を安易に削除しないでください。ログに名前解決のタイムアウトがある場合は、エラーのドメインがサーバーかアクセス先かを特定してから、基本ネットワーク、コアのDNS、アプリ独自の設定を確認します。

ルールを変更した後は、既存の接続を閉じるかテストアプリを再起動し、接続の再利用で変更が見えなくならないようにします。ブラウザーのキャッシュや既存の長時間接続が古い結果を引き継ぐことがあり、すぐに更新しても新しい接続になるとは限りません。確認時は対象を明確にし、適用された出口とエラーが起きた段階を記録し、直接接続の比較も残します。ルーティングに成功しても、リモートサービスがリクエストを拒否することはあります。2つの結果を区別すれば、正しく設定されたルールを何度も変更せずに済みます。

設定に関するよくある質問：段階ごとにトラブルを特定する

まず問題の影響範囲を見極める

接続に問題が起きたら、「どこで失敗するか」を明確にします。クライアントを起動できない、コアの起動後に終了する、サブスクリプションを更新できない、ブラウザーにアクセスできない、特定のアプリだけ失敗する、のどれでしょうか。問題がインストール後、アップグレード後、ネットワーク切り替え後、または設定変更後に起きたのかも記録します。範囲が明確なほど、次の確認項目を絞れます。すべてを「サーバーが使えない」とまとめたり、最初に設定を消去したりしないでください。最も重要な変化の手がかりが失われます。

ローカルネットワーク、クライアントのコア、ローカルの入口、リモート接続、アクセス先のリクエストの順に確認します。直接接続も失敗する場合は、まず基本ネットワークを調べてください。コアが終了する場合は、最初に記録されたエラーを確認します。ポートが待ち受けていない場合は、起動状態と競合を解決します。特定のアプリだけ失敗する場合は、そのアプリのプロキシ入口とアプリ別リストを確認してください。すべての対象で失敗するなら、共通のDNS、認証、リモート接続性を調べます。一度に1つの層だけをテストし、複数のサーバーやルーティング設定を同時に変えて結果を混乱させないでください。

クライアントの接続テストが成功しても、ブラウザーでアクセスできないことはあります。テスト機能が現在のサーバーへ直接接続している一方、ブラウザーがシステムプロキシを使っていない、または直接接続ルールに一致している可能性があります。反対に、遅延テストが失敗しても、実際の通信が必ず失敗するとは限りません。同じ宛先と明確な接続入口で再テストし、必要ならこのページのプロキシを明示するコマンドを使って、入口の問題を切り分けます。特定のステータスアイコンではなく、実際のリクエスト経路を基に判断してください。

エラーが起きた段階を把握し、必要最小限のログを残す

「接続が拒否されました」は通常、リクエスト先のアドレスとポートで接続が受け付けられなかったことを示します。ローカルの入口が起動していない場合も、リモートのポートが一致していない場合もあるため、ログの宛先を確認してください。「タイムアウト」は、所定の時間内にある段階を完了できなかったという意味です。名前解決、接続確立、ハンドシェイクのどこでも起こり得るため、サーバーがオフラインだと即断できません。前後の関連ログを読み、ローカルとリモートのどちらで失敗したか確認してから該当する設定を変更します。

ハンドシェイクの失敗では、システム時刻、サーバー名、通信パラメーター、サーバー側の要件が一致しているか確認します。証明書エラーを一時的に回避するために検証を無効にし、それを恒久的な対処にしないでください。接続のセキュリティ境界が変わります。認証に失敗した場合は、有効な設定を再インポートし、識別情報を手作業で変更してずれを広げないようにします。設定の解析エラーでは、該当フィールドとコアの互換性を確認してください。ログの詳しい読み方は実行ログによくあるエラーの解説を参照してください。

一時的にログレベルを上げる場合は、問題を再現するために必要な短い時間だけにします。確認後は通常のレベルに戻してください。詳細ログを長期間記録すると、ストレージやパフォーマンスに影響し、アクセス先が漏れる可能性もあります。公開の問い合わせに投稿する前に、サブスクリプションURL、認証情報、個人用パス、端末識別情報を削除し、エラーの種類、発生段階、関連する設定だけを残します。生成された設定全体や完全な共有リンクを公開しないでください。

問題に対応する設定へ戻って確認する

正常に戻ったら、実際に効果があった変更を記録し、一時的なテスト設定を元に戻します。ポートの競合だけが原因なら、新しいポートとアプリ側の対応設定を残せば十分です。ネットワークの切り替えで接続が切れただけなら、試したDNSやルーティングをそのまま残す必要はありません。最小構成から設定し直す場合は、ガイドのプロキシモード設定に沿って接続方法を1つに戻し、必要な機能を順番に追加します。設定の内容を説明、再現、復元できる状態に保ってください。