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

基本概念：クライアント、コア、設定の関係を理解する

グラフィカルクライアントはプロトコルそのものではない

操作を始める前に、混同されがちな名称を整理しておくことが重要です。V2Rayは通常、Project Vから発展した技術エコシステムを指し、複数のプロキシプロトコル、コア、グラフィカルクライアントをまとめて表す言葉としても使われます。v2rayN、v2rayNG、v2flyNGは、それぞれ異なるプラットフォーム向けのグラフィカルクライアントです。設定の保存、サーバーの切り替え、システムプロキシの制御、ログの表示を担い、整理したパラメータをコアに渡して実行します。XrayとV2Flyはコアの系統に属し、接続の確立、プロトコルのエンコードとデコード、トランスポート層、ルーティングの照合を実際に処理します。この関係を理解しておけば、問題が起きた際に、画面操作、設定データ、システムのトラフィック制御、コアの実行のどこにずれがあるか判断できます。

プロトコルは、VMess、VLESS、Trojanなど、クライアントとサーバーが必要な情報を交換する方法を定義します。トランスポート方式はTCP、WebSocket、gRPCなど、データの運び方を表します。TLSやREALITYなどのセキュリティ層は、これらとは異なる位置で機能します。利用できるノードはプロトコル名だけで決まるものではなく、アドレス、ポート、ユーザー識別子、トランスポート方式、セキュリティ層、ドメイン名などのパラメータで構成されます。どれか一つでもサーバー側と一致しなければ、接続失敗として現れることがあります。名称からパラメータを推測したり、あるノードの項目を別のノードへ機械的にコピーしたりしないでください。

設定はどこから来て、どこへ渡るのか

設定の入口は主に2種類あります。単一ノードの共有リンクは、一時的に1つの設定を追加する場合に適しています。サブスクリプションURLは、サービス提供者が管理する複数のノードをまとめて扱うためのものです。クライアントはサブスクリプションを読み込むと、内容を内部設定へ変換し、サブスクリプショングループに整理します。接続時には、選択中のノード、プロキシモード、ルール、ローカルポートが組み合わされて実行設定になります。つまり、サブスクリプションの更新は「接続の開始」と同じではありません。更新は一覧を最新化するだけなので、ノードを選択して接続を開始して初めて、新しい設定が現在のセッションに反映されます。

システムプロキシとTUNも同じ階層の機能ではありません。システムプロキシは通常、OSが提供するプロキシ設定を変更し、その設定に従うアプリだけがクライアントへリクエストを送ります。TUNは仮想ネットワークインターフェースを作成し、より低い層でトラフィックを受け取るため、対象範囲が広い一方、権限、ルーティング、DNSへの要求も高くなります。使い始めはまずシステムプロキシを理解し、ノードとサブスクリプションが正常に動作することを確認してから、TUNが必要か検討してください。問題の範囲を小さく保てます。

階層ごとにトラブルシューティングする

体系的な切り分けは、最短の経路から始めます。まずクライアントが正常に起動することを確認し、次にサブスクリプションを読み込めるか確認します。その後ノードを選択し、コアが正常に動作しているかを見て、最後にアプリのトラフィックがプロキシへ入っているか確認します。クライアントが起動直後に終了する場合は、実行環境、ディレクトリ権限、残存プロセスを優先して確認します。サブスクリプションの更新に失敗する場合は、URL形式、ネットワーク到達性、システム時刻を確認します。コアは動作しているのにブラウザーに変化がない場合は、システムプロキシとブラウザー側の設定を確認します。一部のアプリだけ動かない場合は、そのアプリがシステムプロキシを無視していないか、TUNが必要かを検討します。

遅延テストは候補を絞る手がかりにすぎず、ノードが完全に利用可能であることを単独で証明するものではありません。テスト方法によって、TCP接続、ハンドシェイク、特定の宛先だけを確認する場合があり、結果はローカルネットワーク、テスト対象、瞬間的な負荷にも左右されます。より確実な判断方法は、まず設定のハンドシェイクが成功することを確認し、実際に使うアプリでアクセスを試し、ログに再試行の繰り返し、DNS失敗、ルーティング拒否がないか確認することです。「クライアント—設定—コア—システム—アプリ」という階層モデルが、各章の基礎になります。

クライアントを選ぶ：プラットフォーム、コア、用途で判断する

デスクトップではv2rayNを優先する

Windows、macOS、Linuxのデスクトップ環境では、v2rayNを優先します。サブスクリプショングループ、サーバー一覧、システムプロキシ、ルール、TUN、ログを1つの画面で管理でき、長期運用のメインクライアントに適しています。デスクトップではブラウザー、開発ツール、オフィスアプリ、コマンドラインプログラムを同時に扱うことが多く、v2rayNのグループ管理とルーティング機能は安定した作業フローを作りやすい設計です。Windowsユーザーには、ダウンロードページでデスクトップ版と従来のWPF版が用意されています。デスクトップ版は新世代のクロスプラットフォームUIを採用し、従来のWPF版は昔ながらのWindows画面に慣れたユーザーに適しています。長く使うものを1つ選べばよく、同時に起動する必要はありません。

macOSではダウンロード時にApple SiliconまたはIntelのインストーラーを選びます。Linuxではディストリビューションのパッケージ体系に合わせてdebまたはrpmを選び、x64とarm64も区別します。アーキテクチャを間違えると、ネットワーク接続ではなく、インストールできない、または起動できないという症状が出ます。インストール前にシステム情報を確認するほうが、後からノードを何度も調整するより効果的です。すべてのインストール入口はインストーラーページにまとまっており、4つのプラットフォームごとに選び方を案内しています。

Androidのv2rayNGとv2flyNG

Androidではv2rayNGを第一候補にします。Xrayコアを基盤とし、一般的なプロトコル、サブスクリプション管理、アプリごとのプロキシ、システムVPNによるトラフィック制御が必要なユーザーに適しています。インストーラーは通常arm64版とユニバーサル版に分かれ、近年の主流端末では一般にarm64を使用します。アーキテクチャを確認できない場合はユニバーサル版のほうが対応範囲は広いものの、サイズは大きくなりがちです。初回接続時には、VPN接続の作成を許可するようAndroidから求められます。これはアプリのトラフィックをクライアントに渡すために必要な手順です。許可しただけでサブスクリプションがインポートされたり、ノードが利用可能になったりするわけではありません。

v2flyNGは、AndroidでV2Flyコアを中心に使う場合の選択肢です。設定がV2Flyの挙動に明確に依存している場合や、同じプラットフォームで異なるコアの実装を比較したい場合に適しています。名前だけでどちらが「速い」と判断しないでください。実際の使用感は、設定のプロトコル、ローカルネットワーク、リモート側の状態、コアの互換性によって変わります。Androidで初めて設定するユーザーの多くは、まずv2rayNGで安定した接続を作るほうが簡単です。v2flyNGへ切り替えるのは、設定の出所、対応プロトコル、必要なコアが明確な場合に限るとよいでしょう。

クライアントの乗り換えで問題を隠さない

接続に失敗したとき、複数のクライアントを続けてインストールしても問題の範囲は通常狭まりません。まず1つのクライアントに固定し、サブスクリプションの取得、コアの起動、ログが止まる箇所を記録するほうが効果的です。同じサブスクリプションのすべてのノードが失敗する場合は、サブスクリプションの状態、システム時刻、ネットワーク、設定の互換性を優先して確認します。1つのノードだけ失敗する場合は、そのノードと正常なノードのプロトコルおよびトランスポート項目を比較します。システムプロキシは使えるのにTUNだけ使えない場合、ノード経路はおそらく正常なので、権限、DNS、ルーティングを確認します。

クライアントを移行する際も、既存の設定ディレクトリをいきなり上書きしないでください。まずサブスクリプショングループ、ルール、ローカルポートをエクスポートまたは記録し、旧クライアントとコアのプロセスを終了して、システムプロキシが復元されたことを確認してから新しいクライアントを起動します。2つのクライアントが同時にシステムプロキシを制御したり、同じポートを待ち受けたりすると、一見ランダムな接続障害が起きます。Androidでv2rayNGとv2flyNGを切り替える場合も、現在のVPN接続を停止してから別のクライアントを起動し、前のセッションが残らないようにします。

選択基準を明確にする

クライアント選びは、次の3つの質問に整理できます。現在のOSは何か、サブスクリプションがどのコアを必要としているか、高度なルーティングやTUNが必要か。デスクトップではv2rayN、Androidではv2rayNGから始め、設定側がV2Flyの挙動を明示的に求める場合にv2flyNGを検討します。画面の好みは最終的な選択に影響しますが、プロトコルの互換性やシステムアーキテクチャより優先すべきではありません。3つのクライアントの違いは比較レビューで詳しく確認でき、インストーラーの種類はダウンロードページの最新一覧を基準にしてください。

クライアントを決めたら、少なくとも一定期間は継続して使ってからツールを見直すことをおすすめします。頻繁に画面を変えるより、設定手順を安定させるほうが価値があります。サブスクリプションの備考を統一し、ルール名を決め、システムプロキシの状態を明確にし、必要なログを残せば、後のメンテナンスを再現可能な手順にできます。次章では、この考え方でインストールと初回起動を扱います。

インストールと初回起動：復旧できる基本環境を先に作る

インストール前にOSとCPUアーキテクチャを確認する

インストールの第一歩はファイルをダブルクリックすることではなく、OSのバージョン、CPUアーキテクチャ、書き込み可能なディレクトリを確認することです。Windowsではx64が一般的です。macOSではApple SiliconとIntelを区別します。Linuxではx64、arm64に加え、ディストリビューションに応じてdebまたはrpmを選びます。Androidではarm64版とユニバーサル版から選択します。システム情報の「システムの種類」「チップ」「プロセッサ」といった項目は、製品名より信頼できます。アーキテクチャが合わない場合は正しいインストーラーを選び直し、拡張子の変更や実行ファイルのコピーで制限を回避しようとしないでください。

デスクトップでは、パスが分かりやすく、現在のアカウントに読み書き権限がある場所へクライアントを置くことをおすすめします。クライアントはサブスクリプション、ログ、ルール、画面設定を保存するため、読み取り専用のディレクトリでは設定を保存できない、更新後に設定が戻る、コアがファイルを解放できないといった問題が起きます。パスはできるだけ短くし、実行中のディレクトリをオンデマンドでファイル解放する同期ツールに任せないでください。移行時はまずクライアントを終了してから設定ディレクトリ全体をコピーします。メインプログラムだけではサブスクリプショングループやカスタムルールを保持できません。

初回起動では必要な設定だけ行う

初回起動後は、画面が正常に開くか、コアコンポーネントを呼び出せるか、ログウィンドウに継続的なエラーがないかを確認します。この段階でTUN、カスタムDNS、複雑なルーティングを急いで有効にしないでください。ローカルポートと基本プロキシモードは初期設定のままにし、出所が明確なサブスクリプションまたは単一ノードを1つ読み込んで初回接続を行います。クライアントの起動、設定の読み込み、コアの実行、システムプロキシの反映、アプリからのアクセスという最短の確認経路を作れます。どこで失敗したかも明確になります。

Windowsで起動直後に終了する場合は、システムの実行環境、プログラムディレクトリの権限、旧プロセス、設定ファイルの破損を確認します。macOSで初回起動がブロックされた場合は、アプリを何度もコピーするのではなく、システム設定で開く操作を確認します。Linuxでインストール後に起動できない場合は、まずターミナルから一度実行し、不足している依存関係や権限のメッセージを確認します。Androidではインストール後に必要な通知を許可し、接続状態を確認できるようにします。システムVPNの許可は、初回接続時に処理します。

Windows：設定 → システム → システム情報 → システムの種類
macOS：Appleメニュー → このMacについて → チップ
Linux：uname -m
Android：システム情報ツールでABIを確認し、arm64-v8aを優先して確認する

終了、再起動、システムプロキシの復元

デスクトップクライアントはウィンドウを閉じても、すぐに終了するとは限りません。設定によってはプロセスが常駐します。更新、移行、ポート使用状況の確認を行う前に、クライアントの終了コマンドを使い、コアのプロセスも終了したことを確認してください。プロセスを強制終了すると、システムプロキシが前回のローカルポートを指したまま残り、ブラウザーのリクエストがすべて失敗することがあります。ノード自体が正常でも、まずシステムプロキシを復元してからクライアントを再起動する必要があります。

安全な終了手順は、現在の接続を停止し、システムプロキシまたはTUNを無効にし、クライアントを終了して、プロセスが終了したことを確認する流れです。再起動時は逆に、クライアントを開き、設定の読み込み完了を確認し、ノードを選んでコアを起動し、最後にシステムプロキシまたはTUNを有効にします。まだ待ち受けていないローカルポートへトラフィックが送られるのを防げます。Androidでは、最近使ったアプリの一覧からアプリをスワイプして終了すると、メーカーのバックグラウンド制御で停止することがあります。継続接続が必要な場合は、後のメンテナンス章を参考に省電力の対象外設定とバックグラウンド実行権限を設定してください。

後の切り分けに基準状態を残す

初回接続に成功したら、すぐに設定を重ねないでください。現在のクライアント、サブスクリプショングループ、ノードの種類、プロキシモード、TUNの有効・無効を記録し、ブラウザーと日常的に使うアプリが1つずつ安定してアクセスできることを確認します。この状態が後の調整における基準になります。ルールやDNSを変更して問題が起きた場合も、すべてを再インストールせず、基準状態と比較して影響した変更を判断できます。

ログの入口と設定のバックアップ場所も確認しておくと安心です。ログで重要なのは、エラーが発生した段階、宛先アドレス、プロトコルのハンドシェイク結果、DNSに関するメッセージです。詳細なデバッグ出力を長期間残す必要はありません。バックアップはクライアントを完全に終了してから行い、少なくともサブスクリプション情報、ルール、主な設定を含めます。ランタイムや権限が原因の起動問題については、クライアント起動時のクラッシュ修復ガイドも参照してください。

サブスクリプションとノード：設定の出所を管理しやすいグループに整理する

サブスクリプションURL、共有リンク、手動設定

サブスクリプションURLは、複数のノードを一度に取得して継続的に更新するためのもので、長期運用に適しています。共有リンクは通常1つのノードだけを記述し、一時的なインポートやピンポイントのテストに向いています。手動設定では、アドレス、ポート、ユーザー識別子、トランスポート、セキュリティパラメータを1つずつ入力する必要があり、インポート形式が使えない場合や細部を確認したい場合に適しています。3つの入口はいずれもクライアントで選択できるサーバー項目になりますが、更新方法は異なります。サブスクリプションのノードは更新によって管理され、手動変更は次回の更新で上書きされる可能性があります。

サブスクリプションを追加するときは、まず識別しやすいグループ名を作成し、完全なURLを貼り付けます。名前にはサービス名、用途、環境などを使うとよく、「サブスク1」「予備2」のような名前だけでは、複数の出所を管理する際に更新対象を判断しにくくなります。保存後は手動で一度更新し、クライアントが項目を取得できたか、形式エラーが出ていないか確認します。サブスクリプションURLにはアクセス情報が含まれるため、管理下にある端末とクライアントだけに保存し、公開文書、スクリーンショット、共有ログには載せないでください。

更新してもすぐに切り替わるわけではない

サブスクリプションの更新では、現在のグループ内のノードが追加、削除、変更されますが、使用中の接続が自動的に置き換わるわけではありません。更新後は、選択中の項目がまだ存在するか確認し、必要に応じてノードを選び直して再接続します。一覧に変化がない場合は、対象グループを更新しているか確認し、キーワードフィルター、重複除去、並べ替えが有効になっていないか確認します。同名のノードがあると変化がないように見えても、内部パラメータが更新されていることがあります。

更新に失敗した場合は、URL形式、ネットワーク到達性、システム時刻、クライアントログの順に確認します。URLをコピーするときは前後の空白や改行を入れないでください。ブラウザーでページを開けても、サブスクリプションのAPIに到達できるとは限りません。システム時刻のずれは安全な接続に影響することがあります。ログのステータスコードや解析メッセージから、リクエストの失敗か、対応していない内容形式かを切り分けられます。同じ時刻に更新を何度もクリックしないでください。連続リクエストでは形式問題は直らず、ログも読みにくくなります。

サブスクリプショングループ名の例：
作業環境｜メインサブスク
モバイル端末｜常用
プロトコルテスト｜一時用

フィルタールールの例：
保持キーワード：VLESS|Trojan
除外キーワード：メンテナンス|期限切れ|残り

ノード選びはプロトコル、場所、実際の用途を組み合わせて考える

ノード一覧の名前は通常、設定提供者が付けた備考であり、安定性を保証するものではありません。遅延テストは、接続できない項目や明らかに遅い項目を素早く除外するのに役立ちますが、結果は経路、テスト方法、瞬間的な状態に左右されます。ノードを選ぶときは、現在のコアがプロトコルに対応しているか、トランスポートパラメータがそろっているか、実際のアプリが安定して動くか、継続利用中に頻繁な再接続が起きないかを確認します。一度だけ低い数値が出ても、継続的なアクセステストの代わりにはなりません。

あるノードが使えない場合は、まず同じサブスクリプショングループから別のノードを選びます。他のノードが正常なら、問題は通常その設定1件またはリモート側の状態にあります。グループ全体が失敗する場合は、サブスクリプションの期限や更新内容を確認します。複数の出所が同時に失敗する場合は、ローカルネットワーク、システムプロキシ、クライアントのコアをさらに確認します。順序なくDNS、ルーティング、ポートを変更するより、この比較のほうが効果的です。

複数サブスクリプショングループとフィルター戦略

複数のサブスクリプションを管理する場合は、インポート後に1つの平坦な一覧へ混ぜず、出所ごとに分けます。グループを分けると更新範囲が明確になり、出所ごとに独立したフィルターも設定できます。ノード名は、プロトコルや地域を先に置き、その後に元の備考を置くなど、統一した並び方にすると管理しやすくなります。キーワードは簡潔にし、メンテナンス表示を隠す、特定のプロトコルを残す、不要な用途を除外するなど、1回につき1つの目的だけを解決します。ルールが長すぎると、新しいノードを意図せず隠しやすくなります。

フィルタールールを変更したら、まずフィルター前の元の件数と名前を確認し、その後条件を少しずつ追加します。正規表現の縦棒は「または」を表し、括弧は組み合わせに使います。ドットとアスタリスクには特殊な意味があります。通常の語句を検索するだけなら、明確なキーワードを直接使うほうが安全です。複数のサブスクリプションをグループ、備考、フィルターで管理する方法は、複数サービスのサブスクリプション管理実践を参照してください。サブスクリプションの整理が終わってからプロキシモードを設定し、一覧の問題をシステムによるトラフィック制御の問題と取り違えないようにします。

プロキシモード：システムプロキシ、ルールモード、グローバル処理を理解する

システムプロキシは対応アプリをクライアントへ誘導する

デスクトップ環境のシステムプロキシは、OSのプロキシアドレスをクライアントが待ち受けるローカルポートに設定する仕組みです。ブラウザーや多くのデスクトップアプリはこの設定を読み取り、HTTPまたはSOCKSリクエストをクライアントへ渡します。クライアントは現在のノードとルールに基づいて処理方法を決めます。システムプロキシは対象範囲が分かりやすく、必要な権限も比較的少ないため、初回接続と日常利用の標準的な入口に適しています。ただし、一部のアプリは独自のネットワークスタックや個別のプロキシ設定を使うため、自動では従いません。

システムプロキシを有効にする前に、クライアントのコアが起動し、対応するポートを待ち受けている必要があります。システムプロキシが指すポートでプログラムが待ち受けていなければ、その設定に従うアプリはすべて接続に失敗します。確認するときは、まずシステムプロキシを無効にしてローカルネットワークが復旧するか確認し、クライアントを起動してから再度有効にします。ローカルポートをむやみに変更しないでください。変更する場合は、クライアントのインバウンドポート、システムプロキシのアドレス、手動設定したアプリのプロキシが一致しているか確認します。

ルール、グローバル、直接接続の役割

ルールモードは、ドメイン、IP、ポート、プロセス、プロトコルなどの条件に応じて、トラフィックをプロキシ、直接接続、ブロックのどれへ送るか決めます。日常利用では最もバランスのよい方式です。グローバルモードは通常、制御可能なトラフィックを現在のプロキシへ一律に通します。ノードが対象リクエストを処理できるか短時間で検証したり、ルールの誤判定を切り分けたりする場合に適していますが、接続品質が高くなるという意味ではありません。直接接続モードはリモートプロキシを迂回し、通常のネットワークを一時的に復旧したり、問題がプロキシ経路にあるか比較したりするために使います。

切り分けでは、3つのモードを比較に利用できます。グローバルモードは使えるのにルールモードが使えない場合は、ルールのマッチングを優先して確認します。グローバルモードも使えない場合は、ノード、コア、システムによるトラフィック制御に問題がある可能性が高くなります。システムプロキシを無効にしてもアプリがプロキシを使い続ける場合は、アプリに独自のプロキシ設定があるか、別のネットワークツールが動作している可能性があります。モードを切り替えたら再接続し、ログのアウトバウンドタグを確認して、新しい設定が現在のセッションに反映されたことを確かめます。

ブラウザー、コマンドライン、独立したプロキシアプリ

ブラウザーは通常システムプロキシに従いますが、拡張機能や企業ポリシーによって独自設定を使うこともあります。ブラウザーを切り分けるときは、追加のプロキシ拡張機能を無効にし、新しいウィンドウで対象へアクセスして、システム上の他のアプリと比較します。コマンドラインツールはデスクトップのシステムプロキシを読み取らないことがあり、現在のターミナルセッションでHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定する必要があります。設定先はクライアントが実際に待ち受けているローカルアドレスとポートだけにし、テスト後はすぐに削除してください。クライアント終了後に後続のコマンドが失敗するのを防げます。

# 現在のターミナルセッションに一時的なローカルプロキシを指定。ポートはクライアントの設定と一致させる
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# テスト終了後に削除
unset HTTP_PROXY
unset HTTPS_PROXY

一部の開発ツール、ダウンロードツール、ゲームプラットフォームには独自のネットワーク設定があります。まずアプリの公式ドキュメントを確認してください。システムプロキシに従わないアプリをカバーするために、すぐTUNへ切り替える必要はありません。手動のHTTPまたはSOCKSプロキシに対応しているかを先に確認したほうが、制御しやすい場合が多くあります。アプリでプロキシを設定できず、UDPや子プロセスも含めて制御する必要がある場合に、TUNの導入を検討します。

接続状態と実際のアクセスを分けて判断する

クライアントに「接続済み」と表示されても、通常はコアが起動した、またはローカルVPNインターフェースが確立したことを示すだけで、すべてのリモートリクエストが成功するとは限りません。実際のアクセスでは、DNS解決、ルーティング、プロトコルのハンドシェイク、宛先からの応答も必要です。「接続済みなのにアクセスできない」場合は、ログにDNS失敗、接続タイムアウト、直接接続へのルーティング、リモート側の拒否がないか確認します。ログの宛先とアウトバウンドタグから、トラフィックが想定した経路に入っているか判断できます。

安定した使い方ができるようになったら、日常利用はルールモードに固定し、グローバルモードを診断用に残すとよいでしょう。サブスクリプション、ノード、モードを変更するときは、一度に1項目だけ変更して再接続し、同じテスト対象で確認します。結果を比較しやすくなり、次章でルールを作成するための基礎にもなります。

ルーティング：トラフィックごとの出口を明確なルールで制御する

ルールはマッチング条件、宛先、順序で構成される

ルーティングの要点は、ルールを増やすことではなく、どのトラフィックを特別に扱い、どの出口へ送るかを決めることです。一般的な条件には、完全なドメイン名、ドメインサフィックス、IPセグメント、ポート、ネットワーク種別、プロセス名があります。宛先は通常、プロキシ、直接接続、ブロックのいずれかです。クライアントは画面上のルールをコア設定へ変換し、決められた順序で照合します。通常は具体的なルールを前に置き、範囲の広いフォールバックルールを後ろに置きます。

DNS解決の前後で、ドメインルールの挙動が異なることがあります。アプリがIPへ直接アクセスする場合、ドメインサフィックスだけのルールは一致しません。クライアントが元のドメイン名を取得できない場合は、解決後のIPで判断するしかありません。プロセスルールはOSの権限やプロセス識別機能に依存し、デスクトッププラットフォームによって対応状況も異なります。ルールを書く前に、クライアント画面で利用できる条件を確認し、別のツールの構文をそのまま貼り付けないでください。

最小限のルールセットから始める

管理しやすいルールセットには、明確な直接接続、明確なプロキシ、最後のフォールバックを含めます。まず、ローカルネットワークのアドレスを直接接続にする、特定の業務ドメインを指定した出口へ送るなど、最も確実な条件を書きます。その後、残りのトラフィックのデフォルト経路を決めます。最初から出所不明の大量のルールを取り込まないでください。ルールが重複し、更新後の変化も追跡しにくくなります。新しいルールを追加するたびに、何に一致し、なぜ必要で、なぜその位置に置くのかを説明できるようにします。

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

上の構成は、一般的なコアのルーティングロジックを示しています。プライベートアドレスは先に直接接続し、指定ドメインはプロキシへ送り、それ以外のTCPとUDPはプロキシ出口を使います。実際のv2rayNやモバイルクライアントでは、アウトバウンドタグが画面から生成されることがあるため、名前を独自に想定しないでください。設定断片をコピーする前に、クライアントが完全な設定の直接編集に対応しているか確認します。グラフィカルなルールエディターを使う場合は、条件を対応する項目へ1つずつ入力し、JSON全体を1つの入力欄へ貼り付けないでください。

ドメイン戦略とDNSの連携を理解する

AsIsは元のドメイン名を優先して照合し、ルーティング判断のためにIPを追加で解決しないことを示します。他の戦略では、ドメインルールに一致しない場合に解決を続け、IPルールを試すことがあります。積極的な戦略ほどDNSクエリが増え、DNS設定の正確さにも依存します。主にドメインサフィックスで振り分けるなら、ドメイン処理を単純にしたほうが切り分けやすくなります。IPセグメントで処理する必要がある場合は、解決結果、DNSの出口、IPルールが一致していることを確認します。

DNSとルーティングは相互に影響します。DNSクエリ自体もトラフィックなので、どのサーバーで解決し、どの出口から送るかを決める必要があります。解決結果は後続のIPルールにも使われます。よくある異常には、現在の経路に適さないアドレスへ解決される、誤った出口からクエリが送られる、キャッシュに古い結果が残るといったものがあります。切り分けでは、まず特定ドメインの解決結果を確認し、次にそのクエリと実際の通信がそれぞれどのルールに一致したかを確認します。複数のDNS、ドメイン戦略、ルールセットを同時に変更しないでください。どの変更が効いたのか分からなくなります。

ルールのマッチングテストと競合の切り分け

ルールを検証するときは、特徴が明確な対象を選び、ログのドメイン、宛先IP、アウトバウンドタグを確認します。具体的なルールが一致しない場合は、より広いルールの後ろに置かれていないか、ドメイン形式が正しいか、アプリがIPを直接使っていないか、古い接続を再利用していないかを確認します。ブラウザーは長時間接続を保持することがあるため、ルール変更後にページを更新するだけではすべてのリクエストが再構築されない場合があります。必要なら関連するタブを閉じるか、アプリを再起動してテストします。

プロセス単位の振り分けでは、子プロセスも考慮します。ブラウザー本体とネットワークサービスのプロセス名が異なることや、ランチャーと実際のプログラムが分かれていることがあります。モバイルのアプリごとのプロキシは、アプリパッケージ単位で選択する方式に適しています。結果はクライアントの「選択したアプリをバイパス」または「選択したアプリのみプロキシ」の意味に左右されるため、切り替える前に説明を確認してください。Androidの権限、省電力対象外設定、アプリごとのプロキシについては、v2rayNG Android利用の要点を参照してください。

読みやすく、取り消せるルールを保つ

ルールグループごとに用途を明記し、大きく変更する前にバックアップをエクスポートします。ルール名は「ローカルネットワーク直接接続」「業務ドメインプロキシ」「特定アプリ直接接続」のように用途を直接表すと、抽象的な番号より管理しやすくなります。削除する前に無効化してしばらく様子を見て、依存がないことを確認してから削除します。外部ソースから更新されるサブスクリプションのルールセットは個人ルールと分けて保存し、更新で手動調整が上書きされないようにします。

成熟したルーティング構成は、ルール数が最も多いものではなく、各マッチングの理由を安定して説明できるものです。まず主要な用途を満たし、少数の例外を後から処理します。例外が増え続ける場合は、デフォルトの出口が適切か見直してください。ルーティングの基礎を終えてもシステムプロキシに従わないアプリ、UDPトラフィック、複雑な子プロセスを制御する必要がある場合に、TUNモードへ進みます。

TUNモード：トラフィック制御の範囲を広げ、複雑さを管理する

TUNがより多くのアプリをカバーする理由

TUNモードは仮想ネットワークインターフェースでシステムのトラフィックを受け取り、クライアントのコアへ渡してルーティングを判断させます。各アプリがHTTPやSOCKSプロキシに対応している必要がないため、システムプロキシを無視するプログラム、一部のUDPトラフィック、複数プロセスのアプリもカバーできます。Androidクライアントが作成するシステムVPN接続も、同様のトラフィック制御の考え方に属します。対象範囲が広がる分、システムルーティング、DNS、権限、除外設定も関係するため、TUNは基本ノードとルールモードが正常だと確認してから有効にするのが適切です。

TUNを使っても、すべてのトラフィックがリモートプロキシを通るとは限りません。トラフィックが仮想インターフェースに入った後も、ルールに従ってプロキシ、直接接続、ブロックが選択されます。ローカルネットワーク、印刷サービス、開発環境を直接接続のままにする必要がある場合は、有効化前にプライベートアドレスと関連ドメインのルールを確認します。デフォルトルートを誤るとローカル機器に到達できなくなり、DNS設定を誤ると「IPにはアクセスできるがドメインにはアクセスできない」という症状になります。

有効化前のチェックリスト

まず、仮想インターフェースを作成したりルーティングテーブルを変更したりする他のネットワークツールを終了し、v2rayNの通常のシステムプロキシ接続が使えることを確認します。現在のノードが必要なネットワーク種別に対応しているか確認し、既存のDNS設定とルーティングモードを記録してからTUNを有効にします。デスクトップOSでは管理者権限や必要なコンポーネントのインストールが求められる場合があるため、クライアントの案内に従って完了させます。権限が拒否された場合、スイッチを何度も切り替えても解決しません。システムの権限設定を確認してください。

有効化後は3つの層をテストします。通常のドメインアクセス、IPへの直接アクセス、ローカルネットワーク資源へのアクセスです。通常のドメインだけ失敗してIPが成功するなら、まずDNSを確認します。両方とも失敗するなら、仮想インターフェース、デフォルトルート、コアのログを確認します。外部アクセスは正常なのにローカルネットワークだけ失敗するなら、プライベートセグメントの直接接続ルールを確認します。テスト対象を固定し、項目を1つ変更するたびに再接続して、キャッシュや古いセッションが結論に影響しないようにします。

DNS、厳格なルーティング、ループバックの問題

TUNではDNSも制御することが多いため、ドメイン解決と後続の接続が同じルーティング戦略を使うようにします。DNSサーバーを増やせば信頼性が自動的に高まるわけではなく、結果が一致しなくなることがあります。最初はクライアントが推奨する単純な方式を使い、クエリがコアへ入ることを確認してから、必要に応じて直接接続用とプロキシ用の解決を分けます。解決ループが起きた場合は、DNSリクエストが同じローカル待ち受けポートへ戻されていないか確認します。

厳格なルーティングは、トラフィックが仮想インターフェースを迂回する可能性を減らしますが、仮想マシン、コンテナ、ローカルネットワーク共有、カスタムNICに影響することがあります。有効化前に、特に開発環境で使うプライベートアドレスを含め、システムに存在するセグメントとインターフェースを記録します。コンテナへのアクセスが突然失敗しても、先にノードのプロトコルを変更せず、TUN有効化前後のルーティングテーブルを比較し、必要なセグメントを明示的に処理します。ルールは狭く正確にし、広すぎるセグメントで通常のシステムルートを覆わないようにします。

Androidの接続許可とアプリごとのプロキシ

v2rayNGまたはv2flyNGで初回接続すると、システムVPNの許可を求められます。通常、システムが同時に許可できるアクティブなVPNセッションは1つだけなので、クライアントを切り替える前に現在の接続を停止します。アプリごとのプロキシには正反対の2つの方式があります。選択したアプリだけをプロキシへ通す方式と、選択したアプリをプロキシから除外する方式です。設定時は画面の説明を確認し、検証しやすいアプリ1つでテストしてください。最初から大量のアプリを選択しないでください。

画面ロック後に接続が頻繁に切れる場合、システムの省電力設定、バックグラウンド制限、メーカー独自のタスク管理が原因であることが多くあります。クライアントを省電力対象外にし、バックグラウンド実行を許可し、常時通知を残すとVPNサービスを維持しやすくなります。ログレベルを長期間詳細なデバッグにするのは避けてください。書き込みと処理の負荷が増えます。モバイル端末の電池消費とバックグラウンド実行の切り分けは、v2rayNGの電池消費とバックグラウンド実行の確認で詳しく解説しています。

システムプロキシに戻すべきタイミング

主な用途がブラウザーと、プロキシに対応した少数のデスクトップアプリだけなら、システムプロキシのほうが簡単です。TUNは明確な問題を解決するために使い、複雑さを増やすための標準設定にはしないでください。有効化後にローカルネットワーク、コンテナ、DNSの競合が続く場合は、いったんシステムプロキシへ戻して通常業務を復旧し、制御が必要なアプリだけを個別に分析します。検証済みの通常プロキシ設定を残しておくことが、TUN障害への重要な退路になります。

TUNを無効にするときは、クライアントのスイッチで正常に停止し、仮想インターフェースとルートが削除されたことを確認します。プロセスを強制終了した後にネットワーク異常が起きた場合は、クライアントを再起動して正常な終了操作を一度行うか、システムのネットワーク設定で残存インターフェースを確認します。これらの基本処理が済んだら、次章で更新、バックアップ、ログ、トラブルシューティングを再現可能なメンテナンス手順に整理します。

日常のメンテナンス：更新、バックアップ、ログ、安定性の確認

更新をクライアント、サブスクリプション、ルールの3種類に分ける

日常の更新は1つの操作ではありません。クライアントの更新は画面、コア、機能の挙動を変えることがあります。サブスクリプションの更新はノードパラメータを刷新し、ルールの更新はトラフィックの出口を変える可能性があります。3種類の更新は分けて実行し、更新のたびに基本確認を行うのが理想です。同じ日にクライアントを変更し、サブスクリプションを更新し、新しいルールを取り込むと、異常の原因を特定しにくくなります。安定した環境では、まず設定をバックアップし、クライアントを更新して起動と旧設定を確認し、次にサブスクリプションを更新し、最後にルールを処理します。

クライアントを更新する前に、動作中のコアを終了し、現在のインストール形式とアーキテクチャを記録します。旧プログラムが動作したままファイルを上書きしないでください。更新後は、サブスクリプショングループ、ルーティングモード、ローカルポート、TUN設定が保持されているか確認し、既知の正常なノードを1つ起動します。サブスクリプション更新後は、項目数、現在の選択、フィルターを確認します。ルール更新後は再接続し、主要な対象が想定した出口を通っていることをログで確認します。

バックアップの要点はファイル数ではなく復元性

価値のあるバックアップには、少なくともサブスクリプショングループ、手動ノード、カスタムルーティング、DNSの設定、重要なクライアント設定を含めます。バックアップ時はクライアントを完全に終了し、書き込み途中の設定ファイルをコピーしないようにします。バックアップディレクトリは日付とクライアント名で分けてもよいですが、サブスクリプションの認証情報を含むファイルを公開場所へアップロードしないでください。復元時はまず同じクライアント系列でテストし、その後にバージョン間、クライアント間の移行を検討します。

システムのプラットフォーム、CPUアーキテクチャ、クライアント名、プロキシモード、カスタムローカルポート、TUNの有効・無効など、簡潔な環境記録も残すとよいでしょう。ノードの認証情報を含める必要はありませんが、再インストール後に操作の流れをすばやく復元できます。複雑なルールには用途の説明を添え、数か月後に意味不明な条件だけが残らないようにします。復元可能な設定とは、「空の環境から安定状態へ戻るために、最小限どの手順が必要か」に答えられるものです。

エラー語だけでなく、ログの段階から原因を特定する

ログを調べるときは、まず時系列を確認します。クライアントが設定を読み込み、コアが起動し、ローカルポートが待ち受け、DNSクエリが行われ、ルールが照合され、リモート接続とアプリリクエストが発生する各段階が、どこに現れているかを見ます。1つのerror表示は単なる再試行かもしれません。同種のエラーが連続しているほうが、処理が止まっている段階を示しやすくなります。問題が起きた正確な時刻を記録し、その前後の関連行だけを抜き出すと、ログ全体をコピーするより分析しやすく、サブスクリプションURLなどの機密情報を公開するリスクも減らせます。

トラブルシューティング記録テンプレート
1. プラットフォームとクライアント：Windows / v2rayN
2. トラフィック制御方式：システムプロキシまたはTUN
3. 影響範囲：すべてのアプリ、1つのアプリ、または1つのドメイン
4. 直近の変更：クライアント、サブスクリプション、ルール、DNS
5. 比較結果：直接接続、ルール、グローバルでそれぞれどうなるか
6. ログの段階：起動、解決、ルーティング、ハンドシェイク、タイムアウトのどこか

クライアントが起動しない場合は、実行環境、ディレクトリ権限、設定の破損、ポート使用状況を優先して確認します。サブスクリプションを更新できない場合は、URLとリクエストエラーを確認します。コア起動後にすべてのノードが失敗する場合は、システム時刻、ネットワーク、プロトコル互換性を確認します。ルールモードだけ失敗する場合はルールの順序を確認し、TUNだけ失敗する場合は権限、DNS、システムルーティングを確認します。段階ごとに分類すれば、多くの問題を1つか2つのモジュールまで絞り込めます。

ポート競合、残存プロキシ、バックグラウンド制限に対処する

ポート競合は、クライアントの異常終了、重複起動、複数ツールの同時実行時によく発生します。まず関連するクライアントをすべて正常に終了し、残存プロセスを確認します。ローカルポートを変更する場合は、システムプロキシと手動でプロキシを指定したアプリも同時に更新します。システムプロキシが残っていると、クライアント終了後にブラウザーへアクセスできなくなることがあります。その場合はまずOSのプロキシ設定を復元してからクライアントを再起動すればよく、サブスクリプションの削除やOSの再インストールは必要ありません。

Androidでバックグラウンド接続が切れる場合は、省電力設定、バックグラウンド活動の制限、自動起動権限、常時通知を確認します。設定の入口は端末ごとに異なりますが、判断方法は同じです。前面では安定し、画面ロック後に切れるなら、通常はバックグラウンド管理が原因です。前面でも接続できない場合は、まず設定とVPN許可を確認します。サービスを維持するためにログレベルを無制限に上げないでください。ログは観察のためのものであり、システムのスケジューリングを変えるものではありません。

定期的に軽い点検を行う

日常のメンテナンスで頻繁に設定を変える必要はありません。定期的にサブスクリプションを更新し、明らかに使えない一時設定を削除し、フィルターが新しいノードを誤って除外していないか確認し、クライアント設定が現在の用途に合っているか確認します。ルールは業務内容が変わったときだけ調整し、TUNは対象範囲が本当に必要な場合だけ有効にします。新しい設定を追い続けるより、長期的な安定性を重視してください。

異常が起きたら、まず直近の変更を思い出し、「高度な機能を無効にする—基本ノードへ戻す—システムプロキシを確認する—設定を1つずつ戻す」の順で進めます。再インストールが必要な場合も、先に設定をバックアップし、旧プロセスが終了していることを確認します。起動クラッシュ、権限、残存プロセスへの対処方法は、ランタイムと権限の問題を切り分ける方法も参照してください。次章では、これらの基礎をプロトコル、コア、設定の読み解きへ広げます。

応用への道筋：クライアントを使うだけでなく設定を読めるようになる

第1段階：完全なノード設定を読み解く

応用学習は、最初から設定ファイル全体を書く必要はありません。まず正常に使えるノードを1つ選び、クライアント画面と照らし合わせながら、アドレス、ポート、ユーザー識別子、プロトコル、トランスポート方式、セキュリティ層、ドメイン、フィンガープリントなどを1項目ずつ理解します。重要なのはすべての選択肢を暗記することではなく、サーバー側と一致させる必要があるパラメータと、ローカル側の好みを区別することです。動作する設定をテスト項目として複製し、重要ではない項目を1回に1つだけ変更してログを観察すると、項目と挙動の関係を理解できます。

プロトコル層とトランスポート層は分けて学びます。VLESS、VMess、Trojanは識別情報とプロトコルのやり取りを表し、TCP、WebSocket、gRPCはデータの運搬方式を表します。TLSやREALITYは、対応するセキュリティとハンドシェイクを処理します。名前が似ていても、パラメータを相互に使えるとは限りません。設定は外側から内側へ読みます。まずサーバーアドレスとポート、次にプロトコルの識別情報、その後にトランスポート、最後にセキュリティ層とドメインを確認します。この順序は、接続失敗時の手作業による確認にも使えます。

第2段階：XrayとV2Flyのエコシステム上の関係を理解する

XrayとV2FlyはいずれもProject Vの技術エコシステムから発展した系統で、クライアントは用途に応じたコアを統合します。v2rayNはデスクトップでの総合管理、v2rayNGはXrayコア、v2flyNGはV2Flyコアを使うAndroid向けの選択肢です。コアの違いは、対応プロトコル、設定項目、更新のペースに影響します。サブスクリプション設定が特定の機能に明確に依存している場合は、それに合ったクライアントとコアを使います。

コアの違いを学ぶときは、「対応一覧」を絶対的な優劣に置き換えないでください。より有用な問いは、現在の設定がどのプロトコルとトランスポート項目を使っているか、クライアントに統合されたコアが認識できるか、更新後に挙動が変わったか、ログに未知の項目が出ていないかです。2つのコア系列の発展とクライアント選びについては、XrayとV2Flyのコアの違いを詳しく解説を参照してください。

第3段階：グラフィカルなルールから構造化設定へ進む

クライアントのルーティングエディターに慣れたら、コア設定の基本構造を読み始めます。一般的な設定は、ログ、DNS、インバウンド、アウトバウンド、ルーティングで構成されます。インバウンドはシステムプロキシやTUNからのトラフィックを受け取り、アウトバウンドはプロキシや直接接続などの出口を定義し、ルーティングはマッチング条件をアウトバウンドへ結び付けます。読むときはまずタグ同士の参照関係を探し、その後で各オブジェクトのパラメータを確認します。タグの表記が一致しないと、ルールが存在しない出口を指してしまいます。手動編集でよくある問題です。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

この例は、ローカルSOCKSインバウンド、直接接続のアウトバウンド、プライベートアドレスのルールだけを示しており、リモートサーバーの認証情報は含みません。実際のクライアントは通常、インバウンドと主要なアウトバウンドを自動生成します。手動設定の前に現在の結果をエクスポートして読み、使用中の設定を直接置き換えないでください。変更するたびにJSON構造が完全か確認し、クライアントログでコアが項目を受け入れたことを確認します。

第4段階：再現可能な実験方法を作る

応用設定では、「たくさん変更したが、どれが効いたのか分からない」状態に陥りがちです。実験用に独立したサブスクリプショングループまたはテスト設定を作り、安定した基準状態を残し、変更内容、予想結果、実際のログを記録することをおすすめします。ルーティングをテストするときはノードを固定し、ノードをテストするときはルーティングを固定し、DNSをテストするときは対象ドメインを固定します。変数を少なくするほど、結論の信頼性は高まります。異常が起きたら、新しいパラメータを重ねるのではなく、最後の変更をまず元に戻します。

ログレベルは短期テスト中だけ上げても構いませんが、切り分けが終わったら通常レベルへ戻します。詳細ログには多くの情報が含まれ、アクセス先や設定断片が出力されることもあります。共有する前に、サブスクリプションURL、ユーザー識別子、その他の認証情報を削除してください。コマンドラインテストではローカルループバックアドレスとクライアントの実際のポートだけを使い、一時的な認証情報を長期利用するスクリプトへ直接書き込まないでください。

第5段階：自分用のメンテナンス文書を作る

複数のサブスクリプション、ルーティンググループ、TUN、アプリごとのルールを含む設定では、環境の簡単な説明を作成します。内容には、クライアントを選んだ理由、サブスクリプショングループの用途、デフォルトのプロキシモード、重要なルール、DNS方式、バックアップ場所、復元手順を含めます。機密パラメータを記録する必要はありませんが、再インストールやアップグレード後にどう復元するか分かる内容にします。大きな変更のたびに説明も更新すると、記憶に頼るより確実です。

ゼロから使いこなすとは、すべての項目を有効にすることではありません。現在の設定がなぜ動作しているかを説明でき、異常時にどの層から確認すべきか分かることです。長期運用では、安定したクライアントを1つ使い、サブスクリプショングループとシステムプロキシを理解し、最小限のルールセットを作り、明確な必要性がある場合にTUNを有効にし、最後に構造化設定とコアログを読む、という順序がおすすめです。まだ初回接続が済んでいない場合は、クイックスタートに戻って基本手順を進めてください。プラットフォームやアーキテクチャを変更する場合は、インストーラーページで対応するクライアントを選びます。