V2Rayの設定完全ガイド

1. 基本概念と接続の流れ

クライアント、コア、サーバーの役割

V2Rayの設定では、まず3つの役割を区別しましょう。GUIクライアントはサーバー情報やサブスクリプションを管理し、設定を表示します。コアはトラフィックを受け取り、ルールに基づいて接続先を選び、接続を確立します。リモートサーバーは実際の通信経路を提供します。クライアントをインストールしただけでは、接続可能なサーバーは用意されません。デスクトップではv2rayN、モバイルではv2rayNGまたはv2flyNGが候補です。詳しくは次の章をご覧ください。

Project Vは関連するプロキシ技術のエコシステムを支えるプロジェクトです。V2FlyはV2Rayの開発を引き継ぎ、Xrayは同じ技術領域における別のコアです。クライアント名とコア名は一対一で対応するわけではなく、名前だけで全プロトコルへの対応を判断することもできません。設定をインポートしたら、クライアントが使用するコア、対応フィールド、サーバー側の要件を確認してください。GUIに設定が表示されても、コアで実行できるとは限りません。

プロトコル、トランスポート、セキュリティ設定を分けて理解する

プロトコルはクライアントとサーバー間の通信方式を定めます。代表例はVMess、VLESS、Trojan、Shadowsocksです。トランスポートはTCP、WebSocket、gRPCなど、データを運ぶ方法を指します。TLSとREALITYは接続時のセキュリティハンドシェイクに関係します。共有リンクは複数のレイヤーの設定をまとめてエンコードするため、単なるアドレスに見えても、ポート、識別情報、トランスポート、セキュリティ設定が含まれています。

VLESS自体は完全な暗号化通信方式ではありません。TLSまたはREALITYを使うかどうかは、サーバーの設定に従って判断してください。REALITYはVLESSと並ぶプロキシプロトコルではありません。手動で追加する場合は、アドレス、ポート、ユーザーID、トランスポート、サーバー名などの整合性を確認します。どちらもVLESSだからといって、一方の公開鍵、Short ID、パスをもう一方に流用することはできません。

再現可能な最小構成で接続する

一般的な接続経路は、ブラウザーがシステムプロキシ設定を読み取り、ローカルの受け入れポートにリクエストを送り、コアがルーティングルールに従ってプロキシ経由の接続を選び、リモートサーバーへ接続する流れです。システムプロキシを無視するアプリもあり、TUNは別のトラフィック経路を提供します。「クライアントに入ること」と「どの経路から出るか」は別の問題です。モードを調整するときは、この流れに沿って確認し、入口の問題をサーバーの問題と取り違えないようにしましょう。

初回テストでは、提供元が明確なサーバー設定を1つだけ使い、クライアントの基本ルーティング設定を維持して、複雑なカスタムルールは使わないでください。システム時刻が正確であること、プロキシプロセスが重複起動していないことを確認し、コアを起動して明確なテスト先にアクセスします。接続に成功したときのモードとログの概要を記録しておけば、以後の変更を基準と比較できます。速度テストだけでは実際のアプリ利用を確認できず、すべてのトランスポートが正常だとも判断できません。

トラブル時は手前から順に確認します。ローカルの受け入れが起動しているか、アプリがその入口を利用しているか、ルールがどの経路を選んだか、リモート接続が完了したかを調べてください。ログの起動失敗、ハンドシェイク失敗、リクエストのタイムアウトは、それぞれ異なる段階を示します。まずどのレイヤーで失敗したかを特定し、その設定を調整します。クライアントを何度も再インストールしても、無効なアドレスやサーバーパラメーターの不一致は解決しません。

2. プラットフォームとコアに合わせたクライアント選び

デスクトップではv2rayNがおすすめ

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを検討してください。本ガイドのサブスクリプショングループ、サーバー、パラメーター、ルーティング、DNSの説明を活用できます。ダウンロード前にファイルサイズだけで判断せず、OS、CPUアーキテクチャ、パッケージ形式を確認しましょう。クライアントは無料で利用でき、ソースコードも公開されていますが、配布パッケージによって必要な実行環境やシステムとの連携方法が異なります。導入前にプラットフォームごとの説明を確認してください。

Windows向けダウンロードページには、Desktop版と従来のWPF版があります。DesktopはクロスプラットフォームのUIを採用しており、複数のデスクトップOSで似た操作感を求めるユーザーに向いています。WPFはWindows向けの従来型UIです。これはプロトコルの違いではなく、Desktop版のほうがサーバー速度が速いという意味でもありません。まずどちらか一方で設定し、トラブル対処のために両方を同時に起動してシステムプロキシを競合させるのは避けましょう。

モバイルは設定との互換性で選ぶ

Androidでは、Xrayコアを使用するv2rayNGがおすすめです。V2Flyコアを使う場合はv2flyNGも候補になります。どちらも基本操作は設定のインポート、サーバーの選択、接続の開始ですが、プロトコルの実装やフィールドの対応状況が完全に同じとは限りません。特にREALITYや特定のトランスポート設定を含む場合は、選択したコアが対応しているか確認してください。リンクを解析できることだけを根拠に互換性を判断しないでください。

比較的新しいAndroid端末ではarm64版が一般的ですが、購入年だけでアーキテクチャを判断しないでください。ハードウェアが64ビットに対応していても、システム環境が異なる場合があります。不明な場合は端末情報を確認するか、汎用版を選んでください。汎用版は複数のアーキテクチャで使える一方、ファイルサイズが大きい場合があります。インストールに失敗したら、別のクライアントを試す前にアーキテクチャ、システム要件、署名が異なる旧版の有無を確認しましょう。

コアを切り替えてもサーバー設定の確認は必要

v2rayNでは、配布パッケージや機能の対応状況に応じて異なるコアを選べます。代表的な選択肢はXrayとsing-boxです。切り替える前に、現在の設定を切り替え先のコアで再現できるか確認してください。特にルーティング、DNS、TUNの設定に注意が必要です。コア間ですべてのJSONフィールドが共通しているわけではなく、GUIの設定が変換されることもあります。一方のコア向けの設定全体を、もう一方のカスタム設定欄にそのまま貼り付けないでください。

基本接続を確立するときは、サーバーの種類に合わせてクライアントが推奨する標準的なコアを使いましょう。明確な互換性の問題がある場合や特定機能が必要な場合に限り、別のコアを試してください。切り替えたら接続を再起動し、実際に生成された設定とログを確認して、プロキシの入口、ルール、DNSが初期値に戻っていないか調べます。画面に同じサーバー名が表示されていても、接続経路がまったく変わっていないとは限りません。

複数の端末で使う場合は、各設定の目的を把握し、ボタン名まで一致させようとしないことが大切です。デスクトップではシステムプロキシを使ってブラウザーを接続できますが、Androidでは通常、システムVPNインターフェースを使ってアプリの通信を取り込みます。OSごとに権限や制限が異なります。ダウンロード先はダウンロードセンターをご覧ください。Desktop版とWPF版の違いはDesktop版とWPF版の違いで確認できます。どちらかを選んでから導入に進みましょう。

3. 導入と初回起動時の確認

導入前にアーキテクチャ、保存先、既存設定を確認

導入の目的は、コアが正常に起動し、設定を保存でき、必要な権限を取得できる環境を整えることです。起動中のクライアントを終了し、残したいサーバーやルーティング設定をバックアップしてから、ダウンロードセンターで該当パッケージを選んでください。デスクトップの設定保存先には、現在のユーザーが書き込める必要があります。圧縮ファイル形式の配布物は完全に展開してから実行してください。圧縮ソフト内からメインプログラムを一時的に開くのは避けましょう。

移行と初回インストールを同時に行わないでください。まず新しい環境を起動し、ウィンドウが正常に表示され、基本設定を保存できることを確認してから旧設定をインポートします。旧ディレクトリ全体を上書きすると、古いコアファイル、ポート設定、カスタムパラメーターまで引き継がれることがあります。インストーラーがプログラムファイルを管理する場合は、インストーラーの手順に従ってください。独立したディレクトリを使う場合は、同じディレクトリ内のファイル構成を保ち、配布元の異なるコアとUIファイルを混在させないようにしましょう。

WindowsとmacOSでの初回起動

Windowsではv2rayNを起動し、実行環境の不足やコアの起動失敗が表示されないか確認します。実行環境に関する案内が出た場合は、配布パッケージの説明に従ってください。ファイル不足を管理者権限で回避しようとしてはいけません。通常のシステムプロキシ設定では、常に管理者として実行する必要はありません。TUNやシステムレベルのネットワーク設定では、別途管理者権限が必要な場合があります。権限、実行環境、ポートの競合は別々の問題として確認してください。

macOSでは「このMacについて」でチップの種類を確認し、Apple Silicon版またはIntel版を選びます。手順に従ってアプリを標準のアプリケーションフォルダに移動し、初回起動してください。未確認の開発元からのアプリとしてシステムにブロックされた場合は、まずダウンロード元を確認し、「システム設定 → プライバシーとセキュリティ」で対象アプリの許可項目を探します。クライアントを使うために、システム全体のセキュリティ機能を無効にする必要はありません。

起動を許可した後も、ネットワーク関連の操作がシステムに拒否されていないか確認します。アプリが開いても、システムプロキシの変更や仮想ネットワークアダプターの起動に必要な権限が得られているとは限りません。実際の案内に従って必要な操作を許可し、変更後に接続を再起動してください。「アプリが破損しているため開けません」と表示されても、必ずしも権限の問題とは限りません。まずアーキテクチャに合ったパッケージを再ダウンロードし、インストール手順を確認してください。詳しくはmacOSでのインストールと権限の設定をご覧ください。

LinuxとAndroidのインストール時の注意点

Linuxではディストリビューションのパッケージ体系に合わせてdebまたはrpmを選び、x64とarm64も確認してください。依存関係やプログラムファイルを正しく配置できるよう、まずはシステム標準のパッケージ管理ツールを使いましょう。デスクトップセッション、権限昇格ツール、システムプロキシとの連携方法は環境によって異なります。アプリのウィンドウは正常に表示されるのにシステムプロキシが機能しない場合は、アプリ内でローカルプロキシを明示的に設定し、画面の起動とシステム連携のどちらに問題があるか切り分けます。

Androidでv2rayNGまたはv2flyNGをインストールするとき、ダウンロードに使ったアプリやファイル管理アプリに、アプリのインストール許可を求められることがあります。許可は現在の操作に必要な範囲に限定してください。上書きインストールに失敗したら、パッケージのアーキテクチャや署名の違いを確認し、バックアップしてからアンインストールを検討します。初回接続時には通常、システムVPNの許可ダイアログが表示されます。許可するとアプリの通信を取り込めるようになります。バックグラウンドのバッテリー制限は、接続が安定してから個別に確認してください。

初回終了時はシステムプロキシの設定が残っていないか確認してください。ウィンドウを閉じてもタスクトレイに最小化され、コアが動作し続けるクライアントもあります。終了操作でプロセスが停止しても、異常終了によってプロキシ設定が元に戻らない場合があります。再度起動して実際の状態を確認し、ローカルの受け入れポートを記録してください。後のトラブル対処では、アプリが正しい入口に接続しているかをこのポートで確認します。既定ポートの記憶に頼らないでください。

4. サブスクリプションの追加とサーバー管理

サブスクリプションURLと共有リンクを区別する

サブスクリプションURLは複数のサーバー設定をまとめて取得・更新するためのものです。共有リンクは通常、1台分のサーバー設定を表します。どちらも長い文字列に見えますが、インポートする場所は異なります。設定を受け取ったら、提供元がどちらの形式を案内しているか確認してください。ウェブページの案内URLをサブスクリプションとして扱ったり、VLESSの共有リンクをサブスクリプションのダウンロード欄に入れたりしないでください。QRコードはテキストを運ぶためのもので、読み取った後もサブスクリプションか単一の設定かを見分ける必要があります。

v2rayNではサブスクリプショングループを開き、グループ名とサブスクリプションURLを登録して保存した後、更新を実行します。グループ名は接続品質ではなく、提供元や用途が分かる名前にしましょう。v2rayNGとv2flyNGでは、サブスクリプション設定または該当するインポートメニューから登録し、保存後に設定を更新します。メニュー名が多少異なっても、手順は同じです。提供元を登録し、設定を取得し、内容を確認して、使うサーバーを選びます。

更新後は一覧だけでなく設定項目を確認

更新が終わったら、サーバーが想定したグループに表示されていることを確認し、プロトコル、アドレス、ポート、トランスポート、セキュリティ設定を調べます。一覧の名前は識別用であり、接続可能である証明にはなりません。更新によって既存の項目が置き換わると、選択中のサーバーが無効になったり、別の位置に移動したりすることがあります。更新後に選択中の項目を確認し、削除済みの設定や現在のコアに適さない設定を使い続けないようにしましょう。

共有リンクはクリップボードからインポートできます。コピーするときは文字列全体を含め、チャットアプリによる末尾パラメーターの欠落や、説明文との混在を防いでください。手動追加は各項目の意味を把握している場合に適しています。共有リンクがある場合は、まずインポートしてから項目を一つずつ確認すると、パス、サーバー名、公開鍵、Short IDなどの入力漏れを防ぎやすくなります。

サブスクリプションと個別の設定は、それぞれ適切に保護してください。URL内のトークン、ユーザーID、認証情報によって、第三者が設定を取得したりサービスを利用したりできる可能性があります。公開スクリーンショット、ログ投稿、サンプルコードに含めないでください。トラブル対処を依頼する場合は、実際のアドレスや識別情報を隠し、項目名とエラー情報だけを共有します。サブスクリプションが漏えいした場合は、クライアントの行を削除するだけでなく、提供元で再発行または無効化してください。

更新に失敗したら取得・解析・実行の3段階で確認

第1段階は取得の失敗です。サブスクリプションのドメインを名前解決できるか、有効期限が切れていないか、システム時刻が正しいか、ログインページに置き換わった内容が返っていないかを確認します。第2段階は解析の失敗です。テキスト形式、文字コード、プロトコルの種類が現在のクライアントに対応しているか調べます。第3段階は実行の失敗です。設定をインポートできても、コアが特定のフィールドに対応していない、またはサーバーに接続できない場合があります。原因ごとに対処が異なるため、すべてを「サブスクリプションの不具合」とまとめないでください。

初めてインポートするときは、「サブスクリプションを更新（プロキシを使用しない）」を試すと、まだ確立していないプロキシ接続に更新を依存せずに済みます。サブスクリプションURLへのアクセスにプロキシが必要な場合は、別の利用可能なサーバーを確保してから、プロキシ経由で更新してください。どのURLにも使える固定の設定はありません。更新リクエストが、置き換え中の接続、すでに無効な接続、自分自身を参照する接続に依存していないことが重要です。

複数の提供元はグループごとに管理し、項目を頻繁に混ぜてコピーして提供元が分からなくならないようにしてください。自動更新の前に、既存設定を上書きするか、手動で変更した名前やパラメーターが再生成されるか確認します。失敗を繰り返す場合は利用可能な設定を一つ保管し、自動更新を一時停止してから、サブスクリプション更新失敗時の確認手順に沿って返却内容と更新方法を確認してください。この段階を終えてからプロキシの入口を設定すると、問題を切り分けやすくなります。

5. システムプロキシモードとアプリの入口

モードが制御するのは入口であり、すべての接続先ではない

システムプロキシモードは、OSがアプリにプロキシ設定を提供する方法を決めます。ルーティングルールは、コアに入ったリクエストを直接接続するか、プロキシ経由にするかを決めます。「システムプロキシを自動設定」を有効にすると、ブラウザーがローカルの入口を使うようになる場合がありますが、ルーティングルールによって直接接続が選ばれることもあります。「システムプロキシが有効」と「すべての通信がサーバー経由」は同じ状態ではありません。テストではアプリの入口と実際の接続先をそれぞれ確認してください。

v2rayNの主な選択肢は「システムプロキシを解除」「システムプロキシを自動設定」「システムプロキシを変更しない」です。「解除」はOSの現在のプロキシ設定を削除します。「自動設定」はクライアントのローカルアドレスとポートを書き込みます。「変更しない」はOSの既存設定を維持します。最後の項目では残ったポート設定は修復されないため、終了した別のクライアントを指していると、アプリが引き続き接続に失敗する場合があります。

アプリの明示的なプロキシ設定とシステムプロキシを分けてテスト

システムプロキシを読み取らないアプリもあります。HTTPまたはSOCKSを個別に設定できるアプリや、起動時にしか環境設定を読み取らないアプリもあります。システム設定を変更した後、アプリの再起動が必要な場合もあります。まずシステムプロキシに対応していることが明確なブラウザーを選び、拡張機能やアプリ内設定による上書きを除外してください。その後ほかのアプリを試すと、「クライアントの接続失敗」と「アプリがクライアントを経由していない」を区別できます。

アプリにプロキシを明示的に設定する場合は、通常、ローカルのループバックアドレスを指定し、ポートはクライアントに実際に表示されている値を使います。種類は待ち受け側の入口と一致させてください。HTTP入口とSOCKS入口は名前だけの違いではありません。アプリ側で種類を誤ると、ハンドシェイクに失敗することがあります。受け入れ側がループバックアドレスだけで待ち受けている場合、ほかの端末から直接利用することはできません。安易にすべてのネットワークインターフェースへ公開すると、ローカルプロキシにアクセスできる範囲も広がります。

既存の設定、クライアントの配布パッケージ、ユーザーによる変更でポートが異なるため、本ガイドでは特定の既定ポートを指定しません。ログにアドレスの競合が表示されたら、まずほかのプロキシプロセスを終了し、二重起動していないか確認してからポートの変更を検討してください。変更後はシステムプロキシやアプリ内設定も同じ値に更新します。クライアント側だけを変更し、ブラウザーには古いポートを残すと、「コアは正常に起動するのにページを開けない」原因になります。

接続を確認し、問題発生時の状態を復元する

自動設定後に接続を開始し、明確なテスト先にアクセスして、その時刻前後のログを確認します。すぐに速度を比較せず、まず接続が確立したかを確認してください。接続テスト機能は異なる接続先や段階を測定することがあり、表示結果だけでウェブサイトの利用品質を判断できません。クライアントにリクエストログやルーティングログがあれば、対象のリクエストが記録されているか、どの接続先が選ばれたかを調べて、問題の範囲を絞り込みます。

コアにリクエストが届いていない場合は、アプリ内プロキシ設定、システム設定、ローカルポートを確認してください。リクエストは届いてもリモートとのハンドシェイクに失敗する場合は、サーバーのパラメーターとコアの互換性を確認します。ハンドシェイク後に接続先へアクセスできない場合は、DNS、ルーティング、接続先のサービスを調べてください。すべてのモードを次々と切り替えるより、この順序で確認するほうが効率的で、問題が起きた段階を説明する情報も残せます。

Androidの接続入口は通常、システムVPNインターフェースを使って確立するため、デスクトップのシステムプロキシメニューと同じ方法では設定できません。モバイルではシステムの許可、アプリの対象範囲、バックグラウンド制限を個別に確認してください。まず1つのアプリを前面で正常に使える状態にし、その後画面ロック時やネットワーク切り替え時もテストします。入口が安定してから次の章のルーティング設定に進み、アプリ接続の問題をルールの問題と混同しないようにしましょう。

6. ルーティングとDNSの連携

ルールが評価される順序を理解する

ルーティングの目的は、明確な条件に基づいて接続先を選ぶことです。ルールをできるだけ多く追加することではありません。代表的な方式には「中国本土を除外する（Whitelist）」「ブラックリスト（Blacklist）」「全般（Global）」がありますが、既定のルールはクライアント設定によって異なります。名前は識別の手がかりにすぎません。実際の動作はルールの内容、順序、条件に一致しない場合の既定の接続先で決まるため、ラベルだけで判断せず、使用前にルールを確認してください。

多くのルールは上から順に評価され、先に一致した条件によって後続ルールの適用が変わります。通常、LANやプライベートアドレスは直接接続にし、特定サービスのドメインは汎用ルールより前に配置し、広い範囲を対象にするフォールバックルールは後ろに置きます。特定のドメインが意図しない接続先に送られる場合は、先行するドメイン、アドレス、ポートの条件に一致していないか確認してください。末尾にルールを追加するだけでは、動作が変わらないことがあります。

ドメインルールとアドレスルールの判定条件

geosite:cnはドメインリストを参照し、geoip:privateはプライベートアドレスのリストを参照します。利用には、対応するリソースをコアが読み取れる必要があります。ドメインルールではリクエストにドメイン情報が保持されている必要があり、アドレスルールでは接続先のIPアドレスが判定に使われます。アプリが手元で名前解決を済ませ、IPアドレスだけを入口に渡す場合、ドメインによる判定が制限されることがあります。スニッフィングで一部の通信からドメインを補える場合もありますが、すべてのプロトコルを識別できるわけではありません。

DNS設定も接続経路に関係します。どこから名前解決が行われ、リクエストがどの接続先を経由し、どのアドレスが返されるかによって、ルーティングや接続結果が変わります。解決結果を変えるためだけに、互いに重複する複数のDNS機能を同時に有効にしないでください。まずアプリ側のDNSとコア側のDNSの役割を明確にし、直接接続用とプロキシ用の名前解決が同じ上流を使うことで、依存関係のループが起きていないか確認します。

既存設定に意味を説明できるルールを追加

以下はXray / V2Ray形式のルーティング例です。プライベートアドレスとドメインリストを直接接続にする意味を示しています。完全なクライアント設定ではありません。既存の接続先にdirectタグがあり、対応する地理データファイルも必要です。GUIクライアントでは、まずルーティング設定から同等のルールを作成してください。別のコアを使う場合は、そのコアのルール形式に合わせて書き直す必要があります。

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

AsIsは、ルーティング段階でアドレス判定のためだけにドメインを積極的に名前解決しないことを意味します。接続段階でDNSを一切使わないという意味ではありません。ドメインの処理方式によって、名前解決のタイミングやアドレスルールを評価するタイミングが変わり、これまで一致しなかった条件が適用されることがあります。初めて設定する場合は基本設定を維持し、不足している判定情報を確認してから調整してください。方式名だけを根拠に、固定的なパフォーマンス最適化とみなさないでください。

カスタムルールは、まず対象が明確なドメインを一つ使って検証します。直接接続かプロキシ経由かを決め、ログでルールの適用を確認してから、ドメインリストへ対象を広げてください。LAN機器をテストするときは、プライベートアドレス、LAN内のドメイン名、アプリがTUNに取り込まれているかを同時に確認します。プライベートIPを直接接続にしても、LAN内のドメインを名前解決できない問題は解決しないことがあります。ルーティングとDNSは別々に検証してください。

ルール用リソースを更新すると結果が変わり、手動ルールがサブスクリプションや既定テンプレートと競合することもあります。変更前後の内容を保存し、テスト先と適用された接続先を記録してください。問題が起きたら直前の変更を元に戻します。複雑な設定でも、「このルールは何に一致し、なぜここにあり、一致しない場合はどうなるか」を説明できるようにしましょう。そうでなければ、メンテナンスの負担が増え続けます。

7. TUN仮想ネットワークアダプターと対象範囲

アプリのプロキシ設定からネットワークの入口へ

TUNは仮想ネットワークインターフェースを通じてIP層の通信を取り込み、システムプロキシを読み取らないアプリにも使えます。通信を取り込む範囲を広げる機能であり、無効なサーバーを修復したり、すべてのアプリのプロトコルを利用可能にしたりするものではありません。有効にする前に基本接続が正常で、現在のルーティング設定を理解していることを確認してください。入口、DNS、サーバーで同時に問題が起きると、ログから原因を特定しにくくなります。

デスクトップのTUNでは仮想インターフェースの作成やシステムルートの変更が必要になり、権限昇格やネットワークコンポーネントが求められる場合があります。v2rayNの「TUNモードを有効にする」は操作の入口にすぎず、実際の動作はコア、プラットフォーム、各種設定によって変わります。まず環境が機能に対応しているか確認し、クライアントの案内に従ってください。コアが起動していない場合や依存コンポーネントが不足している場合に、システムルートの有効・無効を繰り返さないでください。

ループバック、LAN、ほかのトンネルを確認

有効にする前に、ルーティングを変更するほかのプロキシやVPNを終了し、2つの入口がデフォルトルートやDNSを奪い合わないようにします。システム内に複数の仮想ネットワークアダプターがあっても、必ずしも問題ではありません。ただし、現在の通信をどのアダプターが受け取っているか把握する必要があります。有効にした後は、インターフェースの作成成功がクライアントのログに記録されたか確認し、次にアプリを一つテストし、最後にLAN機器と一般的な直接接続先を調べてください。画面上のスイッチ状態だけで判断しないようにしましょう。

リモートサーバーへの接続に使う通信が再びTUNの入口へ戻ると、ループが発生する場合があります。クライアントやコアに自動ルーティング、インターフェース選択、除外設定が用意されていることもありますが、複数のネットワークアダプター、テザリング、カスタムルートによって前提が変わる可能性があります。ログに接続が繰り返し表示され、確立できない場合は、まずTUNを無効にしてシステムプロキシの基本状態に戻してください。その後、出口インターフェースとサーバーアドレスへの実際のルートを確認します。

LANへのアクセスではプライベートアドレスと名前解決の両方を考慮する必要があります。プリンター、ルーターの管理画面、ネットワークストレージに接続できない場合は、まずLAN内のIPアドレスを指定して試し、次にデバイス名でアクセスします。IPアドレスでも失敗する場合はルーティングやファイアウォール、名前だけで失敗する場合はDNSが原因と考えられます。LANの問題をすべて広範囲なプロキシルールで解決しようとしないでください。本来ローカルで完結するリクエストがリモートへ送られる可能性があります。

DNS、UDP、ネットワーク切り替えの確認順序

TUN設定はDNSの取り込みと組み合わせることが多いものの、DNSの取り込みだけで名前解決の仕組み全体を補えるわけではありません。システムからの問い合わせ先、コアがリモートサーバーの名前を解決する方法、DNSの上流がプロキシ接続に依存しているかを確認してください。サーバーアドレスの名前解決が、まだ確立していないトンネルに依存していると、起動時にデッドロックが起きることがあります。最初の接続を確立できる名前解決経路を設定に残し、すべてのDNSを無条件に同じ接続先へ送らないでください。

ブラウザーでウェブページが表示されても、UDPやすべての通信が正常とは限りません。音声、リアルタイム通信などのアプリは、それぞれのプロトコルに応じてテストし、サーバーとトランスポートが必要な通信に対応しているか確認してください。失敗した場合は、通信がコアに届いているか、正しい接続先が選ばれたか、システムファイアウォールに遮断されていないかを調べます。TUNを有効にすればすべてのアプリが同じように接続できると考えないでください。

有線から無線への切り替え、スリープからの復帰、テザリング先の変更によって、出口インターフェースやDNSが変わることがあります。すぐにルール全体を書き換えず、まず接続を再起動してテストしてください。AndroidではシステムVPNの状態、バックグラウンド制限、アプリの取り込み範囲も確認します。前面、バックグラウンド、ネットワーク切り替えの3つの状況で結果を確認してから、日常利用に適した入口か判断しましょう。

8. 日常のメンテナンスと段階別トラブル対処

利用可能な基準設定と最小限のバックアップを維持

日常のメンテナンスでは、動作を確認した設定を一式保存します。クライアントの種類、使用コア、サブスクリプショングループ、プロキシモード、ルーティング、必要なDNS設定を含めてください。バックアップには復元に必要な情報だけを保存し、ログ全体を長期保管用の設定ファイルに混ぜないようにします。エクスポートファイルにサブスクリプションの認証情報やサーバーの識別情報が含まれる場合があります。安全な場所に保管し、移行時も公開同期や誤共有を防いでください。

サブスクリプション、クライアント、コア、ルール用リソースの更新は、できるだけ別々に行います。一度に一種類の変更だけを行い、接続を再起動して普段使う接続先をテストしてから次に進みます。すべてを同時に更新すると、サーバー設定、パラメーターの変換、ルールの適用、プログラムの依存関係のどれが原因か判断しにくくなります。複雑な表を作る必要はありませんが、少なくとも変更内容、変更理由、元に戻す方法を記録してください。

失敗した段階に応じてログを読む

コアの起動に失敗したら、設定の構文、フィールドの互換性、リソースファイル、ポートの競合を確認します。起動は正常でもアプリからリクエストが届かない場合は入口を調べます。リクエストが届いた後にタイムアウトする場合は、サーバーアドレス、ネットワーク、接続先を確認してください。ハンドシェイクエラーは、識別情報、TLS、REALITYのパラメーターを確認します。ログのエラーメッセージは手がかりにすぎません。操作した時刻と照合し、以前の接続のエラーを現在の設定に対する結論として扱わないでください。

ログを集める必要がある場合は、一時的に詳細度を上げ、明確な操作を一度だけ再現した後、通常のレベルに戻します。ログが多すぎるとストレージを圧迫し、接続先のドメイン、アドレス、アカウント関連の項目が記録されることもあります。トラブル対処用の資料を送る前に認証情報と無関係なリクエストを削除し、クライアント環境、エラー発生時刻、操作手順、関連ログだけを残してください。状況を具体的に説明すると、検証可能な助言を得やすくなります。

時刻、ポート、ネットワーク環境の基本確認

システム時刻が誤っていると、証明書の検証や一部プロトコルの認証に影響することがあります。長時間オフラインだった場合、スリープから復帰した場合、自動時刻合わせを無効にした場合は特に確認してください。ポートの競合は、複数プロセスやほかのプロキシソフトが原因の場合があります。まず正常に終了してから再試行し、ポートを変更した場合はアプリ側の設定も合わせてください。ネットワーク環境が変わった場合は、新しいDNS、出口インターフェース、ログイン画面での認証の要否を確認します。

同じ設定が一方のネットワークでは正常で、別のネットワークでは動作しない場合、クライアント設定を変えずに比較テストします。まず接続先ネットワークで通常のアクセスと名前解決ができるか確認し、その後、接続のどの段階で失敗するか調べてください。接続先によって結果が異なる場合、すべてのサーバーが無効だとすぐに判断しないでください。逆に、1台のサーバーが失敗してもクライアントの再インストールが必要とは限りません。条件を固定すると、違いの原因を適切なレイヤーに絞り込めます。

更新後に元へ戻す場合は、メインプログラムだけを置き換えるのではなく、設定と互換性のある実行環境を優先して復元します。新しいバージョンの設定形式を古いUIで完全に読み取れない場合があります。移行前に独立したバックアップを保存しておくと安心です。Androidではアンインストールによってアプリデータが削除されることがあり、デスクトップでも設定フォルダが必ず残るとは限りません。操作前にエクスポートした内容を読み取れるか確認し、機密情報を適切に保護してください。

よくある質問はFAQで確認できます。最小限の接続経路をすぐに作り直す場合は、使い方ガイドに戻ってください。メンテナンスで大切なのは、すべての設定を常に最新にすることではなく、不確かな変更を減らすことです。現在の設定を説明でき、問題を安定して再現し、確実に元へ戻せることが、応用設定に進むための基礎です。

9. 応用設定を学ぶ手順

まず生成された設定を読み、その後カスタム設定を書く

応用設定の第一歩は、空のファイルから一式を作ることではなく、クライアントがすでに生成している設定を理解することです。まずローカルで実行中の設定を確認し、受け入れ、接続先、ルーティング、DNSの関係を把握してください。GUIで選んだ項目がどのフィールドに変換されるかも確認します。生成ファイルは次回の起動時に上書きされる可能性があります。クライアントが提供する設定画面から変更し、一時ファイルを直接編集して長期運用しないでください。

設定を読むときは、まずタグをたどります。どの受け入れ口がアプリのリクエストを受け取り、ルールがどの接続先を指定し、既定の接続先が何かを確認してください。その後、トランスポートとセキュリティ設定を読み、最後にDNSと特殊機能を確認します。一つのリクエストの経路に絞って調べると、特定のフィールドが現在の接続に使われているか分かります。参照されていない接続先や、一度も一致していないルールは、ファイルに記載されているだけでは動作しません。

最小限のルールで一致条件を理解する

まず対象範囲が明確なドメインルールを一つ追加し、適用を確認してからドメインリストへ広げます。以下の例は、example.comとそのサブドメインをdirectという名前の接続先へ送る設定です。ルールの動作を試すためのものであり、すべての環境でこのドメインを直接接続にすべきという意味ではありません。この設定は、既存のXray / V2Ray形式のルーティングルール配列に追加し、対応する接続先タグが存在している必要があります。

{
  "type": "field",
  "domain": ["domain:example.com"],
  "outboundTag": "direct"
}

実験前に元のルール順を記録します。実験後は、対象ドメインがコアに届いているか、ドメイン情報が保持されているか、指定した接続先が選ばれたかを確認します。一致しない場合は、DNSやスニッフィングを調整する前に、先行ルールと入口の情報を分析してください。条件を追加する前に失敗の原因を説明できるようにすると、一度の起動では偶然動いても理由を説明できない設定になるのを防げます。

要件に応じてDNSとFakeDNSを学ぶ

FakeDNSは予約済みアドレスプールのIPアドレスをドメインの代わりに返し、両者の対応関係を管理します。その後の通信では、この対応関係を使って元の接続先を復元します。TUNやドメインによるルーティングと組み合わせて使われることがありますが、一般的なパブリックDNSのアドレスではなく、どの環境にも適しているわけではありません。アプリのキャッシュ、LAN内の名前解決、入口での取り込み不足によって問題が起きる場合があります。返されたアドレスがどのように受け渡され、コアに取り込まれ、実際の接続先に変換されるかを理解してから使いましょう。

この機能を調べる前に、通常のDNS、TUN、ドメインルーティングをそれぞれ検証できる状態にしてください。有効にした後は、ドメインでのアクセス、IPアドレスを直接指定したアクセス、LAN機器へのアクセス、機能を無効にした後の復旧をテストします。アプリに以前返されたアドレスがキャッシュされていないかも確認してください。仕組みとTUNとの連携についてはFakeDNSの仕組みとTUNとの連携をご覧ください。接続失敗を何でも直すための機能として使わないでください。

応用設定をメンテナンス可能な形にまとめる

カスタム設定、複雑なルーティング、異なるコア間のルール変換は、元の日常利用設定を残したまま、独立した設定で試してください。各機能について、目的、入力条件、依存するリソース、元に戻す方法を記録します。たとえば、ドメインルールはアプリ側でドメイン情報が保持されていること、TUN設定は権限と出口インターフェース、DNS方式はプロキシ接続を先に確立できることが前提になる場合があります。長いパラメーターをコピーすることより、こうした前提の理解が重要です。

性能を評価するときも、条件を固定してください。ネットワーク、サーバー、テスト先を同じに保ち、接続の確立、ページの読み込み、アプリでの実際の動作を個別に確認します。短時間のテスト結果をすべての利用状況に当てはめないでください。ログの詳細度、同時に動作するアプリ、DNSキャッシュも観察結果に影響します。結果を繰り返し確認でき、変更が接続経路に与える影響を説明できてから、実験した設定を日常利用に取り入れましょう。

このページの順序を繰り返しながら学習できます。まず導入とサブスクリプションを確認し、次にアプリの入口を確かめ、その後ルーティングとDNSを検証してから、TUNやカスタム機能に進みます。基本用語を確認したい場合は、V2Ray初心者向け入門FAQ 10選を読んでから該当する章に戻ってください。理解できない設定一式に頼るより、簡潔で説明しやすい設定のほうが長期的に管理しやすくなります。