v2rayN設定ガイド完全版

1. 基本概念：クライアント、コア、接続経路

画面と処理を切り分ける

v2rayNはグラフィカルクライアントです。サーバー情報の保存、サブスクリプションのグループ管理、プロキシの入口設定、コアの起動を担います。実際に接続を確立し、ルーティングルールを解釈してプロトコルやトランスポートを処理するのはコアです。画面が正常に開いていても、コアが起動しているとは限りません。コアが動作中でも、ブラウザーの通信がコアに渡されているとは限りません。この2つの役割を理解すれば、「接続できない」という問題を具体的な確認箇所に分解でき、クライアント全体を何度も再インストールせずに済みます。

Project Vは、関連するプロキシ技術のエコシステムを形成するプロジェクトです。V2FlyとXrayは関連しつつも、独立して開発されているコアです。対応する設定項目、トランスポートの組み合わせ、拡張機能はコアによって異なります。クライアントに特定のプロトコルが表示されても、それは設定項目があることを示すにすぎません。実際に動作するかどうかは、選択したコア、サーバー側の設定、使用中のビルドに左右されます。互換性に問題がある場合は、プロトコル名だけで比較せず、まずこれらの条件を確認してください。

通信の流れに沿って設定を理解する

一般的なデスクトップ環境では、通信はアプリ、システムプロキシまたはアプリ独自のプロキシ、ローカルの待ち受け口、ルーティングルール、アウトバウンド、リモートサーバーの順に進みます。通信を受け取る入口は通常「インバウンド」と呼ばれ、コアがどのように通信を受け取るかを決めます。アウトバウンドは、コアから通信をどう送り出すかを決めます。よく使われるアウトバウンドには、プロキシ経由、直接接続、ブロックがあります。サブスクリプションは主にサーバー情報を提供し、ルーティングルールはリクエストごとに使用するアウトバウンドを決めます。両者は役割が異なります。

ノードは、項目を自由に入れ替えられる単なるアドレス帳ではありません。サーバーアドレス、ポート、ユーザーID、プロトコル、トランスポート方式、TLSの設定が組み合わさって接続条件を構成します。ドメイン名はサーバーの検索に使われる場合もあれば、TLSのサーバー名検証に使われる場合もあり、両者が同じとは限りません。トランスポートのパス、ホスト名、サーバー名も、サーバー側での照合に使われることがあります。サーバーアドレスだけでは、通常ほかの接続情報を補えません。

プロトコル、トランスポート、暗号化の役割を分けて考える

VMess、VLESS、Trojanは認証やプロトコルの動作がそれぞれ異なります。TCP、WebSocket、gRPCなどは、別のレイヤーに属するトランスポートの選択肢です。TLSは対応する接続に暗号化と認証を提供し、REALITYには独自の設定項目があります。プロトコル名が同じでも、トランスポートやセキュリティ設定が異なれば接続に失敗することがあります。サブスクリプションの項目を確認するときは、各レイヤーを分けて確認してください。特定のプロトコルを、固定の暗号化方式やトランスポート方式と同一視しないことが大切です。

DNSはドメイン名をIPアドレスに変換しますが、どこで名前解決するかによってルーティング結果が変わります。アプリが接続前に名前解決すると、コアには接続先のIPアドレスしか見えない場合があります。アプリがドメイン名を渡す場合は、コアがドメインルールを適用できる可能性があります。システムプロキシは通常、アプリが設定に従うことを前提とします。一方、TUNは仮想ネットワークインターフェースを通じて対象の通信を受け取ります。入口ごとに対象範囲は異なりますが、同じルーティングやアウトバウンドを利用することもあります。入口だけを見て、最終的な接続経路を判断することはできません。

次の章に進む前に、次の3つを区別できるようにしておきましょう。クライアントに設定が保存されたこと、コアが設定を受け付けたこと、アプリのリクエストが実際にその設定を通ったことです。1つ目は画面で、2つ目は起動ログで確認できます。3つ目は実行ログとアプリのテスト結果を照らし合わせて確認します。用語が分からない場合は用語集を参照してください。ただし、初回接続の前にすべてのプロトコルを理解する必要はありません。すべての項目を暗記するより、まず接続経路全体を把握することが重要です。

2. クライアント選び：プラットフォーム、コア、用途

デスクトップではまずv2rayNを選ぶ

Windows、macOS、Linuxのデスクトップでは、まずv2rayNから始めるのがおすすめです。同じクライアントを使えば、サブスクリプションのグループ管理やトラブル対処の手順を統一しやすくなります。ただし、3つのOSでメニュー、権限、通信の取り込み方法が完全に同じとは限りません。操作手順を確認するときは、現在の画面に表示されている項目名を基準にしてください。スイッチが見つからない場合は、別のOSの設定ディレクトリや権限操作をそのまま試すのではなく、まずプラットフォームと使用中の画面を確認しましょう。

Windowsのダウンロードページでは、デスクトップ版と従来のWPF版を選べます。デスクトップ版はクロスプラットフォーム対応の画面を採用しており、複数のデスクトップOSで似た操作感を求める方に向いています。従来のWPF版は従来型のウィンドウレイアウトを維持しており、使い慣れた環境を続けたい場合に適しています。どちらも同時にインストールする必要はありません。初期設定ではどちらか一方を選び、接続を確認してから移行を検討してください。複数のインスタンスが待ち受けポートを取り合ったり、システムプロキシの設定を上書きしたりするのを防げます。

Androidでは用途に応じてコアを選ぶ

Androidではv2rayNGが第一候補で、一般的にはXrayコアを使用します。V2Flyコアを使いたい場合は、v2flyNGが選択肢になります。選ぶ際は名称の似ているかどうかではなく、手元のサーバー設定と必要な機能を基準にしてください。特定のコア機能を必要とする設定では、別のクライアントが同じ機能に対応しているかを事前に確認しましょう。インポートに成功したということは、項目が解析されて保存されたことを示すだけです。拡張項目がすべて実行レイヤーで使われるとは限りません。

インストールパッケージのアーキテクチャは、デバイスに合わせて選びます。新しいAndroid端末の多くはarm64ですが、プロセッサだけでなく、実際のシステム環境も確認してください。判断できない場合は、システム情報を確認するか、ダウンロードページにある汎用版を選びます。デスクトップでもx64とarm64の違いに注意し、macOSではApple Silicon版とIntel版を選択してください。アーキテクチャが合わない場合は、インストールに失敗したり、アプリが起動しなかったりします。サブスクリプションやネットワーク回線の問題と混同しないようにしましょう。

移行の手間も考慮して選ぶ

クライアント間でサブスクリプションURLを共用できる場合はありますが、ローカル設定をそのまま移行できるとは限りません。システムプロキシ、アプリごとの振り分け、ルーティングテンプレート、DNS、TUNの設定は、クライアント固有の形式で保存されている可能性があります。移行時はまずサーバー情報をインポートし、その後、通信動作に関わる設定を1つずつ作り直してください。データディレクトリ全体を直接コピーすると、非互換の項目、古いパス、ローカルポートまで引き継ぎ、新しい環境の問題が特定しにくくなることがあります。

組織管理下のデバイスか、仮想ネットワークインターフェースをインストールできるか、ほかのネットワークツールが起動しているかも考慮しましょう。システム権限に制限がある場合は、まずアプリ独自のプロキシや通常のシステムプロキシを使えます。TUNをインストール完了の必須条件にする必要はありません。既存のネットワーク設定がある場合は、元のプロキシやDNSの状態を記録してください。クライアントを選んでもシステムのポリシーを回避することはできません。複数のツールを重ねて、どの設定が有効なのかを推測するのも避けましょう。

この章の完了条件は、使うクライアント、インストール方法、最初に使う接続方式をそれぞれ1つに決めることです。デスクトップでは通常のプロキシを使って接続を確認し、Androidではシステムの案内に従って必要なネットワーク接続を許可します。プラットフォームに合ったパッケージをクライアントのダウンロードページから選び、異なるアーキテクチャのパッケージを何度も試さないでください。選んだ理由を記録しておけば、後で機能の違いに直面した際に、プラットフォームの制約、画面の違い、コアの機能差を切り分けやすくなります。

3. インストールと起動：元に戻せる基本環境を整える

インストール前にネットワークの状態を記録する

インストール前に、クライアントを使わない状態でネットワークが正常か確認します。システムプロキシに既存のアドレスが設定されていないか、自動設定スクリプトが有効になっていないか、DNSがネットワークから自動取得されているか、ほかの仮想ネットワーク接続がないかを記録してください。通常アクセスできるサイトを1つテストし、後で元に戻ったか確認するための基準にします。ネットワーク自体に問題がある場合は、接続、認証、システム時刻などを先に確認しましょう。そうしないと、プロキシとは無関係な問題がテスト結果に混ざります。

ダウンロードページの説明に従い、プラットフォームに合ったソフトウェアをインストールします。Windowsでは2種類の画面からどちらか一方を選びます。macOSではチップに合ったインストール方法を選び、システムの案内に従ってインストールします。Linuxではディストリビューションのパッケージ形式に合わせてdebまたはrpmを選び、プロセッサのアーキテクチャも確認してください。実行環境が不足しているとシステムに表示された場合は、エラー内容に応じて対処します。サーバーを次々に切り替えても、プログラムが正常に起動していない問題は解決しません。原因の切り分けのために、システムの保護機能をすべて無効にすることも避けてください。

初回起動ではコアの状態を確認する

プログラムを開いたら、まず実行ログまたは起動出力の表示場所を確認し、コアが起動できているかを調べます。ファイルが見つからない、設定を解析できない、アドレスが使用中といったメッセージにも注意してください。ビルドによってコンポーネントの配置や動作条件は異なるため、メイン画面が表示されたからといって、必要な依存関係がすべてそろっているとは限りません。コアがすぐに終了する場合は、最初に出たエラー行を残してください。その後の再試行や接続失敗は連鎖的な結果であることが多いため、まず最初の明確なエラーを解消しましょう。

ローカルの待ち受けアドレスとポートは、現在の設定画面で確認してください。ガイドでよく見かける番号を固定の初期値だと思い込まず、確認していないポートを別のプログラムに入力することも避けましょう。2つのクライアントが同じアドレスとポートを使うと、後から起動した方が待ち受けに失敗する場合があります。余分なインスタンスを終了してから、起動ログを確認してください。ポートを変更する必要がある場合は、クライアントと利用するアプリの両方を変更し、対応関係を記録します。

保存先、権限、バックグラウンド動作

クライアントの設定ディレクトリは、プラットフォーム、インストール方法、ビルドによって異なる場合があります。プログラムの設定画面や、フォルダーを開く機能から場所を確認してください。特定の端末のパスを、すべての端末で共通の場所だと考えないでください。設定を保存してプログラムを再起動した後も読み込めることを確認して、現在のアカウントに必要な書き込み権限があると判断できます。終了後に設定が消える場合は、別のプログラムを起動していないか、異なるアカウントやデータディレクトリを使っていないかを確認しましょう。

通常のシステムプロキシとTUNでは、必要な権限が異なります。インストール直後は必要最小限の環境だけを整え、スタートアップ起動、自動サブスクリプション更新、すべての通信取り込みを一度に有効にしないでください。Androidではシステムのダイアログでネットワーク接続を許可します。デスクトップのTUNでは、追加の権限やコンポーネントが必要になる場合があります。権限の確認画面は、直前に行った操作と関連しているか確かめてください。表示元が分からない場合はキャンセルし、クライアントの設定とログを確認しましょう。

最後に正常終了できることを確認します。通信の取り込みを停止してからクライアントを終了し、システムプロキシが想定どおりに戻ったか確認します。インストール前にテストしたサイトにも再アクセスしてください。終了後もアプリが停止済みのローカルポートを参照している場合は、システムのネットワーク設定から今回追加した設定を削除します。ただし、インストール前からある組織の設定は残してください。起動、保存、終了後の復元まで確認できれば、基本環境は完成です。サブスクリプションの問題は、この基準状態から切り分けられます。

起動時の問題が解決しない場合は、コアの起動失敗・ポート競合のトラブル対処もご覧ください。この段階で大量のサーバーをインポートしたり、インストール方法を次々に変えたりする必要はありません。エラーの記録と現在のインストール先を整理しておくと、同じ端末に複数のコピーを重ねるより原因を特定しやすくなります。

4. サブスクリプションの追加とグループ管理：URL、項目、更新を区別する

サブスクリプションURLと個別ノードのリンクは別々に扱う

サブスクリプションURLはサーバー情報を取得するための入口です。個別ノードのリンクは、1つの接続設定を表します。どちらもテキストとしてコピーできますが、インポートする場所が異なる場合があります。v2rayNでは、まずサブスクリプショングループの設定を開き、識別しやすいグループを追加します。配布元のサブスクリプションURLを入力して保存し、そのグループを更新してください。画面の項目名は変更されることがありますが、先にグループを作成し、クライアントに内容を取得・解析させるのが基本です。

v2rayNGとv2flyNGでは通常、サブスクリプション設定または設定追加の画面から配布元を管理します。インポートするものがサブスクリプションか単一の設定かを確認し、該当する操作を選んでください。クリップボードに説明文、改行、全角の句読点、チャットアプリが付けた文字列などが混ざると、URLの解析に失敗することがあります。URL末尾のクエリパラメーターが認証に使われる場合もあるため、短くする目的で削除しないでください。説明用URLには https://example.com/sub?token=xxxx のような明確な例だけを使用します。

グループを作成し、個別の変更を保護する

グループ名には、配布元や用途が分かる名前を付けましょう。アクセス情報や、変更されやすい宣伝用の回線名は含めないでください。動作確認用、日常用、手動で追加した項目を分けて管理する方法もあります。サブスクリプションを更新すると、グループ内の項目が作り直されることがあります。手動で変更した別名や設定が残るかどうかは、クライアントの実装によって異なります。長期間使う独自の項目は別のグループに置き、配布元とローカルのどちらが各項目を管理するか記録してください。

既存のグループを更新する操作と、同じグループを新たに追加する操作は異なります。後者では重複項目が増え、選択やテストの対象が分かりにくくなることがあります。更新後は、解析エラーがないか、項目が想定したグループに入っているか、選択中のサーバーが残っているかを確認してください。配布元で項目が削除または改名されると、選択中のサーバーを選び直す必要があります。リストに古い名前が残っていても、配布元が同じサービスを提供し続けているとは限りません。

失敗した段階から更新の問題を切り分ける

更新に失敗したら、まずURLを取得できないのか、取得した内容を解析できないのかを区別します。接続タイムアウトやドメイン名の解決失敗は、通常、取得段階の問題です。ログイン画面やエラーメッセージ、非対応の内容が返る場合は、解析段階の問題かもしれません。エラーを共有するときは種類を残し、サブスクリプションURL全体を公開しないでください。ブラウザーでページを表示できても、クライアントが有効なサブスクリプションを取得したとは限りません。返された内容の用途と、選択したインポート方法が一致しているか確認しましょう。

環境によっては、サブスクリプションの更新に利用可能なプロキシが必要です。クライアントに直接更新とプロキシ経由の更新がある場合は、現在の接続状態に合った方法を選びます。利用可能なプロキシがない状態でプロキシ経由の更新を行うと、「サーバーがないため更新できず、更新できないためサーバーも取得できない」という循環に陥ることがあります。その場合は、配布元が案内する適切なインポート方法を使うか、まず基本ネットワークを確認してください。DNSやTUNの設定をやみくもにすべて切り替える必要はありません。

サブスクリプション変換を利用すると、元の情報を処理する工程が増え、対象クライアントが認識しない拡張項目が失われる可能性もあります。配布元の形式を直接インポートできず、変換サービスと出力形式を把握している場合に限って検討してください。接続トラブルの標準的な対処として変換を使うのは避けましょう。初回の設定後は、グループ名、更新方法、テストした項目を記録してください。次回の更新で問題が起きたとき、配布元、取得経路、ローカル設定のどこが変化したのか比較しやすくなります。

別の端末へ移行する場合は、公開スクリーンショットでURLを渡さず、新しい端末でサブスクリプショングループを設定し直してください。インポートに関する相談はFAQのインストール・設定カテゴリを確認し、クライアント名、インポート方法、エラーが起きた段階を伝えます。ログを共有する前に個人情報を削除しても、原因の特定に必要な情報は十分残せます。

5. プロキシモード：システムプロキシ、アプリプロキシ、全体ルーティング

まずアプリからプロキシへの接続方法を決める

デスクトップで初回接続を試すときは、サーバーを1つ選び、システムプロキシを有効にする方法がおすすめです。v2rayNでよく使われる「システムプロキシを自動設定」は、OSが対応するプロキシ設定をクライアントのローカル入口に向けます。すべてのネットワーク通信を強制的にトンネルへ流す設定ではありません。各アプリがその設定を使うかどうかは、アプリの動作、ネットワークライブラリ、拡張機能、独自のプロキシ設定などに左右されます。設定に成功したことと、すべての通信を取り込めたことは分けて確認してください。

ブラウザーは初回テストに使いやすい一方、拡張機能、独自のプロキシ設定、自動設定スクリプトによって接続経路が変わる場合があります。まずは変数を減らし、接続方法を1つに絞ってください。新しいリクエストを送信し、該当する接続がクライアントのログに記録されるか確認します。ページに古い内容が表示されるだけなら、キャッシュが原因かもしれません。ブラウザーでページを開けただけでは、リクエストがプロキシを通ったとは判断できません。画面の結果と実行ログをあわせて確認してください。

全体プロキシは特定の1つの設定階層を指す言葉ではない

「全体」と呼ばれる設定は、システムプロキシの有効化、ルーティングでの全通信プロキシ、TUNによる通信取り込み範囲の拡大などを指すことがあります。これらは別の機能です。システムプロキシは一部のアプリからの接続方法を決め、全体ルーティングはコアに入った通信のアウトバウンドを決め、TUNはより多くの接続を取り込みます。ルーティングをすべてプロキシに設定しても、システムプロキシに従わないアプリがコアに入らなければ、元のネットワーク経路を使い続ける可能性があります。

アプリがHTTPプロキシまたはSOCKSプロキシに対応している場合は、クライアントの現在の待ち受けアドレスとポートを直接入力できます。数字が一致しているだけで同じプロトコルだと考えず、プロキシの種類と待ち受け口が合っているか確認してください。自分の端末だけで使う場合は、待ち受け範囲を必要以上に広げないでください。LANからの接続を許可すると、外部に公開される範囲が変わります。ファイアウォール、アクセス制御、端末が接続しているネットワーク環境もあわせて把握しましょう。

ターミナルとバックグラウンドのプログラムは個別に確認する

ターミナルのプログラムは、デスクトップのシステムプロキシを参照するとは限りません。プロセスの環境変数だけを認識するものや、専用のパラメーターが必要なものもあります。ブラウザーで成功したからといって、ターミナルの設定も完了したと判断しないでください。逆に、ターミナルのプログラムが動作しても、システム全体の通信が取り込まれているとは限りません。環境変数は通常、起動時にプロセスへ引き継がれるため、変更後も起動済みのプログラムは古い値を使い続けることがあります。新しいプロセスで確認し、テスト後に一時設定を削除してください。

「ブラウザーは使えるが、ほかのアプリでは使えない」場合は、すぐTUNを試すのではなく、そのアプリが参照するプロキシ設定、除外リスト、リクエストのプロトコルを確認してください。クライアントに該当するログがなければ、リクエストが入口に届いていない可能性があります。接続記録はあるのに失敗する場合は、サーバー、ルーティング、DNSを確認しましょう。詳しくはシステムプロキシが効かないときの対処：ブラウザー・ターミナル編をご覧ください。入口を確認せずに、いきなりリモート側の設定を変えるのは避けましょう。

この章の最後には、サーバー1つ、テストアプリ1つ、接続方式1つ、明確なルーティング設定という最小構成を残します。モードを切り替える前に、競合する古い設定を無効にしてください。切り替え後は新しいリクエストを送り、ログを確認します。クライアント終了後に設定が元へ戻ることも確認し、停止したローカルポートへアプリが接続し続ける状態を避けましょう。この再現可能な基準状態が、次章で複雑なルーティングルールを加える際の比較対象になります。

6. ルーティング：ルールの順序、ドメインの照合、DNS

アウトバウンドの選択は入口を通過した後に行う

ルーティングでは、コアに入った接続をドメイン名、アドレス、ポートなどの条件に基づいて振り分けます。まずは「中国本土を除外」など、クライアントに用意されたルーティングテンプレートを使い、動作を把握しやすい基本設定を作ってからカスタムルールを追加しましょう。テンプレート名は内容を要約したものにすぎず、実際の結果はルールの中身、参照データ、順序によって異なります。接続先が誤ったアウトバウンドを使う場合は、実際にどの条件が一致したかを確認してください。テンプレート名だけを見て、すべての接続の扱いを判断しないでください。

ルールは通常、上から順に確認され、最初に一致したルールで結果が決まります。そのため、より具体的な例外ルールは上に置くのが一般的です。ドメイン名とIPアドレスの条件は、完全に置き換えられるものではありません。ドメイン名はサービスの識別に、IPアドレスはネットワーク範囲の指定に向いています。ドメイン名が複数のIPアドレスに解決されたり、同じIPアドレスが複数のサービスで共有されたりすることもあります。1つのサイトを修正するために広い範囲のアドレスをすべてプロキシにすると、無関係な通信にも影響する場合があります。

V2Rayのルーティング設定例を読む

次の例は、互換性のあるV2Ray設定に組み込むルーティングの断片であり、起動可能な完全設定ではありません。プライベートアドレスを直接接続に、指定した広告カテゴリをブロックに振り分け、対応するアウトバウンドのタグを定義します。利用には対応するリソースデータが必要です。また、既存の設定に同名のアウトバウンドがある場合は統合してください。トップレベルの項目をそのまま重複して貼り付けないでください。グラフィカルクライアントが設定を再生成する場合は、同じ目的を実現できるクライアント内のルーティング編集画面を優先しましょう。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

outboundTagには、実際に存在するアウトバウンドのタグを指定する必要があります。タグは名前にすぎず、それだけで接続機能が作られるわけではありません。geoip:privateは対応するプライベートアドレスの分類に、geosite:category-ads-allはドメイン分類データの参照に使います。リソースが不足している場合や、指定した分類が存在しない場合は、設定の読み込みに失敗することがあります。ルールのタグ、フィールド、リソースファイルをひとまとまりで確認してください。JSONの構文が正しいかどうかだけでは不十分です。

ドメインルールと名前解決のタイミング

IPIfNonMatchは、ドメインルールに一致しなかったとき、接続先ドメインを名前解決してIPアドレスのルール判定を続けられることを示します。DNSサーバーを指定する項目ではなく、すべてのアプリにコアのDNSを強制する設定でもありません。アプリから接続先のIPアドレスが渡された場合、ルーティング側で確認できる情報は想定と異なる可能性があります。ドメインルールが機能しない場合は、入口で受け取った情報がドメイン名かIPアドレスか、また接続先の識別に影響する機能が有効になっていないかを確認しましょう。

V2RayのDNS設定では、DNSサーバーへの到達性、問い合わせ自体のアウトバウンド経路、解決結果をどのルールで使うかをあわせて考える必要があります。DNSサーバーのアドレスを変えても、すべての接続障害が直るわけではなく、既存のキャッシュがすぐに更新されるとも限りません。まず現在の設定を記録し、1つのテスト対象で名前解決と接続のログを比較します。暗号化DNSを使う場合は、そのサーバー名を先に解決する必要が生じることもあります。まだ確立していないプロキシ経路に、DNSの前提を依存させないようにしましょう。

カスタムドメインルールでは、full:はドメイン名の完全一致、domain:はドメインとそのサブドメインへの一致に使われます。キーワードや正規表現のルールはより広く一致するため、意図しない対象まで拾わないか確認が必要です。まず具体的なルールを1つ追加し、動作を確認してから範囲を広げましょう。詳しくはカスタムルーティングの構文と優先順位をご覧ください。この章の目標は、ルールを増やすことではありません。特定の接続先がなぜそのルールに一致したのか説明でき、ルールを削除して元の動作に戻せることが大切です。

7. TUNによる全体通信の取り込み：権限、ルーティング、競合への対処

通常のプロキシが動作してから有効にする

TUNは仮想ネットワークインターフェースを通じて、システムのルーティングが送る通信を受け取ります。通常のシステムプロキシでは対応できないアプリに向いています。変わるのは通信をクライアントに取り込む方法であり、接続できないサーバーを修復する機能ではありません。また、取り込んだすべての接続がプロキシ経由になるわけでもありません。有効にする前に通常のプロキシで接続を確認し、動作する設定を残してください。そうしないと、サーバー、インターフェース、DNSの問題が同時に発生し、新たな問題がどのレイヤーにあるのか判断しにくくなります。

クライアントのTUNスイッチは、特定のコンポーネント、実行権限、システム機能に依存する場合があります。プラットフォームごとに仕組みが異なるため、別の環境とそのまま比較することはできません。v2rayNのデスクトップでの通信取り込みと、Androidのシステムが提供するネットワーク接続の許可には違いがあります。現在のクライアントの案内に従って許可した後、ログでインターフェースとルートが実際に作成されたか確認してください。スイッチがオンでも、インターフェースの作成やルートの設定に失敗していれば、通信は想定した経路に入りません。

有効化の前後を比較する

テスト前に、通信の取り込みを競合する可能性のあるほかのツールを停止し、システムプロキシが有効かどうかを記録します。共存できる組み合わせもありますが、初回の確認では接続口を減らしてください。システムプロキシに従わないアプリを1つ選び、TUNを有効にして新しい接続を試した後、コアのログを確認します。そのアプリが明示的なプロキシ設定ですでに接続している場合、成功してもTUNが通信を取り込んだ証拠にはなりません。接続方式の違いを判別できるテスト条件を選び直してください。

ローカルネットワークへの接続も個別に確認します。ルーターの管理画面、LAN内の機器、直接接続が必要な社内サービスなどをテストしてください。TUNでルーティングが変わると、これらの接続先が誤ってリモートのアウトバウンドへ送られる場合があります。サーバーを次々に切り替えるのではなく、クライアントが対応する除外設定や振り分け設定を使いましょう。プライベートアドレスを直接接続にするルールは役立つことがありますが、システムルートや実際のアドレス範囲の確認に代わるものではありません。特殊なネットワークでは、追加の内部ネットワークが存在する場合もあります。

DNS、ループバック、既存の仮想インターフェース

TUNとDNSが密接に関係するのは、アプリが従来のシステムDNSリゾルバーに問い合わせを送り続ける一方、仮想インターフェースによってその通信経路が変わることがあるためです。DNS通信を取り込む必要があるか、問い合わせをどう処理するかは、実装方式とクライアントの設定を確認して判断してください。別のコア向けのDNS項目をそのまま現在の設定に貼り付けたり、互いを上書きする複数の名前解決方式を同時に有効にしたりしないでください。DNSの設定を1つ追加するたびに、ドメインの名前解決と接続先への接続を再確認しましょう。

プロキシ自身の通信が再び取り込まれ、ルーティングループになるリスクもあります。一般的な通信取り込み機能では自分自身の通信を処理しますが、ルーティング、インターフェース、アウトバウンドの関連付けを手動で変更すると、この前提が崩れることがあります。有効化後にサーバーへ接続できなくなった場合は、まずTUNを無効にし、通常のプロキシが復旧するか確認してください。通常モードでは動作し、TUNだけ失敗する場合は、サブスクリプション全体を再インポートする前に、端末側の通信取り込み経路を確認しましょう。

モバイル端末では、バックグラウンド制限、スリープ、ネットワーク切り替えにも注意が必要です。前面では接続できるのに画面ロック後に切れる場合は、省電力設定やバックグラウンド動作の制限が影響している可能性があります。Wi-Fiからモバイルネットワークに切り替えた後に失敗する場合は、切り替え前後のログと許可状態を比較してください。バックグラウンド設定を変更する前に、システムが提供する具体的な選択肢を確認しましょう。常時前面に表示する方法を恒久的な解決策にしたり、動作状況の観察の代わりに再インストールを繰り返したりしないでください。

この章の完了後は、通常の入口、TUNの入口、終了後の復元をそれぞれ検証できる状態を目指します。必要な権限、設定した除外ルール、システムプロキシを併用しているかを記録してください。通信を取り込む必要がない端末では、通常のプロキシだけでも十分な設定です。スイッチを増やすためだけに複雑さを加える必要はありません。TUNは、明確な通信取り込みの問題を解決するための機能であり、クライアントが正しく設定されたかを判断する唯一の基準ではありません。

8. 日常のメンテナンス：更新、ログ、設定のバックアップ

更新対象を分けて作業する

クライアント本体、実行コア、サブスクリプション情報、ルーティング用リソースは、それぞれ別のメンテナンス対象です。クライアント本体の更新は画面や設定の生成方法に、コアの更新はプロトコルや項目の解釈に、サブスクリプションの更新はサーバー項目に、リソースの更新は分類ルールの照合に影響します。同時にすべて更新すると、問題が発生した際に原因を特定しにくくなります。1回の作業で変更する対象を1つに絞り、基本的なテストを終えてから次へ進んでください。更新前に動作していた状態も記録しましょう。

更新前に、クライアントが対応するエクスポート機能やバックアップ機能で設定を保存し、何が含まれているか確認します。サーバー情報だけを保存し、DNS、ルーティング、システムの動作設定は含まないエクスポートもあります。サブスクリプションの認証情報やユーザーIDを含むバックアップは、機密情報として保管してください。ファイルがあるだけでは復元できるとは限りません。復元方法、クライアントの種類、設定の保存先、手動で再設定する必要がある項目を記録しておきましょう。

ログから問題のあるレイヤーを特定する

問題が起きたら、発生時刻、テストしたアプリ、接続先、直近の変更を記録してから、コアの起動出力と実行時のエラーを確認します。起動直後に終了する場合は、設定とローカルファイルを優先して確認します。リクエストが記録されない場合は入口を確認してください。リクエストがあるのにタイムアウトする場合は、リモートへの到達性とアウトバウンドを調べます。ドメイン名の解決に失敗した場合は、DNSの経路を確認します。ログは原因特定のための証拠です。「エラー」という語を含む記録をすべて同じ原因だと考えないでください。

アクセスログはリクエストや通信経路を確認するためのもので、エラーログは異常や実行時の問題を記録します。ただし、クライアントによっては両方がまとめて表示されます。一時的にログの詳細度を上げると再現に役立ちますが、テスト後は日常使用に適したレベルに戻し、記録が増えすぎないようにしましょう。ログを共有する前に、サブスクリプションのクエリパラメーター、ユーザーID、個人情報を含む接続先を削除してください。時系列、エラーの種類、関連する項目名を残せば、原因調査と情報保護を両立できます。

変更を1つに絞って再現し、元に戻す

サーバーとアプリを1つずつ選んで問題を再現し、変更する項目は毎回1つに絞ってください。変更後は新しい接続を作り、既存の長時間接続が動き続けるかどうかだけで判断しないようにします。変更前後の差を記録し、成功したらほかのアプリやルールを戻します。改善しなかった項目は元に戻してから、次の項目を試しましょう。試行錯誤を重ねて設定が混在すると、接続が復旧しても、どの項目が必要だったのか分からなくなります。

サブスクリプションの遅延テストや接続テストは、特定のテスト方法による結果にすぎません。接続先の利用体験全体を表すものではありません。テストに失敗した場合は、疎通、ハンドシェイク、特定のリクエストのどれを検査しているのかを確認してください。実際のアプリ通信は、DNS、ルーティング、UDP、サーバー側のポリシーにも影響されます。メンテナンス記録にはテスト数値だけでなく、「どのアプリがどの経路で動作したか」を残しましょう。数値からネットワーク全体の性能を推測するのも避けてください。

アップグレード後に問題が起きたら、まず古い設定が移行されたか、現在どのプログラムを実行しているか、システムプロキシが新しい待ち受け先を参照しているかを確認します。元に戻す場合は、保存しておいた設定と適切なインストール方法を使い、新旧のプログラムを同時に起動しないでください。すぐに原因を特定できない場合は、最小構成に戻してから、章ごとにルーティングやTUNを再設定します。こうすれば利用を再開しつつ、安定した比較環境を残せます。

ログの項目が分からない場合は、実行ログのメッセージ一覧をご覧ください。この章の完了条件は、復元可能なバックアップ、再現可能なテスト手順、個人情報を削除したトラブル記録がそろっていることです。メンテナンスとは、設定を絶えず変更することではありません。変更の理由を説明でき、結果を検証し、元に戻せる状態を保つことです。偶然接続が復旧しただけなのに、原因を特定できたと判断しないようにしましょう。

9. 応用編：プロトコルの互換性と設定の検証

まず設定の管理元を明確にする

応用設定に進む前に、クライアントが生成する設定と、ユーザーが長期的に管理する設定を切り分けてください。グラフィカルクライアントは、画面上の設定からコアの実行設定を生成することがあります。生成ファイルを直接編集すると、サーバーの切り替えや再起動時に上書きされる可能性があります。カスタムルーティング、テンプレート、クライアントが明示的に提供する設定画面を優先してください。完全なカスタム設定が必要な場合は、サブスクリプション、サーバーの選択、画面上のスイッチとの関係を理解し、同じ項目を複数の設定元から同時に制御しないようにしましょう。

通常利用する設定を1つ残し、実験用の設定を別に作って、調べたい機能を1つずつ試します。実験ごとに、期待する結果、確認方法、元に戻す手順を明記してください。たとえばドメインルールを調べる場合は、サーバー、DNS、入口を固定し、照合条件だけを変えます。TUNを調べる場合は、動作確認済みのルーティングとアウトバウンドを固定します。目的は項目を増やすことではなく、原因と結果の関係を明らかにすることです。そうすれば、後で問題が起きても、証拠に基づいて原因を絞り込めます。

プロトコルの設定項目をレイヤーごとに学ぶ

プロトコルを学ぶときは、認証、トランスポート、セキュリティの各レイヤーに分けて確認します。VMessとVLESSでは認証と暗号化の役割が異なるため、プロトコル名を置き換えるだけでは変換できません。Trojanにも独自の接続条件があります。WebSocketのパスやホスト、gRPCのサービス名、TLSのサーバー名、REALITYに必要な設定を、サーバー側の情報と1つずつ照合してください。配布元に記載のない項目を経験だけで推測しないようにしましょう。インポートできても、すべての組み合わせが実行時に動作するとは限りません。

プロトコルの互換性は、使用するコアとクライアントの設定生成方法にも左右されます。オンラインで見つけた設定が別のコア向けの項目を使っている場合、JSONの構文が正しくても、現在の環境で未知の項目としてエラーになったり、異なる意味で解釈されたりすることがあります。新しい機能を試す前に、どのコア向けの機能か、現在のクライアントが対応する設定を提供しているかを確認してください。基本を比較するには、VMessとVLESSの違いを読み、実際の設定をレイヤーごとに照合しましょう。

ルールの検証から保守しやすい設定へ

複雑なルールは、特定のサービスを決まったアウトバウンドに送る、LAN内の通信を直接接続にする、特定カテゴリをブロックするなど、明確な目的に沿って追加します。ルールごとに用途と一致する範囲を記録し、不要になった例外は定期的に整理してください。重複するルールが増えると順序を把握しにくくなり、リソース更新後に照合結果が変わる可能性もあります。原因を説明できない動作が起きた場合は、より広いルールを追加し続けるより、検証可能な少数のルールに絞る方が効果的です。

DNSの応用テストでも、何を観察するかを明確にします。アプリが要求したドメイン名、コアが実行したDNS問い合わせ、ルーティングで使われる接続先アドレスは、同じ段階の情報とは限りません。名前解決の失敗、想定外の解決結果、接続先アドレスへの到達不能を分けて記録してください。DNSの方針を変更した後も、古いキャッシュや長時間接続が以前の動作を続けることがあります。新しい接続を作って再テストしましょう。ページを1回再読み込みしただけでは、名前解決経路全体が切り替わったとは確認できません。

最後に、定期確認用のテストを固定します。通常のブラウザーからのリクエスト、システムプロキシに従わないアプリ、LANへの接続、サブスクリプションの更新、終了後のネットワーク復元を確認します。新機能だけをテストしても不十分です。新しいルールが既存の経路を変えたり、DNS設定の変更がサブスクリプションの取得に影響したりすることがあります。テストは簡単でも構いませんが、条件を一定に保ち、対象と成功基準を明確にすると、変更による改善を比較できます。

このガイドを使いこなせている目安は、通信がどこから入り、どのルールでアウトバウンドが選ばれ、どこで名前解決され、失敗時にどう復旧するかを説明できることです。症状から調べる場合はよくある質問をご覧ください。最小構成を作り直す場合はクイックスタートガイドに戻れます。動作する基準設定を保ち、実験の結果を1つずつ日常設定に反映してください。設定の出所を説明できないまま複雑な構成を使い続けるより、保守しやすくなります。