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

準備と設定の範囲

クライアント・コア・サービス設定を区別する

v2rayNはサブスクリプションの管理や設定の生成、コアの起動を行うデスクトップ用GUIクライアントです。Androidではv2rayNGとv2flyNGを使用します。実際の接続、プロトコル処理、ルーティングはコアが担当します。Project Vは関連するオープンソースエコシステムの起点であり、V2FlyとXrayはそれぞれ異なるコアの開発系統です。クライアントをインストールしただけでは接続に必要なサービス設定はそろいません。利用が許可されたサブスクリプションURL、または個別の共有リンクを用意してください。

デスクトップではv2rayNが第一候補です。Androidでは通常v2rayNGから試し、V2Fly設定との互換性が必要な場合はv2flyNGを検討します。名称だけで機能の多さを判断せず、必要なプロトコル、トランスポート、安全設定を現在のコアがサポートしているか確認してください。たとえばREALITY設定には対応するコアが必要です。コア名を変更しただけで互換性が得られるわけではありません。詳しくはXrayとV2Flyのコア選びを比較をご覧ください。

ダウンロード前にOSとネットワーク環境を確認

クライアントをダウンロードし、まずOS、次にプロセッサのアーキテクチャとパッケージ形式を選びます。OSのアーキテクチャとアプリのアーキテクチャは個別に確認してください。互換レイヤーで動作するアプリがあっても、そのパッケージが端末に最適とは限りません。パソコンではシステム情報、Android端末では端末仕様を確認します。判断できない場合はダウンロードページの汎用パッケージを選んでください。外観や購入時期からアーキテクチャを推測しないでください。

作業前に、既存のプロキシ、VPN、仮想ネットワークアダプター、セキュリティソフトの状態を記録します。ネットワークを制御するツールを複数同時に有効にすると、通信経路の切り分けが難しくなります。ほかのプロキシクライアントを終了し、通常のネットワークが使えることと、システム時刻が自動同期されていることを確認してください。暗号化通信には正確な時刻が必要です。時刻のずれで証明書検証に失敗した場合、検証を無効にして回避してはいけません。

サブスクリプションとバックアップを整理する

サブスクリプションURLは設定を取得するための入口で、共有リンクは個別の設定情報です。用途が異なるため、入力欄を間違えないでください。サブスクリプションはHTTPSのURLで提供され、エンコードされた設定一覧が返ることがあります。一方、共有リンクにはプロトコルのプレフィックスが含まれます。クライアントには通常、それぞれ別のインポート方法があります。URLをコピーするときはクエリパラメーターを残し、前後の空白や改行を確認してください。ブラウザーのログインページのURLをサブスクリプションURLとして使わないでください。形式の詳細はサブスクリプションURLと共有リンクの形式をご覧ください。

ルーティング、DNS、コアを大幅に変更する前に、クライアントのエクスポートまたはバックアップ機能で現在の設定を保存してください。設定にはサブスクリプションのパラメーター、ユーザー識別情報、サービスアドレスが含まれることがあります。バックアップは自分で管理できる場所に保管してください。サポートを求める場合は、エラーの種類、発生時刻、必要最小限の設定構造だけを残し、識別情報を伏せます。サブスクリプションURL全体を公開の場に貼り付けたり、認証情報を含む設定をオンライン変換サイトにコピーしたりしないでください。

元に戻せる手順で検証する

初回設定は、インストール、インポート、設定の選択、コアの起動、通信の入口の有効化、アクセス確認の順に進めます。一度に変更する設定は一種類に絞り、結果を確かめてから次へ進んでください。まずシステムプロキシで基本接続を確認し、必要に応じてTUNを検討します。最初はデフォルトルートで通信を確認し、その後に独自のルールを追加してください。変更の前後が明確になり、問題が起きても直前の動作状態に戻しやすくなります。複数の設定を同時に推測する必要もありません。

以下に登場するローカルポート番号は設定の関係を説明するための例であり、クライアントの固定された初期値ではありません。現在の設定画面で実際の待ち受けポートを確認し、アプリに入力してください。サブスクリプションの内容だけでローカル設定がすべて決まるわけではありません。システムプロキシ、権限、ルーティング、DNSは個別に確認が必要です。利用前にネットワークや端末の管理要件を確認し、使用が認められた環境で設定してください。

Windows：v2rayNの導入とサブスクリプション設定

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

Windowsのダウンロードからv2rayNを選びます。デスクトップ版はクロスプラットフォームのUIを採用し、従来のWPF版はWindows向けのUIを引き継いでいます。これは画面やアプリ構成の違いであり、サービス設定のプロトコルの違いではありません。初めて使う場合はどちらか一方を選べば十分です。移行する場合は、まず設定をバックアップし、新しい画面でのインポート方法、待ち受けポート、プロキシモードを確認してください。2つのアプリで同時にシステムプロキシを制御するのは避けましょう。

インストーラーの案内に従い、書き込み可能な場所を選びます。展開形式を使う場合は、ディレクトリ内のファイルをすべて保持し、メインプログラムだけをデスクトップに移動しないでください。クライアントは関連ファイルや設定ディレクトリを必要とします。コアがない、またはセキュリティソフトにファイルが隔離されていると、画面は開いても接続を開始できないことがあります。実行環境に関するメッセージが表示されたら、まず要求されているコンポーネントを確認し、OSとアーキテクチャに合ったものを選んでください。適合しないコンポーネントを繰り返しインストールしないでください。

サブスクリプショングループを作成して更新する

v2rayNのサブスクリプショングループ設定を開き、新しいグループを作成します。識別しやすい名前を入力し、完全なサブスクリプションURLを貼り付けて、グループを有効にして保存してください。その後、サブスクリプションを更新します。使えるプロキシがまだない初回は、まず「プロキシを使用しない」で更新します。利用可能な設定があり、現在のネットワークから配信元へ直接アクセスできない場合は、「プロキシを使用して」更新を試してください。更新後はグループに設定が表示されているか確認し、空のままになっていないことを確かめます。

自動更新の間隔はサブスクリプションを取得し直す頻度を決めるもので、接続を維持したりサービスの有効期限を変更したりする機能ではありません。更新頻度が高すぎると、配信元のリクエスト制限にかかることがあります。フィルター条件は表示内容に影響します。初回インポート時は空欄にし、設定がすべて表示されることを確認してから指定してください。更新成功と表示されても一覧が空の場合は、現在のグループとフィルター条件を確認し、配信元からサブスクリプションではなくログインが必要なページが返っていないか確かめます。

設定を選びシステムプロキシを有効にする

一覧から使う設定を選んで有効にし、コアが正常に起動していることを確認します。次にシステムプロキシのメニューから設定を有効にしてください。プロキシのポートはクライアントのローカル待ち受けポートと一致させます。ほかのツールがシステムプロキシを変更していた場合は、古い設定を解除してからv2rayNで設定し直してください。ブラウザーは通常システムプロキシを参照しますが、ゲーム、コマンドライン、一部のデスクトップアプリは参照しないことがあります。ブラウザーが使えるからといって、すべてのアプリの通信が切り替わっているとは限りません。

ルーティングモードとシステムプロキシは別の設定です。システムプロキシはアプリがクライアントにリクエストを渡すかどうかを決め、ルーティングは受け取ったリクエストを直接接続にするかプロキシ経由にするかを決めます。初回はLANを迂回するルーティングを選ぶと、ローカル機器へのアクセスが遠隔側へ送られるのを避けられます。その後、用途に応じて調整してください。特定のアプリだけを試す場合は、手動プロキシに対応したアプリにローカルアドレスと実際のポートを入力できます。すぐにすべての通信を切り替える必要はありません。

権限・スリープ・終了後の復旧

通常のシステムプロキシを使うだけなら、通常は管理者として実行する必要はありません。TUNでは仮想ネットワークアダプターやルートの変更を伴うため、現在のクライアントの案内に従って必要な権限を付与してください。有効化後にLAN機器へアクセスできない場合は、ファイアウォールを無効にするのではなく、LAN迂回ルールとルーティングテーブルを確認します。セキュリティソフトがコアの起動を止めた場合は、ブロック履歴とファイルの場所を調べ、原因を確認してから必要な許可を設定してください。すべてのファイルを無条件に許可しないでください。

スリープからの復帰後や有線から無線へ切り替えた後は、ネットワークインターフェース、ゲートウェイ、名前解決の環境が変わっていることがあります。まずTUNを無効にしてから再度有効にしてください。それでも解決しない場合は、クライアントを終了して起動し直します。異常終了後にブラウザーがオフラインになった場合は、Windowsのプロキシ設定に手動設定が残っていないか確認し、到達できないローカルアドレスを削除して、元のネットワークが使えるか確かめます。ネットワークを復旧してからクライアントを起動し、残ったプロキシ設定をサービス障害と取り違えないようにしてください。

最後に2種類の確認を行います。プロキシが必要な接続先へアクセスし、プロキシ経由で通信できることを確認します。続いてLAN機器や直結を想定した接続先へアクセスし、分割ルーティングがローカル通信を妨げていないことを確認してください。同じ時間帯のログを見て、コアの起動、ドメイン名解決、接続のエラーを切り分けます。速度測定は参考情報であり、実際のアプリでのアクセス確認に代わるものではありません。ブラウザーは正常でも特定のアプリだけに問題がある場合は、そのアプリのプロキシ対応を先に調べてから、このページのTUNの章を確認してください。

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

チップとインストール先を確認する

システムの「このMacについて」でチップの種類を確認し、macOSのダウンロードからv2rayNを選びます。Apple Siliconでは対応するアーキテクチャ版、Intelではx64版を使用してください。互換機能で別アーキテクチャのアプリを動かせる場合でも、ネイティブ対応パッケージを優先すると、コアの起動や権限設定に伴う余計な要因を減らせます。アーキテクチャの不一致による起動エラーを、サブスクリプションやネットワークの問題と取り違えないでください。

ディスクイメージを開き、アプリを「アプリケーション」フォルダに移してから、固定した場所から起動します。マウント中のインストールイメージから常時実行したり、パッケージ内のファイルだけを取り出したりしないでください。場所を固定すると、権限の記録や更新を一貫して管理しやすくなります。システムのセキュリティ警告が表示されたら、まずダウンロード元とファイルを確認し、macOSが案内するセキュリティ設定の手順に従ってください。システム全体の保護を無効にして、すべてのチェックを回避する方法は使わないでください。

サブスクリプションを追加して基本接続を確立する

v2rayNを開き、サブスクリプショングループ設定で名前と完全なURLを入力し、グループを有効にして保存します。更新後、設定を1つ選んで有効にしてください。デスクトップ版はプラットフォームが違っても基本的な設定手順は同じですが、メニューの場所やショートカットは異なる場合があります。他のOSのマウス操作をそのまま当てはめず、操作名を目印に探してください。更新できない場合は、まず配信元へ直接アクセスできるか確認します。まだ確立していない接続に頼って更新しないでください。

初回起動時は、システムプロキシを有効にする前にコアが正常に動作しているか確認します。ログに実行不可、権限不足、ファイル不足が表示された場合は、まずローカルの起動問題を解決してください。コアがローカルポートで待ち受けて初めて、システムプロキシがリクエストを受け取れます。起動していないポートをプロキシ先に指定すると、アプリが待ち続けたり接続に失敗したりします。遠隔側の接続問題と誤認しやすいため注意してください。

ネットワークサービスごとに保存されるプロキシ設定を理解する

macOSのプロキシ設定はネットワークサービスごとに管理されます。Wi-Fi、有線などのサービスに個別の設定が保存されるため、ネットワークを切り替えたらプロキシの状態を確認してください。システムのネットワーク設定で現在使っているサービスを開き、HTTP、HTTPS、SOCKSプロキシのローカルアドレスとポートを確認します。クライアントでは設定成功と表示されるのにブラウザーがプロキシを使わない場合は、未接続のサービスではなく、現在のアクティブなネットワークサービスを確認してください。

アプリによっては独自のネットワークスタックやプロキシ設定を使い、システムプロキシに従いません。その場合は、まずアプリ内に手動プロキシ設定があるか確認し、クライアントの現在の待ち受け方式に合わせて入力してください。SOCKS専用ポートをHTTPプロキシ用の欄に入力してはいけません。システムプロキシが影響するのは設定に従うアプリだけです。それ以外の通信も処理する必要がある場合は、システムプロキシのモードを切り替え続けるのではなく、TUNを検討してください。

TUNの権限とほかのネットワークツール

TUNを有効にする際、権限の引き上げやクライアント指定の補助コンポーネントのインストールが必要な場合があります。手順は現在のビルドによって異なります。案内を確認して許可した後、仮想インターフェースが作成されたか確認してください。他のOS向けのドライバー導入手順を流用したり、権限の警告に対処するためにアプリパッケージ内部の権限を任意に変更したりしないでください。許可済みでも起動できない場合は、最初のエラーメッセージを確認し、補助コンポーネント、ポートの競合、仮想インターフェース作成のどこに問題があるか切り分けます。

業務用端末には、ネットワークフィルター、企業VPN、デバイス管理ポリシーがすでに設定されている場合があります。TUNと併用すると、ルーティングやDNSの管理が複雑になります。管理対象端末では管理者の指示に従ってください。個人端末で切り分ける場合は、ほかの通信制御ツールを一時的に停止し、設定を1つずつ検証します。複数のVPNの優先順位を同時に変更すると、復旧しても、どの変更が有効だったのか判断できません。

スリープから復帰したら、まず現在のネットワークサービスに正常なアドレスが割り当てられているか確認し、その後でプロキシの状態を調べます。ネットワーク切り替え後だけ失敗する場合は、通信制御機能を停止し、元のネットワークでアクセスを試してから再度有効にしてください。アプリ終了後もネットワークに接続できない場合は、アクティブなサービスにローカルプロキシが残っていないか確認します。新しい端末に移行するときはサブスクリプションやルーティングを引き継げますが、ローカルポート、システムの許可、チップへの適合は改めて確認してください。別の端末のネットワークサービス状態をそのまま再利用できるとは限りません。

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

ディストリビューションとアーキテクチャに合うv2rayNをインストールする

Linuxのダウンロードからv2rayNを取得し、ディストリビューションに合わせてdebまたはrpmを選び、x64かarm64かを確認します。パッケージ形式はシステムのパッケージ管理方式、アーキテクチャは端末に応じて選択します。両方の条件を満たす必要があります。デスクトップ画面の表示には、現在のグラフィカル環境やシステム依存関係も影響します。拡張子が合っているだけで動作条件がすべてそろったと判断しないでください。

まずはダウンロードしたファイルをグラフィカルなソフトウェアインストーラーで開き、依存関係とインストール結果を確認してから、アプリメニューで起動します。インストールに失敗したら、依存関係の不足、アーキテクチャの不一致、ファイルの読み取り不可のどれかを確認し、依存関係を無理に無視しないでください。システムのパッケージソースが未設定の場合は、先にパッケージマネージャーを正常に使える状態にします。旧版の削除や新版のインストール前にクライアント設定を保存してください。通常のインストールエラーを解決するために、システムのネットワーク設定を手動で消去しないでください。

サブスクリプションを追加して書き込み可能なディレクトリを確認する

一般ユーザーでクライアントを起動し、サブスクリプショングループ設定からURLを追加して更新し、使用する設定を選びます。クライアントの設定ディレクトリは、現在のユーザーが読み書きできる必要があります。以前に高い権限でGUIアプリを起動した場合、所有者が異なるファイルが残り、設定を保存できない、または起動のたびに古い内容へ戻ることがあります。その場合は対象ディレクトリと所有者を確認してください。個人用ディレクトリ全体やシステムディレクトリ全体の権限を再帰的に変更しないでください。

コアを起動できない場合、ログには画面のメッセージより詳しい情報が記録されていることがよくあります。まず関連するコアファイルが存在し、実行可能か確認します。次にセキュリティポリシーによる制限を調べ、最後に待ち受けポートの競合を確認してください。ソフトウェアのインストール成功とコアの実行成功は別の段階です。接続エラーが表示されても、すぐにサービス側のアドレスを変更しないでください。ローカルでコアが起動していない場合、遠隔設定を変えても実行権限の問題は解決しません。

デスクトップ設定とアプリの設定は別

Linuxには、すべてのデスクトップ環境で共通して使えるシステムプロキシの仕組みがありません。デスクトップのネットワーク設定がブラウザーに反映されても、端末、コンテナ、バックグラウンドサービスには反映されないことがあります。v2rayNでシステムプロキシを有効にした後、実際に使うアプリで動作を確認してください。手動設定に対応したアプリには、ループバックアドレスとクライアントの実際のポートを入力し、HTTPかSOCKSかも指定します。すべてのアプリがデスクトップ設定を自動共有すると考えないでください。

端末のプロキシ環境変数は通常、現在のプロセスと子プロセスだけに適用されます。デスクトップ設定の代わりにはならず、すでに起動済みのアプリにも自動では反映されません。以下は一時的な変数の設定例です。ポートをクライアントの実際のHTTPプロキシポートに変更し、同じ端末から、これらの変数に対応したプロキシ利用ツールを実行します。テスト後は変数を削除してください。SOCKSを使う場合は、ツールがドメイン名の解決をプロキシ側に任せられるかも確認します。

export http_proxy="http://127.0.0.1:10809"
export https_proxy="http://127.0.0.1:10809"
export no_proxy="localhost,127.0.0.1,::1"

# テスト後、現在の端末の一時設定を削除する
unset http_proxy https_proxy no_proxy

TUN・名前解決サービス・コンテナの境界

TUNは仮想ネットワークインターフェースを作成してルーティングを変更するため、ネットワーク管理権限が必要になる場合があります。現在のクライアントの許可手順に従い、GUIクライアントを常に最高権限で実行する方法を標準にしないでください。有効化後はまず基本ネットワークを確認し、その後にプロキシ経由で使う接続先を検証します。プロセスが動いていても仮想インターフェースが作成されない場合は権限を調べます。インターフェースがあるのにすべての通信に失敗する場合は、アプリの再インストールを繰り返さず、ルーティングとDNSを確認してください。

ディストリビューションによってDNSを管理するコンポーネントが異なるため、名前解決用ファイルを直接書き換えてもネットワークサービスにすぐ上書きされることがあります。クライアントまたは現在のネットワーク管理ツールから設定し、変更前の状態を記録してください。コンテナ、仮想マシン、独立したネットワーク名前空間は、ホストのプロキシやルーティングを引き継ぐとは限りません。ホストのブラウザーが使えても、コンテナの通信がプロキシ経由とは限りません。設定時はゲートウェイ、DNSリゾルバー、ホストの待ち受けアドレスへの到達性を確認してください。

アップグレード前に動作中の設定を保存してクライアントを終了し、アップグレード後はコアのパス、待ち受けポート、権限の案内を確認してください。デスクトップへのログイン時に起動に失敗し、手動起動なら正常な場合は、ネットワークの準備前に起動していないか、起動環境と対話セッションが異ならないか確認します。インストール、設定保存、コア起動、アプリ接続、接続先へのアクセスを段階ごとに検証すれば、Linux環境の違いを具体的な問題に分けられ、目的のないシステム設定変更を減らせます。

Android：v2rayNGとv2flyNGの設定

コアとインストールパッケージを選ぶ

Androidのダウンロードを開き、まずはXrayコアを使用するv2rayNGを選びます。v2flyNGはV2Flyコアを使う場合の選択肢です。サービス設定の要件を確認してから選んでください。一般的なarm64端末では対応パッケージを使用できます。アーキテクチャがわからない場合は汎用パッケージを選びます。OSのバージョンだけでプロセッサのアーキテクチャを判断しないでください。また、プロトコル互換性を確かめるために2つのクライアントを交互にインストールするより、まず設定項目を確認するほうが確実です。

システムのインストーラーからインストールします。提供元からのインストール許可を求められた場合は、現在使うファイルマネージャーまたはブラウザーだけに必要な権限を与え、インストール後は必要に応じて取り消してください。パッケージに互換性がないと表示されたら、アーキテクチャ、システム要件、既存アプリを確認します。署名の競合が表示された場合は、まず既存アプリの設定をバックアップし、インストール元を変更する必要があるか判断します。サブスクリプションやルールが消える場合があるため、更新失敗のたびにすぐアンインストールするのは避けてください。

サブスクリプション管理と個別リンクのインポート

v2rayNGでサブスクリプショングループ関連の画面を開き、グループを追加して名前と完全なサブスクリプションURLを入力します。保存後に更新してください。個別の共有リンクを受け取った場合は、クリップボードからインポートするか、該当情報を読み取る機能を使います。共有リンクをサブスクリプションURL欄に入力しないでください。v2flyNGでは画面上の手順が異なる場合がありますが、設定一覧の取得と個別設定のインポートを区別する点は同じです。メニュー名が変わっていたら、機能を基準に判断してください。

更新後、使用する設定を選び、接続ボタンをタップします。一覧が空の場合は、グループが有効か、URLが完全か、フィルター条件が適切かを確認してください。Androidのブラウザーによっては、共有ページのタイトルだけをコピーしたり、URLの一部を省略したりすることがあります。テキスト全体を確認してください。ユーザー情報に関わるパラメーターを含むサブスクリプションは個人端末にだけ保存してください。端末を移行する場合は管理下のバックアップ方法を利用し、URL全体を公開メッセージやスクリーンショットで共有しないでください。

システムVPNの許可とアプリの対象範囲

初回接続時には通常、システムのVPN許可画面が表示されます。これはシステムのインターフェースを使って通信をクライアントに渡すために必要です。許可した後、接続状態とログを確認してください。Androidのこの方式は、デスクトップの「システムプロキシを設定」とは異なります。対象アプリの通信をクライアントに渡し、ルーティングによって直結またはプロキシを選べます。ステータスバーに接続アイコンが表示されても、インターフェースができたことを示すだけで、すべての接続先にアクセスできる保証にはなりません。

アプリごとのプロキシ対象とルーティングによる振り分けも別の概念です。アプリ一覧では、どのアプリを通信制御の対象にするかを指定します。ルーティングルールでは、対象に入ったリクエストの出口を決めます。選択したアプリだけをプロキシにするモードでは、対象アプリを選び忘れると通信はプロキシに入りません。選択したアプリを除外するモードでは、チェックしたアプリの意味が逆になります。変更前に現在のモードを確認し、対象アプリを1つ使って試してください。長い一覧を見ただけで選択結果を誤認しないようにしましょう。

バックグラウンド制限・ネットワーク切り替え・競合

一部のシステムではバックグラウンド動作が制限され、画面ロック後の切断が省電力設定に関係することがあります。まずクライアントがシステムによって終了されていないか確認し、バッテリー設定で端末のポリシーに沿ったバックグラウンド実行を許可してください。バックグラウンド動作を許可しても、すべての接続が常時維持されるわけではありません。Wi-Fiからモバイルネットワークへ切り替えると、古い接続を再確立する必要があります。ロック中やネットワーク切り替え後だけ問題が起きる場合は、プロトコルを変える前にプロセスの状態とネットワーク切り替えを確認してください。

システムVPNのインターフェースは、ほかのネットワークツールに占有されることがあります。別のアプリを有効にしたときに既存の接続が切れた場合は、競合を調べてください。切り分け中は通信を制御するツールを1つだけ有効にします。プライベートDNS、ネットワークフィルター、アプリごとの設定も、名前解決や対象範囲に影響することがあります。元の設定を記録してから一つずつ試してください。調査のためにシステムのネットワーク保護をすべて恒久的に無効化せず、関係を確認したうえで、範囲が明確で元に戻せる変更を選びます。

検証では、まず対象アプリから実際にアクセスし、名前解決と接続の結果をログで確認します。クライアントのテストは成功するのに特定のアプリだけ失敗する場合は、アプリの対象範囲、アプリ独自のプロキシ設定、プロトコル要件を確認してください。すべてのアプリで失敗する場合は、サービス設定とDNSに戻って確認します。新しい端末に移行したら、VPNの許可、省電力制限、アプリ一覧を改めて確認してください。これらのシステム状態はサブスクリプションと一緒には完全に移行されません。簡単な操作手順はサブスクリプションの追加ガイドもご覧ください。

ルーティング・DNS・ドメインの照合

振り分けでは入力と出口を明確にする

リクエストがクライアントに入ると、ルールに基づいて直結、プロキシ、または遮断の出口が選ばれます。ルールはドメイン、宛先アドレス、ポート、プロトコルなどを基準に照合され、優先順位や順番によって結果が変わります。通常は保護が必要なLAN向けルールを先に置き、次に個別の接続先ルールを置いて、最後にデフォルトの処理を残します。複数ルールが同時に一致する可能性がある場合は、現在のコアの照合方式を確認してください。ドメイン名が長いルールほど自動的に優先されるとは限りません。

ドメインルールが機能するかどうかは、コアが接続先のドメイン名を認識できるかによります。アプリが自分で名前解決を行い、IPアドレスだけを送信する場合、クライアントにはIP情報しか届かないことがあります。スニッフィングで一部の通信から接続先名を取得できる場合がありますが、すべてのプロトコルに有効ではなく、DNSの設計に代わるものでもありません。設定時は、リクエストがどの形式で届くかを確認してから、ドメインまたはアドレスのルールを選んでください。入力したルールが正しくても、照合に必要な情報が得られなければ機能しません。

サービスアドレスの名前解決と接続先の名前解決を区別する

少なくとも2種類の名前解決があります。プロキシ接続を確立する前には、プロキシサービスのアドレスを解決する必要があります。接続先へのアクセス時には、接続先のドメイン名を解決する場合があります。前者を、まだ接続していないプロキシに依存させると起動時に行き詰まります。後者は想定する直結またはプロキシの経路に合わせて設定してください。システムリゾルバー、アプリ内蔵の名前解決、コアのDNSが同時に使われることもあるため、クライアントのDNS設定を1か所変更しただけですべてのアプリの問い合わせ経路が変わるとは限りません。

リモートDNSは、どのDNSサービスを使うかを示すもので、問い合わせが自動的にプロキシ経由になるとは限りません。そのリゾルバーへの通信がどのルートを通るか、クライアントがアプリの問い合わせを処理しているかも確認してください。暗号化DNSが改善するのは問い合わせの伝送方式であり、出口の方針とは別です。リゾルバーのアドレスが直結ルートに振り分けられていると、問い合わせはローカルネットワークから送信されることがあります。設定時はリゾルバーの選択と、接続経路を分けて検証してください。

設定例はルールの構造を理解するためのもの

以下はXray/V2Fly形式の部分的なルーティング構造で、ルール項目と出口の関係を説明する例です。完全な実行設定ではありません。この構造を使うカスタム設定に統合し、直結出口のタグが実際にdirectであることを確認してください。GUIが別のタグを生成する場合もあるため、一致すると決めつけないでください。別形式の設定を使うコアでは、対応する設定画面を利用し、この構造を互換性のないファイルに無理に追加しないでください。

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

AsIsは、ルーティング段階でこのポリシーによるドメイン名からアドレスへの変換を行わないという意味であり、後続の接続で名前解決が不要になるわけではありません。geoip:privateを使うには、対応するルールデータが利用可能である必要があります。ログにデータファイルの不足が表示された場合は、すべての振り分けルールを削除するのではなく、リソースの読み込みを解決してください。例のドメインは構造を示すためのものです。実際の用途に合わせて接続先を指定し、広すぎるルールで大量の通信が意図せず直結されないようにしてください。

FakeDNSと漏えい検査の範囲

FakeDNSは仮想アドレスでドメイン名との対応を維持するため、問い合わせと後続の接続が同じ処理経路に入る必要があります。アプリがクライアントを迂回して名前解決したのに仮想アドレス用のルールを適用した場合や、仮想アドレスを取得しても接続がクライアントに渡らない場合は、アクセスに失敗することがあります。有効化する前に、TUNのDNS処理方式とコアの対応状況を確認してください。すべてのアプリに使える万能の設定として扱わないでください。

名前解決の経路を調べるときは、クライアントのログ、システムのDNS設定、テスト対象のアプリを合わせて確認します。テストページに表示されるDNSの出口は手がかりであり、端末全体のすべての問い合わせを証明するものではありません。システムの名前解決、ブラウザー独自の名前解決、TUN利用時の動作をそれぞれ確認し、直結先とプロキシ先の両方で検証してください。詳しくはDNS漏えいの検査と設定方法をご覧ください。問題が起きたら、まず使える名前解決方法に戻してから機能を一つずつ追加し、通信が途絶えて切り分けられなくなるのを防ぎます。

システムプロキシとTUNの選び方

通信の入口と出口のルーティングを分けて考える

システムプロキシはアプリにプロキシアドレスを提供し、その設定に従うアプリがリクエストを自分で渡します。TUNは仮想ネットワークインターフェースを作り、ルーティングを通じて対象範囲の通信をクライアントへ送ります。解決する入口の問題が異なるため、「どちらが速いか」だけでは比較できません。普段ブラウザーを主に使うなら、動作を確認しやすいシステムプロキシから始めてください。システムプロキシを参照しないアプリを使う場合や、より広い種類の通信を処理する必要がある場合はTUNを検討します。

TUNで通信の対象範囲を広げても、すべての通信が遠隔プロキシを経由するとは限りません。仮想インターフェースに入った後もルーティングで出口が決まり、LAN通信、指定した接続先、一部のシステム通信を直結にできます。反対に、全般をプロキシにするルーティングを選んでも、クライアントにまったく入っていないアプリが自動的にプロキシを使うわけではありません。トラブル対処では、まずリクエストがクライアントに入っているか、次に入った後でどの出口が選ばれるかを確認し、2段階を混同しないでください。

デスクトップで有効にする前の確認手順

まずシステムプロキシで基本接続を確立し、有効な設定、コア、サブスクリプションが使えることを確認してからTUNを準備します。現在のネットワークインターフェース、デフォルトゲートウェイ、ほかのVPNの状態を記録し、競合する可能性のあるツールを終了してください。クライアントの案内に従って仮想インターフェース作成の権限を取得し、TUNを有効にしたらインターフェース作成とルーティングの結果をログで確認します。画面上でスイッチがオンでもログにエラーがある場合は、表示ではなく起動結果を基準に判断してください。

自動ルーティング、厳格なルーティング、DNSの制御などは対象範囲と互換性に影響します。それぞれの意味を現在使っているコアの説明で確認してください。厳格なルーティングは迂回を減らす一方、LAN、仮想マシン、一部のシステムサービスに影響する場合があります。初回から高度な設定をすべて有効にせず、まずクライアント推奨の基本構成を使い、実際に不足する点に応じて追加してください。変更のたびにプロキシ先、直結先、LANへのアクセスを確認し、元に戻せる状態を保ちます。

サービスへの接続が自身に再投入されないようにする

プロキシサービスへの接続もネットワーク通信を発生させます。TUNはこの通信を適切に処理し、コアからの接続が同じ入口へ再び送られてループしないようにする必要があります。クライアントやコアには、インターフェースの除外、出口のバインド、ルーティング処理などの仕組みが用意されている場合があります。まず既存の統合設定を利用してください。ログに接続が繰り返し表示され、リソース使用量が増えるのに接続先へアクセスできない場合は、遠隔設定を変えるだけでなく、ルーティングループやほかの通信制御ツールとの干渉を確認します。

サービスアドレスにドメイン名を使う場合は、起動時の名前解決も必要です。まだ確立していないプロキシ経由にDNS問い合わせが強制されると、サービスアドレスを取得できないことがあります。サービスアドレスには到達可能な起動時の名前解決経路を確保し、接続先ドメイン名は想定するポリシーに従って解決してください。複数のネットワークインターフェースが接続されている場合は、実際のデフォルト出口を確認します。古いインターフェースにバインドされたアプリは、ネットワーク切り替え後に通信制御機能を再起動して、有効な経路を選び直す必要がある場合があります。

UDP・LAN・アプリの互換性

システムプロキシ、クライアントのローカル入口、遠隔プロトコルでは、UDP対応がそれぞれ異なります。接続先のサービス側に制限がある場合もあります。TUNを有効にしても、通信がコアに渡されるだけで、経路全体のUDP対応が自動で補われるわけではありません。Webページは表示できても音声通話、ゲーム、ほかのアプリが失敗する場合は、まずアプリが使う通信の種類を確認し、入口、コア、遠隔プロトコル、サービス側のポリシーを調べてください。TCPでアクセスできるだけでは、トランスポートの問題を除外できません。

LAN機器へのアクセスにはアドレスのルーティングが関わります。機器の検出にはブロードキャストやマルチキャストが使われることもあり、LAN迂回ルールだけですべての検出が解決するとは限りません。まず既知のLANアドレスへ直接アクセスし、アドレス通信と検出方式のどちらに問題があるか判断します。仮想マシンやコンテナの仮想ネットワークも設計に含め、TUNのアドレス範囲と重ならないようにしてください。ネットワーク範囲が競合した場合は該当設定を変更し、すべてを直結するような広いルールで回避しないでください。

終了や切り替えの際に復旧手段を確保する

テスト後はまずTUNを無効にし、不要になったシステムプロキシを解除してからクライアントを終了します。特定の構成では両方の入口を併用できますが、初回のトラブル対処では経路が不明確にならないよう、どちらか一方だけを使ってください。ネットワーク切り替え、スリープからの復帰、アップグレード後は、仮想インターフェースとデフォルトルートを改めて確認します。無効化後も問題が続く場合は、システムにプロキシやDNS設定が残っていないか調べてください。仕組みと設定例はv2rayNのTUNモードを詳しく解説で確認できます。

設定のよくある問題と段階別のトラブル対処

まず問題が起きている段階を特定する

問題を、アプリのインストール、コアの起動、サブスクリプションの取得、サービスへの接続、通信の取り込み、ルーティングと名前解決の6段階に分けます。発生時刻、現在のネットワーク、最後に変更した設定を記録し、同じ時間帯のログを確認してください。後から繰り返される失敗に埋もれないよう、最初に出た重要なエラーを探します。画面上の接続状態、仮想インターフェースの表示、個別のテスト成功が証明するのはそれぞれの段階だけであり、全経路の確認にはなりません。

クライアントを終了した後も元のネットワークが使えない場合は、まずシステムプロキシ、DNS、通常のネットワークインターフェースを復旧し、ネットワーク自体の状態を確認します。元のネットワークは使えるのにコアが起動しない場合は、ローカルファイル、権限、ポートを調べます。コアは正常でもすべての設定で失敗する場合は、時刻、ネットワーク制限、共通のパラメーターを確認してください。特定の設定だけ失敗するなら、その設定を重点的に調べます。クライアントを次々に替えるより、影響範囲を絞るほうが原因を明確にできます。

サブスクリプションの更新に失敗する、または更新後に空になる

まずURLが完全か、クエリパラメーターが欠けていないか、空白が含まれていないか、ページタイトルとしてコピーされていないかを確認します。次にネットワークの失敗と内容の失敗を区別してください。配信元に接続できない場合は、現在のネットワークと更新方法を確認します。接続できても解析に失敗する場合は、返された内容がクライアントの対応するサブスクリプション形式か確認してください。ログインページ、エラーページ、リクエスト制限の案内が通常のテキストとして返ることがあります。「取得成功」と表示されても、設定内容が有効とは限りません。

プロキシを使わない更新に失敗し、すでに利用可能な接続がある場合は、プロキシ経由の更新を試せます。初回で使える接続がない場合は、この方法に頼らないでください。更新後に一覧が空なら、グループの有効状態、フィルター条件、配信元の内容を確認します。新しい内容を検証する前に、動作中の設定を削除しないでください。詳しくはトラブル対処FAQをご覧ください。更新失敗と接続失敗は別の問題として切り分けます。

設定をインポートできても接続できない

サービス提供元の完全なパラメーターと照らし合わせ、アドレス、ポート、ユーザー識別情報、トランスポート方式、安全設定、サービス名などを確認します。共有リンクでは情報が短縮されている場合があるため、編集画面で実際の値を確認してください。似た名前の項目でも意味が異なることがあります。サーバーアドレスを、すべての安全設定の値として使わないでください。証明書エラーが出た場合は、システム時刻と設定の接続先名を確認します。検証を無効にして問題を一時的に隠さないでください。

コアの互換性も別に確認する必要があります。共有リンクをクライアントが受け付けても、選択中のコアがすべてのオプションをサポートするとは限りません。インポート時の項目欠落や、移行時に古い設定が残ることも不一致の原因です。まずサブスクリプションの元の設定で基準となる動作を確認し、その後に手動調整を検討してください。コアを切り替えて失敗した場合は、以前動作していたコアに戻して対応の違いを比較します。無作為にパラメーターを組み合わせる方法は、適切な調整手順ではありません。

ブラウザーは使えるのにほかのアプリが失敗する

まず、失敗するアプリがシステムプロキシを参照するか確認します。手動設定に対応している場合は、プロキシ方式、ループバックアドレス、実際のポートを確認してください。非対応の場合は、TUNまたはAndroidのアプリごとの通信対象を検討します。アプリの通信がすでにクライアントに入っているなら、ルーティングルールの適用結果とDNSを確認してください。アプリ内蔵の暗号化DNS、古いアドレスのキャッシュ、異なる通信方式などが原因で、動作が異なることもあります。設定変更後は毎回新しい接続を試し、既存セッションに変更結果が隠れないようにしてください。

通常のアプリの接続失敗を解決するために、ローカルの待ち受けをすべてのネットワークインターフェースに変更しないでください。同じ端末上のアプリなら通常はループバックアドレスで十分です。別の端末からローカルプロキシに接続するのは別の用途であり、アクセス制御とファイアウォールの設計が必要です。待ち受けポートが使用中の場合は、まずそのポートを使っているアプリを特定し、競合プロセスを終了するか、空いているポートに変更してください。その後、アプリ側の設定も合わせます。片方だけ変更すると新たな接続エラーになります。

動作状態を復旧してから問題を報告する

断続的に問題が起きる場合は、画面ロック、スリープ、ネットワーク切り替え、サブスクリプション更新、ほかのネットワークツールの有効化と同時に発生しているか記録します。同じ接続先で繰り返し試し、変更する条件は一度に1つだけにしてください。まず通信制御機能を停止して元のネットワークを復旧し、直近の動作するバックアップを読み込む方法を優先します。問題を報告する際は、OSとアーキテクチャ、クライアント名、コアの種類、試した手順、個人情報を伏せたエラーの抜粋を提示し、認証情報全体は公開しないでください。用語がわからない場合は用語解説を確認してから、該当する章の手順に戻ってください。