全プラットフォーム対応インストール・設定

事前準備と設定の基本

クライアント・コア・接続設定の違い

v2rayNは、接続設定の保存やコアの起動、プロキシ関連設定の変更を行うデスクトップGUIクライアントです。プロトコルの解析、リモートサーバーへの接続、ルーティング規則の適用はコアが担当します。Project Vは関連技術エコシステムの背景にあたり、V2FlyとXrayは異なるコア開発系統です。画面が開いてもコアが起動しているとは限らず、コアが正常に動作していても、システム上のアプリから通信が渡されているとは限りません。それぞれを個別に確認してください。

デスクトップでは、本ガイドに沿ってv2rayNを使用してください。Androidでは、まずXrayコアを採用したv2rayNGを選びます。既存の設定でV2Flyの動作が明確に必要な場合は、v2flyNGを検討してください。名前が似ているからといって設定ファイルを使い回さないでください。対応プロトコル、トランスポート設定、拡張フィールドはクライアントと実際に使うコアの組み合わせによって異なります。設定の提供元が示す互換性情報が、選択した構成に合っているか確認しましょう。

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

ダウンロード前に、OS名だけでなくデバイスのプロセッサアーキテクチャを確認してください。一般的なデスクトップPCではx64、一部のデバイスではarm64が使われています。macOSではApple SiliconとIntelの区別も必要です。Androidでは、プロセッサ、OSのビット数、インストール可能なアプリのアーキテクチャが一致しない場合があります。パッケージ形式も重要です。インストーラー、ディスクイメージ、ディストリビューション用パッケージはそれぞれ導入方法が異なり、拡張子を変更して相互に変換することはできません。

利用権限があり、有効期限内のサブスクリプションURL、または接続に必要な情報一式を用意してください。クライアントには利用可能なリモートサービスは含まれていません。接続情報には通常、サーバーアドレス、ポート、認証情報、プロトコル、トランスポート設定が含まれます。TLSやREALITYを有効にする場合は、サーバー名や公開鍵なども必要になることがあります。情報が不足している場合は設定の提供元に確認し、推測で値を補わないでください。

まずデバイスが通常どおりインターネットに接続できることと、日付・時刻・タイムゾーンが正しく設定されていることを確認してください。時計が大きくずれていると、証明書の有効期限判定に影響したり、一部プロトコルの認証に失敗したりすることがあります。ブラウザーで通常のWebページを開けることを確かめたら、組織ネットワークの認証ページ、システムプロキシ、起動中の別のトンネルアプリ、セキュリティソフトのルールも確認します。基本ネットワークに問題がある場合、サブスクリプションを何度更新しても解決しないことがあります。

システムプロキシとTUNの違いを理解する

システムプロキシは、OSのプロキシ設定を使い、その設定に従うアプリの通信をローカルの待ち受けポートへ送ります。すべてのアプリの通信が転送されるわけではありません。独自のプロキシ設定を持つアプリや、システムプロキシを無視するアプリもあります。一方、TUNは仮想ネットワークインターフェースを通じて対象の通信を取り込みます。より広い範囲をカバーできますが、ルーティング、DNS、権限に関する要素も増えます。通常のプロキシ経由の接続を確認してから有効にするのがおすすめです。

LAN内での共有と、このデバイスだけでの利用も異なる使い方です。自分のデバイスから接続する場合、通常はループバックアドレスで待ち受ければ十分です。LANからの接続を許可すると、ほかのデバイスからも待ち受けポートにアクセスできる可能性があるため、ファイアウォール、待ち受けアドレス、アクセス範囲に注意が必要です。初回インストール時はLAN共有を無効のままにし、トラブル対処のためにすべてのネットワークからのアクセスを許可しないでください。共有が必要な場合は、LAN内でのプロキシ共有方法を参照してください。

元に戻せる手順で作業する

インストールや移行の前に、クライアントを完全に終了してから設定ディレクトリをバックアップしてください。バックアップにはサブスクリプションURL、認証情報、利用履歴が含まれる場合があるため、安全な場所に保管します。変更を始める前に、現在のシステムプロキシの状態、待ち受けポート、ルーティング設定を記録してください。スクリーンショットを共有する場合は、サブスクリプションURL全体、サーバーの認証情報、QRコードを隠しましょう。これらが流出すると、他人が同じ接続設定を使える可能性があります。

インストール、インポート、起動、プロキシを明示した接続テスト、システムプロキシのテスト、TUNのテストの順に進めるのがおすすめです。一度に変更する主要な設定は一つに絞り、変更前後の状態を記録してください。アップデート後に問題が起きた場合は、まずバックアップとログを照合します。すべての設定を一度に不明な状態へ戻すのは避けましょう。元に戻す場合は新しいクライアントを終了してから、対応する設定のコピーを復元してください。2つのプロセスが同じディレクトリを同時に読み書きするのを防げます。

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

デスクトップ版とクラシックWPF版を選ぶ

Windowsのダウンロードページで、v2rayNデスクトップ版とクラシックWPF版の違いを確認してください。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のデスクトップ操作を維持しています。接続プロトコルの優劣を表すものではなく、外観だけで性能を判断することもできません。OSや使い方、必要な機能に合わせて選べば十分です。設定のために両方をインストールする必要はありません。

ダウンロードページのWindows向け標準版はx64です。デバイスが別のアーキテクチャを使用している場合は、OSとの互換性を確認し、x64ファイルをarm64向けのネイティブ版として扱わないでください。インストール時は、インストーラーの指示に従って保存先と必要なコンポーネントを設定します。実行環境が不足していると表示された場合は、エラー内容に合ったコンポーネントを導入してください。不明な配布元からDLLをコピーするのは避けましょう。インストールは完了しても起動しない場合は、エラーメッセージをそのまま記録してください。

初回起動時は、設定ディレクトリを読み取り専用の場所に置いたり、同期ソフトと同時に変更させたりしないでください。インストール先とユーザー設定の保存先は異なる場合があります。クライアントのディレクトリ表示やログで実際のパスを確認しましょう。通常のシステムプロキシを使うだけなら、常に管理者として実行する必要はありません。仮想インターフェース、ドライバー、特権操作が必要な場合に限り、明示された指示に従って許可してください。権限の引き上げを汎用的な解決策にしないでください。

サブスクリプションを追加し、コアの起動を確認する

サブスクリプショングループの設定を開き、用途が分かる名前を付けて、URL欄にアドレス全体を貼り付けます。保存後、サブスクリプションを更新してください。更新が成功したら、一覧から接続に使う設定を選びます。インポートは接続情報を端末に保存する操作であり、リモート接続が利用できることを保証するものではありません。更新後に一覧が空の場合は、更新結果を確認し、URLがアカウントのログインページではなく接続設定を返しているか確かめてください。

設定を選んだらコアを起動または再読み込みし、ログに起動失敗、ポート競合、未対応フィールドなどのエラーがないか確認します。設定がXrayの拡張機能に依存する場合、選択したコアが該当パラメーターを解釈できる必要があります。説明を確認せずにコアの設定を一括で切り替えないでください。複数のグループがある場合は、更新したグループの設定が選択されていることを確かめましょう。以前の設定の接続状況を、新しいサブスクリプションの状態と取り違えないためです。

まずローカルプロキシをテストし、その後でシステムプロキシを設定する

設定画面でローカルの待ち受けポートを確認してください。一般的な設定値は10808ですが、実際の値はクライアントの画面で確認します。これはPC側の待ち受けポートであり、サーバーのポートではありません。待ち受けの種類を確認したら、プロキシを手動設定できるアプリでループバックアドレスとそのポートを指定します。明示的なプロキシ接続が成功したら、システムプロキシを自動設定にし、ブラウザーに新しい設定が反映されているか確認してください。

システムプロキシの動作は、ブラウザーのポリシー、拡張機能、アプリ内の設定にも左右されます。あるブラウザーでは接続できても、別のアプリで失敗する場合は、先にそのアプリがシステムプロキシに対応しているか確認してください。リモート設定をすぐに変更する必要はありません。ターミナルツールでプロキシを使う場合は、対象のプロセスだけに設定し、作業後に解除します。システムプロキシとターミナルの環境変数は別の設定経路なので、一方を変更しても他方には反映されません。

TUNの有効化とWindows固有の問題への対処

システムプロキシに従わないアプリの通信も取り込みたい場合は、TUNを試してください。現在のクライアントの案内に従って必要な権限を許可した後、仮想インターフェース、デフォルトルート、DNSに異常がないか確認します。最初はシンプルなルーティングを使い、ほかの仮想ネットワークツールは一時的に終了してください。有効化後に通常の直通接続まで切れた場合は、まずTUNを無効にしてネットワークを復旧し、ログとインターフェースの状態を確認します。証明書、サブスクリプション、ファイアウォールを同時に変更しないでください。

Windowsファイアウォールの警告では、外向きの接続と、ほかのデバイスからローカルサービスへのアクセス許可を区別してください。自分のPCだけでプロキシを使う場合、警告を消すために任意のネットワークからの受信接続を許可する必要はありません。ポートが使用中の場合は、複数のv2rayNが起動していないか確認し、通知領域に古いプロセスが残っていれば終了します。ポートを変更したら、プロキシアドレスを手動設定したすべてのアプリも更新してください。変更前のポートに接続し続けるのを防げます。

終了前にシステムプロキシを解除してから、クライアントを通常の方法で終了してください。異常終了後にブラウザーがすべて接続できなくなった場合は、システムプロキシ設定が停止済みのローカルポートを指していないか確認します。自動起動は手動起動で安定動作を確認してから有効にし、再ログイン時にプロセスが一つだけ起動することも確かめましょう。スリープ復帰後に接続できない場合は、まず基本ネットワークが復旧しているか確認してからコアを再読み込みしてください。ネットワーク接続の復旧前に設定が壊れたと判断しないようにします。

アップデート前に必要な設定をエクスポートし、設定ディレクトリをバックアップしてください。インストール後は、待ち受けポート、選択中の設定、ルーティングを照合します。異なるUI間で移行する場合、すべての画面設定が一対一で対応するとは限りません。まず接続に必要な情報を戻し、プラットフォーム固有の設定を改めて確認してください。基本的な手順は使い方ガイドのプロキシ設定を参照し、移行時に新しいルーティング規則を一度に追加しないでください。

macOSのインストールと権限設定

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

「このMacについて」でチップまたはプロセッサを確認してください。Apple Silicon搭載機ではarm64、Intel搭載機ではx64を選び、macOSのダウンロードページからv2rayNを入手します。購入年だけでアーキテクチャを判断しないでください。同じ年に異なるチップを搭載した機種が販売されることがあります。アーキテクチャが合わないと、起動できない、変換実行環境への依存が生じるなど、互換性の問題が起こる場合があります。デバイスに合ったパッケージを選びましょう。

ディスクイメージを開いたら、パッケージ内の案内に従ってアプリを「アプリケーション」フォルダへコピーし、その場所から起動します。ディスクイメージから直接起動し続けるのは避けてください。イメージの取り出しやパスの変更、ログイン時に未マウントであることが、次回起動に影響する可能性があります。設定ファイルをアプリケーションパッケージの内部に手動で保存しないでください。アップデート時に内容が置き換わることがあり、ユーザーデータはクライアントが実際に使用する設定場所に保存する必要があります。

セキュリティ警告が表示された場合は、まずファイルの入手元と警告の種類を確認し、macOSの「セキュリティとプライバシー」から必要な許可を設定してください。アプリの破損、アーキテクチャの非互換、開発元の確認は、それぞれ別の問題で対処方法も異なります。最初からシステム全体のセキュリティ機能を無効にしたり、出所不明のターミナルコマンドで属性を削除したりしないでください。判断できない場合は警告全文を記録し、ダウンロードページで選択したファイルを再確認しましょう。

設定をインポートしてプロキシ接続を確認する

起動後、サブスクリプショングループを作成してURLを保存し、更新します。メモアプリやチャットから貼り付ける場合は、全角記号、改行、末尾の空白に注意してください。更新が成功したら接続設定を選び、コアを起動してログを確認します。macOSでは画面上の項目名がWindowsと少し異なることがあります。ボタンの位置を揃えるのではなく、設定の意味をもとに探してください。サーバー側のパラメーターとローカルの待ち受け設定は分けて考えます。

まず、明示的なプロキシ設定に対応したアプリで、ループバックアドレスと待ち受けポートをテストします。コアが正常に動作していることを確認してから、システムプロキシを有効にしてください。macOSのプロキシ設定はネットワークサービスごとに管理され、Wi-Fi、有線LAN、その他のサービスで状態が異なる場合があります。ネットワークを切り替えた後にアプリがプロキシを使わなくなったら、クライアントに前回表示されたスイッチだけでなく、現在のサービスに設定されたプロキシ項目を確認しましょう。

アプリによっては起動時にプロキシ設定を読み込むため、システムプロキシを変更した後に再起動が必要な場合があります。また、独自のネットワーク設定を使い、システム設定に従わないアプリもあります。ブラウザーで接続できても、ほかのアプリも必ず接続できるとは限りません。テストでは同じ接続先と同じ通信の取り込み方法を使い、ブラウザーのキャッシュ、既存の接続、新規接続を混在させないでください。必要に応じてウィンドウを閉じてから再テストし、現在の設定が結果に反映されるようにします。

TUNの権限とネットワーク切り替え

TUNは仮想ネットワークインターフェースとシステムルートを使います。具体的な許可方法は、クライアントの実装によって異なります。アプリが明示的に要求した場合にのみ必要な権限を付与し、許可後にコアが実際に起動したか確認してください。画面上のスイッチがオンでも、有効なインターフェースが作成されたとは限りません。権限不足、インターフェース作成失敗、ルート追加失敗が表示された場合は、ログに沿って確認し、スイッチを何度も切り替えて解決しようとしないでください。

企業向けネットワークツール、仮想マシンのブリッジネットワーク、ほかのトンネルサービスを同時に使うと、ルーティングやDNSが競合することがあります。まずv2rayNだけを起動して基本状態を確認し、その後、ほかのツールを一つずつ再開してください。併用が必要な場合は、どのアドレスを直接接続し、どの通信を別のネットワークに任せるのか明確にします。Webページを一時的に表示させるために、よく分からないシステムルートを削除しないでください。リモートアクセスや組織のネットワーク資源に影響する可能性があります。

スリープからの復帰、有線LANからWi-Fiへの切り替え、Web認証が必要なネットワークへの接続後は、既存の接続が使えなくなる場合があります。まずプロキシの取り込みを無効にして、基本ネットワークの認証を済ませてから、コアを起動しプロキシを再設定します。復帰のたびに失敗する場合は、通常のWebページに直接アクセスできるか、ローカルの待ち受けが続いているか、ログにリモート接続の再試行が記録されているかを確認してください。「ネットワークが固まる」という説明だけより、問題の範囲を切り分けやすくなります。

終了・更新・設定の移行

通常終了する前にシステムプロキシとTUNを無効にし、システムのネットワーク設定が復元されたことを確認してください。プロセスを強制終了すると、ローカルポートを参照するプロキシ設定が残る場合があります。その状態ではアプリの待ち受けが停止しているため、ブラウザーは接続に失敗し続けます。ネットワークを復旧する際は、現在のネットワークサービスのプロキシ項目を確認し、今回のクライアントに関係する設定だけを解除してください。組織管理のデバイスでは、管理者が設定したプロキシを上書きしないでください。

別のPCへ移行する場合は、まずサブスクリプションと必要な設定をバックアップし、新しいチップに対応するアプリをインストールします。接続設定は移行できますが、元のPCのパス、ログイン時の起動設定、ネットワーク権限はそのままコピーできません。移行後に待ち受けアドレス、システムプロキシ、TUNを再確認し、正常動作を確認してから古いバックアップを削除してください。認証情報を含むバックアップを共有フォルダに長期間置かないようにし、インポート後は適切に管理しましょう。

Linuxのインストールとデスクトップ環境

ディストリビューションのパッケージ形式とアーキテクチャを確認する

Linuxのダウンロードページを開き、ディストリビューションに合ったdebまたはrpmを選んでから、プロセッサアーキテクチャを確認します。DebianやUbuntuなどでは一般にdeb、Fedoraなどではrpmを使います。派生ディストリビューションの場合は、各ディストリビューションのパッケージ管理方法に従ってください。x64とarm64はアーキテクチャの違いであり、パッケージ形式の違いではありません。同じ形式でも複数のアーキテクチャ向けに配布されることがあり、ファイルをダウンロードできてもインストールできるとは限りません。

システム設定でOSとプロセッサの情報を確認できます。ターミナルに慣れている場合は、以下の読み取り専用コマンドも確認に使えます。一般的な出力では、x86_64はx64、aarch64は通常arm64に対応します。インストール方法の選択にはディストリビューションの識別情報を使い、デスクトップの見た目だけで判断しないでください。画面が似たシステムでも、パッケージ管理ツールや依存関係は異なる場合があります。

uname -m
cat /etc/os-release

ディストリビューション標準のGUIソフトウェアインストーラーで、ダウンロードしたパッケージを開き、依存関係と権限に関する案内を確認してください。インストールに失敗したら、アーキテクチャの不一致、依存関係の不足、パッケージ管理ツールがデータベースを使用中の状態を切り分けます。依存関係を無視してインストールしたり、別の更新処理が終わる前にパッケージ管理のロックファイルを削除したりしないでください。システムのパッケージ状態を直してから再インストールするほうが、アプリのディレクトリを何度も上書きするより安全です。

一般ユーザーで起動し、設定ディレクトリを確認する

インストール後は、アプリケーションメニューから通常のユーザーとしてv2rayNを起動してください。便宜上、GUIクライアント全体を常に高い権限で実行するのは避けましょう。別ユーザー所有の設定ファイルが作成され、次回の通常起動時に書き込めなくなる場合があります。保存に失敗した場合は、実際の設定パスとファイルの所有者を確認してください。アプリに表示される設定ディレクトリを基準にし、すべてのディストリビューションで保存場所が同じだと思い込まないでください。

サブスクリプショングループを作成して更新し、接続に使う設定を選んだらコアを起動し、ログに実行権限、ポート競合、コアファイルの不足などがないか確認します。パッケージが正しくインストールされているのにコアを起動できない場合は、セキュリティポリシー、マウントオプション、ファイル権限も確認してください。ユーザーディレクトリ全体の権限を一括で緩めず、まずエラーが起きたファイルを特定し、ディストリビューションの権限ルールに沿って対処します。

システムプロキシはすべてのプログラムで共通とは限らない

Linuxのシステムプロキシは、デスクトップ環境、アプリのツールキット、プログラムの実装に左右されます。デスクトップ設定でプロキシを有効にしても、ブラウザーは使う一方でターミナルのプログラムは直接接続する場合があります。これは接続経路の違いであり、必ずしもクライアントの異常ではありません。まず手動でプロキシを指定できるアプリからローカルの待ち受けをテストし、コアの接続経路が正常であることを確認します。その後、デスクトップのシステムプロキシ設定が、現在のセッションで参照される場所に反映されているか確認してください。

GUIアプリ、ターミナルの環境変数、バックグラウンドサービスの間で、プロキシ設定が自動的に同期されるとは限りません。ターミナルに環境変数を設定しても、デスクトップセッション全体の設定が変わるわけではありません。バックグラウンドサービスには独自の実行環境がある場合もあります。トラブル対処では、どのプログラムがリクエストを送信し、どこからプロキシ設定を読み込むか記録してください。特に待ち受けポートの変更後やクライアントのアンインストール後は、競合する複数のプロキシアドレスを残さないようにします。

アプリにSOCKSプロキシを手動で設定する場合は、そのアプリがドメイン名をどのように解決するか確認してください。先にローカルで名前解決してからアドレスをプロキシへ渡す実装もあれば、ドメイン名の解決をプロキシ側に任せる実装もあります。その違いによってDNSの動作も変わります。「SOCKS」と表示されているだけで名前解決の経路まで同じとは限りません。アプリの設定、クライアントのログ、実際のテスト結果をもとに判断してください。

TUN・特権操作・ネットワーク管理サービス

TUNには通常、デバイスへのアクセス権限やネットワーク管理権限が必要です。クライアントは許可画面や補助機能を使って関連する操作を行うことがあります。まずエラー内容を確認し、現在のアプリの権限設定手順に従って許可してください。プログラムのディレクトリ全体に広範な機能を安易に付与しないでください。ネットワーク管理や名前解決に使うサービスはシステムごとに異なり、ルートやDNSの設定方法も変わることがあります。ほかのディストリビューション向けの修正コマンドをそのまま使うと、既存のネットワーク設定を上書きするおそれがあります。

TUNを有効にした後にドメイン名を解決できなくなった場合は、まずTUNを無効にすると復旧するか確認し、システムのリゾルバー状態、クライアントのDNS設定、既存の仮想インターフェースを調べます。LAN内のアドレスにも接続できない場合は、プライベートアドレスのルーティングとインターフェースの優先順位を重点的に確認してください。仮想マシン、コンテナー、企業向けトンネルが別のアドレス範囲を使用している場合もあります。ローカルネットワークが家庭用ルーターの一つの範囲だけで構成されているとは限りません。

自動起動を設定する前に、デスクトップへログインして手動で起動したときに安定して動作することを確認してください。ユーザーセッションの起動とシステム起動サービスでは、権限、環境変数、設定パスが異なります。GUIクライアントをバックグラウンドのデーモンと同じものとして扱わないでください。終了またはアンインストールする前にシステムプロキシを解除し、TUNを無効にしてネットワークが正常か確認します。設定を移行する場合はプロセスを停止し、ファイルの所有権を維持したうえで、新しいシステムでパスと権限を確認してください。

アップデート後、通知領域のアイコンだけが消え、ウィンドウとコアが動作している場合は、サブスクリプションをすべて再インポートする前にデスクトップ環境の通知領域対応を確認してください。ウィンドウが表示されない場合は、GUIセッションと起動時のエラーを調べます。UI、コア、ネットワークの問題を分けて記録すると、不要な変更を減らせます。ルーティング関連データの更新方法はルールファイルの更新方法も参照してください。

Androidのインストールとバックグラウンド実行

v2rayNGとv2flyNGを選ぶ

Androidのダウンロードページから、まずv2rayNGを選びます。V2Flyコアとの互換性が必要な場合は、v2flyNGを使用してください。2つは別々のアプリです。サブスクリプション、使用中の接続設定、バックグラウンド設定はそれぞれ確認が必要で、自動的に共有されるとは限りません。複数のクライアントを比較する場合は、一度に起動するVPNサービスを一つだけにしてください。もう一方のアプリがシステムに停止された状態を、接続障害と誤認するのを防げます。

比較的新しいスマートフォンではarm64を選ぶのが一般的ですが、最終的にはOSが対応するアプリのアーキテクチャを確認してください。確認できない場合や、アーキテクチャ関連のインストールエラーが出る場合は、端末情報を調べてユニバーサル版を検討します。ユニバーサル版は複数のアーキテクチャに対応する内容を含みますが、リモート接続機能が強化されるわけではありません。テレビ、エミュレーター、古い端末では特に個別の確認が必要です。プロセッサの製品名だけから、OSが対応するビット数を判断しないでください。

インストール時に、ファイルマネージャーやブラウザーなど、インストールを開始したアプリに対して「不明なアプリのインストール」権限を求められる場合があります。今回必要なアプリだけに許可し、完了後は端末の管理方針に応じて取り消してください。更新インストールに失敗した場合は、署名の不一致、ストレージ不足、アーキテクチャの不一致、OSの制限を切り分けます。バックアップを取らずに古いアプリをアンインストールしないでください。通常、アンインストールすると保存済みのサブスクリプション、接続設定、ローカル設定も削除されます。

サブスクリプションを追加してVPN接続を許可する

サブスクリプショングループにURLを追加して保存し、更新後に接続設定を選びます。クリップボードからインポートする場合は、接続情報やサブスクリプションURLをコピーしたのか、共有ページの説明文をコピーしたのか確認してください。QRコードからインポートする場合は、用途にも注意が必要です。単一接続用のQRコードとサブスクリプション用のQRコードは意味が異なる場合があります。インポート後は設定の種類と主要なパラメーターを確認し、一覧に項目が表示されただけで情報がそろったと判断しないでください。

VPNモードを初めて起動すると、システムに接続リクエストが表示されます。インストールしたばかりのクライアントからの要求であることを確認してから、VPN接続を許可してください。ステータスバーにVPNアイコンが表示されても、システム上でサービスが存在することを示すだけで、リモート接続が確立したとは限りません。続けてクライアントのログと実際の接続結果を確認します。サービスがすぐ停止する場合は、バッテリー設定を変更する前に、権限、選択中の設定、コアの起動エラーを確認してください。

Androidでは通常、同じユーザーまたはプロファイル内で同時に有効にできるVPNサービスは一つです。ほかの通信フィルター、企業向けアクセスツール、トンネルアプリが競合する場合があります。起動後に別のアプリが切断された場合は、システムの制限と仕事用プロファイルを確認し、どのサービスを使うか決めてください。複数のアプリを同時に何度も起動しないでください。切断ログだけでは、個々のクライアントの安定性を正確に判断できません。

アプリ別ルーティングとプロキシのみのモード

一部のアプリだけを通信の取り込み対象にする場合は、クライアントのアプリ選択機能を利用できます。リストが許可対象と除外対象のどちらを選ぶ形式なのか、最初に確認してください。アプリを選ぶとプロキシ経由になる場合もあれば、プロキシを迂回する場合もあります。変更後は接続を再起動し、対象アプリから新しいリクエストを送って確認しましょう。システムアプリ、仕事用プロファイルのアプリ、別ユーザーのアプリは、同じリストに表示されない場合があります。

VPNモードとプロキシのみのモードでは、通信を取り込む範囲が異なります。プロキシのみのモードは主にローカルの待ち受けサービスを提供するため、対象アプリが自分でそのプロキシを使う必要があります。スマートフォンのすべてのアプリが自動的に従うわけではありません。自宅のWi-Fiに設定する手動プロキシも、クライアントのVPNモードと同じではなく、特定のネットワークや一部のプロトコルにしか適用されない場合があります。消費電力や接続性を比較する際は、両方のテストで同じモードを使用してください。

バックグラウンド動作・電池消費・ネットワーク切り替え

画面点灯中は使えてロック後に切断される場合は、まずクライアントが動作中か確認し、バッテリー最適化、バックグラウンド動作、自動起動、データセーバーの設定を調べます。設定名はOSによって異なるため、バックグラウンド実行を許可する項目を探してください。まずはクライアントに必要な制限だけを変更し、改善するか確認しましょう。省電力設定を一括で無効にする必要はありません。詳しい設定例はバックグラウンド動作と省電力設定を参照してください。

通信の継続、頻繁な再接続、短い間隔でのチェックは、いずれも電池消費を増やす可能性があります。トラブル対処では、待機中の環境、ネットワークの種類、大容量通信を行うアプリの有無を記録してください。バッテリー使用量の特定項目の割合が高いだけで、異常とは断定できません。Wi-Fiからモバイルネットワークへ切り替えると、既存の接続を再確立する必要がある場合があります。まずモバイルネットワーク自体が使えることと、クライアントのバックグラウンド通信が許可されていることを確認してください。

「常時接続VPN」や「VPNを経由しない接続をブロック」が有効な場合、クライアントを停止した後も直接接続できないことがあります。ネットワークを復旧するには、アプリ内のボタンだけでなく、これらのシステム設定も確認してください。アンインストールや別のクライアントへの切り替え前に、対応するシステム設定を解除し、必要な設定をエクスポートします。エクスポートファイルやスクリーンショットにも機密性の高いURLが含まれることがあります。トラブル情報を共有する場合は、エラーの種類、発生時刻、機密情報を伏せた設定の説明だけを残してください。

サブスクリプションの追加と設定管理

サブスクリプションURL・共有リンク・設定ファイル

サブスクリプションURLは通常、複数の接続設定を返し、まとめて更新するのに適しています。単一の共有リンクは一つの接続情報を示すことが多く、設定ファイルにはローカルの待ち受け、ルーティング、DNSなどが含まれる場合があります。長さや見た目だけで相互に置き換えられるものではありません。インポート前に、クライアントの入力欄がどの種類のデータに対応しているか確認してください。カーネル設定全体をサブスクリプションURL欄に貼り付けたり、ログインが必要なアカウントページを更新用URLとして使ったりしないようにしましょう。

サブスクリプションURLのパスやクエリパラメーターには、アクセス用の認証情報が含まれていることがよくあります。コピー時は全体を保ち、複雑に見える末尾を勝手に削除しないでください。また、出所の分からない変換サイトにURLを入力しないようにしましょう。設定の提供元が特定のクライアント向けの形式を案内している場合は、対応する形式を選んでください。汎用形式ではすべてのトランスポート拡張が保持されないことがあるため、インポート後に実際の接続パラメーターも確認します。

グループを作成し、更新順を決める

提供元や用途ごとにグループを分け、区別しやすく、アカウント情報が分からない名前を付けます。初回更新では、デバイスが現在利用できるネットワーク経路を使ってください。プロキシ経由で更新する設定にすると、既存のプロキシ接続に依存します。既存の設定がすべて無効になっている場合、「更新にはプロキシが必要だが、プロキシには更新後の設定が必要」という循環が起こることがあります。その場合は独立して使えるネットワーク経路を復旧するか、クライアントの設定に従って直接接続での更新を試してください。

更新後はグループ内に設定があるか、件数が大きく変化していないか、選択中の接続設定が残っているか確認します。提供元が設定の識別子を変更したり、古い項目を削除したりすると、以前選んでいた項目が自動的に引き継がれない場合があります。改めて設定を選んでコアを起動し、接続をテストしてください。古いログと新しい設定の状態を混同しないようにしましょう。必要であれば更新完了時刻を記録し、その後に出力されたエラーを確認します。

サブスクリプションから生成された設定を手動で変更する場合、次回の更新で上書きされる可能性を考慮してください。長期的に使うルーティング、待ち受けポート、アプリ設定は、できるだけクライアントの独立した共通設定に保存します。調整済みの接続設定を残す必要がある場合は、更新との関係を理解したうえで別に管理し、サーバー側の変更が自動で反映されないことを把握してください。サブスクリプショングループと手動設定を混在させる場合は、各設定の入手元を記録しておきましょう。

サブスクリプションの更新エラーを確認する

タイムアウトは、制限時間内にリクエストが完了しなかったことを示します。基本ネットワーク、名前解決、選択した更新経路が原因の可能性があります。認証失敗はURLの認証情報やアカウントの状態が関係していることが多く、解析失敗は返された内容が想定形式ではないことを示します。エラーごとに原因が異なるため、同じ操作で解決できるとは限りません。まずエラーの種類を全文確認し、該当する階層を調べてください。制限につながる再更新の繰り返しや、認証情報付きURLの公開も避けましょう。

ブラウザーでURLを開くとWebページが表示される場合でも、ログインページ、エラーページ、正常なサブスクリプション表示のどれなのかを確認してください。Webページ本文を接続設定の一覧として貼り付けないでください。想定と異なる内容が返された場合は、URLの有効期限や必要な出力形式を設定の提供元に確認します。クライアントが処理できるのは対応した形式だけで、任意のアカウントページを自動的に接続設定へ変換することはできません。

インポートには成功しても起動時に未対応フィールドが表示された場合は、コアとプロトコルのパラメーターを確認してください。VMess、VLESS、Trojanはそれぞれ異なるプロトコルです。REALITYは関連する接続設定で使われるセキュリティ機能であり、名前を置き換えるだけで変換できるものではありません。トランスポート方式、サーバー名、認証情報にはそれぞれ異なる役割があります。コアを更新または切り替える前に元のデータを保存し、変更がログに示された問題への対処として必要か確認してください。

バックアップ・移行・情報共有時の注意

移行時は、まずクライアントが明示的に提供するインポート・エクスポート機能を使ってください。ディレクトリ全体をコピーする場合はクライアントを終了し、移行先のプラットフォームが同じ形式を扱えるか確認します。システムプロキシの状態、ファイルパス、証明書の場所、権限は端末固有の環境であり、接続情報と一緒に移行できるとは限りません。移行先でインポートしたら、まず一つの接続をテストし、その後にグループやほかの設定を戻してください。設定を大量に一度に移すと、問題の原因を特定しにくくなります。

サブスクリプションが漏えいした場合は、アクセス用の認証情報を取り消すかリセットすることが重要です。ローカルのグループ名を変更しても保護にはなりません。トラブル情報を共有する際は、プロトコルの種類、トランスポート方式、エラーの分類だけを残し、サーバーアドレス、識別情報、サブスクリプションのクエリパラメーター、QRコードは隠してください。バックアップにも保管期限を設定し、古いアカウント、停止済みサービス、重複するエクスポートファイルを無制限に残さないようにしましょう。

更新頻度を必要以上に高くする必要はありません。設定がどれくらいの頻度で変更されるか確認し、手動または定期更新の頻度を決めてください。更新と接続チェックは別の操作です。基本手順はサブスクリプションの追加ガイドを参照してください。一つのグループだけ更新に失敗する場合は、ほかのグループと分けて確認しましょう。一つの提供元の問題を解決するために、クライアント全体を初期化する必要はありません。

ルーティングとDNSの設定

まず通信の取り込み範囲を決め、その後に出力先を設定する

プロキシによる通信の取り込みとルーティングは、異なる問題を扱います。システムプロキシやTUNはリクエストがクライアントに届くかどうかを決め、ルーティング規則は届いたリクエストの出力先を決めます。アプリがシステムプロキシを使っていない場合、ルーティングをグローバルに設定しても、そのアプリの通信がコアに届かないことがあります。一方、TUNで取り込んだ後も、ルーティングによって直接接続、プロキシ経由、ブロックを選べます。通信の取り込み方法と出力モードを混同しないでください。

初回設定では、まずクライアントに用意されているシンプルなルーティングを使い、通常のWebページ、LAN内のリソース、接続先のリモートサービスに想定どおりアクセスできるか確認してください。「中国本土を迂回する」といった設定は、通常、ドメイン、アドレスデータ、ルールの組み合わせに基づくもので、リアルタイムの位置判定ではありません。グローバルプロキシは一時的にルーティングの変数を減らすのに役立ちますが、ローカルサービスや組織のネットワークに影響する場合があります。テスト後は、実際の利用環境に合うルールへ戻し、トラブル対処用の設定を常用しないでください。

ルールの順序とマッチ条件を理解する

ルーティングは通常、規則を上から順に評価し、先に一致したルールが後続ルールの適用を左右します。完全一致のドメイン名、ドメインのサフィックス、分類データベース、アドレス範囲、ポートは、それぞれ異なる条件です。複数条件を組み合わせた場合の意味は、コアのルール構文によって異なります。一行に複数の項目があるからといって、どれか一つに一致すればよいとは限りません。変更前に対象リクエストが持つ情報と、使用したい出力先を明確にしてください。

以下は、プライベートアドレスを直接接続する方法を示すXrayルーティングオブジェクトの一部です。単独で動作する完全な設定ではありません。既存のインバウンドとアウトバウンドを残し、directという名前のアウトバウンドが存在することを確認してから組み込んでください。クライアントが設定を生成する際に手動編集が上書きされる場合があるため、対応するルーティング編集機能を使い、一時生成ファイルを直接変更しないことをおすすめします。

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

AsIsは、アドレスのマッチングを目的とした名前解決をルーティング側から積極的に行わないことを示します。システム全体でDNSリクエストが発生しないという意味ではありません。リクエストにアドレスが含まれていれば、アドレス規則に一致する場合があります。geoip:privateは対応するルールデータを必要とし、ほかの分類名もデータファイルの存在が前提です。ファイルの不足、分類の未定義、ルール順序の誤りでは症状が異なるため、コアのログで実際の原因を確認してください。

DNSの経路を分けて確認する

ドメイン名はアプリ、システムリゾルバー、クライアント内部のいずれかで解決され、名前解決のリクエスト自体も異なる出力先を通ることがあります。ブラウザーで独自の暗号化DNSを使っている場合は、さらに別の経路が加わります。そのため、クライアントのDNS設定を変更しても、すべてのアプリの名前解決を制御できるとは限りません。トラブル対処では、まずどのコンポーネントが名前解決を行い、リクエストがどこへ送られ、どの経路を通るのか、その結果のアドレスがルーティングにどう使われるのかを確認してください。DNSサーバーのアドレスを一つ変えただけで調査を終えないようにしましょう。

システムプロキシは、アプリが明示的にプロキシへ渡した通信を主に処理します。システム全体のDNSが取り込まれるとは限りません。TUNは通信を取り込む範囲を広げられますが、DNSが正しく処理されるかどうかはインターフェース、ルーティング、クライアント設定によります。DNSリクエストの経路を調べる方法に沿って確認できます。検査ページに表示される名前解決の出口は、キャッシュやネットワークサービスの影響も受けます。一度の結果だけで、すべてのリクエスト経路を判断しないでください。

FakeDNSは、仮想アドレスを使って後からドメイン名を復元する仕組みで、特定の通信取り込みやルーティングの用途に使われます。一般的なパブリックDNSと同じものではなく、単独で有効にすればすべてのアプリが対応するわけでもありません。対応する通信の捕捉、アドレスのマッピング、ドメイン名の復元が連携する必要があります。アプリが仮想アドレスをキャッシュした後で直接接続に切り替えると、接続に失敗することがあります。関連機能の有効・無効を切り替えた後は、状況に応じて接続を作り直し、キャッシュも処理してください。

ルールの管理と動作確認

GeoIP・GeoSiteデータは分類ルールの適用範囲に影響しますが、データファイルを更新してもルール構文の誤りは解決しません。クライアントがどのファイルを読み込んでいるか、更新に成功したかを確認してから、分類名と使用箇所を調べます。詳しくはGeoIP・GeoSiteの更新方法と設定例を参照してください。設定ファイルで存在しない分類を指定しても、名前が正しそうに見えるだけで有効にはなりません。

ルールは一度に一つ追加し、同じ接続先に新しい接続を作成して確認してください。ログで選択された出力先も確認します。アプリの既存の長時間接続は変更前の経路を使い続けることがあるため、ルール変更後に画面を更新するだけでは判断できません。対象が複数のドメインやリダイレクトを含む場合は、メインページ、リソースのドメイン、APIリクエストを分けて確認します。一部のコンテンツが読み込めても、関連するすべてのドメインが同じルールに従っているとは限りません。

継続して使う場合は、LAN内のリソースに対する直接接続の範囲を明確にし、カスタムルールの用途を記録してください。複雑なDNS設定を追加する前に、FakeDNSの仕組みと有効にするタイミングを参照できます。ネットワーク設定を元に戻す場合は、直近の変更を逆の順序で取り消します。まず追加したルールを削除し、次にDNSを戻してから、最後に通信の取り込み方法を切り替えてください。動作確認済みのシンプルな設定を残しておくと、次回のトラブル対処を短縮できます。

設定のよくある質問とトラブル対処

症状から問題の範囲を特定する

まず、再現できる症状として問題を説明します。使用するプラットフォームとクライアント、システムプロキシとTUNのどちらを使っているか、どのアプリで失敗するか、プロキシを無効にすると復旧するかを整理してください。次に、サブスクリプションの更新、ポートの変更、DNS機能の有効化、ネットワークの切り替えなど、最後に行った変更を確認します。すべての設定を同時に初期状態へ戻すと、原因を示す手掛かりが失われ、正常だった部分まで戻せなくなる可能性があります。

トラブル対処は、基本ネットワーク、ローカルプロセス、リモート接続、アプリの動作の順に進めます。まずデバイスがインターネットに接続できることを確認し、次にコアが起動してポートを待ち受けていること、プロキシを明示した接続が成功することを確認してください。最後にシステムプロキシ、TUN、ルーティングを調べます。ある段階で問題が見つかったら、それより上位の設定変更はいったん保留しましょう。ポート競合をDNS設定で直そうとしたり、システムに残ったプロキシ設定をクライアントの再インストールで解決しようとしたりするのを防げます。

起動・サブスクリプション・接続の問題

アプリによる違いとネットワークの復旧

必要な情報を記録し、復旧手段を残す

ログは、エラー発生の直前から直後までの短い範囲を記録します。エラーの種類、時刻、クライアント名、OS、通信の取り込み方法があれば十分です。共有前にサブスクリプションURL、サーバーの認証情報、QRコード、アカウント情報を隠してください。接続タイムアウト、証明書エラー、名前解決失敗、未対応の設定フィールドは、別々の症状として説明します。すべてを「使えない」とまとめないでください。未整理のログを大量に送るより、問題の範囲が分かる情報のほうが確認しやすくなります。

問題が解決したら、最終的な変更内容をローカルのメモに記録し、動作確認済みの設定を一つ保存しておきます。自動起動、バックグラウンド制限、ほかのツールを無効にしていた場合は、一つずつ元に戻して再テストし、新たな競合が起きないことを確認してください。最短手順を確認する場合は使い方ガイドへ、プラットフォームやインストーラーを変更する場合はクライアントのダウンロードページへ戻ってください。このページの各章は、今後のアップデートや移行時にもチェックリストとして活用できます。