体系的な操作ガイド 基本設定から上級メンテナンスまで

V2RAY · XRAY · CLIENT WORKFLOW

V2Rayをゼロから習得完全ガイド

基本概念、クライアントの選択、サブスクリプション登録、プロキシモード、ルーティング、TUNによる通信の取り込み、診断とメンテナンスを実際の操作順に解説します。初回接続を先に済ませたい場合は、より短いクイックスタートガイドから始めてください。本ページでは仕組みの理解、パラメータの確認、例外的なケースへの対処を扱います。

v2rayN をダウンロード まずクイックガイドを見る
Xrayコア サブスクリプションとグループ システムプロキシ geositeルーティング TUNモード

CHAPTER 01

基本概念：コア、クライアント、設定を区別する

V2Ray、V2Fly、Xrayはそれぞれどの層に属するのか

設定を始める前に重要なのは、メニューの場所を覚えることではなく、頻繁に登場する名称を正しい階層に整理することです。V2Rayは通常、Project Vから発展したプロキシ技術のエコシステムと設定体系を指します。V2Flyはその中の一つのコア系統を引き継ぎ、保守しています。Xrayは同じ技術ファミリーに属する別のコア実装です。コアは設定を解析し、インバウンドとアウトバウンドを構築し、プロトコルのハンドシェイクを実行し、DNSポリシーを適用して、ルーティングルールに従って通信を転送します。通常はバックグラウンドで動作し、サブスクリプション一覧、トレイメニュー、システムプロキシの切り替えといったGUI操作を直接担当するものではありません。

v2rayN、v2rayNG、v2flyNGはクライアント層に属します。クライアントはサブスクリプション管理、サーバー選択、ログ確認、プロキシモードを操作画面にまとめ、対応するコアを呼び出して接続を処理します。デスクトップ環境ではWindows、macOS、Linuxに対応するv2rayNが第一候補です。AndroidではXrayコアを採用するv2rayNGを優先し、v2flyコア系統が必要な場合にv2flyNGを選びます。この関係を理解していれば、問題が画面設定、サブスクリプション内容、コアの起動、ネットワーク環境のどこにあるか判断でき、クライアント全体を何度も再インストールせずに済みます。

一つの接続は何で構成されるのか

接続を確立できる設定には、少なくともインバウンド、アウトバウンド、ルーティングという3つの論理部分があります。インバウンドは、ローカルのSOCKSポート、HTTPプロキシポート、TUN仮想NICから受け取ったデータなど、本機のアプリがどのように通信をコアへ渡すかを定義します。アウトバウンドはコアが通信をどう処理するかを表し、プロキシ、直接接続、ブロックなどのタグがよく使われます。ルーティングはその間に位置し、ドメイン、IP、ポート、ネットワーク種別、インバウンドタグなどに基づいて使用するアウトバウンドを決定します。GUIクライアントが設定の一部を生成するため、普段の利用で完全な設定ファイルを手書きする必要はありませんが、構造を理解しておくとログの読解やルール確認に役立ちます。

サーバーエントリには、リモート接続に必要なアドレス、ポート、認証情報、プロトコル、トランスポートのパラメータが含まれます。プロトコルはデータ交換の方法を、トランスポート層はTCP、WebSocket、gRPCなどどの通信路でデータを運ぶかを決め、TLSやREALITYなどのセキュリティパラメータがハンドシェイク方式を制約します。重要な項目が一つでも一致しなければ接続に失敗します。クライアントがURLを取り込めたからといって、設定が有効とは限りません。取り込み成功は構文が認識されたことを示すだけで、実際に使えるかどうかはDNS解決、ネットワーク到達性、システム時刻、リモート側の状態などを確認する必要があります。

サブスクリプションはプロトコルではなく、ノードはクライアントではない

サブスクリプションURLは設定を配布する入口です。クライアントがURLへアクセスすると、サーバーはサーバーエントリの一覧または構造化設定を返し、クライアントがリストへ変換します。サブスクリプション自体が通信を転送するわけでも、特定のプロトコルを意味するわけでもありません。よくある誤解は「サブスクリプションの更新成功」を「プロキシが有効」と捉えることです。前者は一覧を取得して解析できたことを示すだけで、後者にはサーバーの選択、コアの起動、アプリの通信をローカルプロキシまたはTUNインバウンドへ入れる操作が必要です。

「ノード」は、画面上でサーバー設定エントリを指す一般的な呼び方です。一つのエントリにVMess、VLESS、Trojanなどのプロトコルパラメータが含まれる場合もあれば、同じリモート入口に対する異なるトランスポート構成を参照する場合もあります。現在の環境に適しているか判断する際は、まずプロトコルとトランスポートがクライアントのコアに対応しているかを確認し、次にアドレスが解決できるか、ポートへ到達できるかを見て、最後にルーティングモードを確認します。表示名だけで用途を判断しないでください。表示名は通常、サブスクリプション提供元が設定したメモであり、実際のハンドシェイクには関与しません。

トラブル対処の順序

まずサブスクリプションが更新できるかを確認し、次にサーバーエントリを起動できるかを確認します。その後、システムプロキシまたはTUNが通信を取り込んでいるかを確認し、最後にルーティングとDNSを調べます。通信の流れに沿って確認すれば、ルーティングの問題をインストールの問題と誤認せずに済みます。

アプリのリクエストからリモートアウトバウンドまでの経路

ブラウザでWebサイトへアクセスする場合、まずドメインを解決し、OSのプロキシ設定に従ってリクエストをv2rayNのローカル待受ポートへ渡します。コアは対象ドメインと対象IPを取得した後、ルーティングルールを上から順に照合します。directに一致すると本機のネットワークから直接アクセスし、proxyに一致すると現在のサーバーのアウトバウンドを経由し、blockに一致すると転送を停止します。アプリがシステムプロキシを読み取らない場合、この経路には入りません。その場合はアプリ内で個別にプロキシを設定するか、TUNで通信を取り込む必要があります。

この流れから、「クライアントは実行中」と表示されていても実際のプロキシ効果がない理由が分かります。実行中とはコアのプロセスが存在することを示すだけです。システムプロキシが有効でない、アプリがシステム設定を回避する、ルールが対象を直接接続へ振り分ける、といった可能性があります。反対に、あるWebサイトが開けても、すべてのルールが正しいとは限りません。たまたま直接接続された可能性があるためです。設定を検証する際は、クライアントログ、システムプロキシの状態、対象リクエストのルーティング結果を同時に確認し、Webページが一つ読み込めるかだけで判断しないでください。

CHAPTER 02

クライアントの選択とインストール：プラットフォームごとに安定した出発点を作る

3つのクライアントの役割分担

デスクトッププラットフォームではv2rayNを優先します。サブスクリプションのグループ化、サーバー一覧、システムプロキシ、ルーティングルール、TUN、ログを一つの操作画面にまとめられ、基本接続から複雑な振り分けまで段階的に拡張できます。Windowsでは画面実装に応じてデスクトップ版または従来のWPF版を選べます。前者はクロスプラットフォームのデスクトップUIを採用し、後者は従来のWindows操作感を引き継いでいます。基本的な役割は同じなので、同時に起動する必要はありません。macOSとLinuxでは各プラットフォーム向けのv2rayNパッケージを使い、ダウンロード時にCPUアーキテクチャとディストリビューションのパッケージ形式を確認します。

Androidではv2rayNGを優先します。Xrayコアを採用し、設定の考え方はデスクトップ版に近い一方、プロキシの取り込みはシステムVPNインターフェースで行い、画面構成もよりコンパクトです。v2flyNGはv2flyコアを採用した代替クライアントで、そのコア系統が明確に必要な設定に適しています。2つのAndroidクライアントは別々にインストールできますが、日常の接続ではシステムVPNセッションを一つだけ有効にし、取り込み権限の競合を避けてください。完全なインストールパッケージとプラットフォームの説明はダウンロードページにまとめています。

利用環境 第一候補のクライアント 主な用途 選ぶ際のポイント
Windows v2rayN システムプロキシ、ルーティング、TUN デスクトップ版と従来のWPF版から一方を選んでインストール
macOS v2rayN デスクトッププロキシとシステム通信の取り込み Apple SiliconとIntelのアーキテクチャを区別
Android v2rayNG モバイル通信のプロキシとアプリ単位の振り分け 一般的な端末ではarm64パッケージを優先
Linux v2rayN デスクトップ環境のプロキシ、ルーティング、ログ管理 ディストリビューションに応じてdebまたはrpmを選択

インストール前にアーキテクチャと権限を確認

CPUアーキテクチャによって、インストールパッケージを起動できるかどうかが決まります。WindowsとLinuxの一般的なデスクトップPCは通常x64を使用し、ARMプロセッサ搭載端末ではarm64が必要です。macOSでは「システム情報」のチップまたはプロセッサ欄で確認できます。Appleチップと表示される場合はApple Silicon向けパッケージ、Intelと表示される場合はx64を選びます。Androidでは端末情報またはハードウェア検査画面でABIを確認できます。近年の主流端末は通常arm64に対応しています。不明な場合は汎用パッケージを使えますが、一般に容量は大きくなります。

インストール権限は、システムプロキシ、仮想NIC、サービス登録に影響します。通常のシステムプロキシでは現在のユーザー設定を変更するだけで済みますが、TUNモードでは仮想ネットワークインターフェースの作成やルーティングテーブルの変更が必要なため、管理者権限を求められる場合があります。権限要求はユーザーが該当機能を明示的に有効化した時点で行われるべきです。クライアントは開けるのにTUNだけ起動できない場合、まず権限とドライバーの状態を確認し、サーバープロトコルを変更するのは後にしてください。企業管理端末では、プロキシやネットワーク拡張がポリシーで一元管理されている場合があり、その制限はシステム管理の範囲で対処する必要があります。

初回起動後に行う最小限の確認

初めてクライアントを開いたときは、すぐにすべてのオプションを有効にしないでください。まずメイン画面が正常に表示されるか、設定画面からコアのパスを確認できるか、ログウィンドウを開けるかを確認してから、サブスクリプションを登録します。v2rayNのメイン画面には通常、サブスクリプショングループ、サーバー一覧、システムプロキシ、ルーティング設定があります。v2rayNGは設定一覧、選択中の項目、接続ボタンを中心とした構成です。この段階ではシステムプロキシを無効にしておくと、インストールの問題と設定の問題を切り分けられます。

続いてシステム時刻、タイムゾーン、ネットワークの基本状態を確認します。TLSやREALITYなどのハンドシェイクは時刻のずれに敏感で、システム時刻が間違っていると証明書やハンドシェイクの失敗として現れることがあります。まずプロキシを使わないネットワークで、通常のWebサイトとDNSが動作することを確認してからクライアントを起動します。現在のネットワークでWeb認証が必要な場合は、先に認証を済ませてください。認証ページはプロキシ起動前のほうが安定しやすいためです。ネットワークを切り替えた後も、新しいアドレスとDNSを取得するまで待ってから再接続します。

Windows PowerShell
Get-Date
Get-NetIPConfiguration
Test-NetConnection example.com -Port 443

macOS / Linux
date
curl -I https://example.com

これらのコマンドは、本機の時刻、NIC設定、基本的なHTTPS到達性を確認するためだけに使います。プロキシサーバーが有効かどうかを判定するものではありません。基本接続自体に失敗している場合は、まずローカルネットワークを復旧します。基本接続が正常なのにクライアントのコアが起動できない場合は、設定の解析とポート使用状況を確認します。これにより、ネットワークが切断された状態でサブスクリプションの項目を何度も入れ替える事態を避けられます。

アップグレード、並行インストール、設定ディレクトリ

クライアントをアップグレードする前に、実行中のコアを終了し、現在のサブスクリプショングループ、ルーティングモード、カスタムルールを記録します。クライアント設定は通常、ユーザーディレクトリまたはアプリデータディレクトリに保存されますが、場所はプラットフォームとインストール形態によって異なります。上書きインストールの前に、クライアントのバックアップまたはエクスポート機能で必要な設定を保存してください。キャッシュ、ログ、サーバー一覧を唯一のバックアップにしないでください。サブスクリプションURLは再取得できますが、手動追加したサーバー、ルーティングルール、DNS設定はサブスクリプションから復元できない場合があります。

同じPCに異なるUI実装を残して移行テストすることはできますが、2つのクライアントで同じローカルポートを同時に待ち受けたり、システムプロキシを同時に変更したりしないでください。ポート競合は通常、ログに「アドレスはすでに使用されています」や待受失敗として表示されます。クライアントを切り替えるときは、まず旧クライアントが設定したシステムプロキシを解除して完全に終了し、その後に新しいクライアントを起動します。異常終了後もシステムにプロキシアドレスが残っている場合は、OSのネットワーク設定でプロキシを無効にしてから、クライアントで再設定します。

CHAPTER 03

サブスクリプション登録：URLから設定を取得してグループを作る

サブスクリプションURLの構造と保存方法

サブスクリプションURLは通常HTTPS URLで、パスやクエリパラメータにアカウントを識別するトークンが含まれます。クライアントが定期的にサーバー一覧を取得するためのものなので、アカウント認証情報として管理し、公開ページ、スクリーンショット、ログに掲載しないでください。コピーする際は、プロトコルの先頭から最後の文字まで完全に保持し、チャットツールによるクエリパラメータの自動切り詰めに注意します。クライアントに保存するのはURLであり、Webページの本文ではありません。ブラウザで開いた際にエンコードされた文字列やダウンロードレスポンスが表示されても、URLが間違っているとは限りません。

https://example.com/sub?token=xxxx

上のURLは一般的な構造を示したものです。実際のサブスクリプションでは異なるパスやパラメータ名が使われる場合があります。登録時に、余分に見えるイコール、スラッシュ、パーセントエンコードを手動で削除しないでください。トークンや署名の一部である可能性があります。コピー後の末尾に空白や改行が付いている場合は、見えない文字を先に削除します。サブスクリプションURLが切り替わった場合は、重複グループを増やし続けず、既存グループを編集してください。古いサーバーと新しいサーバーが同じ一覧に混在するのを防げます。

v2rayNで登録・更新する

デスクトップ版では、まずサブスクリプショングループを作成し、そのグループ設定にURLを登録します。「サブスクリプショングループ」に関するメニューを開き、グループ名とURLを入力して保存した後、更新を実行します。グループ名はローカルで識別するためだけのものなので、用途や提供元に合わせて命名でき、リモートのレスポンスには影響しません。更新に成功すると、サブスクリプションの内容からサーバー一覧が生成されます。古い項目を削除する更新方式を有効にしている場合、今回の結果でそのグループの以前の項目が置き換えられるため、手動追加したサーバーは別グループに分けるのがおすすめです。

更新後は、項目数が妥当か、プロトコルが認識されているか、アドレスとポートの列が存在するかを確認してから、項目を一つ選びアクティブサーバーに設定します。更新中に何度も連続クリックしないでください。同時リクエストがサブスクリプション側のレート制限に触れたり、ログを読みにくくしたりする可能性があります。複数のサブスクリプションを併用する場合は、提供元ごとに独立したグループを作り、必要に応じて更新間隔を設定します。サーバーをさらに整理したい場合は、複数サブスクリプショングループとキーワードフィルターを参照し、グループ、フィルター、ルーティングの用途を分けて管理してください。

v2rayNGとv2flyNGで登録する

Androidクライアントでは通常、サブスクリプション設定からURLを追加し、メイン画面に戻って更新を実行します。更新にはクライアントのネットワークアクセスが必要です。省電力制限、バックグラウンドデータ制限、プライベートDNSの異常がリクエストを妨げることがあります。更新後に設定項目が一覧へ表示されたら、その中から現在の設定を手動で選択します。選択状態は次回の接続に使う設定を指定しただけで、システムVPNセッションが確立したことを意味しません。接続を実行し、ステータスバーにVPNマークが表示されることを確認してください。

v2rayNGとv2flyNGのサブスクリプションデータは別々に管理します。一部の汎用共有URLは両方で認識できますが、2つのコアでは新しいプロトコル項目や拡張オプションへの対応時期が異なる場合があります。ある設定が一方のクライアントで解析できないときは、まず現在のコアが未対応の項目を含んでいないか確認し、サブスクリプション全体が無効だと決めつけないでください。コアごとに対応した入口が用意されている場合は、クライアントに合った入口を使います。

更新成功、解析成功、接続成功の違い

サブスクリプション更新は、独立して判断できる3段階に分かれます。第1段階はHTTPリクエストの成功で、URLへアクセスしてレスポンスを取得できたことを意味します。第2段階は内容の解析成功で、返された形式をサーバー項目へ変換できたことを示します。第3段階で初めて項目を選択し、プロキシ接続を確立します。レスポンスのステータスは正常なのに一覧が空の場合、内容形式、アカウント状態、フィルター条件が原因であることが多いです。一覧はあるのにすべて接続できない場合は、サーバーパラメータ、時刻、DNS、現在のネットワークを確認します。

ログのエラーは段階ごとに読みます。ドメイン解決失敗はサブスクリプションのドメインからIPを取得できないことを示します。接続タイムアウトは期限内にリクエストが完了しなかったことを示します。認証エラーやアクセス禁止は、URLトークン、アカウント状態、リクエストポリシーに関係することが多いです。解析失敗はレスポンス内容がクライアントの想定形式ではないことを意味します。「プロキシ経由でサブスクリプションを更新」を設定している場合、プロキシ自体が無効だと依存関係が循環します。トラブル対処では一時的に直接接続で更新し、成功後に元の方式へ戻します。

サブスクリプション登録後に確認できる正しい状態

グループ内に認識可能なサーバー項目が表示され、選択した項目でコアを起動でき、ログに設定解析エラーがない状態です。それでも次の段階でシステムプロキシまたはTUNを選択しなければ、アプリの通信は接続へ入りません。

グループ、フィルター、重複排除の方針

グループの価値は見た目の整理だけではありません。更新と削除の対象範囲も限定できます。仕事、普段の閲覧、テスト設定を分けて保存すれば、一つの提供元を更新しても他のグループは上書きされません。サーバー名に地域や用途のキーワードが含まれている場合は、クライアントのフィルターで一覧を絞れます。ただしフィルターが変えるのは表示または選択範囲であり、リモート設定ではありません。フィルターを作る前に命名パターンを確認し、広すぎるキーワードで無関係な項目まで選ばないようにします。

重複項目は、同じサブスクリプションを何度も登録した、提供元が重複して返した、移行時に古いグループを残した、といった原因で発生します。まず項目が属するグループを確認し、その後で古い提供元を削除します。表示名だけで一括削除しないでください。異なる設定が同じメモを使っている可能性があります。更新後も古い項目が残る場合は、そのグループの更新方式が追加方式になっていないか確認します。長期的には自動更新をサブスクリプション項目に任せ、手動設定は独立グループに置きます。2種類のデータはライフサイクルが異なるため、混在させると誤削除の可能性が高まります。

サブスクリプション更新失敗時の最短診断ルート

まずプロキシ経由でサブスクリプションを更新する設定を無効にし、現在の基本ネットワークから一度リクエストします。次にURLが完全か、システム時刻が正しいか、サブスクリプションのドメインを解決できるかを確認します。一つのURLだけ失敗し他が正常なら、そのURLの権限やレスポンスに問題がある可能性が高いです。すべて失敗するなら、DNS、システムプロキシの残留、セキュリティソフトのネットワークポリシーを確認します。更新後にサーバーが表示されない場合は、名前フィルターが有効になっていないか、レスポンスがWebエラーページとして返されていないかを確認します。

一つのサブスクリプションエラーを解決するために、頻繁な削除や再インストールを繰り返さないでください。クライアントを再インストールしてもリモートのレスポンスは変わらず、間違ったURLも修正されません。失敗時のログを一度保存し、リクエストの段階とステータス情報を確認してから、URLの修正、更新ネットワークの切り替え、解析方式の調整を判断します。より多くの具体例はよくある質問で「インストールと設定」および「トラブル対処」の分類から探せます。

CHAPTER 04

プロキシモード：どのアプリのリクエストをクライアントへ渡すか決める

システムプロキシとコアのルーティングは別の問題を解決する

システムプロキシは、OSのプロキシ設定に対応するアプリのリクエストをクライアントのローカルポートへ送ります。コアのルーティングは、リクエストがクライアントへ入った後で、最終的にプロキシ、直接接続、ブロックのどれを使うか決めます。前者は「入るかどうか」、後者は「入った後にどこへ進むか」を制御します。両者を同じスイッチと考えると設定が混乱します。ルーティングをグローバルプロキシにしても、システムプロキシを読まないアプリは自動的に入ってきません。システムプロキシが有効でも、ルーティングによって特定の対象が直接接続へ振り分けられることがあります。

v2rayNの「システムプロキシを自動設定」は、ブラウザやシステム設定に従うデスクトップアプリに適しています。有効にすると、クライアントがOSのプロキシアドレスをローカル待受ポートへ向けます。システムプロキシを解除すると、この設定が取り消されます。「システムプロキシを変更しない」は、コアだけを起動し、他のアプリからローカルポートへ手動接続する場合に使います。PACモードでは、ルールファイルを通じてアプリへ異なるプロキシ判断を返します。普段はシステムプロキシの自動設定を選び、コアのルーティングと組み合わせるのが最も理解しやすい方法です。

システムプロキシを解除
システムプロキシを自動設定
システムプロキシを変更しない
PACモード

グローバル、ルール、Chinaバイパスモードの考え方

クライアント画面の「グローバル」は通常、コアに入った通信をデフォルトでプロキシアウトバウンドへ送ることを意味します。ルールの問題を短時間で切り分けるのに適していますが、すべてのアプリを強制的に取り込むわけではありません。ルールモードはルーティングテーブルを上から順に照合し、LAN、プライベートアドレス、特定のドメイン集合を直接接続へ、それ以外をプロキシへ送るのが一般的です。Chinaバイパスモードは、あらかじめ用意されたルールの組み合わせで、中国本土のドメインとIPを直接接続へ振り分け、その他の対象をプロキシへ送ります。プリセットは使い始めに便利ですが、実際のアプリで誤判定がないか確認してください。

モードは目的から選びます。普段の閲覧ではルールモードまたはChinaバイパスモードを優先し、不要なプロキシ経路を減らします。特定の対象が誤って振り分けられていないか調べるときは、一時的にグローバルモードへ切り替えて比較します。開発ツールだけをプロキシに通したい場合は「システムプロキシを変更しない」にして、そのツールにローカルSOCKSまたはHTTPアドレスを手動入力します。モードの違いと代表的な用途はシステムプロキシ、グローバル、Chinaバイパスモードの違いで詳しく解説しています。

ローカルSOCKSポートとHTTPポート

コアは通常、SOCKSとHTTPという2種類のローカルインバウンドを同時に提供します。SOCKSはTCPを転送でき、クライアントの実装によってはUDPも処理できます。HTTPプロキシはHTTP CONNECTを標準でサポートするアプリに適しています。ポートはクライアント設定から生成されるため、他のガイドにある固定番号をそのまま使わないでください。個別のアプリでプロキシを設定する場合は、現在のクライアント設定画面からローカル待受アドレスと実際のポートを確認します。ホストには通常、ループバックアドレス127.0.0.1を使い、ローカルプロキシをLANへ公開しないようにします。

アプリの設定では「プロキシDNS」と「ローカル解決」も区別します。SOCKSクライアントによっては本機で先にドメインを解決してIPをプロキシへ渡しますが、別の実装ではドメインをリモート経路へ渡して解決します。前者はコアのドメインベースのルーティングを回避する可能性があり、後者はドメイン情報を保持しやすくなります。アプリにsocks5hのようなモードがある場合、ホスト名の解決は通常SOCKSリクエストに含めてプロキシへ渡されます。具体的な選択は、コアのDNSとルーティング方針に合わせてください。

HTTP_PROXY=http://127.0.0.1:ローカルHTTPポート
HTTPS_PROXY=http://127.0.0.1:ローカルHTTPポート
ALL_PROXY=socks5h://127.0.0.1:ローカルSOCKSポート

上記は環境変数の構造を示す例です。実際には文字のポート部分をクライアントに表示される数字へ置き換えます。コマンドラインツールがこれらの環境変数を読み取る場合にだけプロキシが使われます。ターミナルを閉じるか変数を削除すると、直接接続に戻ることがあります。システムプロキシ、環境変数、アプリ内プロキシがそれぞれ別のクライアントを指すなど、競合するプロキシ元を同時に設定しないでください。リクエスト経路の判断が難しくなります。

システムプロキシが本当に有効か確認する

まずv2rayNのステータスバーで、システムプロキシが自動設定になっていることを確認します。次にシステムプロキシに従うブラウザでページを開き、クライアントのアクセスログを同時に確認します。ログに新しい接続が現れれば、リクエストはコアへ入っています。ログがない場合は、ブラウザが独自プロキシを使っていないか、直接接続ポリシーが有効でないか、古いプロセスから環境変数を引き継いでいないかを確認します。ブラウザを完全に終了して再起動すると、接続プールやプロキシ設定のキャッシュを切り分けられます。

ログはあるのに対象へアクセスできない場合は、ルーティングタグとアウトバウンドエラーを確認します。directに一致していれば、ルールが直接接続を選択しています。プロキシアウトバウンドへ進んだ後にタイムアウトするなら、リモート経路またはネットワークの問題です。システムプロキシを無効にしても直接接続できない場合、OSに古いアドレスが残っている可能性があります。システムのネットワーク設定で手動プロキシ欄を確認し、使っていないループバックアドレスとポートを削除してから、クライアントで自動設定し直します。

モバイル端末で通信を取り込む方法

v2rayNGとv2flyNGはシステムVPNインターフェースを通じてアプリの通信を受け取るため、ブラウザごとにシステムプロキシを変更する必要はありません。接続ボタンを押すと、システムがVPNセッションの確立を要求します。許可後、クライアントがルーティングとアプリ単位の設定に従って通信を振り分けます。接続アイコンが表示されるのはインターフェースが確立したことを示すだけなので、ログで現在の設定がリモートへ正常接続していることも確認してください。ネットワークの切り替え、省電力モード、長時間のバックグラウンド動作後は、システムがプロセスを終了させる場合があります。バッテリー最適化とバックグラウンド実行の権限を確認します。

アプリ単位のプロキシでは、どのアプリをクライアントへ入れるかを限定でき、仕事用アプリと他の通信を分けるのに適しています。設定時は「選択したアプリのみをプロキシする」のか「選択したアプリをバイパスする」のかを明確にしてください。意味が正反対だからです。リストを変更した後は接続を再確立し、システムにルーティングを再読み込みさせます。アプリ内にも独自プロキシが設定されている場合は、システムVPNとの二重転送を避けます。まずアプリのネットワーク設定を初期状態に戻してテストしてください。

CHAPTER 05

ルーティング：ドメイン、IP、インバウンドでアウトバウンドを選ぶ

ルールは上から順に照合される

ルーティングルールで重要なのは、ルールの数ではなく照合順序です。コアは通常、リストを上から下へ確認し、リクエストが一つのルールに一致すると対応するアウトバウンドを使い、後続の通常ルールの照合を止めます。そのため、範囲が狭く意図が明確なルールを前に置き、広い範囲を対象とするフォールバックルールを後ろに置きます。たとえば広告ドメインのブロックは汎用ドメインプロキシより前に、LANとプライベートアドレスの直接接続はデフォルトプロキシより前に配置します。順番が逆なら、ルール構文が完全に正しくても結果は誤ります。

ドメインルールは、コアが対象ドメインを取得できる場合にだけ機能します。アプリが本機で先に解決し、IPだけを送信すると、geositeルールが一致しない可能性があり、その後はgeoipなどのIPルールに頼ることになります。逆にIPルールには解決結果が必要です。解決方式とDNSの応答が影響します。安定した振り分けには、アプリのインバウンド、DNS、ルーティングを同じ設計に組み込む必要があり、ルール一覧だけをコピーすればよいわけではありません。

geosite、geoip、domainStrategy

geositeはドメイン集合で照合するルールデータです。たとえばgeosite:cnは該当するドメイン集合を表し、geosite:category-ads-allは広告ドメインの分類によく使われます。geoipはIP集合で照合し、geoip:privateはプライベートアドレス、geoip:cnは該当地域のIPに使われます。ルールデータはクライアントまたはコアのリソースとともに更新されます。集合が存在しないというログが出た場合は、リソースファイルが完全か、現在のデータセットがそのタグに対応しているか確認します。

domainStrategyは、ルーティングがどの条件でドメインをIPへ解決するかを決めます。AsIsは元のドメインによる照合を優先し、IPルールのために積極的な解決は行いません。IPIfNonMatchはドメインルールに一致しなかった場合にIPを解決し、照合を続けます。IPOnDemandはルールでIPが必要になった時点で、より積極的に解決します。ドメインとIPを混在させる日常的な振り分けではIPIfNonMatchがよく使われ、ドメイン照合を維持しながら後続のIPルールも機能させられます。ただし、DNS設定と性能も考慮して選択してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

このJSONは、blockとdirectという名前のアウトバウンドが完全な設定内で定義されていることを前提に、Xray設定へ追加できるルーティングオブジェクトを示します。デフォルトプロキシは通常、ルールに一致しない場合にクライアントが選択するか、範囲の広い最後のルールで明示的に指定します。断片をコピーする前に、クライアントが生成したアウトバウンドタグを確認してください。クライアントによってタグ名が異なる場合があり、タグが一致しないとコア起動時にアウトバウンドが見つからないエラーになります。

説明可能な最小ルールセットを作る

初めてカスタマイズする場合は、意図を4種類に絞るのがおすすめです。不要なドメイン集合の明示的なブロック、プライベートネットワークの直接接続、直接接続が必要なドメインとIP、それ以外をデフォルトプロキシへ送る処理です。ルールを一つ追加するたびに、「何に一致するのか」「なぜこの位置なのか」「一致後にどのアウトバウンドへ進むのか」を説明できるようにします。説明できないルールは、まず追加しないでください。数が多く出所の分からないルールセットは更新依存を増やし、誤判定の特定も難しくします。

プライベートアドレスの直接接続は特に重要です。LANプリンター、ルーター管理画面、ファイル共有、ローカル開発サービスは通常プライベートネットワークにあり、リモートプロキシへ送るべきではありません。geoip:privateのほか、対象ポート、インバウンドタグ、明示的なネットワーク範囲でルールを追加できます。TUNからLANへアクセスする場合は、仮想NICのルーティングがローカル経路を上書きしていないことも確認します。直接接続はコアの判断にすぎず、OSのルーティングテーブルも対象へ到達できなければなりません。

ドメイン、ポート、プロセスで細かく分ける

カスタムドメインには、完全なドメイン名、サブドメインのサフィックス、キーワード、正規表現を使えます。予測しやすい完全一致とサフィックス一致を優先してください。キーワードは無関係なサイトまで誤って一致させる可能性があり、正規表現は複雑さを抑えて用途を記録します。ポートルールは特定サービスの限定に適していますが、ポートだけでWebサイトの所属は判断できません。同じポートで多くの異なるサービスが動く可能性があるためです。ドメインとポートを同じfieldルールに入れる場合、通常は両方の条件を満たす必要があります。設定前に、コアが複数フィールドをどう照合するか確認してください。

プロセス単位の振り分けは、プラットフォームの機能とクライアント実装に依存します。画面にプロセス名ルールがあっても、権限、プロセスの派生方法、コンテナ環境の影響を受けることがあります。プロセスルールはデスクトップアプリに対する補助的な制御として使い、ドメインとIPルールの代わりにはしないでください。アプリの更新で実行ファイル名やパスが変わると、古いルールが機能しなくなることもあります。メンテナンス時は、ルールが残っているかだけでなく、ログで実際のプロセス識別結果を確認します。

DNS漏洩と振り分けのずれ

対象ドメインをローカルDNSで直接解決し、接続自体はプロキシを通すと、解決リクエストと実際の通信が異なる経路になります。その結果、地域による応答の違い、ドメインルール情報の消失、解決失敗が起こる可能性があります。単にDNSアドレスを変更するのではなく、どのドメインをどのDNSサーバーで解決し、DNSリクエストをどのアウトバウンドから送るかを明確にします。コアDNS、システムDNS、ブラウザのセキュアDNS、TUNのDNSハイジャックが同時に存在する場合があるため、重複する層はできるだけ減らします。

トラブル対処では、まずブラウザ独自のDNS機能を無効にし、システムとクライアントの統一経路でテストします。次にログで対象ドメインが保持されているか、DNSクエリがどのアウトバウンドを通ったか、返されたアドレスが想定のIPルールに入ったかを確認します。さらに調べる場合は、V2RayのDNS漏洩チェックと設定実践を参照してください。DNSを変更した後は、システムとアプリのキャッシュを削除してから接続を再確立します。古い結果が判断に影響し続ける可能性があるためです。

ルールのテスト方法

まず最小ルールセットでデフォルトプロキシが使えることを確認し、その後で直接接続とブロックのルールを一つずつ追加します。毎回変更する条件は一つだけにし、ログで一致したアウトバウンドタグを確認します。グローバルモードは正常なのにルールモードが失敗する場合、ルールの順序、DNS、ルールリソースに問題があることが多いです。

ルール変更後の確認リスト

ルーティングを保存したらコアを再読み込みし、フィールド、タグ、リソースに関するエラーがないことを確認します。次に、直接接続を想定した対象、プロキシを想定した対象、LANアドレスをそれぞれ一つずつアクセスします。各リクエストの対象ドメイン、対象IP、アウトバウンドタグを確認し、最後にネットワークを切り替えてもう一度テストします。DNSキャッシュや古い接続プールの影響を除外するためです。特定のアプリだけがルールに従わない場合は、システムプロキシを読むか、独自DNSを使うか、古い接続を再利用しているか、QUICを有効にしているかを確認します。

ルールのメンテナンスでは、短い説明と変更理由を残します。クライアントがメモに対応していれば、そこへ直接記録します。JSONしか編集できない場合は、外部ドキュメントにルールの意図を保存し、厳密なJSONファイルへコメントを追加しないでください。ルールを削除する前に、他のインバウンドが依存していないかを確認します。長期的に安定するルールセットは、頻繁にルールを積み重ねる構成より短い傾向があります。明確なデフォルト動作と少数の例外のほうが検証しやすいためです。

CHAPTER 06

TUNモード：システムプロキシを読まない通信を取り込む

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

システムプロキシは、アプリがOSの設定を自発的に読み取ることに依存します。一方TUNは仮想ネットワークインターフェースを作り、ルーティングテーブルに合致するIP通信をOSからクライアントへ渡します。プロキシ設定に対応しないアプリ、一部のコマンドラインプログラム、UDPが必要な用途では、TUNのほうが広い範囲をカバーできます。その代わり設定層が増えます。コアのインバウンドとルーティングルールに加え、仮想NICの権限、システムルート、DNSハイジャック、MTU、LANのバイパスも扱う必要があります。

TUNは「より高速なシステムプロキシ」ではなく、すべての問題に対する最初の解決策でもありません。ブラウザがシステムプロキシで安定して動いているなら、まずサブスクリプション、サーバー、ルーティングを検証し、その後でTUNを有効にします。そうすれば異常が起きたとき、基本のプロキシ経路に問題がないことを確認でき、仮想NICやシステムネットワーク層に範囲を絞れます。最初からTUNを使うと、サーバー、DNS、権限、ルーティングテーブルのどれが原因か区別しにくくなります。

有効化前の権限と競合チェック

仮想NICの作成には通常、管理者権限が必要です。v2rayNでTUNを有効にすると、権限の許可や関連コンポーネントのインストールを求められる場合があります。完了後は、システムのネットワークインターフェース一覧に新しい仮想インターフェースが表示されることを確認します。ログにインターフェース作成失敗、アクセス拒否、ルート書き込み失敗が出た場合は、まずシステムが許可する方法で権限を与え、エンドポイントセキュリティが仮想NICを阻止していないか確認します。エラーを回避しようとしてスイッチを何度も押さないでください。複数の一時ルートが残る可能性があります。

他のVPN、仮想マシンネットワーク、コンテナネットワーク、セキュリティソフトも、ルーティングテーブルやDNSを変更することがあります。TUNを有効にする前に不要な同種ツールを終了し、基本ネットワークのデフォルトゲートウェイとDNSを記録してからクライアントを起動します。2つのツールがデフォルトルートを宣言すると、通信が誤ったインターフェースへ入ったり、ループを形成したりする可能性があります。どうしても並行利用が必要な場合は、より具体的なネットワーク範囲とルート優先度で境界を分け、両方に全通信を取り込ませないでください。

ルーティングテーブル、厳格ルーティング、自動ルーティング

自動ルーティングは、TUNインターフェースへシステムルートを書き込み、対象通信を仮想NICへ入れます。厳格ルーティングはTUNを迂回できる経路をさらに制限するため、DNSと実通信の経路を揃えるのに役立ちますが、仮想マシン、LAN探索、特殊なNICへ影響する可能性もあります。初回はクライアント推奨の自動ルーティング設定を使い、基本アクセスを確認してから、必要に応じてより厳格な方針を有効にします。

LANへのアクセスに異常がある場合は、まずプライベートネットワーク範囲に直接接続のシステムルートが残っているか確認し、次にコア内でgeoip:privateがdirectを指しているか確認します。どちらも必要です。OSはLAN対象を正しいゲートウェイへ渡せなければならず、コアも直接アウトバウンドを選択しなければなりません。企業ネットワークなどで一般的でない内部ネットワーク範囲を使っている場合は、一般的なプライベート範囲に含まれると決めつけず、明示的なネットワークルールを追加します。

Windows PowerShell
Get-NetRoute | Sort-Object RouteMetric
Get-DnsClientServerAddress

macOS
netstat -rn
scutil --dns

Linux
ip route
ip address

これらのコマンドは、TUNの有効化前後でインターフェース、デフォルトルート、DNSがどう変化したかを確認するために使います。確認すべき点は、デフォルトルートが想定したインターフェースに取り込まれているか、LAN範囲により具体的なルートが残っているか、TUNを無効にした後で一時ルートが削除されているかです。システムごとに出力形式は異なるため、他人のインターフェース名やゲートウェイアドレスをそのまま使わないでください。

DNSハイジャックとFakeDNS

TUNが受け取るのはIPパケットですが、ルーティングルールはドメインに依存することがよくあります。DNSハイジャックは、システムのDNSリクエストをコアへ渡し、ドメインと解決結果の関係をコアに保持させます。FakeDNSはドメインに一時的なマッピングアドレスを割り当て、アプリがそのアドレスへ接続すると、コアが元のドメインを復元してルーティングします。こうした仕組みはドメイン振り分けを改善できますが、アドレスプールがLAN、仮想マシン、他のVPNネットワークと競合しないことが条件です。

「解決できるのに接続できない」場合は、FakeDNSのアドレスが他のルートに奪われていないか確認します。「クライアントを終了してもネットワークがおかしい」場合は、システムDNSとルーティングが復元されているか確認します。アプリによっては内蔵DNSや暗号化DNSを使い、システムの通常のDNSリクエストを回避します。その場合はアプリ内の独自解決を無効にするか、TUNルーティングで解決接続もクライアントへ入るようにします。DNS設定では一度に一つの主要な仕組みだけを有効にし、システムDNS、クライアントDNS、ブラウザDNSが互いに上書きしないようにします。

MTU、UDP、接続異常

MTUは一つのネットワークパケットの最大サイズを決めます。TUNにプロキシ転送が重なると追加のオーバーヘッドが発生します。経路がフラグメントを許可しない、または必要な制御メッセージを破棄すると、MTUが大きすぎて小さなページは開くのに大きなファイルや特定サイトだけ長時間停止することがあります。この症状が出たら、クライアントが許可する範囲でTUN MTUを段階的に下げ、変更のたびに接続を再確立して同じ対象をテストします。最初から極端に小さくしないでください。パケット数と処理負荷が増えるためです。

UDPは、サーバーのプロトコル、アウトバウンド機能、クライアント設定が共同で対応している必要があります。音声、ゲーム、DNS、QUICベースの接続ではUDPが使われることがあります。UDPだけ通らずTCPは正常な場合、まず現在の設定がUDPを許可しているか確認し、次にTUNインバウンドがUDPを受け取っているか、ルーティングルールが正しいアウトバウンドへ送っているかを調べます。切り分けのため、ブラウザで一時的にQUICを無効にしてWebページが戻るか確認できます。ただしこれは診断手段であり、最終的にはUDPまたはルーティング設定を修正してください。

TUNを長期利用するのに適したケース

システムプロキシに対応しない複数のアプリを一括で取り込みたい、UDPに依存している、一つのルーティング方針でデスクトップアプリをカバーしたい場合は、TUNが適しています。ブラウザと一般的なオフィスツールだけを使うなら、システムプロキシのほうが簡単で、LANサービスとも共存しやすいでしょう。TUNを長期利用する場合は、OS更新後に仮想NICの権限が変わっていないか、ネットワーク切り替え後にデフォルトルートが再構築されているか、スリープ復帰後もDNSが有効なインターフェースを指しているかを定期的に確認します。

システムプロキシからTUNへ移行する場合は、まずシステムプロキシを解除し、同じリクエストがローカルプロキシに入った後でTUNに捕捉されるのを避けます。有効化後は、ログでインバウンドタグがTUN由来であることを確認し、TCP、UDP、LAN、DNSを個別にテストします。詳しい有効化手順とプラットフォームごとの差異は、v2rayNのTUNモードの仕組みと有効化手順を参照してください。

CHAPTER 07

日常メンテナンス：更新、バックアップ、ログ、トラブル特定

メンテナンス対象を4層に分ける

安定した利用には、クライアントプログラム、コアとルールリソース、サブスクリプションデータ、ローカルのカスタム設定という4種類の対象があります。更新元とリスクはそれぞれ異なります。クライアント更新は画面や設定移行の仕組みを変える可能性があり、コア更新はプロトコルや設定項目に影響します。ルールリソースの更新はgeositeとgeoipの照合結果を変え、サブスクリプション更新はサーバー項目を置き換えます。すべてを一度に更新すると、問題発生時にどの層の変更が原因か判断しにくくなります。

より安全な方法は、分けて実行することです。まずローカル設定とカスタムルールをエクスポートし、クライアントを更新して起動できることを確認します。次にコアとリソースが読み込まれているかを確認し、最後にサブスクリプションを一つずつ更新してアクティブサーバーをテストします。サーバーを更新するだけなら、ルーティングやDNSまで同時に変更する必要はありません。メンテナンスのたびに、何を変更し、どの経路をテストしたか記録します。回帰が起きたとき、使用可能だった設定へすぐ戻せます。

復元に役立つバックアップ対象

サブスクリプションのサーバー一覧は再取得できますが、URL、グループ構成、手動サーバー、ルーティングルール、DNS、ポート、TUNパラメータはローカル管理情報なのでバックアップ対象に含めます。クライアントのエクスポート機能を使う場合は、サブスクリプションURLや機密項目が含まれるか確認し、バックアップファイルを管理された場所に保存します。スクリーンショットは画面状態の記録には使えますが、完全なバックアップには向きません。長いURL、非表示項目、ルール順序を確実に復元できないためです。

別の端末へ移行するとき、キャッシュや実行状態をすべてそのままコピーしないでください。まず対象プラットフォームに合ったクライアントをインストールし、サブスクリプションと必要なルールを登録してから、新しい端末のCPUアーキテクチャ、権限、ネットワーク環境に合わせて調整します。待受ポート、NIC名、システムプロキシの状態は、そのまま移行できるとは限りません。復元後は最小限のシステムプロキシテストから始め、正常になってからTUNと高度なDNSを有効にします。

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

コアのログでは、一つの根本原因から複数の連鎖エラーが発生することがあります。たとえばDNS解決に失敗すると接続先が空になり、その後にアウトバウンド失敗やリクエスト終了が続きます。ポート使用中の場合はインバウンドの作成に失敗し、その結果すべてのアプリが接続できなくなります。トラブル対処では最後のタイムアウトだけを見るより、今回の起動後に出た最初の明確なエラーを探すほうが効果的です。再テスト前にログを消去するか時刻を覚えておき、古いエラーを現在の状態と混同しないようにします。

よくある情報は段階ごとに分類できます。設定解析エラーは項目、JSON構造、タグの問題を示します。待受失敗は通常、ポート使用中または権限に関係します。ドメイン解決失敗はDNSの問題です。接続拒否は対象へ到達できるもののポートが接続を受け付けていないことを示します。タイムアウトはローカルネットワーク、リモート経路、ハンドシェイクのいずれでも起こります。認証やハンドシェイクのエラーでは、サーバー項目のプロトコルパラメータとシステム時刻を確認します。ログにサーバーアドレスやサブスクリプション情報が含まれる場合、共有前に機密情報を削除してください。

症状 優先して確認する項目 次の対応
コアが起動しない 設定解析、ポート使用中、権限 最小構成に戻して再読み込み
サブスクリプションを更新できない URLの完全性、DNS、更新間隔の設定 直接接続で更新し、レスポンスの段階を確認
グローバルは使えるがルールは使えない ルール順序、アウトバウンドタグ、ルールリソース カスタムルールを一つずつ戻す
システムプロキシは使えるがTUNは使えない 仮想NIC、ルーティング、DNS、MTU 競合するネットワークツールを終了してインターフェースを再構築
特定のアプリだけ失敗する アプリのプロキシ、独自DNS、UDP アプリのキャッシュを削除し、他のアプリと比較

再現可能なトラブル特定手順を作る

第1段階は基本ネットワークの確認です。クライアントを終了し、通常のネットワーク、DNS、システム時刻が正常か確認します。第2段階はクライアントプロセスの確認です。既知の正常な設定でコアを起動し、解析や待受のエラーがないことを確認します。第3段階でシステムプロキシを有効にし、システム設定に従うブラウザでテストしてログを確認します。第4段階ではグローバルとルールモードを比較し、振り分けの問題か判断します。第5段階で初めてTUNを有効にし、仮想インターフェースとDNSを確認します。各段階は、前の段階が成功していることを前提に進めます。

ネットワーク切り替え後に問題が起きた場合は、まず現在のアクティブサーバーへ再接続します。古いTCP接続やDNS結果が無効になっている可能性があるためです。スリープ復帰後に異常が出る場合は、コアプロセス、仮想インターフェース、システムプロキシの3つが一致しているか確認します。クライアントを終了してもシステムプロキシが残っていると、アプリは存在しないローカルポートへ接続し続け、すべてのWebページがすぐ失敗します。この場合はサーバーを変更するより、システムプロキシを解除するほうが直接的です。

サブスクリプションとルールの更新頻度

クライアントを開くたびにサブスクリプションを連続更新する必要はありません。提供元の変更頻度に応じて適切な間隔を設定し、手動更新の入口も残します。更新が頻繁すぎると、リクエスト失敗や一覧の頻繁な並び替えが起こりやすくなります。長期間更新しないと、すでに無効な項目を保持することになります。複数のグループは更新時刻をずらし、同時リクエストを避けます。更新前に使っていたサーバーが削除されると、クライアントが別の項目へ切り替える場合があるため、更新後に現在の選択項目を確認してください。

ルールリソースの更新後は、集合の内容が変わる可能性があります。重要な業務ドメインを広い集合だけに依存させず、より明確な高優先度ルールを追加します。リソース更新後は、普段使う直接接続、プロキシ、ブロック対象を抜き取り確認し、特に内部ドメインとLANサービスを調べます。新しいリソースで異常が出た場合は、まずカスタムルールで具体的な対象を修正し、その後で集合の変化を分析します。互いに上書きするルールパッケージをすぐ重ねないでください。

設定と診断情報を安全に扱う

サブスクリプションURL、サーバーの認証項目、エクスポートした完全な設定には、アカウント情報が含まれる可能性があります。バックアップの保存場所へのアクセスを制限し、ログを送る際はエラーの前後だけを残して、アドレス、トークン、認証項目を置き換えます。完全な設定を公開ディスカッションへ貼り付けないでください。問題を示すには、通常、プロトコル種別、トランスポート方式、エラーの段階、匿名化したルーティング構造があれば十分です。

リモートサポートを受ける前に一時バックアップを作成し、システムプロキシとTUNの現在の状態を記録します。作業後は、サブスクリプショングループ、カスタムルール、OSのネットワーク設定が変更されていないか確認します。クライアントの動作が突然変わった場合も、サーバーだけでなく、まずローカル設定を比較してください。具体的な症状と復旧手順はよくある質問のトラブル対処カテゴリを参照できます。

CHAPTER 08

上級者向けの進め方：使える設定から説明できる設定へ

第1段階：最小構成の動作経路を固定する

上級設定の出発点はパラメータを増やすことではなく、安定して再現できる最小経路を作ることです。一つのクライアント、一つのアクティブサーバー、システムプロキシの自動設定、単純なルーティングを選び、ローカルインバウンド、デフォルトアウトバウンド、DNSの動作を記録します。ブラウザのリクエストがログに入り、直接接続とプロキシ対象が想定どおりのアウトバウンドに一致することを確認します。以後の変更をこの基準と比較すれば、変更による結果を判断できます。

基準を作る段階では、複数のクライアント、複数のシステムプロキシ元、複数のDNS取り込み層を同時に使わないでください。v2rayNでデスクトップ接続を担当するなら、システムプロキシを変更するツールはv2rayNだけにします。AndroidではアクティブなVPNセッションを一つだけ維持します。サーバー一覧は多くても構いませんが、テスト時は項目を一つに固定します。項目の切り替えと設定変更を同時に行うと、接続結果の原因を特定できません。

第2段階：設定オブジェクトとタグを理解する

完全な設定を読めるようになったら、inbounds、outbounds、routing、dns、logを重点的に理解します。インバウンドタグは、システムプロキシ、TUN、特定アプリの送信元を区別するために使えます。アウトバウンドタグは、ルーティングの行き先をプロキシ、直接接続、ブロック、その他の経路へ指定します。DNSサーバーにもアウトバウンド経路を指定できます。タグ名はカスタマイズできますが、参照名は一致させなければなりません。「ルールが効かない」問題の多くは、実際にはタグの綴りやスコープの不一致です。

クライアントが生成した設定を読むときは、自動生成部分とユーザー定義部分を分けて考えます。クライアントは起動時に設定ファイルを書き換えることがあり、一時ファイルを直接編集すると次回起動時に失われます。クライアントが提供するカスタム設定、ルーティングルール、高度な設定の入口を優先してください。外部で管理する必要がある場合は、まずマージ順序を確認します。カスタムオブジェクトと自動生成オブジェクトが同じキー名を使うと、後から書き込まれた側が前者を上書きする可能性があります。

{
  "log": {
    "loglevel": "warning"
  },
  "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インバウンド、直接接続のアウトバウンド、ブロックのアウトバウンドの関係を示しています。実際のクライアントは通常、ポートを自動的に割り当て、リモートプロトコルの項目を生成します。手動でマージする場合は、既存のインバウンドとのポート競合を避けてください。待受アドレスはループバックアドレスにして、LAN端末がローカルプロキシへアクセスできないようにします。

第3段階：DNSとルーティングで同じ意図を使う

成熟した設定では、3つの問いに明確に答えられます。どの種類のドメインをどのDNSで解決するのか、DNSリクエストをどのアウトバウンドから送るのか、解決結果をどのルールで処理するのかです。パブリックDNSのアドレスを一つ設定するだけでは、振り分けの問題は自動的に解決しません。ドメイン集合に応じてDNSサーバーを選び、直接接続するドメインは直接接続のDNSで解決し、プロキシが必要なドメインはプロキシ経路で解決しながら、LANドメインにはシステム解決を残す方法があります。

DNSを調整するときは、まず利用可能なフォールバック経路を一つ残し、ブラウザが独自DNSを使っていないか記録します。テストでは、ドメインの初回解決、キャッシュヒット、ネットワーク切り替えを確認します。同じドメインが安定したり失敗したりする場合は、異なるアドレス族が同時に返されていないか、複数のDNSレスポンスが存在しないか、IPv4とIPv6で異なるルーティング結果になっていないかを確認します。アドレス族の無効化は切り分けに使えますが、長期的な方針は現在のネットワークとリモート側の対応状況で決めます。

第4段階：インバウンドと用途で方針を分ける

システムプロキシ、TUN、アプリ専用ポートを併用する場合は、インバウンドタグで異なるルールを適用できます。たとえばシステムプロキシは普段の振り分け、専用SOCKSインバウンドはデフォルトでプロキシ、TUNはLANを優先して直接接続しUDPも処理する、といった構成です。長いドメイン一覧からアプリの送信元を推測するより明確です。分割する際は、各インバウンドにポート、用途、呼び出し元を明確に割り当て、使っていないインバウンドは速やかに無効にします。

用途の切り替えは、単一ルールを何度も編集するのではなく、ルーティング設定グループで行えます。普段使い、デバッグ、グローバルプロキシを分かりやすいプリセットとして保存し、切り替え後はステータスバーで現在のモードを確認します。デバッグ終了後は普段のルールへ戻し、グローバル状態を長期間残さないでください。複数の設定グループがカスタムルールを共有する場合は、更新順序を確認し、古いリソースを参照するプリセットが残らないようにします。

第5段階：接続を推測せず観測する

上級のトラブル対処では、可観測性を確保します。ログレベルを一時的に上げ、ルーティングと接続段階の情報を確認できるようにします。リクエストを一度再現したら、ログが急増しないよう普段のレベルへ戻します。対象ドメイン、解決結果、インバウンドタグ、一致したルール、アウトバウンドタグ、最終エラーの6項目を記録すると、通常は問題の層を特定できます。「開けない」とだけ記録しても、アプリがプロキシへ入っていない、DNS失敗、ルールによる直接接続、リモートハンドシェイク失敗を区別できません。

システムツールはクライアントログを補完できます。待受ポートを確認してコアが接続を受け付けているか調べ、ルーティングテーブルでTUNが取り込んでいるか確認し、DNS設定で解決の入口を確認します。接続テストで対象ポートの到達性も調べます。ツールの結果はクライアントの状態と合わせて解釈してください。対象ポートに到達できてもプロトコルのハンドシェイクが正しいとは限らず、コアが動作中でもアプリがローカルポートへ接続しているとは限りません。

第6段階：変更と切り戻しの規律を作る

一度に変更する主要な変数を一つにすることが、設定を長期的に保守する鍵です。ルーティングを変更するときにDNSも変えず、TUNを調整するときにクライアントも更新せず、サーバーを切り替えるときにトランスポートパラメータも同時に変えないでください。変更前に現在の設定をエクスポートし、変更後は固定したテスト対象で確認します。失敗したら一時修正を重ねず、すぐに戻します。一時修正が有効だと確認できた場合も、明確なルールへ整理して重複項目を削除します。

設定ドキュメントには、パラメータだけでなく目的を記録します。たとえばgeoip:privateだけを書くより、「LAN機器へアクセスするためプライベートネットワークを直接接続する」と記録するほうが保守に役立ちます。将来ルールリソースやネットワーク環境が変わっても、古い書き方を機械的に残すのではなく、目的に沿って再構成できます。サブスクリプション、ルーティング、DNS、TUNにはそれぞれ復元方法を用意し、一つが壊れたときにすべての設定をリセットせずに済むようにします。

上級設定を終えた状態の基準

アプリからインバウンド、DNS、ルーティング、アウトバウンドへ進むリクエストの完全な経路を説明でき、障害発生時に具体的な段階を特定でき、設定変更にテスト対象と切り戻し方法がある状態です。パラメータの数は習熟度の基準ではありません。

おすすめの継続学習順序

まずシステムプロキシと最小ルーティングに慣れ、次にサブスクリプショングループとルール順序を学びます。その後、DNS、ドメイン戦略、アウトバウンドタグを理解し、基本経路が安定してからTUNを有効にして仮想NICとルーティングテーブルを観察します。最後にアプリ単位の振り分け、複数インバウンド、複雑なDNSを扱います。各段階で、比較用のシンプルな設定を一つ残してください。新しいプロトコルや項目に出会ったら、それがプロトコル、トランスポート、セキュリティ、ルーティングのどの層にあるか判断してから、対応するドキュメントを調べます。

接続を一度すばやく完了したい場合はクイックスタートの基本手順へ戻ります。プラットフォーム別のインストールパッケージを選ぶ場合はダウンロードページへ進みます。v2rayN、v2rayNG、v2flyNGの適した環境を比較する場合はクライアント比較を確認してください。このガイドは設定中の索引として使えます。まず症状から該当章を探し、通信経路に沿って層ごとに確認すれば、毎回すべての設定を最初からやり直す必要はありません。

v2rayNをダウンロード