V2Rayを基礎から理解する
クライアント設定完全ガイド

ステップ1 · 基礎を理解する

基礎知識：通信の流れを把握する

V2Rayは複数のプロキシ技術を指す総称として使われることがありますが、実際に利用する際はGUIクライアント、プロキシコア、接続設定、リモートサーバーを区別する必要があります。GUIクライアントはサブスクリプションの登録、設定の保存、コアの起動を担当します。コアは接続を受け付け、ルーティングを判定して、接続先へ通信を転送します。画面に「起動中」と表示されても、ローカルのプロセスが動作していることしか確認できません。リモートサーバーへの接続や、ブラウザーからの通信がクライアントに届いていることまでは保証されません。

クライアント・コア・サーバー

V2Rayのエコシステムを理解するには、まずProject Vを知るとよいでしょう。V2FlyはV2Ray関連の開発を引き継ぎ、Xrayは別のコア実装として発展しています。共通する概念はありますが、対応機能や設定項目は完全には一致しません。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けのGUIクライアントです。どのクライアントを選んでも、すべてのプロトコルが使えるわけではありません。実際に動作するコアと、その対応範囲を確認してください。

通信は、アプリ、入口、ルーティング、出口の4段階に分けて考えられます。最初にアプリがプロキシを使うかどうかを決めます。入口はローカルのHTTP／SOCKS待受ポートや仮想ネットワークインターフェースです。ルーティングはドメイン名やIPアドレスなどの条件で出口を選び、出口が接続設定を使ってサーバーへ接続します。どこか1か所でも設定が合わなければ通信に問題が起きるため、トラブル時はノードを次々に変更するのではなく、この経路に沿って順番に確認しましょう。

プロトコル・トランスポート・セキュリティ設定

VMessやVLESSはプロキシプロトコル、TCPやWebSocket、gRPCは接続を運ぶトランスポート方式、TLSやREALITYは接続のセキュリティに関する仕組みです。これらは自由に置き換えられる同じ種類の設定ではありません。登録後は、提供元が指定した組み合わせを維持してください。トランスポートを別の方式に変更したり、名前だけを見てセキュリティ設定を追加したりしても、通常は接続が改善せず、クライアントとサーバーのハンドシェイク条件が合わなくなることがあります。

同じ接続設定でも、サーバーアドレス、接続ポート、ユーザーID、サーバー名、トランスポートのパスはそれぞれ役割が異なります。サーバー名はセキュリティハンドシェイクに使われることがあり、アドレス欄のホスト名と一致するとは限りません。パスは特定のトランスポート方式で使うもので、アドレス欄に入力する値ではありません。項目を確認する際は、まずどの層の設定なのかを把握し、該当する設定画面を確認してください。項目の意味が分からない場合は、検索で見つけた設定例を上書きするのではなく、接続情報の提供元に問い合わせましょう。

サブスクリプションとローカル設定の違い

サブスクリプションは接続情報をまとめて取得するためのもので、それ自体が接続中の状態を示すわけではありません。更新後、クライアントで接続先を選び、サービスを起動するかシステムプロキシを設定する必要があります。サブスクリプションのURLにアクセスできても、登録されたすべてのサーバーに接続できるとは限りません。逆に、以前の設定で接続できているなら、サブスクリプションの更新失敗だけでプロキシコアの故障とは判断できません。両者の通信経路が異なる場合もあります。

ローカルの待受ポートはアプリがクライアントへ接続する入口で、リモートポートはクライアントがサーバーへ接続する際の宛先です。両者が同じである必要はありません。たとえばローカルポートが10808と表示されていても、それを理由にサブスクリプションのリモートポートを変更してはいけません。また、待受ポートがどのプロトコルに対応しているかも確認してください。バージョンによってHTTPとSOCKSで別々のポートを使う場合と、複数のプロトコルに対応するポートを使う場合があります。現在のクライアント設定を確認してください。

ステップ2 · 使用するクライアントを決める

クライアント選び：プラットフォームとコアを確認

まず利用するプラットフォームに合ったクライアントを選び、その後に画面やコアを確認します。デスクトップではv2rayN、Androidではv2rayNGから始めるのがおすすめです。V2Flyコア固有の動作が必要な場合や、特定の設定との互換性が必要な場合に限り、v2flyNGを検討してください。複数のクライアントをインストールしても、自動的に接続の選択肢が増えるわけではありません。使い始めはメインのクライアントを1つに絞ると、設定元を把握しやすくなります。

デスクトップ版のバージョンとアーキテクチャ

Windows版v2rayNには、デスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用し、従来のWPF版は異なるレイアウトを引き継いでいます。選ぶ際は、システム要件、使い慣れた操作方法、必要な機能を確認してください。2つの配布版は、異なるプロキシプロトコルを意味するものではありません。どちらも接続情報を読み込み、コア、待受ポート、プロキシモードを確認する必要があります。画面に慣れていることだけで、設定が正しいとは判断できません。

macOSでは、まずシステム情報でチップの種類を確認し、Apple SiliconまたはIntel向けの配布版を選びます。LinuxではCPUアーキテクチャとディストリビューションのパッケージ形式を確認します。一般的にはdebまたはrpmを選び、arm64デバイスでは対応するアーキテクチャのパッケージを選択してください。パッケージ形式とCPUアーキテクチャは別々の条件です。片方しか合っていない場合、正常にインストールまたは起動できないことがあります。

Android版の2つのコア

v2rayNGは主にXrayコアを使用し、v2flyNGはV2Flyコアを使用します。外観や一部の操作が似ていても、すべてのインポート形式やプロトコル拡張に互換性があるとは限りません。コア固有の機能を使う設定の場合は、事前に対応状況を確認してください。項目がインポート後に消える、認識されない、接続できない場合は、まずコアと設定形式の互換性を確認しましょう。すぐにサーバーが使えないと判断する必要はありません。

Androidのインストールパッケージでは、arm64版が比較的新しい多くの端末に適しています。アーキテクチャが分からない場合はユニバーサル版を選ぶ方法もありますが、最終的にはアプリの要件を確認してください。購入時期だけで端末のアーキテクチャを判断せず、システム情報や端末の仕様を確認しましょう。パッケージのサイズは機能の多さを示すものではありません。ユニバーサル版は通常、より多くのアーキテクチャに対応するためのもので、通信速度が速くなるわけではありません。

複数クライアントの同時使用による干渉を防ぐ

クライアントを切り替えるときは、以前のツールを終了してから新しいツールを起動してください。デスクトップでは複数のプログラムがシステムプロキシ、同じ待受ポート、仮想ネットワークインターフェースを取り合うことがあります。AndroidではVPN権限も既存の接続に影響します。ウィンドウを閉じただけでは、バックグラウンドプロセスが終了していない場合があります。タスクトレイ、通知欄、アプリの状態を確認してください。クライアントを比較するときは、同じネットワークと同じ接続情報を使い、回線の違いをソフトウェアの差と取り違えないようにしましょう。

ダウンロード前に3つのクライアント比較レビューを確認できます。インストールファイルはクライアントダウンロードページから入手してください。このガイドでは、特定のパッケージ名やバージョン番号を覚えるのではなく、利用中のプラットフォーム、CPUアーキテクチャ、クライアント、コアを説明できることを重視します。トラブル時には、この4つの情報が「最新版に更新済み」という説明よりも原因の特定に役立ちます。

ステップ3 · ローカル環境を整える

導入と基本設定：ローカルで動作するか確認

導入段階では、すぐに高度な設定を変更する必要はありません。プログラムが正常に起動すること、設定が保存されること、ローカルポートが競合していないことを確認します。まずダウンロードページでプラットフォームごとのシステム要件を確認し、通常の手順でインストールしてください。初回起動後はデフォルトのルーティングとDNS設定を維持し、TUNはまだ有効にしないでください。接続に失敗した場合も、複数のネットワーク制御機能を同時に調べず、基本的な通信経路に原因を絞り込めます。

デスクトップ版を起動する前の確認

Windowsのインストーラーを使う場合は、画面の指示に従って保存先を選び、インストールを完了します。解凍が必要な形式の場合は、すべてのファイルを展開してから起動してください。圧縮ファイルのプレビュー画面から直接実行しないでください。設定フォルダーは書き込み可能な場所に置き、一時フォルダーや自動的に削除される場所は避けましょう。実行コンポーネントが不足しているという警告が出た場合は、クライアントのシステム要件と具体的なエラーを確認してください。出所不明の同名ファイルを追加してはいけません。

macOSでは、インストール後に通常のアプリ起動方法で起動してください。セキュリティ警告が表示された場合は、ダウンロード元と警告内容を確認し、システムが案内する手順で対応しましょう。インストールのためだけにセキュリティ機能を全体的に無効にすることはおすすめしません。Linuxではディストリビューションに対応したパッケージ管理ツールを使い、依存関係の警告やデスクトップ環境を確認します。インストール後にウィンドウが表示されない問題と、コアの起動失敗は別です。まずメインプログラムから設定画面を開けるか確認してください。

ローカル待受と基本スイッチ

基本設定を開き、ローカルの待受アドレス、ポート、入口の種類を記録します。通常の単独利用ではループバックアドレスだけで十分です。「LANからの接続を許可」は有効にする必要はありません。ほかのプログラムが使用していない限り、ポートはクライアントの初期値のままにできます。バインドに失敗した場合は、ポートを変更する前に重複起動したクライアントやほかのプロキシツールを終了してください。ローカルポートを変更したら、手動でプロキシを設定したアプリも同じ値に変更します。システムプロキシの場合は、設定を再適用してください。

「UDPを有効にする」と「トラフィックをスニッフィングする」は、万能な速度向上スイッチではありません。UDPが使えるかどうかは、アプリの入口、ルーティング、サーバー、通信経路全体の対応状況に左右されます。スニッフィングは接続情報の一部から宛先を推定する機能であり、すべての通信を識別できるわけではありません。基本設定の段階では現在の値を記録し、明確な必要が出てから変更しましょう。設定の保存後にサービス再起動を求められた場合は、現在の接続を停止してから指示に従って再起動してください。

Androidのインストール後に必要な権限

Androidへのインストール後は、まずアプリを開き、設定を保存できることを確認してから接続情報を登録します。VPNモードで初めて接続すると、システムの許可ダイアログが表示されます。これはクライアントにローカルの通信経路を制御させるための許可であり、リモートサービスの購入を意味するものではありません。許可しない場合、設定が登録済みでもVPNモードでアプリの通信を制御できません。ほかのVPNが動作中の場合は切断してください。別のアプリに切り替わった後も、現在のクライアントが動作中だと誤認するのを防げます。

バッテリー管理やバックグラウンド制限により、Androidクライアントが画面ロック後に停止することがあります。ただし、インストール直後にすべての省電力設定を変更する必要はありません。まず前面で接続テストを行い、動作を確認してください。その後、「画面ロック後に切断される」場合にバックグラウンド権限を確認します。アプリごとのプロキシ設定も、最初は対象を絞ってシンプルに保ちましょう。開始時から対象アプリを大量に追加すると、サービスの停止と、テスト対象が通信制御から除外されている状態を区別しにくくなります。

初期状態を記録する

基本環境を整えたら、クライアント名、OS、待受ポート、現在のスイッチ設定を記録します。設定をエクスポートまたはバックアップする場合、接続情報が含まれることがあるため、ファイル全体を公開の掲示板に投稿しないでください。プログラムを終了して再度開き、設定が保持されていることを確認します。再起動するたびに設定が消える場合は、インストールのやり直しではなく、フォルダーへの書き込み権限やシステムによる自動削除を確認してください。

ステップ4 · 接続情報を取得する

サブスクリプションの登録：更新・選択・接続を区別する

サブスクリプションURLにはアカウントを特定できる情報が含まれることがあるため、認証情報と同様に扱い、公開のスクリーンショットやフォーラムへの投稿は避けてください。コピーする際は、サブスクリプション用のURLであることを確認します。アカウント管理ページ、ヘルプページ、ブラウザーでログインした後のページURLではありません。すべてのクライアントで共通して使えるサブスクリプション形式はありません。提供元がクライアント別の形式を用意している場合は、対応する形式を選びましょう。登録できてもプロトコル関連の項目が失われることがあります。

デスクトップ版でサブスクリプショングループを作成

v2rayNのサブスクリプショングループ管理からグループを追加し、分かりやすい名前とサブスクリプションURLを入力して保存した後、更新を実行します。グループ名はローカルで整理するためのもので、サーバー側の設定は変わりません。更新後、グループ内に選択できる項目が表示されるか確認し、そのうち1つを現在の接続設定として選びます。「グループを保存した」ことは「サブスクリプションを更新した」ことを意味しません。また、一覧に項目が表示されても「接続済み」とは限りません。

初回の更新では、可能であれば現在利用できる通常のネットワーク経路を使います。プロキシ経由でアクセスする必要がある場合は、まず利用可能な接続を1つ確立し、クライアントが提供するプロキシ経由の更新方法を使ってください。接続を確立する前から、まだ動作していないプロキシ経由でサブスクリプションを更新しようとすると、循環依存が起きることがあります。ネットワークの制限が疑われる場合は、URLのパラメーターを適当に書き換えるのではなく、提供元に接続先への到達性を確認してください。

Android版で登録・確認する

v2rayNGとv2flyNGでは、それぞれのサブスクリプション管理画面から接続情報を追加できます。メニュー名はバージョンによって異なるため、現在の画面で確認してください。更新後は接続先一覧に戻り、使う項目を選択してから接続を開始します。クリップボードからの登録、QRコードの読み取り、サブスクリプションの更新は別の操作です。前の2つは単一の接続先を追加するだけで、その後の自動更新にはつながらない場合があります。継続的に情報を取得したい場合は、一度限りの登録ではなく、サブスクリプショングループに保存されていることを確認してください。

登録後は、プロトコル、アドレス、ポート、トランスポート方式、セキュリティ設定がそろっているか確認します。接続先の名前は提供元が任意に設定できるため、名前だけでは設定の一致を確認できません。同じ項目が重複している場合は、すぐにすべて削除せず、まずグループごとに登録元を確認します。トランスポート設定だけが異なる項目もあります。手動で修正する場合は、別の接続設定としてコピーするのがおすすめです。次回の更新で変更が上書きされ、原因を再現できなくなるのを防げます。

更新失敗の原因を段階的に確認する

更新時に解析エラーが返る場合は、応答がクライアント対応のサブスクリプション形式になっているか確認してください。URLの有効期限切れ、アカウントへのログイン要求、ウェブサイトの認証ページなどにより、「URLにはアクセスできるが解析できない」ことがあります。接続がタイムアウトする場合は、まずネットワークと名前解決を確認します。ウェブページの内容を設定欄に貼り付けたり、一般的な形式変換で元の情報を上書きしたりしないでください。変換によって、特定のコアに必要な拡張項目が失われることがあります。

更新後に登録済みの接続先が減っても、ローカルデータの破損とは限りません。提供元が配信内容を変更した可能性があります。まず以前の設定がまだ動作するかを記録し、グループと更新日時を確認してください。何度もすべて削除して登録し直すと、比較に必要な情報を失います。古い項目では接続できるのに新しい項目がすべて失敗する場合は、プロトコル、トランスポート、セキュリティ設定を比較し、クライアントのコアが変更後の設定に対応しているか確認しましょう。

サブスクリプションの安全性と管理

サブスクリプションの提供元は、配信する接続情報を変更できます。提供元が明確で、必要なものだけを登録してください。グループを削除する前に、独立した接続設定を残す必要がないか確認します。端末を移行する場合も、表示名だけをコピーするのではなく、クライアントが対応するエクスポートや再登録の方法を使いましょう。サブスクリプションURLを公開してしまった場合は、提供元の管理画面で該当する認証情報を変更してください。ローカルのグループ名を変えても、以前のURLは無効になりません。

ステップ5 · アプリの入口を確認する

プロキシモード：システム設定とアプリの動作

プロキシモードで確認するのは「アプリがどのようにクライアントへ通信を渡すか」です。一方、ルーティングモードは「受け取った通信をどこへ送るか」を決めます。この2つは分けて考えましょう。システムプロキシを有効にして「中国本土を除外」を選んでも、すべてのアプリがクライアントを経由するわけではありません。仮想ネットワークで通信を制御しても、すべての宛先がリモートサーバー経由になるとは限りません。まずアプリの入口を確認すると、その後のルーティングやDNSの調査を進めやすくなります。

デスクトップのシステムプロキシが適用される範囲

v2rayNでシステムプロキシを自動設定すると、通常は現在のOSやデスクトップ環境のプロキシ設定が変更され、その設定を参照するアプリに適用されます。ブラウザーは設定を読み込むことが多い一方、ダウンローダー、ゲーム、コマンドラインツールなどは独自のネットワーク設定を使う場合があります。システムプロキシが有効と表示されているのに特定のアプリだけ直接接続する場合は、そのアプリがシステムプロキシを使用するか確認してください。すぐに接続先を変えたり、全般的なルーティングを有効にしたりする必要はありません。

アプリにプロキシを手動設定する場合は、クライアントが実際に待ち受けている入口の種類、アドレス、ポートを指定します。ポート番号だけを見てHTTPとSOCKSを判断してはいけません。複数のプロトコルに対応する入口も、現在のバージョンで実際に利用できるか確認してください。同じ端末内で試す場合は、通常ループバックアドレスを指定します。アプリに「ローカルアドレスを除外する」「独自のDNSを使用する」といった設定がある場合も通信経路が変わることがあります。まず現在の値を記録し、プロキシ設定が明確なアプリで動作を確認してください。

制御しやすいリクエストで入口を確認

以下のコマンドはcurlがインストール済みの環境でのみ使用してください。ポート番号は事前にクライアントの設定と照合します。ローカルのSOCKS入口を明示的に使用し、接続先のドメイン名をプロキシ側で処理します。システムプロキシやサブスクリプションの設定は変更しません。例の接続先は公開テストサイトですが、結果は現在のネットワーク環境にも左右されます。指定したポートでSOCKSが待ち受けていない場合は、実際の入口に合わせてください。コマンドをそのまま実行して失敗しても、クライアントの故障とは限りません。

curl --proxy socks5h://127.0.0.1:10808 --head --connect-timeout 10 https://example.com

プロキシを明示したリクエストが成功し、ブラウザーからアクセスできない場合は、ブラウザーのプロキシ設定、拡張機能、キャッシュ、独自のネットワーク設定に原因がある可能性が高くなります。どちらも失敗する場合は、クライアントのログにリクエストが記録されているか確認しましょう。該当するリクエストがログにない場合は、まずローカルの入口を調べます。リクエストが記録されていて、出口への接続に失敗している場合に、リモートサーバー、ルーティング、名前解決を確認してください。テスト対象と時刻を固定し、別々のリクエストのログを混同しないようにしましょう。

AndroidのVPNモードとアプリごとのプロキシ

AndroidのVPNモードでは、OSの機能を通じて通信を制御するため、通常のブラウザーにループバックプロキシを手動設定する必要はありません。アプリごとのプロキシ設定では、どのアプリを対象にするか、どのアプリを除外するかを指定します。対象を含める方式か除外する方式かは、現在の画面の説明を確認してください。テストするアプリが除外されていると、通知欄に接続中と表示されても、想定した経路を通りません。対象リストを変更した後は、必要に応じてクライアントの案内に従って再接続してください。

アプリの通信が制御されているかを判断する際は、ページが開くかどうかだけで決めないでください。直接接続でも表示できる場合があります。クライアントのログと、条件を絞ったリクエストを組み合わせて確認しましょう。Androidアプリにはバックグラウンドプロセス、アプリ内ブラウザー、独立したサービスがあり、同じアプリ名でも通信経路が異なることがあります。まずシンプルなブラウザー環境で基本経路を確認してから、特定のアプリを調べると、ログイン状態やバックグラウンドキャッシュによる誤判定を減らせます。

終了と復元方法も確認する

デスクトップで利用を終えるときは、システムプロキシが解除または元の状態に戻っていることを確認します。プロセスを強制終了しただけでは、システムが接続を存在しないローカルポートへ送り続ける場合があります。その場合、すべてのサイトにアクセスできなくなっても、ネットワーク自体が切断されたとは限りません。AndroidではVPN接続が切断されていることを確認してください。新しいモードを試す前に、元のモードの終了方法を把握しておきましょう。モードを切り替えた後は、既存の接続が再利用されて結果が食い違わないよう、影響を受けるアプリを再起動してください。

ステップ6 · 接続先を制御する

ルーティングとDNS：ルールと名前解決の連携

ルーティングは通信がコアに届いた後、ドメイン名、宛先アドレス、ポートなどの条件に基づいて出口を選びます。クライアントの「中国本土を除外」「全般」などのプリセットは、ルールを設定するための選択肢であり、プロトコルそのものではありません。「全般」は通常、制御対象の通信にプロキシ出口を使う設定ですが、アプリの入口やプリセットの例外の影響は受けます。接続が必ずリモートサーバーへ送られるとモード名だけで判断せず、実際のルール適用結果を確認してください。

ルールの順序とマッチ条件

多くのルーティングルールは上から順に判定されます。特定の接続に対するルールは、それを上書きする可能性のある広いルールより前に置きましょう。たとえば、特定のドメインを直接接続する例外を追加する場合、既存のルールが先に一致していないか確認します。ドメインルールの判定には、コアが宛先ドメイン名を把握している必要があります。アプリからIPアドレスだけが渡され、入口でドメイン名が保持されていない場合、ドメインルールを追加しても効果がないことがあります。スニッフィングは一部の場面で識別を補助しますが、すべての接続情報を代替するものではありません。

以下はXrayのルーティングオブジェクトの一部を抜粋した例です。特定のドメインを指定するルールの書き方を示すもので、クライアント設定全体ではありません。完全な設定にdirectという名前の出口が存在する場合に限り、このルールが有効になります。GUIクライアントはルーティングや出口のタグを自動生成することがあるため、この断片を任意の入力欄に貼り付けないでください。まずカスタムルール画面で同じ条件を設定し、生成された内容を確認しましょう。

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

V2RayのDNS設定と各層の関係

DNSはクライアントの設定画面にあるサーバー一覧だけではありません。OSのリゾルバー、ブラウザーの暗号化DNS、アプリ内部の名前解決、コアのDNS機能がリクエストに関与する場合があります。アプリが先に名前解決してから接続すると、コアは元のドメイン名を認識できないことがあります。アプリがドメイン名をプロキシに渡す場合は、別の場所で名前解決される可能性もあります。DNSを変更する前に、現在の入口がドメイン名とIPアドレスのどちらを渡しているか確認してください。すでにアプリが済ませた名前解決に影響すると期待して、コアのDNS設定だけを変更するのは避けましょう。

コアによるDNSリクエストにも、利用可能なネットワーク経路が必要です。DNSサーバーへの接続にプロキシが必要なのに、プロキシサーバーのドメイン名を解決するにも同じDNSサーバーが必要な場合、起動時に依存関係の循環が発生することがあります。基本的なトラブルシューティングでは、まずクライアントの初期設定に戻し、サーバーアドレスを解決できることを確認してから、直接接続先とプロキシ接続先を個別に調べましょう。OSのDNS、ブラウザーの暗号化DNS、コアの設定を同時に変更すると、どの層で改善したのか分かりにくくなります。

ドメイン解決ポリシーは万能な最適化設定ではない

AsIsやIPIfNonMatchなどのポリシーは、ルーティング時にアドレスルールと照合するため、ドメイン名をIPアドレスへ解決するかどうかに影響します。単純に「速い」「遅い」を示すものではありません。コアや設定場所によって意味が異なる場合もあります。IPアドレスのルールを使う場合は、解決結果が想定した出口に適しているか確認します。ドメインルールを使う場合は、ドメイン情報が利用できることを確かめてください。見た目に積極的なポリシーを選ぶより、ルールの目的を明確にすることが重要です。

IPv6も個別に確認しましょう。ネットワークから2種類のアドレスが返されても、その一方の経路に到達できない場合があります。その結果、接続に時間がかかったり、一部の宛先だけ失敗したりします。まずログに記録された名前解決と接続のエラーを比較し、その後でアドレス選択の設定を変更してください。特定のアドレス種別を全体で無効にする方法が、あらゆる問題を解決するとは限りません。設定変更後は同じ宛先へ新しく接続して確認します。既存の長時間接続やキャッシュには、変更がすぐ反映されない場合があります。

ステップ7 · 通信制御の範囲を広げる

TUNモード：有効化の条件と復元方法

TUNは仮想ネットワークインターフェースを使って、対象の通信を処理経路へ送ります。システムプロキシの設定に従わないアプリも含めて一括で制御したい場合に便利です。ただし、通信の入口を広げる機能であり、誤った接続情報を修正したり、すべてのプロトコルやネットワーク環境に対応させたりするものではありません。有効化する前に、同じ接続が基本モードで動作することを確認してください。システムプロキシ経由ですでに通信に失敗している場合は、TUNで問題を包み込むのではなく、まず設定を調べましょう。

機能と権限を事前に確認する

デスクトップ版v2rayNのTUN実装、利用可能な設定、必要な権限は、プラットフォーム、クライアント、使用するコアによって異なります。まず設定画面にTUN機能が実際にあるか、必要な権限についてどのような案内が表示されるかを確認してください。管理者権限やシステムの許可が必要な場合は、通常の手順で許可します。トラブルシューティングのためだけに、クライアントを常に高い権限で実行するのは避けてください。該当する設定がない場合は、別のプラットフォームのメニューや設定項目を流用しないでください。

有効にする前に、別の仮想ネットワークインターフェース、ネットワークフィルターの競合設定、既存のプロキシ接続など、通信を制御するほかのツールを終了します。複数の制御機能を重ねると、デフォルトルートが上書きし合う、DNSリクエストが重複処理される、通信が入口に戻るといった問題が起きることがあります。2つのスイッチがどちらも有効と表示されても、互換性があるとは判断できません。まずツールを1つだけ使った状態で動作を確認し、必要な場合に限って併用できるかを順番に検証しましょう。

順番に有効化を試す

1. 現在のシステムプロキシ、ルーティングモード、DNS設定を記録し、クライアントを正常に終了できることを確認します。
2. 動作を確認済みの接続先を選び、現在のプラットフォームの案内に従って権限を許可し、TUNを有効にします。
3. まず通常のウェブページを確認し、次にシステムプロキシに従わないアプリを試して、関連するログを確認します。
4. ローカルネットワークサービスや必要な業務用接続を確認し、誤って通信制御の対象になっていないことを確かめます。
5. 無効化のテストを行い、仮想インターフェースとシステムネットワークを元に戻せることを確認してから、継続利用を決めます。

この手順では、変更前の状態を比較基準として残すことが重要です。有効化後すぐにルーティング、DNS、接続先を同時に切り替えず、通信制御の範囲が実際に変わったことを確認してください。クライアントの説明にシステムプロキシとTUNの併用が必要とある場合は、その実装の手順に従います。互いに独立した機能の場合は、経験だけを頼りに無理に併用しないでください。プラットフォームごとに実装は異なるため、特定の環境で成功した組み合わせが常に使えるとは限りません。

ローカルネットワークとDNSの例外

LAN内の端末、プリンター、社内ドメイン、リモートワーク用の接続は、ローカルルートや専用のDNSに依存する場合があります。TUNを有効にしてこれらのリソースだけ使えなくなった場合は、すべての通信をプロキシに変更するのではなく、ローカルアドレスや社内ドメインの除外ルールを確認してください。社内ドメインの名前解決結果はネットワークによって変わることがあり、アドレスを固定しても長期的に使えるとは限りません。業務ネットワークに関する設定は、ネットワーク管理者の指示に従ってください。

DNSの制御も、原因を切り分ける際の重要なポイントです。有効化後にすべてのドメイン名で失敗する一方、IPアドレスへの接続は成功する場合は、名前解決の経路を重点的に確認します。ローカルゲートウェイや以前から使えていた直接接続まで失敗する場合は、ルーティング制御とインターフェースの状態を先に確認してください。原因が分からないまま仮想インターフェースを何度も再インストールしないでください。まずTUNを無効にして以前の状態に戻します。それで復旧すれば、新たに追加した通信制御層に原因を絞り込めます。

AndroidのVPNモードとデスクトップのTUNの違い

AndroidクライアントのVPNモードも、仮想ネットワークインターフェースを通じて通信を制御します。ただし、権限、アプリごとの設定、システム制限はAndroidの仕組みで管理されるため、デスクトップのTUN設定をそのまま適用することはできません。画面ロック後の切断、別のVPNによる占有、アプリリストが反映されないといった問題は、Androidの設定に戻って確認してください。概念として入口の役割を比較することはできますが、操作は個別に行います。Androidの画面にデスクトップと同じスイッチがある必要はありません。

ステップ8 · 再現可能な状態を保つ

日常のメンテナンス：速度測定・ログ・アップデート

日常のメンテナンスでは、一覧の最小値を追い求めるのではなく、設定の状態を把握できるように保つことが大切です。速度測定の結果は、ローカルネットワーク、リモート側の状態、接続先サイト、測定方法によって変わります。クライアント、サブスクリプション、ルール用データの更新もそれぞれ別の操作です。クライアントの更新はプログラムや機能を変更し、サブスクリプションの更新は接続情報を変更し、ルールデータの更新は判定条件を変更します。一度に1種類だけ変更すると、問題が起きた際に戻す箇所が明確になります。

V2Rayのノード速度測定で確認すること

TCP接続テストで分かるのは、主に宛先ポートへ接続できるかどうかです。プロトコルのハンドシェイクやウェブページの表示まで保証するものではありません。プロキシ経由でテストサイトにリクエストを送ると実際の通信に近い確認ができますが、その結果は接続先と測定時の環境に限られます。転送速度はテストファイル、同時接続数、サーバー側の速度制限、ローカルの帯域にも左右されます。接続先を比較する際は、同じ方法、近い時間帯、同じネットワークで測定してください。異なる種類のテスト結果を並べて直接比較しないようにしましょう。

日常利用では、まずよく使う接続先が安定しているかを確認し、その後に接続時間と継続的な転送速度を見ます。ウェブページの表示が遅いのにファイル転送は正常な場合は、DNS、接続確立、ページが読み込む外部リソースなどが原因かもしれません。特定のサイトだけ遅く、ほかの接続先が正常なら、接続先までの経路を確認してください。一度タイムアウトしただけですべての設定を削除したり、1回成功しただけで問題が解消したと判断したりしないでください。測定ツールを頻繁に切り替えるより、再現可能なテスト対象を少数決めておくほうが有効です。

通信経路に沿ってログを読む

ログでは、まずリクエストがコアに届いているかを確認し、その後で出口の状態を調べます。テストした時刻、宛先、入口に一致する記録を探してください。ローカル待受のエラーはポートや権限、名前解決エラーはDNSが関係している可能性があります。接続拒否、タイムアウト、セキュリティハンドシェイク失敗は、それぞれアドレス、ネットワーク、プロトコル、セキュリティ設定を確認します。エラーメッセージの同じ文言でも原因が複数あるため、前後のログも含めて判断してください。一行だけを見て決まった修正方法を当てはめないようにしましょう。

ログの詳細度を一時的に上げた場合は、テストが終わったら通常のレベルに戻してください。機微なアクセス記録が長期間残るのを防げます。ログを共有する前に、サブスクリプションURL、ユーザーID、トークン、個人用ドメイン、アカウントを特定できる情報を削除し、必要なエラーの種類と発生時刻だけを残します。スクリーンショットにはクリップボードの通知やほかの接続先名が写ることもあるため、公開前に確認してください。公開の場でのトラブル相談に認証情報は不要です。共有すると、その後の管理負担が増えるおそれがあります。

更新前に復元可能な状態を残す

クライアントを更新する前に、使用中のコア、プロキシモード、カスタムルールを記録し、クライアントが対応する方法で必要な設定をバックアップしてください。バックアップは管理された場所に保存し、公開フォルダーへ直接同期しないでください。更新後は元のモードを維持したまま、以前使えていた接続を確認してから新機能を有効にします。更新後に特定の接続だけ失敗した場合は、関連機能や生成された設定の変更を比較しましょう。すぐにリモート側の情報全体を変更する必要はありません。

再現できるトラブル内容を記録する

「接続できない」という問題は、サブスクリプション更新の失敗、サービスが起動しない、リクエストが入口に届かない、出口のハンドシェイク失敗、特定の宛先だけの異常に分けられます。OS、クライアント、コア、現在のモード、発生条件、直近の変更を記録し、プロキシを無効にすると復旧するかも書き留めてください。こうした情報があれば現象を再現でき、次に変更する設定を判断しやすくなります。速度の問題はノード・回線・ローカル設定を分けたトラブルシューティングも参考にしてください。

ステップ9 · 必要な機能を追加する

上級者向けの学習ルート：動作する設定から検証可能なルールへ

上級設定とは、すべてのスイッチを有効にすることではありません。必要な機能を明確にしたうえで、検証可能な項目を1つずつ追加することです。最初の8章を終えた段階で、安定した基準設定を持ち、リクエストの入口、ルーティング、名前解決の場所、終了と復元の方法を把握しているはずです。次は、プロトコルの理解、カスタムルーティング、名前解決ポリシー、設定管理の4つの方向から学習できます。実験ごとに目的、予想される結果、復元手順を記録し、設定値だけを覚えて何を解決するのか分からなくならないようにしましょう。

接続設定の項目を理解する

プロトコルについて学ぶ際は、まずVMessとVLESSを比較し、認証、暗号化、トランスポートの安全性がそれぞれ何を担うのか確認しましょう。その後、TLSやREALITYでサーバー側に必要な設定を理解します。プロトコル名だけで性能が保証されると思ったり、項目を1つ減らせば速くなると考えたりしないでください。実際の通信はトランスポート、ネットワーク経路、サーバーの実装にも左右されます。まずVMessとVLESSの設定の違いを読み、現在の接続情報の各項目を照らし合わせて説明できるようにしましょう。

セキュリティ関連の設定は、サーバー側の条件と一致させる必要があります。サーバー名、公開鍵に関する項目、フィンガープリントの選択、トランスポートパスにはそれぞれ役割があるため、別の設定例から適当に組み合わせないでください。証明書やハンドシェイクの問題が起きた場合は、システム時刻、名前の一致、設定情報の入手元を確認します。証明書検証の無効化を恒久的な解決策にしてはいけません。提供元がセキュリティ設定を変更した場合は、見た目の異なる項目だけを置き換えるのではなく、接続情報全体を取得し直しましょう。

カスタムルーティングは小さく試す

まず特定のドメイン1つを対象に、直接接続するかプロキシを使うかを決めます。ルールを追加して適用結果を確認し、ほかの接続先に影響していないことを調べてください。問題がなければ、ドメインのサフィックスやアドレス範囲へ広げます。範囲を広げるほど、その接続を対象にする理由を明確にする必要があります。ルールの数が多いからといって設定の質が上がるわけではありません。長期間使うルールには用途を記録し、古い例外を定期的に見直してください。デフォルトルールより前に置いた理由を忘れてしまうのを防げます。

複数のルールが競合する場合は、原因を最小限のルールに絞り、1つずつ戻して挙動を確認します。内容を理解していないルールを大量に読み込むと、自分のコアや名前解決の経路に合っているか判断しにくくなります。GUIのプリセット、カスタムルール、完全な設定ファイルの間で、上書きや優先順位が発生することがあります。まずクライアントがそれらをどう統合するかを確認しましょう。変更した生成ファイルがクライアントによって書き換えられる場合は、保存先ではなく編集する設定画面を間違えている可能性があります。

名前解決ポリシーとFakeDNSは後から学ぶ

DNSについては、まず通常のドメイン名解決とIPアドレスによるルール判定を理解してから、FakeDNSを検討してください。FakeDNSは対応するアドレスを使ってドメイン名との関連を保持し、後続の処理で宛先を正しく復元して、通信の入口やルーティングと連携させる仕組みです。環境から切り離して有効にできる万能設定ではありません。アプリのキャッシュ、クライアントを経由しない通信、マッピングの途中で情報が失われることなどが、接続の問題につながる場合があります。ドメイン名の情報がどこで失われるか説明できる段階になってから、この仕組みが必要か検討しましょう。

名前解決ポリシーを試すときは、宛先を1つに固定し、名前解決の結果、実際の出口、失敗した段階をそれぞれ確認します。キャッシュが使われた後の速度をすべての通信で得られる効果と考えたり、1つのサイトで改善した設定をすべての端末に適用したりしないでください。デスクトップとAndroidでは入口やOSの名前解決環境が異なる場合があります。同じ概念を共有できても、設定の組み合わせは個別に検証する必要があります。設定を移行する際は、スイッチの値をそのまま写すより、目的と検証方法を引き継ぐほうが確実です。

設定メモを作成する

設定メモには、日付、変更の目的、対象画面、変更前後の値、テスト対象、結果を記録できます。ただし、実際のサブスクリプションURLやアカウント情報は含めないでください。クライアント設定、接続情報、ルールを分けて整理しておくと、端末を移行する際に再登録するものと手動で復元するものを判断できます。問題が起きたら、まず直近の動作状態に戻してから、1項目ずつ再試行しましょう。古い全画面スクリーンショットに頼るより、継続して管理しやすくなります。

問題の症状に応じて該当する章に戻ってください。登録エラーならサブスクリプション、アプリが通信制御されないならプロキシモード、出口が想定と違うならルーティングとDNS、仮想インターフェースの有効化後に異常が出たらTUNを確認します。基本接続をやり直す場合はクイックスタートガイドを、別のプラットフォームに移行する場合はダウンロードページでクライアントとアーキテクチャを確認してください。上級者とは、複雑な設定を使う人ではなく、設定の目的と動作を説明・検証できる人です。