初心者から応用まで · 設定を体系的に解説

V2Ray設定ガイド
サブスクリプションからルーティング・TUNまで

9段階で設定の考え方を身につけましょう。Androidではv2rayNG、デスクトップではv2rayNを第一候補とし、v2flyカーネルが必要な場合はv2flyNGも確認してください。

初回接続だけを済ませたい場合は、使い方ガイドのクイックスタートをご覧ください。このページでは設定を体系的に確認できます。各設定がどの層に影響するか、変更をどう検証するか、失敗したときにどこから復旧するかを説明します。初めて使う方は第1章から順に、設定済みの方は該当する章からお読みください。クライアントやビルドによってメニュー名が異なる場合があるため、実際の画面とログを確認してください。

第1段階：クライアント、カーネル、通信経路を理解する

画面と設定を実行するカーネルを区別する

クライアントを開くと、まずグラフィカルな画面が表示されます。画面側ではサーバー情報の保存、サブスクリプションの更新、設定の生成、サービスの起動を行います。実際に通信を処理するのはカーネルです。v2rayNGは主にXrayカーネルを使用し、v2flyNGはv2flyカーネルを使用します。v2rayNはデスクトップ向けクライアントで、使用するカーネルは選択した設定とクライアント側の対応状況によって異なります。画面上で項目を保存できても、現在のカーネルがその項目を実行できるとは限りません。

Project Vはこのプロキシエコシステムを理解するための背景知識です。V2FlyとXrayは関連するカーネルの系統であり、互いに置き換えられる3つのアプリ名ではありません。情報を調べるときは、記事がクライアントのメニューを説明しているのか、カーネルの設定項目を説明しているのかを確認しましょう。見慣れない用語は用語集で調べられます。V2Rayという名前が含まれているだけで、別のカーネル向け設定一式を現在のクライアントにそのまま適用しないでください。

入口・ルール・出口からリクエストの流れを把握する

リクエストは通常、アプリから送信され、ローカルのプロキシ入口に入り、ルーティングルールに従って出口が選ばれたあと、接続先のサービスへ送られます。デスクトップのシステムプロキシは、一部のアプリにローカルの入口へリクエストを渡すよう指示します。AndroidのVPNサービスは、システムが提供する仮想ネットワークインターフェース経由で通信を受け取ります。入口はリクエストを受け取り、出口は送信方法を決めます。どの入口を通るかと、最終的にどの出口を使うかは別の問題です。

サーバー情報にはリモート接続の方法が記載され、一般的な項目にはアドレス、ポート、ユーザーID、プロトコル、トランスポート方式、安全設定があります。サブスクリプションはこれらの情報をまとめて取得するためのURLであり、接続そのものではありません。更新に成功したことから分かるのは、設定を取得して解析できたことまでで、リモートサービスへ接続できる保証にはなりません。一方、既存のサーバー情報で接続できるなら、サブスクリプションの更新に失敗しても、使用中の接続にすぐ影響するとは限りません。

プロトコル・トランスポート・セキュリティを個別に確認する

VMess、VLESS、Trojan、Shadowsocksはそれぞれ異なるプロキシプロトコルです。WebSocketやgRPCはトランスポート方式を示し、TLSとREALITYは接続のセキュリティ機構に関係します。これらの項目はサーバー側が指定する組み合わせに従って設定してください。プロトコル名が同じでも、ほかのパラメーターまで一致するとは限りません。たとえばアドレスとポートが正しくても、トランスポートのパス、サービス名、サーバー名が間違っていれば接続時に失敗することがあります。

VLESSは通常、適切なセキュリティ層と組み合わせて使用します。プロトコル自体の設定項目が少ないからといって、すべての接続に暗号化が備わっているわけではありません。VMessでは時刻に関係する認証があるため、端末の時刻も適切に設定してください。REALITYには公開鍵、ショートID、サーバー名などの要件があり、通常のTLSを有効にするだけでは代用できません。プロトコルの違いはVMessとVLESSのプロトコル早わかりで解説しています。

この段階を終えたら、利用中のアプリ、クライアント、カーネル、入口、出口を説明できるようにしておきましょう。まだ設定一式を自分で作る必要はありません。まずはパラメーターの出所が明確な接続を1つ確立し、その後でルーティングや通信の取り込み範囲を広げます。最初から高度な機能をすべて有効にすると、複数の層で同時に問題が起き、どの変更が有効だったのか分かりにくくなります。

第2段階：プラットフォームと設定要件に合わせてクライアントを選ぶ

デスクトップはv2rayN、Androidはまずv2rayNG

クライアントのダウンロードページで、まず端末のOSに合ったプラットフォームを選び、次にCPUアーキテクチャを確認します。Windows、macOS、Linuxのデスクトップではv2rayN、Androidではv2rayNGを第一候補にします。この選び方は、ガイドの手順と実際の画面を合わせやすくするためのものです。同じサブスクリプションでも、すべての環境で同じ機能が使えるとは限りません。必要なプロトコル、トランスポート方式、システムへの通信取り込み方法は、それぞれ確認してください。

Androidでv2flyカーネル向けの設定が必要な場合は、v2flyNGを選択肢として検討できます。接続に一度失敗しただけで、すぐにクライアントを変更しないでください。原因がカーネルの対応状況、サブスクリプションの解析、ネットワーク、権限のどれにあるかを確認しましょう。Androidクライアントを移行するときは、切り戻しに備えて元のアプリと設定を残し、新しい環境で動作を確認してから整理してください。使用できる設定を同時に失うのを防げます。

インストール形式とCPUアーキテクチャは別々に確認する

Windowsのダウンロードページには、v2rayNデスクトップ版と従来のWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用し、WPF版は従来の画面構成を引き継いでいます。メニューの配置や一部のシステム連携方法が異なるため、ガイドを参照するときは使用中の画面の種類を確認してください。新しい画面に同じ名前のボタンが見当たらなくても、機能がないとは限りません。設定やサービスのメニューから該当項目を探してください。

macOSでは「システム情報」でチップを確認し、Apple Siliconならarm64、Intelならx64を選びます。Linuxはアーキテクチャに加えて、ディストリビューションのパッケージ管理方式も確認してください。debとrpmをファイルサイズだけで選ばないでください。新しいAndroidスマートフォンの多くはarm64ですが、CPUが対応していてもOSが同じビット幅で動作するとは限りません。インストールできない場合は、システム情報を確認したうえで汎用パッケージを検討します。

プラットフォームクライアントの選択肢最初に確認する項目
Windowsv2rayNデスクトップ版またはWPF版、OSの対応要件
macOSv2rayNApple SiliconかIntelか
Androidv2rayNG、代替候補はv2flyNGシステムアーキテクチャ、カーネルの互換性
Linuxv2rayNdebかrpmか、x64かarm64か

実際に必要な機能を基準に互換性を確認

サーバー側でVLESSとREALITYの組み合わせが指定されている場合は、クライアントが使用するカーネルが関連項目に対応しているか、インポート後に項目が欠けていないかを重点的に確認します。従来の設定を使う場合も、独自に新しいセキュリティ項目を追加しないでください。設定を移行できるかどうかは、アプリ名の類似性ではなく、双方が同じ項目に対応しているかで決まります。比較するときはプロトコル、トランスポート、セキュリティ層、特殊オプションを記録し、プロトコル名だけで判断しないでください。

端末の日常的な使い方も考慮しましょう。一部のデスクトップアプリだけをプロキシ経由にするなら、システムプロキシやアプリ独自のプロキシ設定から始められます。システムプロキシを参照しないアプリの通信も受け取りたい場合は、TUNを検討します。Androidでは、ほかのVPN系ツールが常時動作していないか確認してください。通常、システムで同時に有効にできるVPNサービスは1つです。必要な通信範囲に応じて適切な方式を選び、機能を最大限有効にすることを基準にしないでください。

最後に、選んだ環境を検証できる形で説明しましょう。たとえば「Androidでv2rayNGを使用し、VPNサービスで選択したアプリの通信を受け取る」と記録します。こうしておけば、インストール、権限設定、トラブル対処の範囲が明確になります。3つのクライアントの違いを比較する場合は、クライアント比較レビューをご覧ください。このガイドでは同じ設定手順に沿って進め、クライアントの変更を既定の修復方法にはしません。

第3段階：クライアントをインストールし、権限の基本状態を整える

Androidへのインストールと初回起動

ダウンロードページでアーキテクチャを選び、システムのインストーラーからインストールファイルを開きます。現在の入手元からアプリをインストールできないという警告が表示された場合は、案内された「不明なアプリのインストール」画面を開き、実際に使用するブラウザーまたはファイル管理アプリに限って一時的に許可します。インストール後は、その入手元に対する許可を無効にできます。警告を回避するためにインストールと無関係なセキュリティ設定を変更しないでください。入手元や用途が分からないまま許可を与え続けるのも避けましょう。

v2rayNGを開いたら、まずメイン画面が正常に表示されることを確認し、通知の権限を確認します。常時表示される通知はサービスの状態確認に役立ちますが、通知の権限とVPNの許可は別です。初めてプロキシサービスを起動すると、システムにVPN接続の確認画面が表示されます。アプリ名を確認してから許可してください。ほかのVPNサービスを使っている場合は、先に停止しましょう。新しいサービスが通信を取り込めない問題を、設定ミスと誤認するおそれがあります。

デスクトップではファイルとシステム連携を確認する

Windowsでは選択した形式に合わせてインストールまたは展開し、アプリが必要とする関連ファイルも残してください。メインプログラムだけを別のフォルダーに移動しないでください。まずは通常のユーザー権限で起動し、管理者権限が必要な機能を有効にするときだけ、クライアントの案内に従って許可します。設定を保存できる場所にインストールしてください。保護されたディレクトリ、同期フォルダー、読み取り専用のメディアでは保存に失敗することがあります。

macOSではアプリケーションフォルダーから起動します。システムのセキュリティ警告が表示された場合は、ファイルの入手元と現在のシステムで許可する方法を確認し、システム保護を一律に無効にしないでください。Linuxではディストリビューションに合ったパッケージ管理方式でインストールし、アプリメニューから起動します。画面が開かない場合は、エラーメッセージとシステムアーキテクチャを記録してください。まだリモート接続の段階ではないため、サブスクリプション、プロトコル、DNSを変更しても起動問題は通常解決しません。

初回接続の前に環境を記録する

クライアントの設定を開き、現在のローカル待ち受けポート、動作モード、ルーティングのプリセットを記録します。バージョンによってポートが異なる場合があるため、実際の画面に表示された値を使ってください。ほかのプロキシソフトがある場合は、そのシステムプロキシ設定と仮想インターフェースによる通信の取り込みを終了してから、新しいクライアントを起動します。古いウィンドウを閉じただけではバックグラウンドサービスが残り、ポートが競合したり、通信が別のプログラムに流れたりすることがあります。

続いて、システムの日時、タイムゾーン、ネットワークが正常か確認します。時刻の自動同期を有効にし、通常のネットワークで必要な基本的なアクセスができることを確かめてください。時刻がずれていると証明書の有効期間を正しく判定できず、ネットワークの認証ページが後続のリクエストを妨げることもあります。現在のネットワークでウェブ認証が必要な場合は、通信の取り込みを停止して認証を済ませてからクライアントを操作します。証明書の検証を無効にして、こうした環境の問題を隠さないでください。

インストール段階の確認項目は、ウェブページが開くかどうかではありません。画面が起動する、設定を保存できる、サービスが必要な権限を要求できる、終了後にシステムのネットワークが元に戻る、の4点を確認してからサブスクリプションをインポートします。ローカルポートの競合が起きた場合は、ローカル待ち受けポートの競合対処を参照してください。先に端末環境を整えることで、起動時の問題とリモート接続の問題を同時に調べる事態を避けられます。

新しい設定のために復旧用の情報も残しておきましょう。もともとシステムプロキシが有効だったか、以前のVPNが自動起動していたかを記録します。共有端末や管理対象端末には、組織が定めたネットワークポリシーが適用されている場合もあります。一般ユーザーが独断で削除しないでください。元の状態に戻すときは、新しいサービスを停止してから以前のネットワーク方式に戻します。複数のクライアントを次々にインストールし、設定を上書きするのは避けましょう。

第4段階：サブスクリプションをインポートし、設定の入手元を管理する

サブスクリプショングループにURLを保存して更新する

v2rayNGのサイドメニューから「サブスクリプショングループ設定」を開き、グループを追加して、識別しやすいメモとサブスクリプションURL全体を入力します。保存したらメイン画面のサブスクリプションメニューに戻り、更新を実行してください。画面によっては更新操作がその他のメニューにある場合もありますが、手順の目的は同じです。まず入手元を保存し、その後に内容を取得します。URLをグループに保存しただけでは、サーバー情報は一覧に表示されません。

URLをコピーしたら、先頭、末尾、途中に空白や改行が混ざっていないか確認します。サブスクリプションURLにはアカウントを識別できるアクセス情報が含まれる場合があり、機密情報として扱う必要があります。スクリーンショット、ログ、問い合わせ文に公開しないでください。URLを見知らぬオンライン変換ツールに直接入力するのも避けましょう。形式変換が必要な場合は、ツールの入手元とデータの取り扱いを確認し、変換後に失われる可能性のあるプロトコル項目も把握してください。

サブスクリプション、共有リンク、完全な設定を区別する

サブスクリプションには通常、複数のサーバー情報が含まれます。単一の共有リンクが記述するのは1つの設定で、カーネル用の完全な設定には入口、出口、ルーティング、DNSが含まれることもあります。これらは同じ種類のインポート対象ではありません。クリップボードから読み込むときは、まずコピーした内容の種類を確認し、適切なインポート方法を選んでください。ウェブページのURLをサブスクリプションとして扱ったり、完全な設定を単一ノードのリンクとして扱ったりすると、解析に失敗したり一覧が空になったりします。

v2rayNでサブスクリプショングループの設定を開き、入手元を追加して保存してから、サブスクリプション更新メニューで情報を取得します。初回は通常の更新方法を使ってください。現在のプロキシ経由で更新する選択肢は、既存のプロキシが利用できる場合に限って適しています。利用できない状態で選ぶと、接続には更新後の設定が必要なのに、更新には接続が必要という循環が発生します。

更新後、サーバー情報の編集画面を開き、サーバー側の情報に照らしてアドレス、ポート、プロトコル、ユーザーID、トランスポート、安全関連の項目を確認します。一覧に表示されるメモは識別用のラベルであり、設定が正しい根拠にはなりません。サーバー側で特定のパス、サービス名、サーバー名が指定されている場合は、大文字・小文字も含めて一つずつ照合します。資料がないままほかの項目を参考に埋めたり、適当にセキュリティ層を切り替えて試したりしないでください。

更新前にバックアップし、更新後に差分を確認する

次回の更新でサブスクリプションの項目が上書きされる場合があるため、重要なパラメーターを長期的に直接編集するのは避けてください。動作を試すときは、まず独立した項目としてエクスポートまたは複製し、入手元を区別できるメモを付けます。動作確認済みの設定を残してから元のグループを更新しましょう。項目の削除、パラメーターの変更、入手元への一時的なアクセス不能が起きても、内容の更新と接続環境のどちらに原因があるか判断できます。

更新に失敗したら、まずエラーの種類を確認します。名前解決の失敗、接続タイムアウト、リモート側のエラー応答、内容の解析失敗のどれでしょうか。URLの期限切れ、権限の変更、ログインページの返却はいずれも更新失敗につながりますが、対処方法は異なります。URLを漏らさないよう注意しながら入手元の状態を確認し、その後で更新経路を変更するか判断してください。すべての設定を何度も消去しても、リモートから返された内容の問題は解決しません。

この段階を終えたら、入手元が明確で必要な項目がそろったサーバー情報を少なくとも1つ残し、サブスクリプション更新で上書きされるかどうかも把握しておきましょう。出所の不明なグループを複数まとめて読み込むのは、ひとまず避けてください。入手元が増えると、重複した情報、異なるパラメーター、期限切れの設定が混在しやすくなります。まず1つの設定を検証し、その後でグループを増やすと、日常のメンテナンスでも追跡しやすくなります。

第5段階：入口とプロキシモードを選び、接続を検証する

システムプロキシとルーティングのプリセットは別の設定

v2rayNでは、まずインポート済みのサーバー情報を現在の設定として選択してサービスを起動し、必要に応じてシステムプロキシを設定します。システムプロキシは、その設定に従うアプリにリクエストの送信先を知らせます。ルーティングのプリセットは、リクエストがカーネルに入った後の出口を決めます。そのため、画面でグローバルルーティングを選んでも、すべてのアプリが自動的にクライアントを経由するわけではありません。システムプロキシを参照しないプログラムは、従来のネットワークを直接使うことがあります。

デスクトップで初回の動作を確かめるときは、まずブラウザーを使います。クライアントのカーネルが正常に起動したことを確認してから、ブラウザーがシステムプロキシを使う状態にし、アクセスできることが分かっている接続先を開きます。ブラウザーではアクセスできてもほかのアプリでできない場合は、サーバーをすぐ変更せず、システム設定を参照しているか、アプリ独自のプロキシ設定があるかを確認してください。入口に通信が届いていないなら、リモートのプロトコルを変更しても通常は効果がありません。

AndroidではVPNモードとプロキシのみのモードを区別する

v2rayNGのVPNモードはAndroidのVPNサービス経由で通信を受け取り、システムにVPNの状態が表示されます。プロキシのみのモードでは通常、ローカルのプロキシ入口が提供されますが、利用するアプリ側で設定が必要です。すべてのアプリが自動的に接続されるわけではありません。初回はガイドに沿ってVPNモードを選び、システムの許可を済ませてから、アプリごとの設定で対象アプリが取り込み範囲から除外されていないか確認してください。

アプリごとのプロキシ設定では、許可リストとバイパスモードも区別してください。バイパスが有効な場合、選択したアプリはVPNを経由しないアプリである可能性があります。バイパスが無効なら、選択したアプリが通信の取り込み対象になる場合があります。チェック状態だけで意味を推測せず、現在の画面に表示される説明を確認してください。リストの変更後は、クライアントの指示に従ってサービスを再起動します。古い接続で以前の経路が使われないよう、テストするアプリも完全に終了してから開き直してください。

遅延だけで判断せず、段階ごとにテストする

接続テストはリモートポートや特定のリクエストだけを確認する場合があり、すべての接続先、プロトコル、名前解決が正常とは限りません。検証では少なくとも、カーネルが動作し続けているか、テスト対象のアプリから新しいリクエストが発生したか、リクエストが想定どおり完了したかを確認してください。まずはアプリ1つ、接続先1つで試し、成功したら対象を広げます。ウェブページが開かない場合は、接続先自体の障害やブラウザーのキャッシュも除外しましょう。

すべてのアプリで失敗する場合は、まずログの起動情報とハンドシェイク情報を確認します。一部の接続先だけで失敗するなら、ルーティング、DNS、接続先側の制限を調べてください。UDPを使うアプリだけに問題がある場合は、クライアントの入口、カーネル、リモート側、ネットワーク経路のすべてが必要な通信に対応しているかを確認します。TCPを使うウェブアクセスに成功しても、ほかの通信が正常とは限らず、端末上のすべてのプロセスが取り込み対象になっている保証もありません。

方式通信を受け取るための条件確認ポイント
デスクトップのシステムプロキシアプリがシステムプロキシ設定に従うローカルポートとアプリ独自の設定
アプリに手動でプロキシを設定アプリに正しい入口を設定するプロトコルの種類、アドレス、ポート
Android VPNシステムの許可を得て、アプリが取り込み対象に含まれている有効なVPNとアプリごとのルール
デスクトップのTUN仮想インターフェースとシステムルートが正常に動作する権限、DNS、バイパス経路

テスト後は終了時の動作も確認します。まずサービスを停止し、システムプロキシが想定した状態に戻っているかを確かめてください。システムが停止済みのローカルポートを参照したままだと、システムプロキシに従うアプリは接続できなくなります。終了後に起きたこの問題を、リモート側の障害と誤認しないでください。起動と停止の両方を確認して基本設定は完了です。続いてルーティングを設定すると、通信の取り込み問題と振り分けの問題を区別しやすくなります。

第6段階：説明できるルーティングとDNSルールを設定する

ルールの順序と出口名を確認する

クライアントのルーティング設定を開き、現在のプリセットを確認してからカスタムルールを追加するか判断します。ルールは通常、上から順に照合され、先に一致したルールが出口を決めると、それ以降のルールは適用されません。そのため、特定のドメインに対する例外は、広い範囲を対象にするルールより前に置きます。まず直結する通信、プロキシ経由にする通信、ブロックする通信を書き出し、その要件をルールに落とし込みましょう。理解していない設定一式をそのままコピーするのは避けてください。

出口のラベルは設定内で参照する名前であり、プロトコル名ではありません。以下の断片はルール構造を説明するためのものです。既存の設定に組み込み、参照先のdirectとproxyが現在の設定に実在する出口ラベルと一致することを確認してください。この断片だけで起動できる完全な設定ではありません。クライアントがグラフィカルなルール編集画面を備えている場合は、次回の保存時に上書きされるリスクを減らすため、同等のルールを画面から作成してください。

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

ドメインの判定方式で、照合時に名前解決するタイミングが変わる

AsIsは受け取ったドメイン名のまま照合し、IPルールのためにアドレスへ変換する処理をできるだけ行いません。IPIfNonMatchはドメインルールに一致しなかった場合に名前解決を試み、その結果をIPルールの照合に使います。IPOnDemandは、アドレス情報が必要なルールの照合時に名前解決を行います。実際に使える項目は利用するカーネルに合わせて確認してください。ルーティングのドメイン判定方式と、出口への接続時に使うアドレス選択の設定を混同しないでください。

入口が受け取るのがIPアドレスだけの場合、ドメインルールだけでは想定どおりに一致しないことがあります。一部のプロトコルでは通信のスニッフィングによって接続先の名前を識別できる場合がありますが、すべてのリクエストからドメインを復元できるとは限りません。DNS設定の誤りを補う方法としても使わないでください。有効にする前に対応範囲とプライバシーへの影響を確認し、変更後はログで実際の照合結果を確認します。ルールの適用可否は、ドメイン名、アドレス、入口から得られる情報によって決まります。

DNSの問い合わせ経路と通常の通信を分けて検証する

DNSの設定を開いたら、まず名前解決を行うのがアプリ、システム、クライアント内蔵のリゾルバー、リモート側のどれかを確認します。DNSサーバーのアドレスを設定しただけでは、問い合わせが必ずプロキシ経由で送られるわけではありません。リゾルバーへの接続経路、ルーティングルール、安全なDNS接続先のドメイン名の解決方法も結果に影響します。特に、まだ確立していない接続にDNSサーバーへのアクセスを依存させ、起動時に名前解決できない循環を作らないでください。

ローカルネットワークのプリンター、管理画面、内部ドメインでは、ローカルでの名前解決と直結が必要な場合があります。リモートのリゾルバーがこれらの名前を知っているとは限りません。まずLAN内のアドレスにアクセスできることを確認し、その後で内部ドメインを個別にテストします。アドレスでは接続できるのに名前で接続できない場合は、プロキシプロトコルではなく名前解決を優先して調べてください。名前解決できてもタイムアウトする場合は、返されたアドレス、出口経路、接続先サービスの状態を確認します。

ルールは一度に1つだけ追加し、一致するはずの接続先と一致しないはずの接続先をそれぞれ1つずつテストします。検証後にルールの位置、出口、名前解決の方法を記録してから、例外を追加してください。ルール一式の価値は、各リクエストがなぜその経路を通るか説明できることです。ルール数の多さではありません。問題が起きたら、検証済みのプリセットに戻し、追加したルールを1つずつ再設定します。

第7段階：VPNとTUNで通信の取り込み範囲を広げる

より広い範囲の通信を取り込む必要があるか確認する

アプリがシステムプロキシを参照しない場合や、より多くの種類の通信を受け取る必要がある場合に、デスクトップのTUNを検討します。TUNは仮想ネットワークインターフェースとシステムルートを通じて通信をプロキシへ渡しますが、サーバー項目の誤りを修正する機能ではなく、リモート側がすべてのプロトコルに対応することを保証するものでもありません。有効にする前に、まずシンプルなシステムプロキシ経由で同じ設定が使えることを確認してください。そうしないと、仮想インターフェースの追加でトラブル対処の範囲がさらに広がります。

AndroidのVPNモードとデスクトップのTUNは、どちらも概念上は仮想ネットワークインターフェースに関係しますが、システム権限、ルーティングの仕組み、メニューの設定は異なります。Androidでデスクトップのドライバーのインストール手順をそのまま使ったり、AndroidのVPN許可をデスクトップの管理者権限と同じものと考えたりしないでください。デスクトップで実際に使えるTUNの動作は、選択したカーネルとクライアントの実装にも左右されます。現在の画面の案内に従って設定してください。

有効にする前に競合と復旧方法を確認する

v2rayNでTUN関連の設定やスイッチを見つけたら、まず権限に関する説明を読み、サービスモードやシステム権限が必要か確認します。ほかの仮想インターフェースによる通信取り込みを停止し、元のシステムプロキシの状態を記録してください。初回テストでは複数の方式で同時にデフォルトルートを変更しないようにします。共存できる場合でも、まずは個別に動作を検証してください。組織の管理下にあるPCでは、既存のネットワークコンポーネントを独断で削除せず、端末のポリシーに従います。

起動後は、仮想インターフェースが作成され、カーネルが動作を続けていることを確認してから、一般のウェブページ、LAN内の機器、実際に使うアプリをテストします。リモートサーバーへの接続が通信の取り込みによるループを回避できないと、リクエストが入口へ繰り返し戻されることがあります。クライアント側で通常は適切に処理されますが、カスタムルーティング、静的ルート、ほかのネットワークソフトが上書きする場合があります。異常が起きたら、まず既定の設定に戻してください。

DNS、UDP、切断後の動作を重点的に確認する

TUNで通信を受け取れても、DNSが想定したリゾルバーを通るとは限りません。アプリが独自の安全なDNSを使う場合や、システムに以前のキャッシュが残っている場合があり、クライアントが別のDNS取り込み方式を提供することもあります。まず明確な名前解決経路を1つ選び、設定を理解する前に複数のリダイレクト機能を同時に有効にしないでください。LAN内の名前が解決できないときは、ローカルでの名前解決が不要にリモートへ送られていないか確認します。

UDPが使えるかどうかは、入口、カーネル、リモート側、ネットワーク経路がすべて対応しているかによります。テストには実際にその通信を必要とするアプリを使い、該当するログを確認してください。ウェブページを一度開いただけで、すべての通信が正常と判断しないでください。一部のアプリだけに問題がある場合は、アプリ独自の制限とトランスポートの問題を区別します。仮想インターフェースの項目を変更する前に元の値を記録し、異なる端末の設定値を根拠なく組み合わせないでください。

Wi-Fiからモバイルネットワークへの切り替えや、PCのスリープからの復帰で、デフォルトルートや名前解決の環境が変わることがあります。切り替え後に接続できなくなったら、まずクライアントのサービスを停止して再起動し、インターフェースを再作成します。その後、古いプロキシ設定がシステムに残っていないか確認してください。端末を再起動しないと復旧しない場合は、切り替え前後のエラーを記録しましょう。何度も再起動する方法を長期的な対処にしないでください。

この段階の最終確認では、サービスを手動で停止します。TUNを終了した後にシステムルート、DNS、通常のネットワークが復旧することを確認し、再起動して同じテストを繰り返してください。LANや基本的なネットワーク接続に影響がある場合は、まずTUNを無効にし、システムプロキシと元のネットワーク方式を復元してから、問題を一つずつ調べます。検証済みのシンプルな入口を比較用に残しておくと、サブスクリプションをすべて再インポートせずに、取り込み層だけの問題か判断できます。

第8段階：バックアップ、更新、日常のトラブル対処

動作確認済みの設定とテスト用設定を分けて保存する

クライアントのエクスポートまたはバックアップ機能で現在の設定を保存し、何が含まれるか確認します。サーバー情報のみが対象で、サブスクリプションの入手元、アプリごとのリスト、ルーティングのプリセットは含まれない場合があります。その場合は、これらの設定も別途記録してください。バックアップファイルにアクセス情報が含まれる可能性があるため、管理された場所に保管し、公開フォルダーへ安易に同期しないでください。復元後は、すべての端末状態が設定と一緒に移行すると考えず、システム権限も改めて確認します。

独立したテスト用の項目には、トランスポートのパラメーターやルーティングの例外を確認するため、など用途が分かるメモを付けます。似た既定のメモだけで区別しないでください。日常的にサブスクリプションを更新するときは項目が置き換わっていないか確認し、クライアントを更新する前に動作確認済みの設定と現在の状態を保存します。アプリの更新、カーネルの切り替え、ルーティングの書き換え、DNSの変更を同時に行わないでください。変更を一度に重ねるほど、問題が起きたときに戻す層を特定しにくくなります。

まず起動ログを確認し、その後に接続ログを見る

サービスを起動できない場合はログを開き、最初に発生した明確なエラーから順に確認します。設定の解析エラー、必須項目の不足、出口ラベルの未定義、リソースファイルの不足、ポートの競合は、リモート接続を試みる前に発生することがあります。起動を妨げる最初のエラーを解決してから再テストしてください。その後に続くエラーは同じ原因から連鎖している場合があり、行ごとに別のパラメーターを変更する必要はありません。

カーネルが正常に起動している場合は、接続タイムアウト、名前解決の失敗、認証エラー、TLSハンドシェイクのエラーを区別します。タイムアウトの原因はプロトコルとは限らず、アドレス、ポート、現在のネットワーク経路から到達できないことも考えられます。認証エラーでは、サーバー側が指定するユーザー情報を確認してください。設定に関するエラーは、カーネル起動失敗時のログ確認の手順に沿って、まず構文と項目を検証し、その後に入口と出口の参照先を調べます。

現象の切り分けに必要な情報だけを集める

問い合わせる前に、OS、クライアント名、動作モード、問題が起きた操作、エラーの原文を記録します。常に発生するのか、ネットワークの切り替え後だけなのかも伝えてください。ログは該当時刻の範囲だけを切り出し、サブスクリプションURL、ユーザーID、パスワード、その他のアクセス情報を隠します。設定ファイル全体を公開しないでください。「失敗」とだけ表示されたスクリーンショットより、主要なエラーの種類と前後のログを残したほうが原因の特定に役立ちます。

証明書エラーが出たら、まずシステムの日時とタイムゾーンを確認し、サーバー名とサーバー側の証明書設定を照合します。「安全でない接続を許可」を既定の修復方法にしないでください。本来解決すべき問題を検証から除外しているだけかもしれません。サーバー側で証明書や名前が変更された場合は、提供されている情報に従って項目を更新します。詳しくはTLSハンドシェイクと証明書エラーの原因をご覧ください。セキュリティ関連の設定を適当に変更して解決を試みないでください。

メンテナンスではアプリのバックグラウンド動作も確認します。Androidで画面ロック後にサービスが停止する場合は、システムのバッテリー制限、バックグラウンド実行、自動起動の設定を確認してください。設定画面は端末によって異なるため、システムの案内に従って調整し、すべてのアプリに一度に権限を与えないでください。デスクトップでスリープ復帰後に動作しない場合は、カーネルと仮想インターフェースが引き続き正常か確認します。むやみに権限を増やすより、問題が起きたタイミングに合わせて調べる層を選びましょう。

メンテナンスのたびに、変更内容、検証内容、復旧方法を簡潔に記録します。機密情報を含める必要はなく、設定名と結果だけを残せば十分です。次に似た現象が起きたら、最近の変更と環境を照らし合わせてから、更新や設定の切り替えを判断します。安定した運用には、再現できる手順と元に戻せる設定が重要です。未検証の最適化を積み重ねないようにしましょう。

第9段階：画面での設定から設定ファイルの読解へ

まず生成された設定を読み、部分的な変更から始める

クライアントの設定表示またはエクスポート機能から、現在有効な設定を開きます。まずは変更せずに読み、入口、出口、ルーティング、DNSの4つに分けて用途を書き込み、画面上の各設定がどの部分に反映されるか確認しましょう。生成された設定にはクライアントが自動で追加した項目が含まれることがあります。ガイドに説明がないという理由だけで削除しないでください。空のファイルから設定一式を書くより、画面上の設定と生成結果の対応を理解するほうが安全です。

設定を読むときは、ラベルの参照、配列の順序、入れ子の階層に注意します。ルーティングから参照する出口ラベルは必ず定義されていなければなりません。同じ名前の項目が別のオブジェクトにある場合、意味が異なることもあります。JSONでは二重引用符、カンマ、括弧も構文の一部です。あるツールがコメントを受け付けても、クライアントの解析器が同じ形式に対応するとは限りません。保存前に現在のカーネルが対応する形式を確認し、異なる形式の設定断片を混在させないでください。

小さな練習でパラメーターを見極める力を身につける

最初の練習ではログレベルだけを調整し、少ない変更で出力の違いを確認します。以下は一般的なログ設定の断片です。完全な設定の該当箇所に追加するもので、単独で起動できるファイルではありません。トラブル対処中は一時的に詳細なログを使い、作業後に通常のレベルへ戻します。詳細なログには接続先のアドレスや接続状況が含まれる可能性があるため、共有する前に必ず内容を確認してください。

{
  "log": {
    "loglevel": "warning"
  }
}

2回目の練習では、既定の出口を変えずに、明確なドメインルールを1つだけ追加します。一致するはずのテスト対象と比較用の対象を用意し、ログまたはクライアントの接続情報から経路を確認してください。ルールが適用されたことを示す情報がない場合、ウェブページが開いたことだけで成功と判断しないでください。異なる出口から同じ接続先へアクセスできる場合もあります。重要なのは、使える結果が得られることだけでなく、仮説を検証することです。

3回目の練習ではDNSの依存関係を整理します。どのコンポーネントが名前を問い合わせ、どこへ問い合わせるのか、問い合わせ自体がどの経路で送信され、返されたアドレスをどの出口が使うのかを書き出してください。こうした関係を数行でまとめ、実際の設定と照合します。一連の流れを説明できるようになってから、ドメインの分類、アドレスファミリーの選択、LAN向けの例外を検討しましょう。複雑にするためだけに名前解決の経路を分割せず、複雑な設定は明確に検証できる要件に対応させてください。

クライアントが生成する設定と独自設定の境界を理解する

設定の保存、サーバー情報の切り替え、サブスクリプションの更新後に、動作設定を再生成するクライアントがあります。一時的に生成されたファイルを直接編集すると、次回起動時に変更が消える場合があります。長期的に使う設定は、まずグラフィカルな画面から保存してください。独自設定を使う場合は、クライアントがどのように起動、更新、バックアップを行うか確認します。互いに上書きし合う設定元を同時に管理すると、画面の表示と実際の動作が食い違うおそれがあります。

カーネルの切り替えも、独立したテストとして行います。対象のカーネルが対応するプロトコル、安全関連の項目、ルーティング構文を確認してから設定を複製して試し、現在使える経路は上書きしないでください。項目名が同じでも、動作の細部まで一致するとは限りません。互換性の問題が起きたら、元のエラーと最小限の再現用設定を残します。必要な構造だけ残して機密情報を置き換え、問題の再現のために実際のサブスクリプションやアクセス情報を公開しないでください。

次の学習は、目的に合わせて入口を選んでください。初回接続の手順をもう一度確認する場合は、クイックスタートガイドへ。具体的なエラーが発生した場合は、よくある質問と関連する技術記事を参照してください。設定項目が分からない場合は、用語集で確認できます。すべてのパラメーターを一度に覚える必要はありません。まずは現在の端末で必要な設定を実現して検証し、その後で段階的に拡張すると、長期的に読みやすく、保守しやすく、復旧しやすい設定を保てます。