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

事前準備と設定の仕組み

OS・アーキテクチャ・クライアントを確認する

インストール前にOSとCPUアーキテクチャを確認し、ダウンロード先を選びます。Windowsでは「設定 → システム → バージョン情報」でシステムの種類を確認します。macOSではAppleメニューの「このMacについて」でチップを確認します。Linuxではシステム設定のデバイス情報、Androidでは端末情報でOSのバージョンを確認し、端末の仕様と合わせてアーキテクチャを判断してください。ファイルサイズから端末への適合性を推測したり、同じOS名だから同じアーキテクチャだと考えたりしないでください。

デスクトップではv2rayNの利用がおすすめです。3つのデスクトップOSで設定の考え方はほぼ共通ですが、権限、システムプロキシ、インストーラーの形式が異なります。Androidでは、まずXrayコアを使用するv2rayNGを検討してください。既存の設定がV2Flyの動作に明確に依存している場合は、v2flyNGを検討します。GUIクライアントはサーバー、サブスクリプション、通信の入口を管理し、コアは接続を処理します。画面が起動しても、コアが正常に動作しているとは限りません。

サブスクリプションURLと復元用の記録を準備する

クライアント自体がサーバーを提供するわけではありません。設定を始める前に、利用権限のあるサブスクリプションURLまたは個別の共有リンクを用意し、有効期限と提供元が指定するプロトコル・通信パラメーターを確認してください。サブスクリプションURLには認証情報が含まれることがあるため、パスワードと同様に扱います。スクリーンショット、ログ、問い合わせ内容を共有する際はURL全体を隠してください。先頭だけを隠してクエリパラメーターを残すのも避けてください。

すでにクライアントを設定している場合は、使用中のサーバー、サブスクリプショングループ、ローカル待ち受けポート、ルーティングモード、DNS設定を記録しておきます。移行が必要な場合は、クライアントのエクスポートまたはバックアップ機能を使い、バックアップを管理された場所に保存してください。OSのプロキシ設定も変更前の値を記録します。端末に職場のネットワーク用プロキシが設定されている場合、値を消すと従来の作業環境に影響することがあります。

混同しやすい4つの段階を見分ける

第1段階はサブスクリプションの取得です。URLからサーバー情報を読み込めるか確認します。第2段階はコアの起動です。ローカルポートで待ち受けできているか確認します。第3段階は通信の流入です。アプリのリクエストがシステムプロキシ、手動プロキシ、TUNのいずれかを経由しているか確認します。第4段階は送信先の選択です。コアに入った接続が、ルーティングルールに従って直接接続、プロキシ接続、遮断のどれになるかを確認します。トラブル時は段階ごとに切り分け、すべての異常をサーバー障害と決めつけないでください。

システムプロキシの影響を受けるのは、OSのプロキシ設定に従うアプリが中心です。独自のネットワーク処理を使うアプリでは、プロキシアドレスを個別に入力する必要があります。TUNは仮想ネットワークインターフェースを介して、より多くの通信を受け取りますが、権限、ルーティング、DNSの連携が必要です。ルーティングの「グローバルプロキシ」は通常、クライアントに入った通信の送信方法を変えるだけで、システムプロキシを迂回するアプリの接続方法まで自動で変更するものではありません。

初めて設定する場合は、通信の入口を1つだけ有効にし、まずシステムプロキシでブラウザーの接続を確認してからTUNを検討してください。プロキシ、仮想ネットワークインターフェース、ルーティングを変更する他のソフトウェアは、一時的に終了しておきます。複数のツールが同時にシステム設定を書き換えるのを防げます。設定は一度に1つだけ変更し、変更前後のログを残してください。正常に接続できてから、自動更新やアプリごとの振り分けなどを追加します。

操作前に、システム時刻が正しいこと、ディスクに書き込めること、インストール先に十分な空き容量があることも確認してください。証明書の検証には時刻が、設定の保存にはディレクトリの権限が、コアの起動には実行ファイルの完全な展開が必要です。インストール後にプロトコルを何度も切り替えるより、こうした基本条件を事前に整えるほうが効果的です。最短の手順を確認する場合は入門ガイドへ、プラットフォームごとの制限を知りたい場合は、以下の各章をお読みください。

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

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

Windowsのダウンロードページからv2rayNを選択します。デスクトップ版はクロスプラットフォームのUI、従来のWPF版はWindowsデスクトップ向けのUIを使用します。メニューの配置は異なる場合がありますが、設定の目的は同じです。ダウンロードページに記載されたOSとアーキテクチャの要件に従って選び、どちらにもv2rayNという名前が付いているからといって、異なる版のファイルを同じフォルダーに上書きしたり、それぞれのプログラムコンポーネントを混在させたりしないでください。

インストーラーを使う場合は、ウィザードの案内に従ってインストールし、スタートメニューから起動します。圧縮ファイルで配布されている場合は、長期保存でき、現在のアカウントで書き込み可能なフォルダーにすべて展開してからメインプログラムを実行してください。圧縮ファイルのプレビューから直接起動したり、依存ファイルを残してメインプログラムだけを取り出したりしないでください。保存先はできるだけ短いパスにし、同期フォルダー、一時ダウンロードフォルダー、追加の許可が必要なシステムフォルダーは避けます。

初回起動時に実行環境が不足していると表示された場合は、必要なコンポーネントとアーキテクチャを確認し、OSが認める方法でインストールしてください。ウィンドウがすぐに閉じる場合は、セキュリティソフトの隔離履歴、システムイベント、クライアントログを確認します。セキュリティ機能をすべて無効にするのは避けてください。通常のシステムプロキシの利用に管理者権限は不要です。システムレベルの操作が必要な機能を有効にする場合に限り、クライアントの案内に従って権限を昇格してください。

サブスクリプショングループを作成してサーバーを起動する

「サブスクリプショングループ設定」を開き、新しいグループを追加します。識別しやすい名前を付け、完全なサブスクリプションURLを「アドレス（url）」に入力して保存し、該当グループの「サブスクリプションを更新」を実行してください。利用可能なプロキシがまだない場合は、通常、まずプロキシを経由せずに更新します。既存の接続を経由しないとURLにアクセスできない場合は、その接続が有効であることを確認してからプロキシ経由で更新してください。起動に必要な接続を自分自身に依存させる状態を避けられます。

更新後は、表示された一覧が先ほどのグループのものか確認し、サーバーを1つ選んで現在の接続先に設定します。ログに設定の解析エラー、コアの起動エラー、ポート競合が出ていないか確認してください。遅延テストはサーバー選びの補助として使えますが、テスト方法と実際のアプリの接続方法は異なる場合があります。最終的にはブラウザーの接続結果とログで判断してください。テストに一度失敗しただけで、サブスクリプションの登録に失敗したと決めつけないでください。

システムプロキシを設定し、必要に応じてTUNを有効にする

タスクバーの通知領域からv2rayNのメニューを開き、「システムプロキシ」を選択し、「システムプロキシを自動設定」など、システムプロキシを書き換える項目を選びます。通知領域にアイコンが見当たらない場合は、隠れているアイコンも確認してください。次にWindowsの「設定 → ネットワークとインターネット → プロキシ」を開き、クライアントが設定したローカルアドレスとポートを確認します。設定項目の名前はWindowsの画面更新で変わることがあります。確認する際は、項目名よりもアドレスとポートを重視してください。

「システムプロキシをクリア」はクライアントが設定した値を取り消す操作で、「システムプロキシを変更しない」は既存の値を変更しない設定です。この2つは同じではありません。手動プロキシを使うアプリでは、クライアントが実際に待ち受けているプロトコルとポートを入力してください。リモートサーバーのポートをローカルプロキシ欄に入力してはいけません。ブラウザーの拡張機能がシステムプロキシを上書きすることもあるため、テスト時はブラウザーがシステム設定を使う状態に戻してください。

TUNは通常のプロキシ接続を確認してから有効にするのがおすすめです。画面の案内に従って管理者権限やサービスの要件を確認し、仮想インターフェースとコアのログを確認します。有効化後にすべての接続が切れた場合は、まずTUNを無効にしてネットワークが復旧することを確認し、他の仮想ネットワークアダプター、職場のネットワーククライアント、セキュリティポリシーとの競合を調べてください。原因を切り分けにくくなるため、サーバーの変更、DNSの変更、ドライバーの再インストールを同時に行わないでください。

終了、アップデート、Windows固有の問題

ウィンドウを閉じても通知領域に最小化されるだけで、終了していないことがあります。アップデート前にトレイメニューから完全に終了し、コアのプロセスが停止したことを確認してから、クライアントの更新機能または新しいパッケージを使ってください。設定のバックアップは残し、古いプログラムのコンポーネントを新しいフォルダーに直接上書きしないでください。ファイルが使用中と表示された場合は、通常のセッションを終了させます。使用中のファイルを何度も強制削除しないでください。

異常終了後にブラウザーがインターネットへ接続できない場合は、システムプロキシが停止済みのローカルポートを指していないか確認し、必要に応じてインストール前に記録した状態に戻してください。ウィンドウは開くものの設定を保存できない場合は、インストール先への書き込み権限を確認します。起動時に自動接続して失敗する場合は、ネットワークがまだ利用可能になっていない可能性があります。スタートアップや自動接続は手動の接続手順が安定してから有効にし、起動順序の問題を恒常的な接続障害と誤認しないようにしてください。

初回インストール時の依存関係、展開先、起動確認については、v2rayNの初回インストールと初期設定も参考にしてください。一部のアプリだけがプロキシを経由しない場合は、まずそのアプリの通信経路を調べます。すぐにクライアント全体を再インストールする必要はありません。

macOS：チップの確認とネットワーク権限

チップに合った版をインストールして初回起動する

まずAppleメニューの「このMacについて」を開きます。Appleシリコン搭載と表示される場合はApple Silicon版、Intelプロセッサと表示される場合はIntel版のインストーラーを選んでください。ダウンロード先はmacOSクライアントのダウンロードです。アーキテクチャは購入年ではなく、端末情報を基準に判断します。同じ製品シリーズでもプロセッサが異なる場合があるため、インストーラーの名前よりもシステムに表示される情報を優先してください。

ダウンロードしたディスクイメージを開き、画面の案内に従ってアプリを「アプリケーション」フォルダーへ移動し、そこから起動します。マウントしたディスクイメージから長期間実行したり、同じ名前のアプリを複数の場所に置いて交互に起動したりしないでください。配置後はディスクイメージを取り出し、「アプリケーション」フォルダー内のアプリが起動していることを確認します。アップデート時に別のコピーを変更してしまうのを防げます。

初回起動時にシステムのセキュリティチェックで制限された場合は、ファイルの入手元と端末のアーキテクチャを確認し、「システム設定 → プライバシーとセキュリティ」に表示された案内を確認してください。アプリを明確に特定できた場合に限り、システムが用意する手順で開きます。クライアントを起動するためにセキュリティチェック全体を無効にしないでください。ファイルの破損、非対応アーキテクチャ、コンポーネント不足の警告は、それぞれ別に調べます。すべてを同じ権限問題として扱わないでください。

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

v2rayNのサブスクリプション管理を開き、「サブスクリプショングループ設定」で新しいグループを作成します。名前と完全なURLを入力して保存し、そのグループを更新してください。チャットアプリからコピーした内容に、説明文、改行、全角記号が含まれていないか確認します。URLの大文字・小文字、エンコードされた文字、クエリパラメーターはそのまま保持してください。見た目を整えるために手動で削除してはいけません。

更新後はサーバーを選択し、現在の接続先になったことを確認してから、コアのログを確認します。メニューバーのアイコンとメインウィンドウでは、異なる段階の状態が表示されることがあります。ウィンドウが表示されているのは画面が動作していることを示すだけで、ポートや設定の問題でコアが起動していない場合もあります。接続を確認する際は、まず対象を明確にしてテストし、そのときのサーバー、入口、ルーティングモードを記録してください。あとで比較する際の基準になります。

ネットワークサービスごとにシステムプロキシを確認する

クライアントでシステムプロキシを自動設定した後、「システム設定 → ネットワーク」を開き、現在使用中のネットワークサービスを選択して詳細情報の「プロキシ」を確認します。Wi-Fiと有線ネットワークは別のサービスです。接続方法を切り替えたら、設定を再確認してください。未接続のネットワークサービスだけを確認したり、あるサービスの表示が正しいからといって、すべてのネットワークインターフェースに同じ設定が適用されていると判断したりしないでください。

システムプロキシのアドレスとポートは、クライアントが現在待ち受けているローカルアドレスおよびポートと一致している必要があります。独自のプロキシ設定を使うアプリもあれば、起動時にだけシステムプロキシを読み込むアプリもあります。設定変更後は、テストするアプリを完全に終了してから再起動してください。ブラウザーのプロキシ拡張機能、仕事用の構成プロファイル、他のネットワークツールが設定を上書きすることもあるため、現在のリクエストをどの設定が制御しているかを確認します。

TUNを有効にする際は、クライアントの案内に従って必要な権限を設定し、インターフェースとルートの確立に成功したかログで確認します。インストール形態によって権限の設定手順は異なります。他のバージョン向けのターミナル認証コマンドをそのまま流用しないでください。何度も認証を求められる場合は、アプリを移動したか、別のコピーを起動していないか、設定フォルダーの所有者が現在のアカウントかを確認します。

スリープ復帰、ネットワーク切り替え、アップデート

ノートPCがスリープから復帰した後、以前の接続が無効になっている場合があります。Wi-Fi、モバイルホットスポット、有線ネットワークを切り替えた場合は特に注意してください。まずOS自体がネットワークに接続できていることを確認し、クライアントの接続を再起動します。通常のシステムプロキシは動作するのにTUNだけが不調な場合は、復帰後のルートとDNSを重点的に確認してください。最初からサブスクリプションを削除する必要はありません。一時的な切断か設定ミスかは、繰り返しテストして見分けます。

アップデート前にメニューバーのクライアントを完全に終了し、設定をバックアップしてからアプリを入れ替えます。プログラムを終了した後もネットワークに接続できない場合は、現在のネットワークサービスにローカルプロキシが残っていないか確認します。復元する際は、変更前の記録に従ってください。自宅のネットワークでは手動プロキシを無効にするのが適切な場合がありますが、職場のネットワークでは元のプロキシアドレスに戻す必要があるかもしれません。すべてのプロキシ設定を一律に消すのを、万能の対処法にしないでください。

インストール後にサブスクリプションを保存できない場合は、アプリの設定フォルダーの権限と空き容量を確認します。特定のネットワーク環境だけで失敗する場合は、サーバーと設定を変えずに別のネットワークで再テストしてください。条件を一度に1つだけ変えると、端末の権限、LANの制限、サーバーへの接続性を切り分けられます。復元できない複雑な設定が混在するのを防げます。

Linux：パッケージ形式、デスクトッププロキシ、TUN

ディストリビューションとアーキテクチャに合ったパッケージを選ぶ

Linuxのダウンロードページからv2rayNを選択します。Debian系のパッケージ管理を使うディストリビューションではdeb、RPM系ではrpmを選び、CPUアーキテクチャが一般的なx64かarm64かも確認してください。パッケージ形式とCPUアーキテクチャは別の条件です。片方だけを確認して選ばないでください。派生ディストリビューションでは、各環境のソフトウェアインストール手順と依存関係の要件も確認してください。

GUIのソフトウェアインストーラーでパッケージを開けば、システムが依存関係を処理してインストールできます。依存関係が不足している場合は、まずインストーラーが示すコンポーネント名とシステムの対応範囲を確認してください。他のディストリビューションのライブラリファイルをシステムフォルダーにコピーしないでください。クライアントはGUIアプリのため、使用には利用可能なデスクトップ環境が必要です。この章では、コマンドラインのみのサーバー環境を対象としていません。

アーキテクチャがわからない場合は、ターミナルで次の読み取り専用コマンドを実行してください。一般的な出力では、x86_64は通常x64、aarch64は通常arm64に対応します。異なる結果が表示された場合は、端末とインストーラーの対応状況を確認してください。パッケージ管理ツールのアーキテクチャチェックを強制的に回避してはいけません。コマンドは環境の識別に使うもので、ネットワーク設定は変更しません。

uname -m
cat /etc/os-release

一般ユーザーで起動してサブスクリプションを登録する

インストール後はデスクトップのアプリメニューからv2rayNを起動し、まず現在のログインユーザーで実行してください。GUIアプリ全体を管理者権限で常用するのは避けます。クライアントの設定、キャッシュ、ログは通常ユーザー環境に保存されます。起動するたびに権限を変えると、フォルダーの所有者が変わり、設定を保存できない、起動後にグループが消える、更新に失敗するといった問題が起きることがあります。

「サブスクリプショングループ設定」で新しいグループを作成し、URLを入力して保存してから更新します。初回の更新に失敗した場合は、ログのネットワークエラーと解析エラーを確認してください。ネットワークエラーの場合は、現在の接続、DNS、更新経路を調べます。解析エラーの場合は、サブスクリプションの応答がクライアントで認識できる形式か確認してください。登録できたら接続先を選び、コアの起動結果を確認します。すぐにTUNの設定へ進まないでください。

デスクトップのシステムプロキシとアプリ個別の接続設定

Linuxではデスクトップ環境によってプロキシ設定の場所が異なります。GNOMEでは通常、システム設定のネットワークプロキシから管理しますが、他のデスクトップ環境では専用の設定モジュールがある場合があります。クライアントが自動設定できる範囲も、現在のデスクトップセッションによって異なります。GUIでプロキシが設定されていても、読み込まないアプリがあります。まずデスクトップのプロキシ設定に従うことが明確なアプリでテストし、システムプロキシの動作を確認してください。

ターミナルの環境変数とデスクトップのプロキシ設定は、別々の接続経路です。ブラウザーが接続できても、ターミナルのプログラムにプロキシ設定が適用されているとは限りません。逆も同様です。特定のアプリに手動設定する場合は、クライアントが現在待ち受けているプロトコルとポートを確認してから、そのアプリが対応するプロキシの種類を入力してください。入手元の不明な環境変数をシステム全体に設定したり、サブスクリプションURLをプロキシサーバーのアドレスとして使ったりしないでください。

ローカルポートの競合は、クライアントのログまたはシステムの待ち受け情報で確認できます。次のコマンドは現在TCPで待ち受けているポートを表示します。表示内容はアカウントの権限によって異なります。チュートリアルと同じ番号である必要はなく、クライアント設定に表示された実際のポートを確認してください。別のプログラムが使用中の場合は、まずその用途を特定し、競合するプログラムを終了するか、クライアントのポートを変更します。

ss -ltnp

TUNの権限、ルーティング、デスクトップとの連携

TUNにはシステムのネットワーク機能が必要で、設定方法はクライアントのインストール形式によって異なります。まず画面で案内される権限設定と起動手順を使ってください。インストールフォルダー全体に広い権限を安易に与えたり、インターネット上の権限付与コマンドを考えずに実行したりしないでください。有効化後はインターフェースの作成に成功したことを確認し、その後、通信ルートを確認します。ログに表示される権限不足と、リモート接続のタイムアウトは別の問題です。

TUNを有効にしてLAN内のサービスに接続できなくなった場合は、LAN通信を取り込む設定、除外するアドレス範囲、ルートの優先順位を確認してください。別のトンネルやコンテナネットワークも稼働している場合は、新たに追加したツールを一時停止して比較し、変更前のルート情報を残します。ネットワークインターフェースをすべて削除しないでください。現在の接続が切れる可能性があるうえ、問題を再現して確認できなくなります。

デスクトップ環境によってはトレイアイコンが標準で表示されず、ウィンドウを閉じてもバックグラウンドプロセスが残る場合があります。アップデート、ポート変更、再起動の前に、古いインスタンスが動作中か確認してください。インストーラーの更新には対応するパッケージ管理の手順を使い、入手元の異なるプログラムを複数残さないようにします。プログラムは起動するのに設定を書き込めない場合は、実行権限を上げるのではなく、まずユーザーフォルダーの権限を確認してください。

Android：サブスクリプション登録とVPNインターフェース

v2rayNGとv2flyNGから選ぶ

Androidのダウンロードページを開き、まずXrayコアを使用するv2rayNGを確認してください。既存の設定がV2Flyに依存している場合は、v2flyNGを検討します。比較的新しい一般的なスマートフォンではarm64を選べます。端末のアプリ用アーキテクチャがわからない場合は、汎用版を検討してください。CPUが特定のアーキテクチャに対応していても、現在のOSが同じアプリ環境を提供するとは限りません。システム情報とインストール時の表示を確認してください。

インストール時は、操作に使うファイルマネージャーまたはブラウザーに限って、必要な権限を許可してください。完了後は、そのアプリの「不明なアプリのインストール」権限を取り消せます。インストールできない場合は、アーキテクチャの不一致、ストレージ不足、OS要件、既存アプリとの競合を切り分けます。上書きインストールのために既存のクライアントを先に削除しないでください。アンインストールでサブスクリプションやローカル設定が消えることがあるため、先にバックアップしてください。

別の入手元からアプリを移行する際、署名の違いにより直接更新できない場合があります。その場合、インストールを何度もタップしても解決しません。設定を保存し、移行先のクライアントと入手元を確認してから方法を決めてください。v2rayNGとv2flyNGは別のアプリです。画面が似ていてもデータベースをそのまま相互利用できるとは限りません。アプリ間の移行では、両方が対応しているサブスクリプション形式または共有形式を優先してください。

サブスクリプショングループを追加して設定を選ぶ

クライアントのサイドメニューから「サブスクリプショングループ設定」または該当するサブスクリプション管理画面を開き、新しいグループを作成します。メモとサブスクリプションURLを入力して保存し、メイン画面に戻って「サブスクリプションを更新」を実行してください。個別の共有リンクをコピーした場合は、クリップボードから設定を取り込む画面を使います。リモートのサブスクリプションURLとして登録しないでください。用途の異なる画面を取り違えると、取得失敗や形式エラーの原因になります。

更新後は設定を1つ選択して現在の接続先にし、接続ボタンで起動します。提供元が特定の通信方式やセキュリティパラメーターを指定している場合は、共有内容全体を基準にしてください。画面を簡単にするために関連項目を安易に無効にしないでください。まず初期設定のままで基本接続を確認し、その後、アプリごとのプロキシ、DNS、ルーティングルールを調整します。

AndroidのVPN許可について

初回接続時には、通常、システムからVPN接続の要求が表示されます。これはクライアントがシステムのインターフェースを通じて端末の通信を受け取るための許可であり、利用できるサーバーが自動的に用意されるという意味ではありません。許可後もコアの起動とリモート接続の成功が必要です。通常、Androidでは2つの一般的なVPNアプリが同じインターフェースを同時に使用できません。同種の接続がすでに動作している場合は、先に切断してからテストしてください。

Androidでは、デスクトップ向けの「システムプロキシを自動設定」の手順を使う必要はありません。一般的には、クライアントがシステムVPNインターフェースを作成し、ルーティングやアプリごとの設定に従って通信を処理します。画面に接続中の表示が出ても、インターフェースの状態が示されているだけで、対象サイトにリモートサーバー経由で接続できた証明にはなりません。アプリでの接続結果、クライアントログ、必要に応じてルーティングを確認してください。

「アプリごとのプロキシ」では、画面のモードに応じて指定したアプリだけをクライアント経由にするか、指定したアプリを除外できます。モードとリストの両方を確認してください。同じリストでも「プロキシ経由のみ」と「除外」では意味が逆になります。設定変更後は接続を切って再接続し、対象アプリも完全に終了してからテストします。以前の経路を使う古い接続が残るのを防げます。

バックグラウンド制限、ネットワーク切り替え、切断後の再接続

端末によっては、画面ロック後にバックグラウンドのプロセスが制限されます。画面を表示している間は正常でも、ロック後に切断する場合は、バッテリー最適化、バックグラウンド動作、メーカー独自の自動起動管理を確認し、クライアントに必要な制限だけを解除してください。すべてのアプリで省電力機能を無効にする必要はありません。切断した時刻と状況を記録し、プロセスの終了、ネットワークの切り替え、リモートセッションの期限切れを切り分けます。

Wi-Fiからモバイルネットワークに切り替えた後は、接続を再確立する必要がある場合があります。まず端末自体のネットワーク接続を確認し、クライアントを切断して再接続してください。一方のネットワークだけで常に失敗する場合は、同じ設定で比較します。プロトコルパラメーターを同時に変更しないでください。プライベートDNS、他のローカルネットワークツール、テザリングを使用している場合も記録し、システム側の違いを見落とさないようにします。

システムの「常時接続VPN」と「VPNを使用しない接続をブロック」は、切断後の通信に影響することがあります。ブロックを有効にしている場合、クライアント停止後に端末がインターネットへ接続できないのは、想定された動作であり、システムの故障ではありません。トラブル対応で一時的に切断する場合は、まずこれらの設定を理解したうえで変更してください。管理対象の端末では、ポリシーを勝手に変更しないでください。

サブスクリプション、共有リンク、更新管理

URLと設定内容を見分ける

サブスクリプションURLは通常、クライアントがアクセスして複数の設定を取得するリモートアドレスです。個別の共有リンクは、1つのサーバー設定を直接表します。サブスクリプションの応答には、エンコードされたテキストなどクライアントが対応する形式が使われる場合がありますが、WebページのURLが必ずサブスクリプションURLとは限りません。アカウントのトップページ、決済ページ、説明ページが開けても、それをサブスクリプションURL欄に入力できるとは限りません。

デスクトップでは通常、「サブスクリプショングループ設定」にリモートURLを保存します。Androidではサブスクリプション管理メニューを使います。クリップボードからのインポートは、クライアントが対応する共有リンクに適しています。ファイルからのインポートは、対応する設定ファイルに使います。操作を選ぶ前に、手元の情報が何かを確認してください。すべてのインポートボタンを順番に試さないでください。誤った入口から登録すると不完全な記録が作られ、後のトラブルシューティングが難しくなることがあります。

URLを貼り付けたら、先頭と末尾の空白、改行、エスケープ文字、句読点を確認してください。メッセージアプリからコピーすると、URLの末尾に句点まで含まれることがあります。Webページに短縮表示されたリンクが、実際のURLと異なる場合もあります。リンク先の完全なURLをコピーし、クエリパラメーターを保持してください。エンコード記号を見やすい文字に置き換えないでください。例示用ドメインでは実際に接続できません。

グループの更新と現在の接続設定

入手元や用途ごとにグループを分け、識別しやすい名前を付けることをおすすめします。どのサブスクリプションか分からない一覧にすべてをまとめないでください。更新時はまず現在のグループを選び、取得件数とログを確認してから、必要に応じてすべてのグループを更新します。複数の入手元をまとめている場合、一部の更新に失敗しても他のグループに影響しないことがあります。グループごとに確認すれば、まだ使える設定を残せます。

サブスクリプションの更新時、管理対象の項目が再作成されることがあります。これらの項目のメモやパラメーターを手動で変更しても、次回の更新後に保持されるとは限りません。継続して使う独自設定を作る場合は、クライアントが項目の複製や独立したグループをサポートするか確認してから変更してください。バックアップなしで、唯一の手動設定をサブスクリプションの項目だけに保存しないでください。一覧の順番も常に同じとは限りません。

更新に成功した後も、現在の接続先を確認してください。以前使っていた項目が削除、改名、置き換えられている場合があり、別のグループの項目が接続先として残っていることもあります。選択中の項目が属するグループ、プロトコル、サーバーアドレスを確認してから、接続を再起動してテストします。サブスクリプションの管理と接続の管理は別の手順です。更新ログの成功表示だけでは、実際に接続できたことの確認になりません。

更新経路と自動更新間隔

プロキシを経由せずに更新する場合、サブスクリプションのリクエストは現在のネットワークから直接送信されます。プロキシ経由で更新する場合は、すでに使えるプロキシ接続が必要です。後者は接続が正常だと確認済みの場合に適していますが、唯一使える設定が無効になっていると、その設定を使って新しい設定を取得できないことがあります。トラブル時は、まずリクエストがどの経路を通るかを特定し、その経路のネットワークを確認してください。更新ボタンを繰り返し押すだけでは解決しません。

自動更新には、「更新を有効にする」などのスイッチをオンにし、画面で指定された単位に合わせて間隔を入力する必要があります。単位が分の場合、時間数をそのまま入力しないでください。間隔は提供元の案内、情報の更新頻度、端末の使用状況に合わせて設定します。短すぎる間隔はリクエストを増やすだけです。間隔を0にした場合の動作は実装によって異なるため、0を「常に更新」と決めつけないでください。

端末がスリープ中、クライアントが終了中、またはOSがバックグラウンド動作を制限している場合、自動更新が予定どおりに実行されないことがあります。使用を再開したら直近の更新結果を確認し、必要なら手動で更新してください。自動更新は失敗するのに手動更新は成功する場合は、実行時のネットワーク状態、プロキシ経路、権限を比較します。まずURLの形式を疑う必要はありません。詳しい対処手順はサブスクリプション更新に失敗する場合の確認方法をご覧ください。

エラーの種類から原因を絞り込む

タイムアウトは通常、リクエストが制限時間内に完了しなかったことを示します。ネットワーク経路とURLへの到達性を確認してください。アクセス拒否は、認証情報、アクセス元の制限、サービスの状態が原因の可能性があります。応答を解析できない場合は、受信内容がログイン画面、エラーページ、またはクライアント非対応の形式でないか確認してください。応答内容全体を公開しないでください。サービスから返される情報にアクセス認証情報やサーバー認証情報が含まれることがあります。

サブスクリプションを切り替える前に、まだ使える設定を保存し、新しいURLが従来の信頼できる入手元から届いたものか確認してください。URLの漏えいが疑われる場合は、提供元が対応していればアクセス認証情報をリセットします。ローカルのグループを削除するだけでは、古いURLを無効にできません。デスクトップとAndroidの登録画面を順に比較するには、サブスクリプションURLの登録方法をご覧ください。

システムプロキシ、TUN、ルーティング、DNS

振り分けを考える前に通信の入口を確認する

システムプロキシ、TUN、ルーティングルールは、それぞれ異なる問題を解決します。システムプロキシは、その設定に従うアプリのリクエストをローカルの入口に送ります。TUNはシステムのネットワークインターフェースを介して、より広い範囲の接続を受け取ります。ルーティングルールは、コアに入ったリクエストの送信先を決めます。まずリクエストがクライアントに入っているか確認してから、直接接続やプロキシのルールを検討してください。クライアントを迂回するアプリには、ルールが正しくても影響しません。

初回の切り分けでは、通常のシステムプロキシを基準にし、システム設定に従うことが明確なブラウザーを1つ選びます。サーバーとルーティングは変更しないでください。ブラウザーは正常なのに別のアプリで問題が起きる場合は、そのアプリ独自のプロキシ、特殊な通信方式、アプリごとの除外設定を確認します。すべてのアプリで問題が起きる場合は、コア、ローカルポート、リモート接続を調べてください。最初から複雑な振り分けルールを追加しないでください。

ローカルの待ち受けアドレスには通常ループバックアドレスを使い、アクセスを自分の端末に限定します。LANからの接続を許可するとアクセス範囲が広がるため、用途を明確にし、ファイアウォールによる制限も検討してください。スマートフォンなど別の端末にプロキシを設定する際、ループバックアドレスはその端末自身を指し、クライアントを実行しているPCを指すわけではありません。PCのLAN内アドレスを使い、端末同士が通信できることと待ち受け範囲が正しいことを確認してください。

ルールの順序と送信先の名前

ルーティングルールは通常、上から順に評価されます。上の広い範囲を対象とするルールが、後の詳細なルールより先に一致することがあります。特定のドメインを直接接続したい場合は、ルールが存在するかだけでなく、上位のルールに先に一致していないか確認してください。送信先のタグは、現在の設定で定義されている実際のタグと一致している必要があります。画面の「プロキシ」「直接接続」は表示名であり、設定内のタグはすべての環境で同じとは限りません。

以下はXrayのルーティングオブジェクトの構造例で、ルールの説明を目的としています。クライアントにそのままインポートできる完全な設定ではありません。ここでは、設定にdirectという名前の送信先が存在し、使用するコアが対応するドメインデータを備えていることを前提としています。GUIクライアントで管理する場合は、クライアントが実行時に生成するファイルを直接編集せず、「ルーティング設定」で同等のルールを作成してください。

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

geositeはドメインのリストに基づく照合、geoipはIPアドレスのリストに基づく照合を表し、互いに置き換えることはできません。ドメインルールを使うには、コアが判定に使えるドメイン情報を取得する必要があります。アプリからアドレスしか渡されない場合は、照合結果が変わることがあります。ルールを追加する前に、入力情報、データファイル、ルールの順序を確認し、ドメインスニッフィングなどが必要か判断してください。1つのルールを一致させるために、すべてのオプションを有効にしないでください。

DNSの名前解決経路と接続経路

DNSはドメイン名をアドレスに変換し、プロキシ接続はリクエストを転送します。この2つの経路は別々の場合があります。ドメインでは開けず、アドレスならアクセスできる場合も、さらに名前解決を調べる必要があるというだけで、特定のDNSサービスの障害とは断定できません。OSの名前解決、クライアント内部の名前解決、アプリ独自の暗号化DNSを区別し、実際のテストでどの経路が使われているか確認してください。

システムプロキシでは、アプリの実装やプロトコルによって、ドメインをアプリ自身が解決する場合と、ローカルプロキシに渡す場合があります。TUNではDNSリクエストも取り込むことがあり、通常のプロキシとは処理が異なります。通信の入口を切り替えたら、以前のブラウザーの動作が変わらないと思い込まず、DNS設定を改めて確認してください。トラブルシューティングでは、複数の設定が上書きし合わないよう、名前解決の入口を一度に1つだけ変更します。

カスタムDNSサーバーを設定する前に、現在のネットワークからアクセスできることと、DNSリクエストがプロキシ経由で送信されるかを確認してください。リモートサーバーに接続できない状態で、名前解決も同じ無効なプロキシに依存させると、別の依存関係の問題が生じることがあります。リモートサーバーのアドレスにドメイン名を使う場合は、プロキシ接続の確立前に最初の名前解決をどう行うかも考慮してください。接続後のDNSクエリだけを確認しても不十分です。

TUN使用時のLAN通信と復元範囲

TUNが通信を取り込むと、新しいルートの影響でプリンター、ネットワークストレージ、LAN内の管理画面にアクセスできなくなることがあります。クライアントにLAN通信の除外やルートの除外設定があるか確認し、LANのアドレス範囲が実際のネットワークと一致していることを確かめてください。1台の機器への接続を復旧するために、範囲が広すぎる直接接続ルールを追加しないでください。範囲が広いほど、本来プロキシが必要な宛先にも影響しやすくなります。

「グローバルプロキシ」はルーティングの違いを一時的に確認するのに便利ですが、システム上のすべての通信を取り込む設定ではありません。テスト後は日常利用に適したルールに戻し、イントラネットにもアクセスできることを確認してください。ドメインのプレフィックス、アドレスリスト、優先順位を詳しく知りたい場合は、v2rayNのカスタムルーティングルールの書き方を参照し、実際の宛先に合わせてルールの範囲を絞ってください。

設定に関するよくある問題と復元手順

症状から問題の範囲を切り分ける

まず「どのアプリで、どの宛先に、どのネットワークから、いつから」問題が起きているか記録し、起動、サブスクリプション、通信の入口、送信先のどこで発生しているかを判断します。ウィンドウが開かない問題とWebサイトにアクセスできない問題は別です。特定のサイトだけの不具合と、すべてのアプリでネットワークに接続できない問題も、同じ対処では解決できません。変更前の設定とログを残してから操作し、元の症状を上書きしないようにしてください。

クライアントが起動しない場合は、インストール形式、システムアーキテクチャ、実行環境、フォルダーの権限、セキュリティソフトの記録を確認します。クライアントは起動するのにコアが動かない場合は、関連する最初のエラーを確認し、設定の解析とポートの待ち受けを優先して対処してください。その後に続く大量の接続エラーは、先に起きた起動失敗の結果かもしれません。1件ずつ別の障害として扱ったり、すべてのサブスクリプションをすぐに削除したりする必要はありません。

サブスクリプションの更新は成功しても接続できない場合は、接続先が想定したグループに属していることと、コアが動作していることを確認してください。次に、テスト対象のアプリがプロキシを経由しているか確認し、その後リモート接続のログを確認します。サブスクリプションは設定を取得する手段にすぎず、サーバーが利用できるかどうかは、認証パラメーター、サービスの状態、ネットワーク経路によって決まります。更新の成功と実際の接続は、別々に検証してください。

変更を最小限にして比較する

サーバーを1つ、テスト用のアプリを1つ、宛先を1つ選び、現在のネットワークでテストします。その後、設定を変えずに別の利用可能なネットワークへ切り替えて再テストしてください。サーバーが1つだけ失敗する場合は、同じグループの別サーバーと比較します。すべてのサーバーで失敗する場合は、ローカルの通信入口とネットワーク条件を確認してください。アプリ、ルーティング、DNS、サーバーを同時に変更すると、どの変更が影響したか判断できません。

接続拒否、接続タイムアウト、認証失敗、証明書エラーは、それぞれ意味が異なります。接続拒否は、宛先またはローカルポートが接続を受け付けていない状態を示すことが一般的です。タイムアウトは、経路上の処理が制限時間内に完了しなかったことを示します。認証失敗では設定とサービスの状態を確認し、証明書エラーではまずシステム時刻、ドメイン名、必要なセキュリティパラメーターを確認します。証明書検証を無効にする方法を恒久的な対処として使わないでください。設定の問題が隠れてしまいます。

ローカルポートが使用中の場合は、まず使用しているプロセスを特定します。古いクライアントのインスタンスであれば、通常の手順で終了してから再起動します。別の必要なプログラムが使用中なら、クライアントのポートを変更し、手動プロキシを使うアプリの設定も合わせて変更してください。クライアントだけを変更してアプリを変更しないと、新たな入口の問題が残ります。用途のわからないシステムプロセスを、ポートを空けるために終了しないでください。

切断後のネットワーク復旧とバックアップ

クライアントを停止した後にネットワークへ接続できない場合、デスクトップではシステムプロキシがローカルの待ち受けアドレスを指したままになっていないか確認します。TUNを使っている場合は、インターフェースとルートが正常に解除されたか確認してください。Androidでは、VPNを使用しない接続をブロックするシステム設定が有効か確認します。各プラットフォームで、変更前の設定に従って復元してください。すべてのネットワーク設定の初期化を最初に行ったり、リモートの作業セッション中にネットワークを不用意にリセットしたりしないでください。

アップデート後に問題が起きた場合は、まずバックアップと設定を比較し、別のインストール先にあるコピーを起動していないか確認します。ロールバックが必要な場合は、クライアントがサポートする手順に従い、設定形式が変更されている可能性にも注意してください。以前の設定と現在の設定の両方を残し、唯一のデータに何度も上書きしないでください。復元できた後に、自動更新、スタートアップ、振り分けを改めて確認します。

ログには通常、時刻、宛先アドレス、ルール、エラーの原因が記録されます。共有する際は再現前後の必要な範囲だけを抜き出し、認証情報を隠してください。調査のために一時的にログレベルを上げた場合は、終了後に元に戻し、記録が増えすぎないようにします。他の人に相談する際は、OS、クライアント名、通信の入口、実施済みの比較結果を伝えてください。「接続できない」という画面のスクリーンショットだけでは十分ではありません。

よくある質問をすばやく確認

復旧後はブラウザー、よく使うアプリ、LAN内のサービス、スリープ復帰後の接続をそれぞれ確認し、テスト対象1つだけが使える状態になっていないか確かめてください。最終的に利用できた通信の入口、ルーティング、DNSをバックアップの説明に記録します。次回のトラブルシューティングは、この基準設定から始めてください。操作の流れをもう一度確認する場合は入門ガイドに戻り、このガイドの応用設定を一度にすべて有効にしないでください。