ZERO TO ADVANCED

V2Ray初心者から応用までの完全ガイド

基本概念、クライアント選び、インストール、サブスクリプション、プロキシモード、ルーティング、TUN、保守と応用への道筋を章ごとに解説します。操作だけでなく、設定の仕組みも説明します。

クライアントを選ぶ クイックガイドを見る
このページとクイックガイドの使い分け

クイックガイドは初回インストール後に接続まで進めたい場合に適しています。このガイドは体系的な学習と継続的な参照向けです。すでに使える方は、プロキシモード、ルーティング、TUNの章から読み始められます。

基礎編 概念、選び方、インストール、サブスクリプション
制御編 システムプロキシ、ルーティングルール、TUN
保守編 ログによるトラブルシューティング、バックアップ、応用への道筋

1. コア解説：クライアント、コア、設定の役割を整理する

グラフィカルクライアントとプロキシコアは別物

V2Rayを学ぶ際に最も混同しやすいのは、グラフィカルクライアント、プロキシコア、ノード設定、システムプロキシを同じものとして扱うことです。実際には、それぞれ異なる階層にあります。v2rayN、v2rayNG、v2flyNGは、ウィンドウ、サブスクリプション一覧、ノード選択、ログ、各種スイッチなどの操作画面を提供します。XrayまたはV2Flyコアは、設定の解析、通信の確立、ルーティングルールの判定、本地プロキシポートの提供を担います。サブスクリプションや個別の共有リンクは、サーバーアドレス、ポート、ユーザー識別子、プロトコル、通信パラメータをクライアントに渡します。システムプロキシとTUNは、アプリの通信をどのようにローカルコアへ送るかを決めます。この4層が正しくつながって初めて、ブラウザーなどのリクエストが想定した経路で転送されます。

そのため、「クライアントが実行中」と表示されても、ローカルプロセスが起動したことしか確認できません。サブスクリプションが有効か、ノードに到達できるか、アプリの通信がプロキシへ入っているかまでは判断できません。トラブルシューティングでは、データの流れに沿って段階的に確認します。まず設定をクライアントが認識できるか、次にコアが正常に起動したか、その後ローカルの待受ポートが存在するか、最後にシステムやアプリが実際にそのポートを使っているかを確認します。段階を分ける方が、接続ボタンを何度も押すより早く原因を特定できます。

インバウンド、アウトバウンド、ルーティングの連携

コア設定では、3つの重要な部分がよく登場します。インバウンドは、ローカルのSOCKSやHTTPプロキシポートなど、本機のアプリから受け取ったリクエストを処理します。アウトバウンドは、本機を出た後の処理方法を示し、通常はリモートプロキシ、直接接続、ブロックなどを含みます。ルーティングはその間に位置し、ドメイン、IP、プロトコル種別、プロセスなどの条件に応じてアウトバウンドを選択します。クライアントの「システムプロキシ」「ルーティングモード」「LANをバイパス」「特定の接続をブロック」といった項目は、これらを操作しやすくしたものです。基礎にある流れは、受信、判定、転送です。

ドメイン名前解決も通信経路の中で独立した役割を持ちます。アプリが先にシステムでドメインを解決し、IPだけをプロキシに渡す場合もあれば、ドメインをそのままローカルプロキシに渡し、コアが設定に従って解決する場合もあります。経路によって、ドメインルールが適用されるかどうかや分流結果が変わります。初めから複雑なDNS項目を変更する必要はありません。ドメインルールが正しいように見えるのに適用されない場合は、リクエストがコアに入った時点でドメインのままなのか、すでにIPへ変換されているのかを確認してください。

階層 主な役割 主な確認ポイント
グラフィカルクライアント サブスクリプション、ノード、画面設定、コアの動作を管理する 現在の設定、実行状態、ログの入口
プロキシコア ローカルポートで待ち受け、接続を確立し、ルーティングを実行する 起動エラー、ポートの競合、ルールの適用結果
ノード設定 プロトコル、アドレス、ポート、ユーザー識別子、通信方式を定義する 項目の完全性、プロトコル対応、サブスクリプションの更新日時
通信の取り込み ブラウザーや他のアプリからのリクエストをコアへ渡す システムプロキシ、アプリのプロキシ、TUNの権限

プロトコル名と通信パラメータを分けて理解する

VMess、VLESS、Trojanなどは通常、プロキシのプロトコル層を示します。TCP、WebSocket、gRPCなどは通信方式に分類され、TLS、REALITYなどは接続の安全性やハンドシェイクの特徴に関わります。共有リンクは複数層のパラメータを1本の文字列にまとめたもので、インポート後にクライアントがコアで読み取れる設定へ戻します。プロトコル名が同じだからといって、2つのノード設定をそのまま入れ替えられるとは限りません。通信方式、ホスト名、パス、セキュリティ設定、サーバー側の設定が一致している必要があります。ノードを手動編集する場合は、経験だけで値を補わず、不足情報を設定提供元に確認してください。

この章を終える頃には、リクエストの流れを明確に説明できるはずです。アプリがリクエストを送信し、システムプロキシまたはTUNが通信を取り込み、ローカルのインバウンドが受信し、ルーティングがアウトバウンドを選び、コアがノード設定に従って接続を確立します。以降の設定はすべて、この流れに当てはめて理解できます。

2. クライアントを選ぶ：プラットフォーム、コア、保守方法で判断する

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

Windows、macOS、Linuxのデスクトップ環境では、v2rayNを第一候補にします。サブスクリプションのグループ分け、サーバー一覧、システムプロキシ、ルーティング、ログ、TUNを1つの画面で管理でき、基本操作からルール管理へ段階的に進めます。Windowsでは画面方式や使い慣れた操作に応じてデスクトップ版または従来のWPF版を選べます。macOSではプロセッサのアーキテクチャに合うインストーラーを選択し、Linuxではディストリビューションのパッケージ形式に合わせてdebまたはrpmを選びます。現在の入口とファイル名はダウンロードページにまとめて掲載しており、このガイドでは固定のバージョン番号を扱いません。

同じサブスクリプションを異なるデスクトップOSで使っても、ノードの内容は通常同じです。ただし、システムプロキシ、権限管理、証明書の保存、スタートアップ、ファイアウォールの挙動は異なります。設定を移行する際は、サブスクリプションURLやカスタムルールの考え方は再利用できますが、本機の設定をすべてそのまま移せるとは考えないでください。特にTUNモードは、OSが提供する仮想ネットワークインターフェースと権限機構に依存するため、現在のプラットフォームに合わせた確認が必要です。

Androidではv2rayNGとv2flyNGを使い分ける

Androidではv2rayNGを第一候補にします。Xrayコアを採用しており、幅広いプロトコルや通信機能を必要とする設定に適しています。v2flyNGはV2Flyコアを使用し、V2Flyエコシステムを重視する場合の選択肢になります。どちらもサブスクリプションの追加、ノード切り替え、ローカルVPNによる通信の取り込みに対応しますが、コアの機能、設定項目の名称、一部設定の互換性は異なる場合があります。サブスクリプションが特定のコア機能に依存する場合は、画面の見た目ではなく、使用するコアが対応しているかを先に確認してください。

インストールパッケージのアーキテクチャも選択が必要です。比較的新しいAndroid端末の多くはarm64を使用します。アーキテクチャを確認できない場合や、幅広い端末を対象にしたい場合は汎用版が適しています。アーキテクチャはパッケージ内のネイティブコードの種類を決めるだけで、サブスクリプションの内容は変わりません。システムに端末との互換性がないと表示されたら、サブスクリプションを作り直すのではなく、まず汎用版を試してください。

利用環境 おすすめのクライアント 選ぶ際のポイント
Windows v2rayN 画面とシステム環境に合わせてデスクトップ版または従来のWPF版を選ぶ
macOS v2rayN Apple SiliconとIntelのアーキテクチャを区別する
Android v2rayNG、v2flyNGは選択肢の一つ コアの機能とarm64、汎用版の違いを踏まえて選ぶ
Linux v2rayN ディストリビューションに応じてdebまたはrpmを選び、プロセッサのアーキテクチャを確認する

ノード数だけで互換性を判断しない

クライアント選びで重要なのは「何件の記録をインポートできるか」ではなく、現在の設定をコアが完全に解析できるか、そしてシステムの通信を安定してコアへ渡せるかです。サブスクリプション一覧にノードが表示されるのは、テキスト形式や共有リンクが認識されたことを示すだけです。接続時には、通信パラメータの不足、コアの非対応、システム時刻のずれ、ネットワークへの到達不能などで失敗する可能性があります。より確実な判断方法は、動作確認済みの設定を1つ選び、対象クライアントでコアが起動するか、ログに設定エラーがないか、ローカルプロキシがリクエストを処理できるかを確認することです。

デスクトップとAndroidを併用する場合は、異なる端末から同じサブスクリプションURLを参照できます。ただし、クライアントのローカル設定は端末ごとに管理することをおすすめします。デスクトップではシステムプロキシや細かなルーティングを使うことが多く、モバイルではOSが提供するVPNインターフェースに依存することが多いためです。バックグラウンド動作、バッテリー設定、LANアクセスの扱いも異なります。サブスクリプションが同期するのはリモート設定であり、各端末の通信取り込み方針ではありません。

クライアントを決めたら、以降の学習は1つのメインクライアントで進めます。複数のクライアントを頻繁に切り替えると、画面の違いを設定障害と誤認しやすくなります。デスクトップはv2rayN、Androidはv2rayNGから始めると、学習の流れが明確です。

3. インストールの準備：システム、権限、初回起動を確認する

ダウンロード前にシステムとプロセッサのアーキテクチャを確認する

インストール前に、OSの種類、プロセッサのアーキテクチャ、現在のアカウントにインストールやネットワーク設定の権限があるかを確認します。Windowsでは新しいデスクトップ画面と従来のWPF画面のどちらを使うかを決めます。macOSではApple SiliconとIntelを区別します。Linuxではディストリビューションがdebとrpmのどちらを使うかを確認し、x64とarm64も区別します。Androidでは端末のアーキテクチャが明確ならarm64、分からなければ汎用版を選びます。アーキテクチャの誤りは、ノード接続エラーではなく、インストールできない、または起動できないという形で現れることが多いです。

ダウンロードはサイト内のクライアントダウンロードページから行ってください。ダウンロードページでは4つのプラットフォーム別にパッケージを整理し、対応アーキテクチャを案内しています。パッケージの更新によりファイル名が変わることがあるため、古いファイル名を長期メモに残すのはおすすめしません。「v2rayN、macOS、arm64」のように、クライアント名、プラットフォーム、アーキテクチャを記録しておくと、再インストール時に対応する項目を見つけやすくなります。

初回起動では保存先と権限を確認する

デスクトップクライアントは通常、サブスクリプション、ログ、ルーティングルール、画面設定を保存します。読み取り専用の場所に置いたり、現在のアカウントに設定フォルダーへの書き込み権限がなかったりすると、設定を保存できない、再起動後にサブスクリプションが消える、コアの展開に失敗するといった問題が起こります。初回起動後は重要でない画面設定を1つ変更して再起動し、変更が保持されることを確認してください。クライアントにログフォルダーを開く入口がある場合は、そこにファイルを作成できることも確認します。

システムプロキシの変更、スタートアップ、TUNモードに必要な権限は、完全に同じではありません。通常のシステムプロキシは現在のユーザーのプロキシ設定を変更するだけですが、TUNは仮想ネットワークインターフェースの作成やルーティングテーブルの変更が必要で、より高い権限を求められることがあります。基礎段階ではまずシステムプロキシで接続を確認し、初回起動時にTUN、複雑なルーティング、LAN共有、カスタムDNSを同時に有効にしないでください。変数を1つずつ増やすと、問題が起きても戻しやすくなります。

  1. クライアントをインストールします。OSとプロセッサのアーキテクチャに合ったパッケージを選び、システムの指示に従ってインストールします。
  2. 起動して書き込みを確認します。クライアントが設定を保存し、ログを作成し、正常に終了できることを確認します。
  3. コアの起動を確認します。大量の設定を追加する前に、ログにコンポーネント不足、ポート競合、権限エラーがないか確認します。
  4. 初期ローカルポートを記録します。アプリのプロキシ設定や競合の特定には、SOCKS、HTTP、混合ポートの番号が必要です。

ローカルの待受ポートを理解する

コアの起動後は通常、ループバックアドレスで1つ以上のローカルポートを待ち受けます。ループバックアドレスは本機からのみアクセスでき、一般に127.0.0.1と表記します。SOCKSインバウンドはSOCKSプロキシに対応したアプリに、HTTPインバウンドはHTTPプロキシに対応したアプリに適しています。混合ポートは両方のリクエストを受け付ける場合があります。ポート番号はクライアントの設定画面に表示される値を使用し、他人の番号をそのまま使わないでください。別のプログラムがポートを使用していると、コアは起動できず、ログに待受失敗やアドレス使用中などのメッセージが表示されます。

デスクトップOSのネットワーク状態ツールで、ポートが待ち受けているか確認できます。以下のコマンドは本機の待受状態を確認するためだけのものです。例のポート10808は、クライアント画面に表示された実際の値へ置き換えてください。Windowsではターミナルで1つ目を、macOSとLinuxでは2つ目を実行します。

netstat -ano | findstr 10808
lsof -nP -iTCP:10808 -sTCP:LISTEN

何も表示されない場合は、サブスクリプションをすぐ変更せず、まずクライアントのログを確認します。ポートが別のプロセスに使用されている場合は、競合するプログラムを終了するか、クライアントで未使用のポートに変更し、手動でプロキシを設定したアプリも更新してください。クライアントがシステムプロキシを自動管理している場合は、通常ポート変更に追従します。一方、ブラウザー、開発ツール、ターミナルで手動設定したプロキシは自動更新されません。

インストール段階の目的は、最初からすべての機能を有効にすることではなく、再現可能な最小環境を作ることです。クライアント名、システムアーキテクチャ、ローカルポート、設定フォルダーの場所を記録しておくと、アップデート、移行、トラブルシューティングが容易になります。

4. サブスクリプション管理：追加、更新、グループ分け、形式の確認

サブスクリプションURLと個別の共有リンクの違い

サブスクリプションURLは通常、複数の設定を返します。クライアントが更新すると再取得され、そのグループの内容が上書きまたは統合されます。一方、個別の共有リンクは1つのノードを表すだけで、追加後にリモートの一覧変更へ自動追従することはありません。長期利用では、サブスクリプションURLを専用グループに追加し、分かりやすい名前を付けるのがおすすめです。一時的な共有リンクは別グループに分け、リモート管理の項目と手動追加した項目を混同しないようにします。

サブスクリプションの内容は、base64でエンコードされた複数行の共有リンクの場合もあれば、クライアントが直接解析できるJSONなどの形式の場合もあります。base64はエンコード方式であり、暗号化プロトコルではありません。また、ノードがVMess、VLESS、Trojanのどれを使うかも決めません。形式の認識に失敗したら、プロキシモードを何度も変えるのではなく、返された内容が完全か、クライアントがその形式に対応しているか、URLのコピー時に空白や改行が混入していないかを確認してください。形式の関係はサブスクリプション形式の詳しい解説で確認できます。

保守しやすいグループ構成を作る

グループ分けの目的は一覧整理だけではありません。更新方針とローカルルールを分離できます。少なくとも「日常用サブスクリプション」「一時テスト」「手動設定」に分けることをおすすめします。日常用は自動更新、一時テストは必要なときだけ更新し、手動設定はリモートで上書きされないようにします。同じURLを複数のグループに追加すると、更新後に内容が重複し、速度測定、並べ替え、現在のノード選択が複雑になります。重複を見つけたら、ノードを1件ずつ削除する前にサブスクリプション一覧を確認してください。

サブスクリプションを更新する前に、クライアントはURLへアクセスする必要があります。このリクエストは現在のネットワークから直接取得する場合もあれば、クライアントの設定により既存のプロキシを経由する場合もあります。現在のノードが無効で、更新もプロキシ経由に設定されていると、「更新しないと使えるノードを取得できないのに、更新リクエストも古いノードに依存する」という循環が起きます。その場合は一時的に直接接続で更新するか、動作確認済みの設定を使って更新してください。成功後に元の方針へ戻します。

  • サブスクリプションURLを追加する
  • グループ名を付ける
  • 更新を実行する
  • ノードの項目を確認する
  • 現在の設定を選ぶ

更新後に確認すること

「更新完了」と表示されても、すべての設定が使えるとは限りません。更新後は3段階で確認します。まずグループにノードが生成されたか確認し、空なら返却形式とフィルター条件を重点的に調べます。次に設定を1つ開き、アドレス、ポート、プロトコル、通信方式、セキュリティ設定に明らかな不足がないか確認します。最後に1つ選んでコアを起動し、ログに解析エラーがないか確認します。ノード名だけで内容を判断しないでください。名前はメモであり、実際の接続には使われません。

サブスクリプションの自動更新間隔は、クライアントの利用を頻繁に中断するほど短くしない方がよいでしょう。設定提供元の変更頻度に合わせ、手動更新の入口も残しておくのが適切です。長時間稼働するデスクトップでは一定間隔で確認させ、モバイル端末ではバックグラウンド制限により自動処理が遅れることがあるため、手動更新の方が確実な場合があります。自動更新の有無にかかわらず、最後に成功した更新日時を把握しておくと、障害が古い設定によるものか現在のネットワークによるものか判断しやすくなります。

サブスクリプション更新失敗の切り分け

更新失敗の原因は、主に4種類です。URL自体が変更された、現在のネットワークからサブスクリプションサービスへアクセスできない、返却内容がクライアント非対応の形式、クライアントの直接取得・プロキシ取得の方針が適切でない、のいずれかです。URLを公開しない形で完全性を確認し、次に取得方法を切り替え、更新ログのHTTPステータス、解析メッセージ、タイムアウトを確認します。応答は成功して解析だけ失敗するなら形式の問題、応答自体がないならネットワークまたはURLの問題です。詳しい手順はサブスクリプション更新失敗の対処手順を参照してください。

安定したサブスクリプション管理には、3つの要点があります。提供元をグループで分離し、更新経路を切り替えられるようにし、更新結果を検証することです。この習慣があれば、リモートの一覧が変わっても、ローカルのカスタムルールや一時テスト用の設定に影響しません。

5. プロキシモード：システムプロキシ、アプリのプロキシ、全体設定

システムプロキシが制御するアプリ

システムプロキシは、OSが提供するネットワーク設定にプロキシアドレスを書き込む機能です。システムプロキシに従うブラウザーやデスクトップアプリは、クライアントのローカルポートへリクエストを渡しますが、すべてのアプリが設定を読み取るわけではありません。一部のコマンドラインツール、ゲーム、仮想マシン、コンテナ、独自のネットワークスタックを使うソフトウェアは、システムプロキシを無視することがあります。「ブラウザーは使えるのに特定のアプリは使えない」場合は、まずそのアプリがシステムプロキシに対応しているかを確認し、すぐにノードが不安定だと判断しないでください。

クライアント画面の「システムプロキシを解除」「システムプロキシを自動設定」「変更しない」といった項目が操作するのは、OSの設定です。コアのルーティングモードとは別のものです。システムプロキシは「通信をコアへ入れるか」を決め、ルーティングモードは「入った後にどのアウトバウンドを使うか」を決めます。この2つは混同されがちです。正しい順序は、まず通信が入っていることを確認し、その後に直接接続、プロキシ、ブロックのルールを検討することです。

アプリの手動プロキシは精密なテストに適している

プロキシ設定に対応したアプリには、127.0.0.1とクライアントに表示されたローカルポートを直接入力できます。対象アプリだけに適用され、システム全体は変更しないため、ローカルのインバウンドが機能しているかの確認や、開発ツールだけに独立したプロキシを設定したい場合に適しています。プロキシ種別は待受ポートと一致させてください。SOCKS設定はSOCKSインバウンド、HTTP設定はHTTPまたは対応する混合インバウンドを指定します。種別を間違えるとポートには接続できても、プロトコルのハンドシェイクに失敗します。

ターミナルのプログラムは、環境変数からHTTPプロキシを読み取ることがよくあります。以下の例ではローカルアドレスとサンプルポートを使用し、現在のターミナルセッションにだけ適用します。ターミナルを閉じると、通常は再設定が必要です。実際に使う前にクライアントのポートを確認し、対象ツールがこれらの変数に対応しているかを確認してください。

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

Windows PowerShellでは、現在のセッションで環境変数を次のように設定できます。

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5://127.0.0.1:10808"

グローバル、ルール、直接接続モードの違い

グローバルプロキシは通常、コアに入ったリクエストを現在のプロキシアウトバウンドへ優先的に渡します。短時間の接続確認に適しています。ルールモードはドメイン、IP、その他の条件に応じてプロキシ、直接接続、ブロックを選択するもので、日常利用の中心です。直接接続モードはコアに入ったリクエストをそのまま対象へ接続し、リモートノードが原因かを比較する際に使います。モード名はクライアントによって多少異なりますが、判断の考え方はほぼ同じです。

トラブルシューティングでは、3つのモードを比較できます。グローバルプロキシが失敗して直接接続が正常なら、まずノードとリモート通信を確認します。グローバルプロキシは正常でルールモードだけ失敗するなら、ルーティングの適用結果を確認します。システムプロキシを無効にしてもアプリがプロキシを使うなら、アプリ自身に手動プロキシが設定されているか、TUNが有効になっている可能性があります。比較テストでは一度に1つのスイッチだけ変更し、終了後に元へ戻してください。

モードまたは入口 適した場面 主な制限
システムプロキシ ブラウザーとシステム設定に従うデスクトップアプリ すべてのプログラムを対象にできない
アプリの手動プロキシ 単一アプリのテストと個別設定 ポート変更後に手動で更新が必要
グローバルプロキシ 現在のノードの接続性をすばやく確認する 長期的に細かなルールの代わりには向かない
ルールモード 目的に応じて異なるアウトバウンドを選ぶ日常利用 ルールの順序と適用結果を理解する必要がある

プロキシモードで重要なのは「どれが最も広範囲をカバーするか」ではなく、アプリの挙動に合った取り込み方法を選ぶことです。通常のデスクトップ通信にはシステムプロキシ、細かな制御には手動プロキシを使い、TUNは基本経路が安定してから有効にします。

6. ルーティング：ルールの順序とドメイン・IPのマッチング

ルーティングルールは順番に適用される

ルーティングの基本は、リクエストの特徴に応じてプロキシ、直接接続、ブロックのアウトバウンドを選ぶことです。多くのルールシステムは決められた順番で確認し、適用した時点で後続の判定を止めます。そのため、ルールの内容が正しくても順序が間違っていれば、意図しない結果になります。範囲の広いルールを先に置くと、後のより具体的なルールが無視されます。範囲の狭い例外は、通常、対応する一般ルールより前に置きます。変更前に現在のモードとルール順を記録しておけば、テストに失敗してもすぐに戻せます。

よく使われる判定条件には、完全なドメイン名、ドメインサフィックス、IPまたはネットワーク、ポート、ネットワーク種別、プロセス名があります。ドメインルールは読みやすく、変化の少ないドメインを対象にするのに適しています。IPルールは明確なアドレス範囲に向きますが、対象サービスが動的アドレスを使う場合は保守の負担が増えます。プロセスルールはクライアントとOSの対応状況に依存し、アプリの更新やパスの変更で動かなくなることがあります。初めはドメインとプライベートアドレスの範囲を使い、動作を確認してから複雑な条件を追加してください。

ドメインのマッチングが失敗する理由

ルールがドメインを確認できるかどうかは、リクエストがコアに入った時点でどの情報を持っているかによります。アプリが先にDNS解決を行い、IPだけをプロキシへ渡す場合、ドメインだけのルールは直接適用できないことがあります。コアがスニッフィングなどで対象ドメインを復元できる場合もありますが、すべての通信に適用できるわけではありません。反対に、アプリがSOCKS経由でドメインをコアへ渡す場合は、ドメインルールが直接適用されやすくなります。トラブルシューティングでは、ルーティングログの対象形式を確認し、ルールの文章だけを見て判断しないでください。

ドメインサフィックスのルールでは境界にも注意が必要です。たとえばexample.comのサフィックスルールは通常そのサブドメインにも適用されますが、同じ文字列を含む別ドメインまで同じサイトと誤認してはいけません。クライアントに「完全なドメイン」「ドメインサフィックス」「キーワード」など複数の種類がある場合は、意味が最も正確なものを優先します。キーワードマッチングは範囲が広いため、一時的な確認には使えても、長期ルールの基盤には向きません。

最小構成のルーティングを読む

以下のJSONは、ルーティング部分の基本構造を示します。1つ目のルールはLANとプライベートアドレスを直接接続し、2つ目は例示したドメインをプロキシへ送り、それ以外は後続のデフォルトアウトバウンドで処理します。directとproxyは、完全な設定内に存在するアウトバウンドのタグに対応していなければなりません。この断片は項目の関係を理解するためのもので、インバウンド、アウトバウンド、DNS設定なしでは単独で動作しません。

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

AsIsは、ルーティング段階でリクエスト本来の対象を優先して処理し、IPルールのためにすべてのドメインを積極的に解決しないことを示します。方式によってドメインルールとIPルールの連携方法が変わるため、どの値が常に優れているとは言えません。現在のクライアント設定が安定しているなら、パラメータを複雑にするためだけに変更する必要はありません。ドメインとIPのマッチングが想定と異なると明確に分かった場合に限り、DNS設定とログを確認しながら調整してください。

まずデフォルトの動作を決めてルールを設計する

ルールセットを作る前に、「どのルールにも一致しなかった場合にどう処理するか」を決めます。デフォルトをプロキシにすると、主に直接接続の例外を定義する構成に向きます。デフォルトを直接接続にすると、明確な対象だけをプロキシへ送る構成に向きます。どちらも機能しますが、混在させると読みづらくなります。説明にはデフォルトアウトバウンドを明記し、「LANを直接接続」「指定ドメインをプロキシ」「特定プロトコルをブロック」のように目的ごとに名前を付けてください。意味の曖昧な番号だけを使うのは避けます。

ルールの検証では、再現可能な対象を使い、ログで実際に適用されたアウトバウンドタグを確認します。ウェブページが開くかどうかだけでは、直接接続とプロキシのどちらが正しいか判断できません。クライアントにルーティングデバッグログがある場合は、確認中だけログレベルを上げ、テスト後すぐに戻します。複数のルールを変更するときは、まとめて読み込むよりグループごとに有効化してテストする方が、競合を特定しやすくなります。

信頼できるルーティング体系には、明確なデフォルト動作、具体的な条件から広い条件へ並べた順序、識別しやすいアウトバウンドタグ、再現可能な検証対象が必要です。ルール数は成熟度の指標ではありません。説明でき、元に戻せることが重要です。

7. TUNモード：仮想NIC、権限、DNS経路

TUNとシステムプロキシの根本的な違い

システムプロキシは、アプリがOSのプロキシ設定を自ら読み取る必要があります。一方TUNは、仮想ネットワークインターフェースとルーティングテーブルを通じて、より広い範囲のIP通信を取り込みます。システムプロキシを無視するプログラムにはTUNが有効なことが多い一方、システム権限、仮想インターフェース、ルーティング競合、DNS経路、ローカルネットワークアクセスなどの変数も増えます。そのためTUNは、基本接続が失敗したときの万能な修復策ではなく、基本プロキシが安定した後に取り込み範囲を広げるための独立した方法です。

TUNを有効にしても、アプリがプロキシの存在を意識するとは限りません。OSが通信を仮想インターフェースへ送り、クライアントがそれをコアで処理できる接続へ変換してルーティングします。この処理はより低い層で行われるため、ブラウザー、コマンドラインツール、プロキシ設定に対応しない一部のプログラムもまとめて扱えます。ただし、仮想マシン、コンテナ、他のVPN系ソフトウェア、セキュリティソフトもルーティングテーブルを変更することがあり、複数のコンポーネントが同時に動くと優先順位の衝突が起こりやすくなります。

有効化前に比較用の基準を作る

TUNを有効にする前に、システムプロキシで現在のノード、サブスクリプション、ルーティングルールが使えることを確認し、TUNを無効にした状態の結果を記録します。次にアプリ内の手動プロキシを無効にし、同じリクエストが手動プロキシとTUNの両方に取り込まれないようにします。有効化後は、仮想インターフェースの作成、クライアントログの権限エラー、デフォルトルートの変更、LANアクセス、ドメイン解決を順番に確認します。すべて正常になってから、以前システムプロキシに従わなかったプログラムをテストしてください。

クライアントが権限の昇格を求める場合は、OSが提供する認証手順で許可します。権限不足は、仮想インターフェースの作成失敗、ルートの書き込み失敗、モードを有効にしてもすぐ無効になるといった形で現れます。これらはノードプロトコルとは関係がないため、サブスクリプションを変更しても改善しません。デスクトップでは、ほかの仮想ネットワークインターフェースが動作していないかも確認します。Androidでは、システムのVPN取り込み状態とバックグラウンド実行制限を確認してください。

  1. 重複する入口を無効にします。アプリ内の手動プロキシを整理し、明確な通信入口を1つだけ残します。
  2. TUNを有効にし、システムの許可を完了します。クライアントが仮想インターフェースを正常に作成できるか確認します。
  3. 基本ネットワークを確認します。ドメインへのアクセス、直接IPへのアクセス、LAN機器へのアクセスをそれぞれテストします。
  4. ルールの適用を検証します。TUNでも既存の直接接続、プロキシ、ブロックルールが想定どおり実行されることを確認します。
  5. 対象アプリをテストします。最後に、システムプロキシでは取り込めなかったプログラムを確認します。

DNSはTUNのトラブルシューティングで重要

TUNを有効にした後に「IPにはアクセスできるがドメインにはアクセスできない」場合、接続経路は存在するもののDNSに問題があることが多いです。DNSリクエストが想定した経路に入っていない、クライアントのDNS設定とシステム設定が競合している、ルーティングルールが名前解決をブロックしている、別のネットワークソフトがDNSを取り込んでいる、といった原因が考えられます。まずクライアントログで名前解決のタイムアウトを確認し、TUNを無効にした場合の結果と比較してください。ノード、DNSサーバー、ルーティングルールを同時に変更すると、どの変更が効いたのか判断できなくなります。

別の現象として、ドメインは解決できるのにルールが誤った対象へ適用されることがあります。TUN環境では、コアがスニッフィングによってドメインを復元する場合もあれば、解決後のIPだけを認識する場合もあります。現在のルーティング方式に照らして、ルールがドメインとIPのどちらに一致しているかを確認してください。ドメインによる分流が必須なら、DNSと通信の取り込み経路が十分な情報を保持できるようにします。対象アドレスが安定している場合は、明確なIPまたはネットワークルールを補助的に使えますが、アドレス変更による保守負担を考慮してください。

LANとスリープ復帰時の問題

TUNがルーティングを変更すると、ローカルプリンター、ストレージ、開発用サービスが誤ってプロキシへ送られることがあります。LANとプライベートアドレスは通常、広範なプロキシルールより前に置き、優先的に直接接続します。TUNを無効にしたときだけLANへアクセスできるなら、プライベートネットワークのルールとバイパス設定を確認し、ルール全体を直接接続に変更しないでください。機器名とLAN IPは別々にテストします。前者はローカルの名前解決、後者は主にルーティングに関係します。

PCのスリープ、ネットワークの切り替え、有線から無線への変更後は、古い仮想インターフェースやルートの状態がすぐ更新されないことがあります。クライアントは実行中のままでも、新しいリクエストがタイムアウトする場合があります。まずクライアントでTUNを無効化してから再度有効化し、インターフェースを再構築させます。それでも戻らなければ、コアを再起動してシステムルートを確認します。システムの再起動は最後に行ってください。すぐ再起動すると、最も重要なエラー状況が失われます。

TUN設定の成功基準は、スイッチが有効なままになることではありません。仮想インターフェース、DNS、ルーティングルール、LAN、対象アプリがすべて説明可能な結果を返すことが基準です。基本プロキシとTUNを段階的に検証すると、トラブルシューティングの時間を大幅に短縮できます。

8. 日常の保守：更新、ログ、バックアップ、障害の切り分け

クライアント、コア、サブスクリプションの更新を分けて考える

日常の保守には、グラフィカルクライアント本体、コアコンポーネント、サブスクリプション内容の3種類の更新があります。解決する問題はそれぞれ異なります。クライアント更新は画面、システム連携、設定管理を変える可能性があります。コア更新はプロトコル解析、通信機能、動作に影響します。サブスクリプション更新が変えるのはリモート設定の一覧だけです。問題が起きたら、最近変わった層を特定してください。サブスクリプション更新の失敗をクライアントのアップグレードが必要だと考えたり、ノード障害時にすべてのコンポーネントを同時に更新したりしないでください。

更新前に、現在使える設定、プロキシモード、重要なカスタムルールを記録します。更新後はまず既存設定で基準テストを行い、その後に新しい機能を確認してください。更新直後に新しいサブスクリプションを追加し、ルーティングを変更し、TUNを有効にすると、異常の原因を特定できません。長期利用する環境の保守では、すべての項目を追い続けることではなく、変更を制御することが重要です。

ログは時系列で読む

ログには通常、クライアント操作、コア起動、設定解析、DNS、ルーティング、接続エラーが含まれます。まず操作を行った正確な時刻を記録し、その前後の短い範囲だけを確認するのが効果的です。起動時は設定ファイルのパス、項目解析、ポート待受、権限を優先して確認します。接続時は名前解決、ハンドシェイク、タイムアウト、ルーティング先を確認します。サブスクリプション関連では、リクエストの状態と内容解析を確認します。最後の1行だけを切り出して判断しないでください。根本原因はもっと前に出ていることがあります。

ログレベルを上げると詳細を確認できますが、大量の記録がすぐに生成されます。問題を再現する前だけ一時的に上げ、明確なテストを1回終えたらすぐ収集して通常レベルへ戻します。ログを公開して相談する場合は、エラーの種類、時系列、必要な項目だけを残し、サブスクリプションURL、ノードアドレス、ユーザー識別子、ローカルフォルダーに含まれる個人名を隠してください。ログは経過を再現するためのものであり、設定のバックアップにしてはいけません。

現象 優先して確認すること 先に行わないこと
コアが起動しない 設定解析、ポート競合、ファイル権限 ノードを何度も変更して速度測定する
サブスクリプションの更新に失敗する URL、ネットワーク経路、返却形式、更新方針 クライアント全体を再インストールする
グローバルは正常だがルールモードが異常 ルールの順序、ドメインとIPの適用結果、デフォルトアウトバウンド インストール先を変更する
システムプロキシは正常だがTUNが異常 権限、仮想インターフェース、DNS、ルーティング競合 サブスクリプショングループを削除する

バックアップは復元に必要な情報を中心にする

バックアップする価値があるのは、サブスクリプショングループの構成、カスタムルーティングルール、クライアントの設定、ローカルの手動ノード、必要な設定メモです。サブスクリプションURLでリモートノードは復元できますが、ローカルの変更までは復元できません。バックアップファイルは管理された場所に保存し、公開共有しないでください。クライアントが設定のエクスポートに対応している場合も、対象範囲を先に確認します。ノードだけを出力するもの、ルーティングと画面設定を含むもの、さらに本機のパスを参照するものがあります。

復元時に既存の設定を一度にすべて上書きしないでください。まずクライアントをインストールして起動し、コアの基準動作を確認します。次にサブスクリプションを追加し、その後ルーティングを復元し、最後にTUNとスタートアップを設定します。各段階で一度起動してログを確認してください。異なるシステムや古い環境で作成したバックアップでも、互換性の問題が起きた段階を正確に特定できます。

最小構成で再現する

複雑な障害は、クライアント1つ、サブスクリプショングループ1つ、動作確認済み設定1つ、システムプロキシ、デフォルトルーティングに絞ります。自動選択、複雑なDNS、プロセスルール、LAN共有、TUNを無効にして再現します。最小構成で正常なら、高度な設定を1つずつ戻します。それでも失敗するなら、設定項目、ネットワーク、コアのログを確認してください。最小構成での再現は、機能を永久に削除することではなく、一時的に変数を減らす方法です。

ノード選択も、一覧の遅延値だけでなく実際の接続結果で判断します。遅延値は通常、特定の検査リクエストの往復時間を示すだけで、対象への接続、通信ハンドシェイク、継続的な通信性能を完全には表しません。選び方はノード選びの考え方を参照し、実際の利用性、プロトコル互換性、用途を重点的に比較してください。

保守の基本は変数を管理することです。更新を層別化し、ログを時系列で読み、バックアップを段階的に復元し、障害を最小構成まで絞る。この4つの習慣で、長期利用中に起きる多くの問題へ対応できます。

9. 応用への道筋：クライアントを使うだけでなく設定を説明できるようにする

第1段階：データの流れ全体を説明できるようにする

応用とは、すぐに大規模な設定を手書きすることではありません。第1段階では、アプリからリモートまでのリクエスト経路を説明し、各段階の確認方法を示せるようにします。アプリがシステムプロキシを読むか、ローカルポートが待ち受けているか、コアが正常に起動したか、ルーティングがどのアウトバウンドを選んだか、ノードの通信パラメータが完全か、DNSがどこで解決されるかを確認します。これらに答えられれば、「接続できない」という曖昧な問題を具体的な階層へ分解できます。

練習では、動作確認済みの同じ設定を使い、システムプロキシ、アプリの手動プロキシ、TUNをそれぞれテストしてログの違いを記録します。次にルールモードへ明確なドメインルールを1つ追加し、アウトバウンドタグの変化を確認します。目的は複雑な環境を作ることではなく、操作とログの対応関係を身につけることです。

第2段階：クライアントが生成した設定を読む

グラフィカルクライアントは最終的に、画面の項目をコア設定へ変換します。生成された設定をエクスポートまたは確認するときは、まずインバウンド、アウトバウンド、ルーティング、DNSの4部分を探し、画面設定と1つずつ対応させます。以下の例は、本機だけで待ち受けるSOCKSインバウンドを示します。項目を理解するための例であり、接続可能なリモートアウトバウンドを含まないため、完全な設定ではありません。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

tagは設定内で対象を参照するために使い、listenは待受アドレス、portはローカルポート、protocolはインバウンドの種類を指定します。待受アドレスをすべてのネットワークインターフェースに変更すると、LAN上の他の端末からそのポートへアクセスできるようになり、安全性の境界が変わります。明確な共有目的がない場合は、ループバックアドレスを維持してください。設定を学ぶときは既存項目の役割を理解することを優先し、出所不明のパラメータを「最適化」のために追加しないでください。

第3段階：XrayとV2Flyのコアの違いを比較する

XrayとV2FlyはいずれもProject Vに関連するエコシステムに属しますが、開発方針と機能構成は完全に同じではありません。クライアントは入れ物にすぎず、特定のプロトコル拡張や通信機能が使えるかどうかを決めるのは、コアとクライアント側の設定対応です。同じ共有リンクがクライアントによって異なる動作をする場合は、リンクが使用するプロトコルやセキュリティ機能を確認し、対象コアの対応状況を調べます。単純にプラットフォームの違いが原因だと考えないでください。

コアを比較するときは、実際の要件を軸にします。現在のサブスクリプションが使うプロトコル、VLESS、REALITY、XTLS関連機能への依存、クライアントが対応する設定を正しく生成できるか、ログから十分にトラブルシューティングできるかを確認します。現在の設定が双方に対応する一般的な機能だけを使っているなら、プラットフォームと保守方法に合うクライアントを選べば十分です。詳しい比較はXrayとV2Flyのコアの違いを参照してください。

第4段階：テスト可能なルール体系を作る

成熟したルーティングルールは、数ではなく、明確なデフォルト動作、グループの目的、検証方法で決まります。まずは3つのグループから始められます。LANとプライベートアドレスを直接接続し、明確なドメイン群を用途に応じたアウトバウンドへ送り、それ以外はデフォルト方針に任せます。各グループに再現可能なテスト対象を用意し、変更後にログの適用結果を確認します。新しいルールを追加する前に、どの問題を解決するのか説明してください。目的を説明できないルールは、長期設定へそのまま追加しないでください。

DNSの調整も具体的な問題を軸に行います。解析経路がルールの失敗、タイムアウト、結果の不一致を引き起こしていると確認できた場合に限り、問い合わせ方法やルーティングとの関係を変更します。DNS、スニッフィング、ルーティング方針、TUNを同時に複雑な構成へ変更すると、短期的には偶然動いても長期的には保守が難しくなります。応用力とは、変更範囲を絞り、その変更が必要な理由を説明できることです。

第5段階：自分用の運用ガイドを作る

個人用の運用ガイドは長くなくても構いませんが、クライアントとプラットフォーム、パッケージのアーキテクチャ、設定フォルダー、ローカルポート、サブスクリプショングループ、カスタムルール、TUNの有効状態、更新方法、復旧手順を含めてください。さらに、システムプロキシを確認するテストと、ルール適用を確認するテストを1つずつ用意します。端末の移行やアップグレードでは、このチェックリストに沿って復元すると、記憶に頼るより確実です。

環境に新しい問題が起きたら、追加ルールを導入する前に、運用ガイドへ現象と対処結果を追記します。記録を重ねると、自分の端末やアプリに合った安定した基準ができあがります。そうなれば、クライアントの画面が変わっても大きな影響はありません。判断の中心は、インバウンド、アウトバウンド、ルーティング、DNS、通信の取り込みだからです。

初心者から応用までの道筋は、まず最小限の通信経路を作り、次に通信の取り込み範囲を広げること。まずルールの適用結果を理解し、その後にルール数を増やすこと。まず復元可能な基準を作り、その後にクライアントとコアを更新することです。問題が起きたら、設定を闇雲に切り替えるのではなく、常にデータの流れへ戻って考えてください。