V2Ray入門から応用まで：サブスクリプション、ルーティング、TUN

基本概念：クライアント、コア、プロトコル、サブスクリプションを区別する

クライアントが操作を担い、コアが接続を担う

V2Rayを使う際に混同しやすいのは、クライアント、コア、プロトコル、サブスクリプションの4つです。クライアントはユーザーが直接操作するGUIで、サブスクリプションの保存、ノード選択、プロキシモードの切り替え、実行用設定の生成、ログ表示を担います。v2rayN、v2rayNG、v2flyNGはいずれもクライアントです。コアはバックグラウンドで設定を読み込み、接続の確立、通信の転送、名前解決、ルールとの照合を行います。代表的なコアにはV2FlyとXrayがあり、設定の考え方は似ていますが、対応プロトコルや項目の細部は異なる場合があります。

したがって、「クライアントにURLを追加できる」ことは、「現在のコアがそのURLを正しく実行できる」ことを意味しません。クライアントは共有URLやサブスクリプションの内容を認識し、パラメータをコア設定へ変換する必要があります。さらにコアが対応するプロトコル、トランスポート方式、安全設定も必要です。トラブル対応では、問題が追加段階、設定生成段階、実際の接続段階のどこで起きているかを先に切り分け、クライアントの再インストールを繰り返さないようにします。追加後にノードが表示されない場合は、サブスクリプション内容や解析が原因であることが多く、ノードはあるのに起動エラーになる場合は項目の互換性が疑われます。正常に起動するのに目的のアドレスへアクセスできない場合は、プロキシ、ルーティング、ネットワーク経路を確認します。

プロトコルは通信方式を定義し、トランスポート設定は組み合わせて一致させる

VMess、VLESS、Trojanなどは、クライアントとサーバー間で認証しデータをやり取りする方法を示します。速度のランクではなく、これだけで接続品質が決まるわけでもありません。同じプロトコルでもTCP、WebSocket、gRPCなどのトランスポート方式を組み合わせ、TLSやREALITYなどのセキュリティ設定を使うことがあります。アドレス、ポート、ユーザー識別子、トランスポート方式、ホスト名、パス、安全オプションは、サーバー側の設定と一つずつ一致させる必要があります。一項目だけ変更しても「似ているが使える」状態にはならず、通常はハンドシェイクに失敗します。

共有URLはこれらのパラメータを受け渡しやすいテキストにエンコードしたものです。サブスクリプションは複数の共有URLや構造化されたノード情報を、更新可能な1つのURLにまとめます。サブスクリプションURLそのものがノードなのではなく、リモート設定リストに近いものです。更新時、クライアントはまずリストを取得し、ノードを解析してからローカルのグループへ書き込みます。更新に成功しても、リストを取得・解析できたことを示すだけで、すべてのノードが接続できるとは限りません。逆に、一時的に更新できなくても、クライアントには直前に同期した設定が残っているため、既存ノードを引き続き使える場合があります。

システムプロキシ、ルーティング、DNSは別の層にある

システムプロキシは、プロキシ設定に対応するアプリがリクエストをクライアントへ渡すかどうかを決めます。ルーティングルールは、クライアントが受け取ったリクエストをプロキシ、直接接続、ブロックのどこへ送るかを決めます。DNSはドメインをアドレスへ変換し、ドメインルールの照合に関わることもあります。3つは分けて確認しましょう。ブラウザは使えるのに特定のプログラムだけ使えない場合、そのプログラムがシステムプロキシを読んでいない可能性があります。すべてのアプリがクライアントに入るのに一部のアドレスだけ経路が違う場合は、ルーティングの問題が考えられます。ドメインだけ失敗してアドレスへの直接アクセスに応答がある場合は、DNS経路を確認します。

クライアント選び：プラットフォーム、コア、管理方法

デスクトップ版はv2rayNを優先

v2rayNはWindows、macOS、Linuxに対応し、デスクトップ版のメインクライアントに適しています。サブスクリプションのグループ管理、ノード選択、システムプロキシ、ルーティング、TUN、ログを1つの画面で扱えるため、長期運用に便利です。Windowsでは新世代のクロスプラットフォームデスクトップUIと従来のWPF UIから選べます。基本的な役割は同じで、主な違いはUI技術と操作感です。macOSではプロセッサのアーキテクチャに合うインストーラーを選び、Linuxではディストリビューションに合うパッケージ形式を選びます。

複数のサブスクリプションを管理したい場合、仕事用と日常用でグループを分けたい場合、またはカスタムルーティングを学びたい場合は、v2rayNのデスクトップ管理が向いています。まず提供元ごとにサブスクリプションをグループ化し、その中からノードを選べます。これにより、ある提供元を更新しても、すべてのノードが追跡しにくい一覧に混ざりません。「グループは設定の提供元、ノードは接続先」と理解し、ノード名の頻繁な変更でグループ管理を代用しないことが大切です。

Android版はv2rayNGとv2flyNGから選ぶ

v2rayNGはXrayコアを採用しており、通常はAndroid版の第一候補です。v2flyNGはV2Flyコアを採用し、対応するコア機能や設定互換性が必要な場合に使えます。どちらもサブスクリプションの追加、ノード切り替え、VPNインターフェースによる通信の取り込みに対応しますが、メニュー名、ルーティング項目、コアの対応範囲は完全には同じではありません。デスクトップ版から出力した高度なルールを、モバイル版へそのまま移行できるとは限らないため、実際に認識される項目を基準にしてください。

インストールパッケージのアーキテクチャは端末に合わせる必要があります。比較的新しいAndroid端末の多くはarm64で、ユニバーサル版はアーキテクチャが不明な場合や他のアーキテクチャとの互換性が必要な場合に向いています。アーキテクチャはパッケージが動作するかどうかだけに影響し、サブスクリプション内容やプロトコルパラメータは変えません。arm64版を正常にインストールできるなら、接続問題を理由にユニバーサル版へ変える必要はありません。接続異常はログ、ノードパラメータ、ネットワーク条件から確認します。

クライアントの変更で設定問題を隠さない

同じ設定でもクライアントによって挙動が異なる場合がありますが、クライアント変更を最初のトラブル対応にしてはいけません。まずプロトコル、トランスポート、安全設定、エラーログを記録し、コアの機能差かどうかを判断します。特定のクライアントで設定を追加できない場合は共有形式が完全か確認します。追加できても起動に失敗する場合は生成された設定またはコアログを確認します。特定のネットワーク環境だけで失敗する場合は、クライアント非互換と即断せず、ネットワーク経路とDNSを比較します。

クライアントを決めたら、メインツールを1つに固定し、ログの場所、設定ディレクトリ、復元方法を把握することをおすすめします。複数のクライアント間で頻繁に設定を移すと、重複ノード、古いグループ、異なるルーティングの初期値が生じ、後の判断が難しくなります。デスクトップはv2rayNを管理の中心にし、モバイルはコアの要件に応じてv2rayNGまたはv2flyNGを選ぶ構成が分かりやすいでしょう。具体的なインストール先とシステムアーキテクチャは、プラットフォーム別にクライアントダウンロードページで確認できます。

インストールと初期設定：復元できる基準状態を先に作る

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

Windowsでは、デスクトップ版と従来のWPF版のどちらを使うかを先に決めます。異なるデスクトップOSで似た画面を使いたいならデスクトップ版、従来のWindows操作に慣れているならWPF版が向いています。macOSではApple SiliconとIntelを区別し、正しいアーキテクチャのインストーラーを選びます。間違えると起動できない、または追加の互換処理が必要になることがあります。Linuxではディストリビューションに応じてdebまたはrpmパッケージを使い、x64とarm64も区別します。Androidではまずarm64か確認し、不明な場合にユニバーサル版を検討します。

インストール先は、現在のユーザーに読み書き権限がある場所にします。クライアントは通常、サブスクリプション、ログ、ルーティング設定、画面設定を保存するため、厳しく制限されたディレクトリでは更新後に設定を書き込めないことがあります。Windowsのポータブル利用では、プログラムを一時解凍フォルダに置き続けないようにします。macOSでは初回起動後に設定を保存できることを確認し、Linuxではパッケージのインストール成功だけで判断せず、アプリメニューまたはターミナルから正常に起動できることを確認します。

初回起動では必要な項目だけ設定

v2rayNを初めて起動したら、まずUIの言語、設定の保存場所、ログの入口を確認し、高度な項目をすぐにすべて有効にしないでください。ルーティングは初期値を保ち、TUNは無効のまま、自動接続も設定せず、最小限の接続テストだけを行うのがおすすめです。基準状態は、クライアントが起動する、サブスクリプションを追加できる、選んだノードでコアが動作する、システムプロキシを有効にしたブラウザから目的のアドレスへアクセスできる、の4点です。これらが安定してから自動更新、スタートアップ、自作ルーティングを追加します。

システム時刻は見落としやすい基本条件です。安全な接続の中には時刻のずれに敏感なものがあり、端末の時刻やタイムゾーンが大きく間違っていると、証明書検証やハンドシェイクで問題が起きることがあります。まずシステムの自動時刻合わせを有効にし、その後でプロトコルパラメータを確認します。プロキシポートも他のローカルプログラムと競合しないようにします。ログにリッスンアドレスが使用中と出た場合は、古いクライアントを終了するか使用中のプログラムを特定します。ブラウザや他のアプリが古いポートを参照している可能性があるため、複数のポートを連続して変更しないでください。

設定ディレクトリと終了方法を把握する

グラフィカルなウィンドウを閉じても、クライアントのプロセスが終了したとは限りません。デスクトップクライアントがシステムトレイに常駐している場合、ウィンドウを閉じた後もコアやシステムプロキシが動き続けることがあります。インストール先の変更、プログラムファイルの置き換え、バックアップの復元を行う前に、トレイメニューから終了し、関連プロセスが終わったことを確認します。ウィンドウを閉じただけでディレクトリを移動すると、ファイルが使用中になる、設定の書き込みが中断される、システムプロキシが古いポートを指し続けるといった問題が起きます。

設定ディレクトリには通常、クライアント設定、ノードデータベース、サブスクリプション情報、ルーティングルール、ログが含まれます。バックアップはクライアントを完全に終了してから、現在のノードだけでなく設定ディレクトリ全体をコピーします。共有URLだけではグループ、自作ルーティング、画面設定を保存できず、プログラムディレクトリだけをコピーするとシステム側に保存されたユーザーデータが抜けることがあります。場所はプラットフォームやクライアントの形態で変わるため、まずクライアントの設定ディレクトリを開く機能やバックアップ機能を使い、実際のパスを記録してください。

初回インストール時の確認順
1. システムとプロセッサのアーキテクチャを確認
2. 長期利用する場所にインストールまたは解凍
3. クライアントを起動してログの入口を確認
4. ルーティングは初期値のまま、TUNは一旦無効にする
5. サブスクリプションを1つ追加してノードを1つ選ぶ
6. システムプロキシを有効にしてブラウザでテスト
7. クライアントを終了し、システムプロキシが復元されたことを確認

終了テストは非常に重要です。正常に終了した後も、システムがローカルプロキシポートを指していると、通常のネットワーク通信に影響が出ます。クライアントを再起動したときは、システムプロキシの状態と画面表示が一致しているか確認します。一致しない場合は、まずクライアントのシステムプロキシ解除機能を使い、その後システムのネットワーク設定を確認します。「端末を再起動すれば直る」を通常の対処にせず、プロキシの切り替えとプロセス状態を理解すれば、多くの場合は直接修正できます。

サブスクリプションとノード：追加、更新、グループ化、絞り込み

サブスクリプションの追加はノードを一度コピーする作業ではない

サブスクリプションURLはノード一覧を継続的に取得するためのものです。共有URLを1つずつ貼り付ける方法は一時的なテストに適していますが、長期利用ではサブスクリプションを専用グループに保存します。追加前にURLが完全か確認し、コピー時に前後の空白、改行、チャットツールが付けた句読点が混ざっていないか注意します。名前は「日常用サブスクリプション」「テスト設定」のように提供元や用途を表すものにします。ノードは更新されるため、現在のノード名をサブスクリプション名にしないでください。

v2rayNでサブスクリプションを追加したら、まず設定を保存してから更新を実行します。「サブスクリプションの追加」と「更新」を同じ操作だと考えると、URLだけ保存されてノードが生成されないことがあります。更新後は3点を確認します。対象グループが表示されるか、グループ内にノードがあるか、既存の手動ノードが独立したグループに残っているかです。更新後に一覧が空になっても、すぐ上書き更新を繰り返さず、まずサブスクリプションログを見て、応答が空なのか、形式を解析できないのか、グループの絞り込みで隠れているのかを判断します。

更新方針は変化と追跡しやすさを両立する

自動更新の間隔を短くしすぎないでください。サブスクリプションは通常、数分単位で更新する必要がなく、頻繁なリクエストに実益はほとんどありません。トラブル対応中にノード一覧が変わり続ける原因にもなります。提供元の更新頻度に合わせて数時間から1日程度に設定し、手動更新も残しておきます。特定のノードを調べるときは、自動更新を一時停止するか、ノードの主要パラメータを記録し、テスト中に名前、アドレス、並び順がリモートリストで変わらないようにします。

サブスクリプションの更新とノードのテストは別の操作です。更新は設定リストを取得できるか確認するだけで、接続性テストでは具体的なノードを使用します。結果もTCP接続、実際の接続遅延、ダウンロード速度に分けて見ます。TCP接続はアドレスとポートが応答したことしか示しません。実際の接続遅延にはプロトコルのハンドシェイクも含まれ、ダウンロード速度は帯域、サーバー負荷、対象リソースに左右されます。数字1つだけで並べ替えないよう、遅延テストの違いと実施順も参照してください。

グループ化、重複排除、無効な設定への対応

複数のサブスクリプションはそれぞれ別のグループにし、ノードをすべて既定グループへコピーするのは避けます。グループがあれば、「このノードはどこから来たか」「どのサブスクリプションの更新で変わるか」「提供元を削除したとき手動設定まで消えないか」を把握できます。手動追加ノードも専用グループに入れ、サブスクリプション更新で同名項目に上書きされないようにします。クライアントに別名、アドレス、全パラメータによる重複排除機能がある場合は、先にルールを確認します。同名でもパラメータが異なるノードがあり、名前が違っても同じ設定を指す場合があります。

無効なノードをすぐに1つずつ削除する必要はありません。まずサブスクリプションを更新し、リモートリストから消えているか確認します。その後ログから、継続的な無効状態なのか、現在のネットワークで一時的に到達できないだけなのかを判断します。比較用に残す場合は手動グループへコピーし、日付や用途を付けます。無効な設定を長くためると誤選択や一括テストの負担が増えるため、定期的に有効なサブスクリプションに属さない孤立ノードを整理します。

プロキシモード：システムプロキシ、アプリプロキシ、接続確認

システムプロキシの影響は対応するアプリに限られる

v2rayNでシステムプロキシを有効にすると、OSのHTTPまたはSOCKSプロキシがクライアントの待ち受けポートを指すようになります。ブラウザやシステムのネットワーク設定に従う多くのアプリはリクエストをクライアントへ渡しますが、独自のネットワークスタックを使うプログラムはシステムプロキシを無視することがあります。そのため、ブラウザは正常なのにコマンドラインツールや特定のアプリだけが直接接続することがあります。これはルーティングルールの失敗ではなく、通信がそもそもクライアントに入っていない状態です。

アプリがプロキシに入っているかを確認する最も直接的な方法は、クライアントのアクセスログを見ることです。対象アプリを操作しても関連する接続がログにまったく出ない場合は、アプリ側のプロキシ設定を確認するか、より広い通信を取り込む必要があればTUNモードを検討します。ログに接続が出ているのに出口が想定と違う場合は、ルーティングを確認します。ページが開くかどうかだけでシステムプロキシの状態を判断しないでください。キャッシュ、既存接続、アプリ独自のプロキシが結論を左右することがあります。

PAC、自動設定、グローバルプロキシの違い

クライアント画面の「自動設定」「PAC」「グローバル」は、システム層でリクエストをローカルプロキシへ渡す方法を示すもので、コアのルーティングモードとは別です。PACはルールスクリプトでシステムプロキシを使うドメインを決めます。グローバルシステムプロキシは、システムプロキシに対応するリクエストをすべてクライアントへ入れます。ただし、クライアントに入った後でコアのルーティングにより直接接続と判定されることはあります。つまり「システムプロキシのグローバル」と「ルーティングのグローバルプロキシ」は別のスイッチです。

初回テストでは、システムプロキシを有効にし、コアのルーティングは初期ルールのまま、パラメータが完全だと確認したノードを1つ選ぶ構成がおすすめです。アプリがシステムプロキシに対応しているか調べる場合は、一時的にグローバルシステムプロキシを使い、ログを確認します。検証後は日常のモードへ戻します。PAC、ルーティングルール、ノードを同時に頻繁に切り替えると、どの変更が結果に影響したのか分からなくなります。

既存接続、キャッシュ、確認方法

ノードやルーティングモードを切り替えても、確立済みの長時間接続がすぐ移行するとは限りません。ブラウザが古い接続を再利用したり、DNSが以前の解析結果を保持したりすることがあります。テストでは対象ページの既存接続を閉じ、必要ならアプリを再起動して新しいリクエストを送ります。ページの再読み込みだけでは接続が再利用されることもあるため、2つのノードを比較するときは同じ対象、同じアプリ状態、近い時間帯で行います。

WindowsでローカルDNSキャッシュを消去する必要がある場合は、システムコマンドを使えますが、ノードを切り替えるたびに必要な操作ではありません。ドメインの解析結果が明らかに古い、DNS設定を変更しても以前のアドレスが使われるといった場合に限り実行します。

ipconfig /flushdns

macOSとLinuxのDNSキャッシュはシステムサービスが管理しており、コマンドはOSのバージョンやディストリビューションによって異なります。むやみにコマンドを実行するより、まず問題が本当に名前解決層で起きているかを確認する方が確実です。同じドメインがクライアントログで解決されているか、想定したルールに一致しているか、既知のアドレスを直接使うと現象が変わるかを調べます。ドメインとアドレスで結果が異なる場合は、システムが使う名前解決サービスに合わせてキャッシュを処理します。

クライアントを終了する前にシステムプロキシを元に戻してください。特にプログラムが異常終了した後や強制終了した後は重要です。クライアントが動いていないのにシステムプロキシがローカルポートを指していると、アプリの多くがインターネットに接続できなくなります。まずシステムのネットワーク設定でプロキシを無効にし、その後クライアントを再起動して終了時の挙動を確認します。基本的なプロキシ経路が安定してからルーティングとTUNを設定すると、変数を大幅に減らせます。

ルーティング：ルール順序、照合条件、確認方法

ルーティングルールは上から順番に照合される

ルーティングの目的は、異なるリクエストを異なる出口へ振り分けることです。代表的な出口にはプロキシ、直接接続、ブロックがあります。ルールは通常、上から順に照合され、先に一致したルールが適用されると後続ルールは処理されません。そのため、ルールの内容が正しくても位置が間違っていれば、期待と異なる結果になります。たとえば範囲の広いドメインルールを先に置くと、後ろにある特定ドメイン向けの例外ルールは実行されない可能性があります。

ルールを設計するときは、明確で範囲の狭い例外を前に置き、範囲の広い既定ルールを後ろに置きます。ドメイン、IP、ポート、ネットワーク種別、プロセス名は異なる照合軸です。論理関係を理解しないまま条件を増やしすぎないでください。設定によっては、1つのルール内の複数項目をすべて満たす必要があり、別のクライアント画面では条件が独立ルールとして展開されます。外部ルールを追加した後は、画面上のルール名だけでなく、クライアントが最終的に生成した設定を確認します。

ドメインルールとIPルールの境界

ドメインルールは、クライアントが元のドメイン名を確認できることが前提です。アプリがIPへ直接接続する場合や、クライアントに入る前にドメインが解決されている場合、ルールはIPに基づいてしか判断できません。IPルールは名前解決の結果やアドレスの変化にも左右され、同じドメインでも時間によって異なるアドレスが返ることがあります。比較的安定した方針は、明確なサービスにはドメインルール、LANや予約アドレスにはIPルールを使い、最後に未一致の通信を既定の出口で受けることです。

よく使われるドメイン照合には、完全一致、サブドメインのサフィックス、ルールセットがあります。完全一致は指定したホストだけに適用され、サフィックスルールはすべてのサブドメインを含むため範囲が広くなります。ルールセットは特定種類のドメインを管理しやすくしますが、更新元と収録範囲を把握しておく必要があります。名前だけで内容を推測しないでください。ルール変更後はログで実際の一致項目を確認し、ドメイン、IP、既定ルールのどれで通信が出ていったのかを判断します。

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

この例では、まずLANと予約アドレスを直接接続し、次に指定ドメインをプロキシへ送り、最後に未一致のTCPとUDPをプロキシ出口へ渡します。実際にクライアントが生成する設定では、出口タグの名前が異なる場合があるため、例のタグを既存設定へそのままコピーしないでください。まず現在のアウトバウンド項目のtagを確認し、ルーティングルールから既存の値を参照します。タグの綴りが一致しないと、コアが設定を読み込めない、またはリクエストが既定の出口へ送られることがあります。

既定ルールから例外を少しずつ追加する

安定したルーティング設定は、単純な構造から始めます。まずクライアントの「LANと中国本土を迂回」などの既定プリセットで基本動作を確認し、その後、明確なルールを少数ずつ追加します。ルールを1組追加するたびに、対象アドレスでテストして一致結果を記録します。大量のルールを一度に追加してからトラブル対応を行うと、順序、データセット、名前解決、出口タグのどれが衝突の原因か判断できません。

プロセスによる振り分けは、システムプロキシに従わないものの、クライアントがプロセス情報を認識できるデスクトップアプリに適しています。これはドメイン振り分けとは異なる問題を解決します。プロセスルールはアプリの送信元で出口を決め、ドメインルールはアクセス先で出口を決めます。同じアプリでもアクセス先ごとに方針を変えるならドメインまたはIPルールを中心にし、あるアプリの全通信を固定出口へ送りたいならプロセスルールが直接的です。TUN使用時は、プロセス識別能力がプラットフォームの権限やクライアントの実装にも左右されます。

ルールの検証では、ログにある対象、インバウンド、一致したルール、アウトバウンドを確認します。最終ページの表示だけでは通信経路を確定できません。変更後は新しい接続を作り、直接接続になる対象、プロキシになる対象、LANの対象を1つずつテストします。3種類すべてが想定どおりなら、ルール全体が広範囲の項目に覆われていないと判断できます。設定ファイル各部の構造は、inbounds、outbounds、routingを順に読み解くも参照してください。

TUNモード：取り込み範囲、DNS、互換性

TUNはシステムプロキシで拾えない通信に対応する

TUNモードは仮想ネットワークインターフェースで、より広い範囲のシステム通信を受け取ります。システムプロキシを読まないアプリ、UDPを扱うプログラム、ルーティングを一元的に適用したい場合に適しています。ただし「高速モード」ではなく、無効なノードを自動修正するものでもありません。TUNを有効にするとネットワークスタック、DNS、ルーティングテーブルという3つの変数が増えるため、通常のシステムプロキシが動作することを確認してから使います。基礎となるノード接続が失敗している状態でTUNを有効にすると、症状が複雑になるだけです。

TUNを有効にすると、仮想インターフェースの作成やシステムルートの変更のため、クライアントが権限昇格を求めることがあります。権限不足では、仮想インターフェースの作成失敗、ルート書き込み失敗、起動後に通信がないといった症状が出ます。具体的にどの段階で失敗したかをクライアントログで確認し、スイッチがオンになっているかだけで判断しないでください。Windows、macOS、Linuxでは仮想インターフェースとシステム権限の扱いが異なります。OSやセキュリティポリシーの更新後に、再承認が必要になることもあります。

厳格なルーティングとLANのバイパス

TUNの取り込み範囲を広げたら、LAN通信をどう扱うか明確にします。プリンター、ネットワークストレージ、ルーターの管理アドレス、ローカル開発サービスは通常、直接接続が必要です。ルーティングではLANと予約アドレスを先に許可し、リモートプロキシへ送らないようにします。TUN有効後にローカルデバイスへ接続できなくなった場合は、まずプライベートアドレスのルールが存在し、広範囲のプロキシルールより前にあるかを確認します。その後、仮想インターフェースによってLANセグメントへの経路が変わっていないかを調べます。

厳格なルーティングはTUNを迂回する通信を減らしますが、仮想化ソフト、企業ネットワーククライアント、コンテナネットワーク、他のネットワークフィルターと衝突することがあります。衝突時にすべての安全オプションをすぐ無効にせず、どのルートまたは仮想アダプターが重複しているかを確認します。TUN有効前後のルーティングテーブルの差分を記録し、迂回対象のネットワークやインターフェースの優先度を一つずつ調整します。複数の仮想ネットワークツールを同時に動かすと、最後に起動したプログラムが既定ルートを書き換え、起動順で結果が変わる場合があります。

TUNにおけるDNS経路

TUNモードではDNSリクエストもクライアントに取り込まれることがあります。名前解決の結果は接続先だけでなく、IPルーティングの照合にも影響します。FakeDNSを使う設定では、クライアントがまず予約アドレスをアプリへ返し、内部で元のドメイン名を復元して実際の出口を選びます。ドメイン情報を保ちやすい一方、実IPを必要とするアプリに合わないことがあります。ドメインは解決できるのにアプリ接続が異常な場合は、すぐノードを替えず、FakeDNSの挙動が関係していないか確認します。

FakeDNSを使わない場合は、DNSサーバーへのリクエストを直接接続とプロキシのどちらに送るか明確にし、ループを防ぐ必要があります。DNSリクエストがプロキシへ送られ、同じDNS結果がプロキシ接続の確立にも必要になる構成です。クライアントの既定設定は通常、基本的なループを避けます。自作設定では、ノードサーバーのアドレスを解決できるブートストラップDNSを残してください。ノードアドレスがドメイン名の場合は特に重要です。

安全な有効化と復元手順

有効化する前に現在の設定を保存し、ルートを変更する他のネットワークツールを終了し、通常のシステムプロキシで使えるノードを記録します。その後TUNを有効にし、仮想インターフェースが作成されたことを確認してから、LAN、名前解決、TCP、UDPのアプリをテストします。失敗したら、まずTUNを無効にして基本ネットワークが戻るか確認します。無効にしても異常が続く場合は、クライアントを終了し、残った仮想インターフェース、システムプロキシ、既定ルートを確認します。ネットワークが復旧していない状態でクライアントを何度も再インストールしないでください。残ったルートは通常、再インストールでは解決しません。

日常のメンテナンス：更新、バックアップ、ログ、速度トラブル対応

クライアント更新とサブスクリプション更新を分ける

クライアント更新では、画面、設定変換のロジック、コアの管理方法が変わります。サブスクリプション更新で変わるのはノード一覧だけです。両者は別々に実施し、復元手段を残します。クライアントを更新する前にプログラムを終了し、設定ディレクトリをバックアップして、現在使えるモードを記録します。更新後は元のノードと元のルーティングで先にテストし、同時にサブスクリプションを更新しないでください。異常が出ても、プログラム更新とリモート設定変更のどちらが原因か判断できます。

サブスクリプションを更新するときは、グループ構成を保ち、新規追加、削除、名前変更を確認します。よく使うノードが消えた場合は、まず提供元が一覧を変更したか確認し、古いキャッシュからメイングループへ何度もコピーしないでください。短期間の比較用に旧設定を残す必要があれば、手動グループへコピーして用途を付けます。比較が終わったら早めに削除し、古いパラメータを誤選択しないようにします。

バックアップ内容と復元テスト

有効なバックアップには少なくとも、サブスクリプション設定、手動ノード、ルーティングルール、クライアント設定、必要なローカル設定を含めます。ログは通常すべてを長期保存する必要はありませんが、安定して再現する問題がある場合は、起動時とエラー発生時を含む部分を残します。バックアップはプログラムディレクトリとは別の場所に置き、クライアント終了後に作成して、書き込み中の不整合を減らします。

バックアップを作るだけで復元を試していなければ、完全かどうか確認できません。更新前に設定ディレクトリの場所を記録し、バックアップに最近変更したグループやルーティングファイルが存在するか確認します。復元時は動作するクライアントを先にインストールし、プログラムを終了した状態で設定を戻し、その後既定ルーティングから検証します。新旧の設定ディレクトリを何度も混ぜて上書きすると、クライアントが最終的にどのファイルを読んだのか分からなくなります。

ログは最初のエラーから読む

コアログでは、1つの根本エラーに続いて連鎖的な情報が何行も出ることがあります。たとえば設定項目が無効だとコアが終了し、その後クライアントがローカルポートへの接続失敗を報告し続けます。対処すべきなのは最初に出た設定エラーであり、最後の「接続拒否」ではありません。読むときはコアの起動箇所から始め、設定読み込み、待ち受けポート、DNS初期化、アウトバウンド接続、プロトコルのハンドシェイクを順に確認します。

ログを共有する前に、サブスクリプションURL、ユーザー識別子、サーバーアドレスなどの設定内容を削除し、エラーの種類、発生順序、必要な前後関係だけを残します。トラブル対応に完全な設定を公開する必要はありません。同じエラーが繰り返される場合は、「サブスクリプション更新後」「TUN有効後」「特定ノードだけ」のように操作条件を記録します。最後の1行だけを切り取るより、発生条件の方が判断材料になります。

速度低下はローカル、ノード、回線に分けて調べる

速度問題は、最初から何度も速度測定して解決しようとしないでください。第1段階はローカル設定です。グローバルプロキシを誤って使っていないか、大容量通信が不適切な出口に送られていないか、TUNが他の仮想アダプターと衝突していないか、端末でバックグラウンドダウンロードが動いていないかを確認します。第2段階はノード比較です。同じ時間、同じ対象、同じプロキシモードで2つのノードをテストします。第3段階は回線です。時間帯や接続方法を変えて比較し、混雑との関係を判断します。

遅延が低くてもダウンロード速度が速いとは限りません。遅延は接続やリクエスト1回の待ち時間を示し、スループットは帯域、輻輳制御、パケットロス、サーバー負荷の影響を受けます。動画の再生が止まる原因には、DNS、分割転送、長時間接続の安定性もあります。詳しい切り分けはV2Rayの速度低下を層別に調べるを参照してください。テストでは一度に1条件だけ変え、ノード、モード、対象、時刻を記録します。

応用への道筋：クライアントを使う段階から設定を読み解く段階へ

まずインバウンド、アウトバウンド、ルーティングの関係を理解する

応用学習は、最初からすべてのJSON項目を暗記する必要はありません。まず3段階のモデルを作ります。インバウンドがアプリの通信を受け取り、アウトバウンドが通信の出方を決め、ルーティングが両者の間で行き先を選びます。システムプロキシは通常、ローカルHTTPまたはSOCKSインバウンドに接続します。TUNは仮想ネットワークカードのインバウンドに対応します。プロキシノード、直接接続、ブロックはそれぞれ異なるアウトバウンドです。ルーティングルールはドメイン、IP、ポート、ネットワーク、プロセス情報に基づき、リクエストを特定のアウトバウンドへ渡します。

このモデルを理解すると、画面の項目を設定構造へ対応付けられます。ローカル待ち受けポートの変更はインバウンドの調整、ノード切り替えはプロキシアウトバウンドのパラメータ変更、LANのバイパスはルーティングルールの調整、TUNの有効化は別種のインバウンドの追加または有効化です。エラー時も、すべてを「ノードが使えない」と考えず、どの部分が成立していないかをログから判断できます。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

この例は、ローカルホストだけで待ち受けるSOCKSインバウンドと、直接接続・ブロックという2つの基本アウトバウンドを示します。完全なプロキシ設定ではなく、サブスクリプションが生成するノードアウトバウンドの代わりにもなりませんが、項目の関係を見るには適しています。待ち受けアドレス127.0.0.1はローカル接続だけを受け付けます。別のアドレスに変えるとアクセス範囲が広がる可能性があるため、端末のファイアウォールとネットワーク境界も考慮してください。クライアントが生成したファイルを手動変更する前に、次回起動やノード切り替えで上書きされないか確認します。

最小構成で再現する方法を身につける

複雑な障害には、設定を絞り込むのが最も効果的です。まずノードを1つ、ローカルインバウンドを1つ、最も単純な既定ルーティング、明確なDNS設定だけ残し、問題が続くか確認します。最小構成が使えるなら、サブスクリプショングループ、自作ルール、TUN、プロセス振り分け、自動更新を1つずつ戻します。どの段階で再発したかが分かれば、その層を集中的に調べます。最小再現は元の設定を削除することではなく、バックアップを取ってから複製で行います。

プロトコルの問題も、項目をグループに分けて検証します。まずアドレス、ポート、ユーザー識別子、次にトランスポート方式、最後にTLS、REALITY、ホスト名、パスなどの組み合わせを確認します。不明なままランダムな値を試さないでください。これらの項目はサーバー側の設定で決まります。ログにハンドシェイク、証明書名、トランスポートパスのエラーが出たら、ルーティングルールではなく該当するパラメータグループを確認します。

自分用の変更記録を作る

既定プリセットから自作ルールへ設定を発展させるときは、簡単な変更記録を残します。日付、目的、対象ルール、検証対象、戻し方を記録するだけで十分です。たとえば「ローカル開発ドメインに直接接続ルールを追加し、ローカルサービスと一般サイトを確認」「特定アプリにプロセスルールを追加し、失敗時は削除」といった内容です。この記録があれば例外ルールを置いた理由を説明でき、数か月後に必要なルールを不要なものとして削除するのを防げます。

設定ファイルを手動調整するときは、まずフォーマット検証ツールでJSON構文を確認し、次にタグの参照を確認します。JSONにはコメントを記述できず、配列の最後に余分なカンマも置けません。構文が正しくても意味的に有効とは限りません。ルーティングが存在しないアウトバウンドタグを参照している、ポートが使用中、プロトコル項目の階層が誤っている、といった場合もコアは起動できません。クライアントログに表示される設定パスとエラー位置を主な手がかりにします。

完全なトラブル対応ツリー

1. クライアントが起動しない：システムアーキテクチャ、ディレクトリ権限、依存関係、古いプロセスの占有を確認します。
2. サブスクリプションを更新できない：URLの完全性、応答、解析形式、対象グループを確認します。
3. コアが動作しない：最初の設定エラーから確認し、ポート、項目、コアの対応状況を調べます。
4. アプリのログが出ない：システムプロキシとアプリのプロキシ対応を確認し、必要ならTUNを検討します。
5. ログは出るが出口が違う：ルールの順序、ドメインとIPの条件、アウトバウンドタグを確認します。
6. ドメインだけ失敗する：DNSの取り込み、キャッシュ、ブートストラップ解決、FakeDNSの互換性を確認します。
7. 接続できるが速度が遅い：ローカル設定、ノード負荷、回線の変動に分けて比較します。

この応用ルートを終えると、4つの問いに自分で答えられるようになります。通信はどの入口から入り、どのルールに一致し、どの出口から出て、どの段階で失敗したのかです。クライアント画面は日常操作の中心として使い続け、設定ファイルとログは挙動を説明するために使えばよく、応用のためにGUIクライアントを手放す必要はありません。初回インストール項目を確認し直す場合はv2rayN初回インストール設定チェックリストを、最短の操作手順をやり直す場合はクイックスタートガイドを参照してください。