V2Rayをゼロから使いこなす完全ガイド

クライアント、コア、設定ファイルの役割

日常的にV2Rayクライアントと呼ばれるものは、通常、グラフィカルインターフェース、プロキシコア、設定データの3つで構成されます。インターフェースはサブスクリプションの受け取り、ノードの管理、モードの切り替え、ログの表示を担当します。コアはローカルポートの待ち受け、アウトバウンド接続の確立、ルールに基づくルーティングを担当します。設定データは、インバウンド、アウトバウンド、DNS、ルーティングの関係を記述します。障害が起きたら、何度も再インストールするより、まずどの層の問題かを切り分けるほうが効果的です。画面が開くのは管理層が正常というだけで、「選択済み」と表示されてもアウトバウンドのハンドシェイク成功を意味しません。実際の接続結果は、テストリクエストと実行ログを合わせて確認してください。

v2rayNはWindows、macOS、Linux向けデスクトップ環境で第一候補となるグラフィカルクライアントで、XrayやV2Flyなどのコアに対応した設定を管理できます。v2rayNGはAndroid向けで、一般的にXrayコアを使用します。v2flyNGもAndroid向けですがV2Flyコアを採用しており、対応する設定をすでに持っているユーザーや、V2Flyの設定仕様を維持したいユーザーに適しています。3つの名称に含まれる「クライアント」と「コア」は同じ意味ではありません。サブスクリプション内のプロトコルは、現在のコアが対応している場合にのみ接続を確立できます。画面にノードが表示されるかどうかだけでは判断できません。

ウェブページへのアクセスで通る経路

ブラウザでウェブページを開く場合、アプリはまずドメインをDNSに渡して解決し、システムプロキシ、アプリ内プロキシ、TUNの有効状態に応じて、リクエストをローカルプロキシの入口へ送るかどうかを決めます。クライアントに入った後、ルーティングモジュールがドメイン、宛先アドレス、ポート、ネットワーク種別、プロセス情報などに基づいてアウトバウンドを選択します。その後、プロキシアウトバウンドがノードのパラメーターを使ってリモートサービスとの接続を確立し、レスポンスを元の経路で返します。どこか1つの設定が誤っているだけでも「ページを開けない」と表示されますが、原因の層は異なります。DNSの失敗では利用可能な宛先アドレスが得られないことが多く、システムプロキシが有効でなければリクエストはコアに入りません。ルーティングの誤判定では誤ったアウトバウンドへ送られ、ノードのハンドシェイク失敗は接続や認証に関するエラーとしてログに残ります。

そのため、トラブル対処ではデータフローに沿って近い側から確認します。まずコアが起動し、ローカルポートを待ち受けていることを確認し、次に対象アプリが実際にその入口を使っているかを確認します。その後DNSとルーティングの判断を調べ、最後にノードと回線を評価します。接続確認の代わりに速度テストだけを行うと、原因を取り違えやすくなります。あるノードでTCPテストを完了できても、到達可能なポートがあることしか分かりません。プロトコルのハンドシェイク、DNSの正しさ、対象サイトが意図したとおりに振り分けられているかは、実際のリクエストとログで確認する必要があります。

プロトコル、トランスポート層、セキュリティ層を混同しない

VMess、VLESS、Trojanなどは主にプロキシプロトコルと認証方式を表します。TCP、WebSocket、gRPCなどはデータの運搬方法を表し、TLS、REALITYなどはハンドシェイクと暗号化層に影響します。サブスクリプションはこれらのパラメーターをノードとして組み合わせます。クライアントに取り込んだ後は、サーバー側が要求する対応関係を維持してください。手動編集では、アドレス、ポート、ユーザー識別子、トランスポート方式、ホスト名、パス、セキュリティ層のどれか1つが一致しないだけでも、タイムアウト、ハンドシェイク失敗、認証拒否が起こります。プロトコル名からトランスポートパラメーターを推測したり、「最適化」のために複数の項目を同時に変更したりしないでください。

「サブスクリプション管理」と「個別ノード設定」も区別する必要があります。サブスクリプションは、サービス提供者が管理するノード記述の集合です。更新するとノードが追加、削除、変更されることがあります。個別ノードは、クライアントで現在選択できる具体的なアウトバウンドです。サブスクリプション内のノード名を手動で変更しても影響は通常小さいですが、アドレス、ポート、プロトコルパラメーターを直接変更すると、次回更新時に上書きされる可能性があります。長期的に保持したいローカルルーティング、DNS、プロキシモードは、サブスクリプションの内容に混ぜず、クライアントの独立した設定欄に保存してください。この層別の理解ができれば、以降の各操作の位置づけも明確になります。ダウンロードページはソフトウェアの入手先、サブスクリプションはアウトバウンド情報、システムプロキシまたはTUNはトラフィックの入口、ルールは行き先、ログは経路全体の再現を担います。

プラットフォームとコアの要件で選ぶ

デスクトップ環境ではv2rayNを第一候補にします。Windowsユーザーはデスクトップ版と従来のWPF版から選べます。デスクトップ版は新世代のクロスプラットフォームUIを採用し、異なるデスクトップOSで似た操作感を保ちたいユーザーに適しています。従来のWPF版は、従来のWindowsインターフェースや操作手順に慣れているユーザー向けです。macOSではApple SiliconまたはIntelチップに合うインストーラーを選び、Linuxではディストリビューションのパッケージ体系に応じてdebまたはrpmを選んだうえで、x64またはarm64のアーキテクチャも確認します。すべての入口はクライアントダウンロードに集約されています。他のプラットフォーム向けインストーラーを改名して無理に実行しないでください。

Androidではv2rayNGを第一候補とします。サブスクリプションにXrayの機能を使うノードが含まれる場合に特に適しています。v2flyNGはV2Flyコア向けの選択肢です。一般的な端末ではarm64版を優先し、アーキテクチャを確認できない場合やインストールに失敗した場合にユニバーサル版を検討します。どちらのクライアントも一般的なサブスクリプションや共有リンクを読み込めますが、対応するコアの範囲は完全には同じではありません。選ぶ際は画面の名称ではなく、サブスクリプションに含まれるプロトコルとトランスポートを確認してからクライアントを決めてください。

インストール前にシステムアーキテクチャを確認

Windowsでは「設定—システム—システム情報」でシステムの種類を確認できます。macOSでは「システム情報」でチップ名を確認できます。Linuxではターミナルからアーキテクチャを読み取れます。アーキテクチャを確認する目的は、複雑なパッケージを選ぶことではなく、インストーラーが起動しなかったり、実行後に対応コンポーネントが見つからなかったりする事態を避けることです。Linuxでよく使うコマンドは次のとおりです。出力がx86_64ならx64、aarch64またはarm64ならarm64を選びます。

uname -m

# Debian、Ubuntuなどでパッケージアーキテクチャを確認
dpkg --print-architecture

# rpmパッケージ体系でマシンアーキテクチャを確認
rpm --eval '%{_arch}'

インストール先や解凍先は固定し、書き込み可能な場所にして、頻繁に移動しないでください。クライアントは通常、サブスクリプション、ログ、ルーティングルール、画面設定も保存します。更新のたびに新しいディレクトリへ移して設定を移行しないと、「ノードが突然消えた」ように見えることがあります。デスクトップ版を初めて起動したら、まず画面にコアの状態とログの入口が表示されることを確認し、すぐに複数のサブスクリプションを取り込んだりTUNを有効にしたりしないでください。モバイル端末で初めて接続すると、システムレベルのネットワーク接続許可が表示されます。これはトラフィックをクライアントへ渡すために必要な手順です。許可後はバッテリー管理も確認し、バックグラウンド動作が早期に停止されないようにします。

初回起動を3つの確認ポイントに分ける

1つ目は「クライアントが正常に開くか」で、アーキテクチャ、実行環境、権限の問題を見つけます。2つ目は「コアが起動するか」です。ノードがなくても、ポート競合、設定解析エラー、コンポーネント不足が発生してはいけません。3つ目になって初めて「ノードを取り込んで接続できるか」を確認します。このように分ければ、2段階目でエラーが起きたときにサブスクリプションを疑わずに済みます。デスクトップ版ではローカルの待ち受けポートが他のプロキシソフトと競合していないかも確認してください。ネットワークツールを複数同時に動かすと、同じポートが占有されやすくなります。

クライアントをアップグレードする前に、実行中のコアを終了し、クライアント設定ディレクトリのバックアップを保存します。アップグレード後は、既存のサブスクリプションとルーティングが残っているか確認してから、通常のプロキシモードで接続テストを行います。アップグレードと同じ日にクライアント、コア、DNS、TUNを一度に変更しないでください。問題が起きたときに因果関係を追跡しにくくなります。システムポリシーによってインストールが阻止された場合は、まずダウンロードしたプラットフォームとアーキテクチャが正しいか確認し、OSの通常のソフトウェア許可手順に従って対処してください。不明なシステムファイルを変更してエラーを回避しないでください。

インストール後の最終確認基準はシンプルです。クライアントが安定して起動し、コアのログに起動エラーが繰り返し出ず、ローカルプロキシポートが待ち受け状態にあり、設定ディレクトリの場所が明確で、クライアントを完全に終了する方法を把握していることです。これらを済ませてからサブスクリプションへ進めば、ソフトウェアのインストール問題をノードの問題と取り違えずに済みます。一度だけ接続したい場合はクイックスタートへ進み、複数のサブスクリプションを長期管理する場合は、次章で命名、更新、復元のルールを整えます。

サブスクリプション取り込みの正しい順序

サブスクリプションURLは、本質的にはクライアントが定期的に読み取る設定ソースです。取り込むときは、まずクライアントのサブスクリプション管理欄でURLを追加し、提供元と用途を識別できるローカルメモを付けてから、1回更新します。更新に成功するとノードが該当グループに入ります。その後でノードを1つ選び、接続を開始してください。サブスクリプションURLをブラウザのアドレスバーへ直接貼り付けたり、公開ページやスクリーンショットで完全なURLを表示したりしないでください。URLにはサブスクリプションを識別するパラメーターが含まれることがあります。

同じクライアントで複数のサブスクリプションを管理できますが、初回設定で多くのソースを一度に取り込むのはおすすめしません。まず1つのサブスクリプションで接続を完了し、更新、選択、起動、確認の流れが正常であることを確かめてから、仕事、日常、テストなどの用途別にグループを増やします。名前は「サブスクリプション1」「サブスクリプション2」ではなく用途を表すものにしてください。数か月後にどのルールとノードが関係するか判断しにくくなります。サブスクリプション更新は提供元のノードを同期するだけで、各ノードが現在のネットワーク環境に適していることを自動的に保証するものではありません。

更新、上書き、ローカル設定を理解する

サブスクリプションを更新すると、クライアントは通常、新しい内容に基づいてそのグループのノードを再構築します。提供元が削除したノードは消えることがあり、パラメーターが変わったノードは置き換えられます。サブスクリプション内で手動編集した値も、リモート側の値へ戻る可能性があります。そのため、長期的なルーティング方針や重要なメモを、特定のサブスクリプションノードの内部だけに保存しないでください。長期保持する内容は、クライアント独立のルーティング設定、DNS設定、バックアップ記録に保存します。ノードを一時的に調整する必要がある場合は、まずローカル設定として複製し、用途を明記して、次回更新で上書きされた後も変更元を判断できるようにします。

更新後もノード数が変わらないからといって、更新に失敗したとは限りません。提供元がアドレス、ポート、トランスポートパラメーターだけを変更している場合があります。更新結果はクライアントの通知とサブスクリプション更新ログを確認し、ノードの更新日時や重要な項目をいくつか確認して判断します。ログにネットワークリクエスト失敗が表示されたら、現在のネットワークからサブスクリプションの提供元へアクセスできるか確認し、次にシステム時刻、プロキシ状態、URLの完全性を確認します。更新に既存のプロキシが必要な場合は、現在のノードが利用可能でなければなりません。そうでないと「接続するには更新が必要、更新するには接続が必要」という循環になります。その場合は、一時的に既知の利用可能なローカルノードへ切り替えてから更新してください。

ノードの速度テストでは対象を区別する

クライアントでよく行われるテストには、ポート到達性、プロトコル遅延、実際のリクエスト、速度テストがあります。ポート到達性はリモートポートとの基本接続だけを確認するため短時間で済みますが、得られる情報は限られます。プロトコル遅延はより多くのハンドシェイクを経るため、日常利用に近い指標です。実際のリクエストはDNS、対象サイト、ルーティングルールの影響も受けます。1回の結果はその時点の環境を示すだけで、数ミリ秒の差を長期的な品質判断に使うべきではありません。安定性、パケットロス、混雑時間帯の輻輳、プロトコルのオーバーヘッドのほうが、1回の遅延値より重要な場合もあります。

正しい選び方は、まず継続的に失敗するノードを除外し、利用可能なノードから数個選んで実際のアクセスを比較することです。各テストでは同じプロキシモード、同じ対象、近い時間帯を保ち、ノードを替えながらDNSも変更することは避けます。速度に異常がある場合はノード・回線・ローカル設定の3層トラブル対処を参考にし、ノード負荷、ネットワーク経路、ローカル設定を分けて確認します。速度測定中に大量のダウンロードを同時実行しないでください。テスト自体が帯域を使い切る可能性があります。

手動取り込みと共有リンクの使い分け

単一の共有リンクは一時的に1つのノードを取り込む場合に適しています。QRコードは信頼できる端末間で短い設定を移す場合に便利で、サブスクリプションはノード群を継続的に同期する用途に向いています。手動入力では、アドレス、ポート、ユーザー識別子、トランスポート方式、TLSまたはREALITYのパラメーター、ホスト名、パスを項目ごとに確認してください。見た目が似ていても意味が同じとは限りません。トランスポートパスのスラッシュ、サービス名の大文字・小文字、サーバー名表示のフィールドなどがハンドシェイクに影響することがあります。取り込み直後に設定解析エラーが出る場合は形式を優先して確認します。起動できるものの接続がタイムアウトする場合はアドレス、ポート、ネットワークを確認し、ログに認証拒否が出る場合はユーザー識別子とセキュリティパラメーターに戻って確認します。

ノード管理の目的は項目をできるだけ増やすことではなく、提供元を明確にし、グループを整理し、更新を制御できる状態に保つことです。長期間使えないローカルテストノードは定期的に削除し、必要なメモは残してください。複数のクライアントで同じ設定を同時に手動変更することも避けます。複数端末で使う場合は、各端末で個別にサブスクリプションを更新し、ローカルルーティングとプロキシモードも端末ごとに管理するほうが、クライアントのデータディレクトリ全体をコピーするより安定します。この章を終えると、現在のノードがどのサブスクリプショングループ由来か、最後の更新が成功したか、失敗がサブスクリプションの取得段階かプロトコル接続段階かを答えられるようになります。

まずトラフィックの入口とルーティング結果を分ける

「システムプロキシ」と「グローバルプロキシ」は混同されがちですが、別の層に属します。システムプロキシは、OSのプロキシ設定に従うアプリがリクエストをクライアントへ送るかどうかを決めます。ルーティングのグローバルモードは、すでにクライアントへ入ったリクエストをプロキシアウトバウンドへ統一するかどうかを決めます。前者は入口、後者は行き先です。グローバルルーティングだけを有効にしても、アプリをクライアントへ入れなければリクエストは直接アクセスします。システムプロキシだけを有効にしても、ルーティングが宛先を直結と判定すればリモートノードは経由しません。トラブル対処では、この2つの状態を分けて確認する必要があります。

ブラウザ、デスクトップソフト、コマンドラインプログラムは、システムプロキシへの対応状況が異なります。システム設定を読むアプリもあれば、自身のネットワーク設定でHTTPまたはSOCKSポートを指定する必要があるアプリもあります。起動時に読み込んだ古い設定を保持するアプリもあります。システムプロキシを変更してもアプリの挙動が変わらない場合は、まずアプリを完全に終了して再起動し、独自のプロキシ設定がないか確認してください。1つのブラウザの結果から、すべてのプログラムが接続を引き継いだと判断しないでください。

よく使う3つの動作方式

ルールモードは日常利用のデフォルトに適しています。クライアントに入ったリクエストを、ドメイン、アドレス、その他の条件に応じてプロキシ、直結、ブロックのいずれかへ振り分けます。不要なリモート接続を減らせますが、効果はルールの品質とDNSの連携に左右されます。グローバルモードは短時間の診断に適しています。ルールの誤判定が疑われる場合、接続を引き継いだすべてのリクエストを一時的にプロキシアウトバウンドへ送れます。グローバルモードで正常、ルールモードで失敗するなら、問題は多くの場合ノードではなくルールまたはDNSの分類にあります。直結モードは、プロキシを停止したローカルネットワークの確認や、メンテナンス中にリモート接続を一時停止する場合に適しています。

モード切り替えは原因の特定に使うもので、恒常的な試行錯誤にしないでください。おすすめの順序は、通常はルールモードを使い、特定の対象だけに異常が出たら一時的にグローバルモードへ切り替え、グローバルでも失敗する場合はノードとDNSを確認し、判断後にルールモードへ戻すことです。グローバルモードを長期間使うと誤ったルールが隠れ、直結すべきLANやローカルサービスまでリモートへ送る可能性があります。直結モードもクライアントが完全に終了したことを意味しません。ローカルポートや一部の接続機能が動作し続ける場合があります。

ローカルポートと環境変数

クライアントを起動すると、通常はローカルループバックアドレス上でHTTP、SOCKS、または混合ポートを待ち受けます。具体的な番号は画面で確認してください。コマンドラインプログラムにプロキシを使わせる場合は、現在のターミナルセッションで環境変数を設定できます。以下では例として10809を使います。実際にはクライアントの現在のHTTPポートへ必ず置き換えてください。

# LinuxとmacOSの現在のターミナルセッション
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# テスト完了後に解除
unset HTTP_PROXY
unset HTTPS_PROXY

環境変数は、それを読み取るプログラムと子プロセスにだけ影響し、システム全体は変更しません。SOCKSアドレスとHTTPアドレスも自由に入れ替えられません。プログラムがHTTPプロキシを要求する場合はHTTPまたは混合ポートを入力し、SOCKS5をサポートする場合に対応するSOCKSポートを使います。ポートが別のプロセスに占有されていると、コアは通常、待ち受けを開始できず、ログにバインド失敗が表示されます。その場合は競合するプログラムを終了するか、クライアントで未使用のポートへ変更して設定を再読み込みします。

プロキシ経路が本当に有効だと証明する方法

確認はクライアントのトレイアイコンだけで判断しないでください。まずコアのログに対象リクエストが現れるかを確認し、通常のウェブページとコマンドラインリクエストをそれぞれテストします。ブラウザは正常でコマンドラインだけ失敗する場合、通常は入口が異なります。ログに新しいリクエストがまったくない場合は、通信がまだクライアントに入っていません。ログにリクエストがあるもののfailed to dial、接続拒否、タイムアウトが出る場合は、ノードとアウトバウンドを確認します。よくあるログ項目についてはV2Ray実行ログで原因を特定する方法を参照してください。

クライアントに接続済みと表示されても、ウェブページを開けない場合があります。「接続済み」をすべての工程が完了した状態だと解釈しないでください。この表示は、コアが動作中であることやノードが選択されていることだけを示す場合があります。システムプロキシ、ノードの可用性、DNS、ルーティング、システム時刻を順番に確認し、詳しいチェックリストは接続成功後もウェブページを開けない場合の対処手順を参照してください。入口と行き先の違いを理解すれば、次章のルーティングもルールの積み重ねだけになりません。

ルーティングルールのマッチング方法

ルーティングモジュールは、クライアントに入った接続を受け取り、ルールに基づいてプロキシ、直結、ブロックなどのアウトバウンドを選びます。一般的な条件には、ドメイン、宛先アドレスの範囲、ポート、ネットワーク種別、プロセス情報があります。ルールは通常、上から順に評価され、最初に一致したルールが実行されます。一致しなければデフォルトアウトバウンドへ進みます。そのため、同じ条件でも配置順が違えば結果が正反対になることがあります。広い範囲を対象にするルールは、より具体的なルールの後ろに置いてください。先頭のワイルドカード条件がリクエストを先に捕捉すると、後続ルールは永遠に有効になりません。

ドメインルールはサイトやサービスの所属を表すのに適し、アドレスルールはLAN、予約アドレス、明確なネットワーク範囲に適しています。ポートルールはサービスのポートを示すだけで、単独では業務種別を表せません。プロセスルールはクライアントとプラットフォームの対応に依存し、アプリの更新やパスの変更で無効になることがあります。ルール設計では、安定して読みやすい条件を優先し、カスタムルールには用途を明記してください。一時的なテストルールをリストの先頭に残さないでください。

最初は3層のルールから始め、大きなリストを一度に取り込まない

保守しやすい出発点は、3つの層に分けられます。1層目では自分の端末、LAN、予約アドレスを処理し、直結を明示します。2層目では固定したアウトバウンドを使う業務ドメインを処理します。3層目はデフォルトとして残りのトラフィックを受けます。問題が起きても、どの層で一致したかを明確に判断できます。LAN機器、ルーターの管理画面、ローカルの開発サービスには、リモートへ送られて戻れなくなるのを防ぐため、直結ルールを前方に置きます。

ルールを追加する前に、「どの具体的な問題を解決するのか」を答えてください。ルールモードで特定のドメインだけ失敗し、グローバルモードでは正常な場合は、ログの対象ドメイン、解決アドレス、現在一致しているアウトバウンドを確認してから、ドメインルールを追加するかDNSを調整するか決めます。ルーティング前にドメインがアドレスへ解決され、ルールがドメインだけに一致する場合、実際の動作が期待と異なることがあります。その場合は、スニッフィング、ドメイン戦略、DNS設定の関係を確認し、同じドメインを繰り返し追加しないでください。

{
  "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"
      }
    ]
  }
}

この設定は構造上の関係を示すものであり、クライアントが生成した完全な設定をそのまま上書きするものではありません。domain:example.comはそのドメインとサブドメインに一致し、full:service.example.netは完全一致のみ、geoip:privateはプライベートアドレス範囲の識別に使います。最後のルールは残りのTCPとUDPトラフィックを受けるため、具体的なルールの後ろに置く必要があります。実際のクライアントではグラフィカルなルールセット、事前定義タグ、異なる設定生成方式が使われる場合があります。画面で同等の設定を行い、最終的な実行設定またはログで結果を確認してください。

DNSとルーティングはセットで確認する

ドメインへのアクセスには、名前解決と接続の2段階があります。DNSクエリ自体に独立したルーティングが設定される場合があり、解決結果は後続のアドレスルールにも使われます。DNSが直結で接続がプロキシ経由の場合や、解決されたアドレスがリモート環境と一致しない場合、ウェブページのタイムアウト、一部リソースの失敗、ルールの誤判定として現れることがあります。DNSを調整するときは、解決失敗を直すのか、ローカルの解決差を避けるのか、特定ドメインを特定サーバーに回答させるのか、目的を明確にしてください。用途が重複するDNS方式を複数同時に有効にしないでください。

AsIsは通常、ドメインをルールマッチングにできるだけ残し、ルーティングのために追加の名前解決を積極的に行わないことを意味します。他のドメイン戦略では、条件に応じてドメインをアドレスへ解決してからIPルールに参加させる場合があります。どの戦略を選ぶかはルール構造によって決まり、単純にどちらが「速い」かで判断するものではありません。ドメインルールを中心にするなら、ドメイン情報が保持されることを確認します。アドレスルールに大きく依存するなら、解決元が安定しているか確認してください。変更後は既知の対象を少数テストし、ログで実際に一致したルールとアウトバウンドタグを確認します。

ルール変更の記録を作る

変更するたびに、1つの明確な目的だけを扱い、追加条件、想定アウトバウンド、検証結果を記録します。異常が出たら、リストの先頭にルールを追加し続けるのではなく、まず直近に追加したルールを一時停止して復旧するか判断します。ルールセットの更新後は回帰テストも行います。LANアクセス、通常のウェブページ、プロキシが必要な対象、UDPアプリから代表例を1つずつ選びます。1つのウェブページだけではルーティング全体を確認できません。

ルーティングが成熟した目印は、ルール数の多さではなく、各ルールについて出典、順序、結果を説明できることです。説明できない古いルールは、すぐ削除せず無効化エリアへ移して様子を見てください。依存関係がないと確認してから整理します。シンプルなデフォルト設定を1つ復元用に残し、複雑な実験はコピー上で行います。そうすれば、ルール更新で接続異常が起きても、ノード障害なのか判断層の変化なのかをすぐ切り分けられます。

TUNが解決するのは接続の引き継ぎ範囲

TUNモードは仮想ネットワークインターフェースを通じて、より多くのシステムトラフィックをクライアントへ渡します。システムプロキシを読まないアプリ、特定のUDP通信、ルーティングルールを統一して適用したい場合に適しています。新しいプロキシプロトコルではなく、利用できないノードを改善するものでもありません。システムプロキシでブラウザや一般的なソフトをまかなえるなら、「より完全にする」ためだけにすぐTUNを有効にする必要はありません。引き継ぐ範囲が広いほど、DNS、LAN、他のネットワークツール、システムルーティングの関係を明確にする必要があります。

TUNを有効にする前に、3つの基準テストを完了してください。通常のシステムプロキシモードでノードが使えること、ルールモードで主要な対象の振り分けが正常なこと、クライアント終了後にシステムネットワークが復旧することです。これらが成立していない状態でTUNを有効にすると、既存の問題がより複雑なデータ経路に包まれます。基準状態が安定したらTUNを有効にし、ノード、DNS、ルールは変えないでください。変化が仮想インターフェースによるものか判断しやすくなります。

初回有効化の手順

まず、仮想NICを作成したりデフォルトルートを変更したりする可能性のある他のネットワークツールを終了します。次にクライアントでTUNに必要なコンポーネントとシステム権限を有効にします。起動後は、インターフェース作成失敗、ルート書き込み失敗、権限不足がログに出ていないことを確認し、通常のウェブページ、LANアドレス、システムプロキシを読まないアプリを個別にテストします。トレイの状態だけで成功と判断しないでください。通常のウェブページは開けるのにLANが使えない場合は、プライベートアドレスの直結ルールと厳格ルーティングを確認します。すべてのドメインに失敗し、アドレスへの直接アクセスだけ応答する場合は、まずDNSの引き継ぎを確認します。

Androidでシステムネットワーク接続をクライアントが引き継いだ後は、想定した設定が有効になっているか確認し、アプリごとのプロキシ設定も確認してください。アプリごとのプロキシでは、選択したアプリだけを引き継ぐことも、クライアントを経由させないアプリを除外することもできます。どちらを選ぶかは目的によって決まります。ルールが多い場合は、まず少数のアプリで確認してから段階的に広げます。バックグラウンド動作はシステムのバッテリー設定にも左右されます。画面ロック後に切断される場合は、まずクライアントが停止されていないか確認し、すぐにノードの障害と判断しないでください。詳しくはv2rayNGの権限、省電力、アプリごとのプロキシ設定を参照してください。

DNSの引き継ぎと仮想アドレスマッピング

TUN環境では、クライアントがDNSクエリを同時に引き継ぎ、ドメインを仮想アドレスへマッピングすることがあります。これにより、後続の接続で元のドメインを復元してルーティングに利用できます。アドレスだけを接続情報として渡すアプリには有効ですが、DNSクエリと接続が一貫したデータ経路を通る必要があります。アプリが古い解決結果をキャッシュしている場合、設定を切り替えた後も古いアドレスへアクセスし続けることがあります。テスト時はアプリを再起動し、必要に応じてキャッシュの期限切れを待ってください。複数のDNSモードを頻繁に切り替えて、直後の1回の結果だけで比較しないでください。

「一部のサイトは開くが、一部はタイムアウトする」場合は、失敗したリクエストにドメイン、解決結果、ルーティングの一致記録があるか確認します。ログにアドレスしかなく元のドメインがない場合、ドメインルールが期待どおり機能しない可能性があります。DNSクエリがクライアントに入っていない場合は、システムが別の解決経路を使っていないか確認します。クエリは成功しているのに誤ったアウトバウンドへ送られる場合は、ルールの順序に戻って確認します。DNS問題とノード問題の違いは、前者が対象を得られない、または不適切なアドレスを得る形で現れやすいのに対し、後者は明確な対象があるもののハンドシェイクに失敗する点です。

競合に対処し、安全に終了する

システムルーティング、DNS、仮想NICを変更するツールを複数同時に動かすと、デフォルトルートが頻繁に変わりやすくなります。トラブル対処では、引き継ぎを行うツールを1つだけ残し、他のツールを終了してからクライアントを再起動します。スリープ復帰後にネットワークが不安定になった場合は、まずTUNを無効にしてコアを停止し、「コアを起動してからTUNを有効にする」順序で再構築します。プロセスを強制終了すると、復元されていないプロキシやルートの状態が残る可能性があるため、クライアントの通常の終了手順を優先してください。

TUN設定後の確認は「アプリがネットワークにつながる」だけでは不十分です。LANへ引き続きアクセスできること、ルールモードの一致が想定どおりであること、DNSログに継続的なエラーがないこと、システムのスリープ復帰後に再接続できること、クライアントを正常終了した後にネットワークが復元されることも確認します。どれかが不安定なら通常のシステムプロキシへ戻して使い、例外ルールをさらに追加するのではなく、項目ごとに解決してください。TUNの価値は制御可能なトラフィック範囲を広げることにあります。その前提は、経路全体を説明でき、復元できることです。

更新対象を3つに分ける

日常のメンテナンスでいう「更新」には、少なくともクライアント更新、コア更新、サブスクリプション更新が含まれます。クライアント更新は画面や設定生成ロジックを変え、コア更新はプロトコル対応や動作を変える可能性があります。サブスクリプション更新はノードデータだけを同期します。3つを同時に更新すると、接続異常の原因を特定しにくくなります。より安全なのは、現在の利用可能な状態を記録し、1つ更新して起動、接続、ルーティング、終了を確認してから、次の対象を更新する方法です。

クライアントに更新通知が表示されても、現在の作業をすぐ中断する必要があるとは限りません。まず画面の変更内容を読み、使用中の機能に関係するか確認してからメンテナンス時間を決めます。サブスクリプションはより頻繁に更新できますが、復元用に利用可能なノードを1つ残してください。コアの切り替えは特に慎重に行います。同じノードパラメーターでも、コアによって対応範囲やデフォルト動作が異なる場合があります。XrayとV2Flyの違いについてはXrayコアとV2Flyコアの違いを参照してください。

何をバックアップし、どの順序で復元するか

価値のあるバックアップには、サブスクリプショングループ情報、ローカルノード、カスタムルーティング、DNS設定、プロキシポート、画面設定、必要なログの抜粋が含まれます。サブスクリプションURLには識別用パラメーターが含まれる場合があるため、バックアップファイルは管理下の端末だけに保存し、公開領域へ直接アップロードしないでください。インストーラーをコピーするだけでは利用状態を復元できません。実際の動作を決めるのは設定データです。クライアントにエクスポート機能がある場合は優先して使い、エクスポート時のクライアント種別とOSも記録します。

復元時は、まずプラットフォームとアーキテクチャに合うクライアントをインストールし、基本設定を取り込んでコアが起動することを確認します。次にサブスクリプションを復元してノードを更新し、最後にカスタムルーティング、DNS、TUNを復元します。最初から古いファイルをすべて新しい環境へ上書きしないでください。パス、権限、設定構造が変わっている可能性があります。段階的な復元は手順が増えるものの、どの層でエラーが入ったかを正確に確認できます。復元後は、ローカルポートが新しいシステムの別プログラムと競合していないかも確認します。

ログは「時刻—入口—判断—アウトバウンド」の順に読む

ログで原因を特定するときは、まず時間範囲を確認します。現在のログを消去または区切ってから、安定して問題を再現できる操作を1回だけ実行し、古いエラーやバックグラウンドリクエストが混ざらないようにします。次にリクエストがローカルの入口へ入ったかを確認します。入口の記録がなければ、システムプロキシ、アプリ内プロキシ、TUNを調べます。入った後は、ルーティングが選択したアウトバウンドタグを確認します。アウトバウンドが想定どおりなら、接続、ハンドシェイク、認証の結果を見ます。この順序のほうが、ログ全体から「error」を検索するより確実です。

failed to dialは通常、アウトバウンド接続の確立に失敗したことを示します。後続のタイムアウト、拒否、ネットワーク到達不能などの情報も合わせて判断してください。connection rejectedは、リモート側の拒否、ルーティングによるブロック、サービスが待ち受けていないことなどが原因です。認証関連の表示が出たら、ユーザー識別子、時刻、セキュリティパラメーターを確認します。1行のエラーだけでは完全な状況を判断できないため、前後の対象、使用されたアウトバウンド、再試行の動作も確認してください。項目の詳しい説明はV2Rayでよくあるログエラーの特定方法を参照してください。

最小限の変数でよくある障害に対処する

接続に失敗したら、まず既知の利用可能なノードと通常のシステムプロキシへ戻し、カスタムDNS、複雑なルーティング、TUNを無効にして最短の経路だけを残します。基本経路が復旧したら、ルーティング、DNS、TUNの順に1つずつ有効にします。基本経路でも失敗する場合は、サブスクリプションパラメーター、ノードの状態、端末の時刻、ネットワーク環境を確認します。毎回1つの変数だけを変え、記録に結果を書いてください。ログを見ずに十数個のノードを試し続けても、問題が残っていることしか分からず、どの層で起きているかは分かりません。

速度が遅い場合も、ハンドシェイク時間、最初のレスポンスまでの待ち時間、継続的なスループット、特定の対象による制限を区別します。まず同じノードを異なる時間帯でテストし、次に同じ時間帯で複数ノードを比較します。その後、オーバーヘッドを増やす可能性のある実験的な設定を無効にし、ローカルのダウンロード、無線ネットワーク、システムリソースを確認します。最低遅延を継続速度の最高値と直接みなさないでください。詳しい段階的な方法はV2Rayの速度低下を段階的に特定する方法を参照してください。

頻繁にリセットせず、定期的に整理する

メンテナンス期間中に、長期間使えないノード、重複したサブスクリプション、不要なルーティングのコピー、古すぎるログを整理できます。ただし、復元用として使われていないことを先に確認してください。クライアントを頻繁にリセットすると問題発生時の状態を失い、同じ設定ミスを繰り返すことになります。安定して再現する障害がある場合は、必要な設定とログを先にエクスポートしてから最小構成でテストします。設定を復元できないと確認した場合に限り、環境を再構築してください。

健全な設定は、サブスクリプションの提供元が明確で、現在のノードを追跡でき、プロキシの入口が分かり、ルールを説明でき、TUNを独立して無効にでき、クライアント終了後にシステムネットワークが正常である状態です。日常のメンテナンスで重視するのは、変更を続けることではなく、不明な状態を減らすことです。基準状態、変更、復元を記録できれば、多くの障害を限られた手順で特定できます。

第1段階：現在の設定を説明できるようにする

応用設定はルールを増やすことから始まるのではなく、既存の設定を説明することから始まります。現在のクライアントがどのコアを使い、ノードパラメーターがどこから来て、ローカルでどの入口を待ち受け、システムプロキシやTUNがどのようにトラフィックを入れ、デフォルトルーティングがどのアウトバウンドを選び、DNSクエリを誰が処理しているかを説明できる必要があります。簡単なデータフロー図で関係を記録するとよいでしょう。アプリがリクエストを生成し、入口が受け取り、DNSがアドレスを提供し、ルーティングがアウトバウンドを決め、ノードがリモート接続を完了します。この経路に位置づけられないスイッチは、用途を確認してから有効にしてください。

この段階では、利用可能なノードを1つ、デフォルトDNS、3層のルーティングだけを残した最小設定のコピーを作ります。そのコピーでシステムプロキシ、アプリ内プロキシ、TUNを個別にテストし、ログの違いを記録します。目的は複雑な機能を追求することではなく、切り替えごとに観察可能な結果を得ることです。完了すれば、別の端末へ移行しても、古い画面の位置を覚えておくのではなく、データフローから環境を再構築できます。

第2段階：ルーティングとDNSをテスト対象にする

LAN、直結するサービス、プロキシを使うサービス、TCP、UDPをそれぞれ代表する固定のテスト対象をいくつか選びます。ルールを調整するたびに同じテストセットを実行し、実際に一致したアウトバウンドを記録します。ドメインルールでは、ドメインを保持した場合と先にアドレスへ解決した場合の違いを比較します。アドレスルールでは、解決結果の変化が結果に影響するかを観察します。プロセスルールでは、プログラムの更新やパス変更後の動作を確認します。こうすれば、「振り分けがおかしい気がする」という感覚を再現可能な条件へ変えられます。

DNS応用の重点は、サーバーを増やすことではなく、クエリの経路、キャッシュ、ドメインの復元を理解することです。まずシステムのクエリがクライアントに入っているか確認し、次にクライアントがどの解決経路を選んだか、最後に結果がルーティングへどう参加したかを確認します。異常時はドメイン解決と対象接続を分けてテストし、2種類のエラーを混同しないでください。DNSを調整する場合は必ず目的を明確にし、デフォルト設定へ戻す方法も残します。

第3段階：コアの違いとプロトコルの境界を理解する

XrayとV2FlyはどちらもProject Vエコシステムを起源としますが、プロトコル拡張、機能の進展、設定対応にはそれぞれ重点があります。内部実装をすべて暗記する必要はありませんが、一部のノード機能が特定のコアに依存すること、クライアント名だけではコアの互換性を判断できないことは理解してください。v2rayNはデスクトップ環境で対応するコア設定を管理でき、v2rayNGはXray方向でよく使われ、v2flyNGはV2Fly方向に対応します。切り替える前に、サブスクリプションのプロトコルとトランスポートが対応しているか確認してください。

設定を読むときは、「アドレスとポート—認証—プロトコル—トランスポート—セキュリティ層—ルーティング」の順に分解します。アドレスとポートはリモートの場所を決め、認証フィールドはユーザーを識別し、プロトコルはメッセージの意味を決め、トランスポートは運搬形式を示し、セキュリティ層は対応するハンドシェイクを担い、ルーティングはそのアウトバウンドを使うタイミングを決めます。エラーが出たら、この階層に沿って照合するほうが、別の設定を丸ごとコピーするより差異を見つけやすくなります。

第4段階：自分用のトラブル対処手順を作る

実際に遭遇した問題を、「現象、環境、最小再現、ログ、原因、修正、復元」の7項目に整理します。現象は「ブラウザのリクエストがログに出ない」のように観察可能な結果を書き、「プロキシが壊れた」とは書きません。環境にはプラットフォーム、クライアント、現在のモードを記録し、関係のない情報を詰め込む必要はありません。最小再現では問題を起こす手順だけを残し、原因は入口、解析、ルーティング、アウトバウンドの具体的な段階まで絞ります。このような記録は、断片的なチュートリアルを大量に保存するより長期利用に適しています。

問題をすぐ解決できない場合は、まず利用可能な状態へ戻してから分析を続けます。たとえばルールモードに異常がありグローバルモードが使えるなら、一時的な解決策を維持しつつ、設定をコピーしてトラブル対処を進めます。TUNの異常ならシステムプロキシへ戻し、新しいコアの異常なら従来のコアの方向へ戻します。復元は原因特定を諦めることではなく、基準状態を守ることです。安定した基準状態があって初めて、実験結果を比較できます。

継続して学ぶ内容の順序

まずクライアントのログとルーティングの一致を使いこなし、その後DNS、TUN、プロトコルの詳細へ進むことをおすすめします。ログは事実を示し、ルーティングは動作を決め、DNSとTUNは変数の範囲を広げます。順序を逆にすると、基本的なリクエスト経路を理解する前に複数のシステム層へ同時に向き合うことになります。具体的な問題が起きたら情報とトラブル対処の記事をテーマ別に参照してください。最短の接続を再構築する場合は入門ガイドへ戻り、プラットフォームを変えたり再インストールしたりする場合はクライアントダウンロードでインストーラーの種類を確認してください。

ゼロから使いこなす過程で最終的に身につくのは、安定したエンジニアリング手法です。まず基本経路を作り、次に機能を層ごとに追加する。まずログを観察し、次に原因を考える。まず基準状態を保存し、次に実験する。毎回、重要な変数を1つだけ変更する。この順序なら、クライアントの変更、サブスクリプションの変化、ネットワーク環境の変化があっても、設定を最初から推測し直す必要はありません。1つのリクエストをアプリからアウトバウンドまで追跡し、どの段階でも既知の状態へ戻せるなら、V2Rayクライアント環境を自力で保守する中核的な能力を身につけたといえます。