総合ガイド · 順を追って学ぶ・章ごとに調べる

V2Ray設定ガイド：
基本概念から日常のメンテナンスまで

クライアントのインストール、サブスクリプションの追加、プロキシモード、ルーティング、TUNの設定を、依存関係に沿って解説します。

初回接続には、まずクイックスタートを参照し、最小限の設定を済ませてからこのページに戻ってください。本ガイドでは、各設定の前提条件や制約、トラブル対処の手順を解説します。基礎から学びたい方にも、問題に応じて章を調べたい方にも役立ちます。

おすすめの順序：まず1台のクライアントと1つのノードで動作する基本環境を作ります。次にサブスクリプション管理とルーティングを追加し、最後にTUNや自動化を設定します。変更のたびに元に戻す方法を確保し、関連する設定を一度に複数変更しないようにしましょう。

基本概念：クライアント、コア、接続経路

画面上の設定と実際の動作

設定を始める前に、GUIクライアント、プロキシコア、リモートサーバーの3つを区別しましょう。クライアントはノードの表示、サブスクリプションの保存、設定の生成、システムとの連携を担当します。コアは設定を読み込み、ローカルのリクエストを受け付け、ルーティングに従って接続先を選びます。リモートサーバーはプロトコル接続を受け付け、宛先への通信を処理します。画面が開くのはクライアントが動作している証拠にすぎません。コアの起動やリモート側の設定が正しいとは限りません。

このエコシステムを理解するには、まずProject Vから始めるとよいでしょう。V2FlyとXrayは関連するコアの系統です。v2rayN、v2rayNG、v2flyNGはGUIクライアントであり、プロトコル名ではありません。クライアントが対応する設定項目は、画面上の実装だけでなく、実際に呼び出すコアの機能にも左右されます。サブスクリプションを追加できても起動できない場合は、使用中のコアと生成された設定を確認してください。クライアント名だけで、すべての機能が使えると判断しないようにしましょう。

入口・ルーティング・出口

接続は、入口・ルーティング・出口に分けて考えられます。入口はブラウザーなどのアプリからの通信を受け付け、一般的にはローカルのHTTPまたはSOCKSリスナーを使います。ルーティングは宛先のドメイン、アドレス、ポートなどを条件に出口を選びます。出口にはプロキシ、直接接続、ブロックなどがあります。リモート接続の失敗と、ローカルの入口にリクエストが届かない問題は別物です。前者はノードやネットワークを、後者はアプリが正しい入口を使っているかを確認しましょう。

設定内のタグは各モジュールを関連付けるためのもので、自由に書き加えるメモではありません。ルールで出口タグを指定した場合、出口一覧に同じ名前の項目が必要です。大文字と小文字も一致させてください。クライアントによっては関連付けを画面上に表示せず、タグを自動生成します。コアの設定例を読むときは、断片を適当な入力欄に貼り付けるのではなく、まず構造を把握しましょう。カスタム設定とGUI設定がそれぞれ何を管理するかも、事前に確認が必要です。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

プロトコルとトランスポートの役割

VMess、VLESS、Trojanはプロキシ接続のプロトコルを表します。トランスポート層は、その接続をネットワーク上でどのように運ぶかを定めます。TLSとREALITYは、接続の安全性やハンドシェイクの条件に関わります。これらを自由に組み合わせることはできません。ノードを追加するときは、アドレス、ポート、認証情報、トランスポートの種類、安全性の設定をひとまとまりとして確認してください。どれか1つでもサーバー側の設定と異なると、接続に失敗することがあります。プロトコル名だけを変更しても、通常は問題を解決できません。

DNSも接続経路から独立した付属設定ではありません。アプリが先にドメインを名前解決してからアドレスをプロキシに渡す場合もあれば、ドメインを保持したままコアやリモート側で処理する場合もあります。ルーティングで元のドメインを参照できるかは、リクエストの形式、プロキシプロトコル、関連設定によって異なります。宛先がアドレスとして表示されても、すぐにドメインルールの異常と決めつけないでください。まず、どのレイヤーで名前解決されたのか、ルール判定に使えるドメイン情報がリクエストに残っているかを確認しましょう。

学習中のテストでは、1つのアプリから既知の宛先へアクセスする条件に絞りましょう。使用した入口、選択中のノード、動作モード、結果を記録し、リクエストがどの段階で止まったかを判断します。上の設定は直接接続のみの構成例で、モジュール間の関係を示すものです。リモートプロキシを利用できる設定ではありません。実際のサービスに関する認証情報は信頼できる入手元から取得してください。他のガイドから、自分のサービスに合わない設定項目をそのままコピーしないようにしましょう。

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

まず端末に合わせて選び、必要な機能を確認

デスクトップでは、まずv2rayNを候補にし、OSとプロセッサに合ったインストール方法を選びます。サブスクリプションの一元管理、接続ログの確認、ルーティングの調整に便利です。AndroidではXrayコアを採用するv2rayNGを、V2Flyエコシステムの設定が必要な場合はv2flyNGを検討しましょう。見た目やクライアント名だけで性能を判断せず、利用中のノードに必要な機能、システム要件、普段の操作方法を基準に選びます。

インストール前に、ノードで実際に必要なプロトコルとセキュリティ設定を確認しましょう。インポートに成功しても、拡張フィールドがすべて正しく認識されたとは限りません。特にREALITY、公鍵、サーバー名、フィンガープリント、フロー制御に注意してください。設定の提供元に、対応するクライアントとコアを確認したうえで、追加後の編集画面と照らし合わせます。必要な項目が画面にない場合、無関係な入力欄で代用したり、項目を削除してそのまま使い続けたりしないでください。

クライアント対応プラットフォーム優先して確認する項目
v2rayNWindows、macOS、Linuxプロセッサアーキテクチャ、画面の種類、システム連携の権限
v2rayNGAndroidXrayの機能、VPNの権限、バックグラウンド制限
v2flyNGAndroidV2Fly設定との互換性、サブスクリプションの項目

デスクトップ版の形式とプロセッサアーキテクチャ

Windowsのダウンロードページには、Desktop版と従来のWPF版があります。前者は新世代のクロスプラットフォームUIを採用し、後者は従来の画面構成を維持しています。メニューの位置や操作方法は異なる場合があります。初期設定では、どちらか一方だけで基本環境を作りましょう。2つのアプリを同時に起動すると、ローカルポートが競合することがあります。移行時はサブスクリプション、ルーティング、システムプロキシを項目ごとに確認してください。プログラムのフォルダーをコピーしただけで、設定移行がすべて完了したとは限りません。

macOSではApple SiliconとIntelを区別し、システム情報でチップの種類を確認してから対応するインストーラーを選びます。購入年だけで判断しないでください。Linuxではプロセッサアーキテクチャに加え、ディストリビューションで使うパッケージ形式との適合も必要です。通常はdebまたはrpmを選びます。アーキテクチャとパッケージ形式は別々の条件です。パッケージマネージャーがファイルを認識しても、中の実行ファイルが現在のプロセッサで動くとは限りません。

Android用のarm64パッケージは、多くの比較的新しい一般的な端末に適しています。対応アーキテクチャが不明な場合や、より幅広い端末をカバーしたい場合は汎用パッケージを選びます。最終的にはシステムの対応状況を確認してください。インストールできない場合、手当たり次第に別のファイルをダウンロードするのではなく、アーキテクチャ、空き容量、既存アプリとの署名の関係を確認しましょう。上書きインストール時に署名が競合したら、設定をエクスポートしてバックアップを確認してから、旧アプリを削除するか判断します。

設定の管理方法も選択のポイント

複数の端末で同じサブスクリプションを使う場合は、サブスクリプションの取得元と必要な設定項目を同期します。クライアントのデータベースをそのまま異なるプラットフォーム間で使えるとは限りません。システムプロキシ、仮想ネットワークインターフェース、アプリの除外リスト、ファイルパスにはプラットフォームごとの差があります。デスクトップで使えるカスタムスクリプトやパスを、そのままスマートフォンに移すことはできません。移行時はノードを追加して単体テストを済ませてから、端末側のプロキシモードとルーティングを設定し直すと、環境への隠れた依存を減らせます。

クライアントとコアの更新時期は、必ずしも一致しません。画面にスイッチがあっても、現在使用中のコアがその機能に対応しているとは限りません。反対に、コアが対応する設定項目がすべて画面で使えるとも限りません。高度な機能を使う前に、現在のクライアントの設定説明を読み、起動ログに表示される実行環境を確認してください。判断できない場合は初期値を維持し、検証済みのプロトコル構成を基準にしましょう。選択肢を増やすためだけに、頻繁にアプリを切り替える必要はありません。

具体的なインストール方法はクライアントのダウンロードページ、特徴の比較はクライアント比較をご覧ください。ダウンロード前にOS、プロセッサアーキテクチャ、必要なコア機能、設定の入手元を記録しておくと、インストール後に同じ項目で確認できます。クライアントを変更するのは、必要な機能が本当に不足している場合に限りましょう。ポート、サブスクリプション、システム権限が原因なら、アプリを変えても同じ設定ミスを繰り返す可能性があります。

インストールと基本環境：まず端末の状態を確認

インストール前に環境を記録

インストール前に、現在ネットワークに接続できるか、システムに既存のプロキシ設定があるか、仮想インターフェースを作成する他のプログラムが動作しているかを記録します。不要な旧クライアントは終了しますが、ネットワークアダプターやシステムサービスを安易に削除しないでください。元のプロキシアドレス、ポート、自動設定の状態も保存しておけば、問題発生時に戻せます。組織の管理下にある端末では、許可されているインストール方法とネットワーク設定を事前に確認しましょう。制限を回避するために、何度も権限を昇格させないでください。

ダウンロードページのプラットフォーム別リンクから適切な形式を選び、インストール後は最初にクライアントを1つだけ起動します。プログラム、ユーザー設定、キャッシュは別のフォルダーに保存されることがあります。アップグレードや移動の前に、実際のデータの保存先を確認してください。サブスクリプションや認証情報を含む設定フォルダーを、公開共有の場所に置かないようにしましょう。デスクトップの同期ツールがフォルダー全体を自動アップロードすると、本来端末内だけに保存する接続情報まで外部に送られる可能性があります。

初回起動と権限の段階設定

初回起動時は、まずメインウィンドウが正常に表示されるか確認し、その後コアが起動できるかを調べます。通常のローカルプロキシを日常的に使うだけなら、常に最高権限で実行する必要はありません。TUNやルーティングの変更には、追加の許可や補助サービスが必要な場合があります。起動に失敗するたびに権限不足と決めつけず、必要な機能に応じて権限を追加してください。システムの確認画面が表示されたら、要求されている権限を読み、現在の操作に必要なものだと確認してから許可します。

Windowsでは、他のツールがシステムプロキシを上書きし続けていないか確認します。macOSでは、アプリの起動許可とネットワーク関連の権限を区別してください。Linuxでは、グラフィカルセッション、トレイ環境、パッケージの依存関係が要件を満たすか確認します。これらの違いはシステムとの連携に影響しますが、ノードの設定項目そのものは変わりません。メイン画面を使えるのにトレイアイコンが表示されない場合は、まず画面から設定を進めましょう。UI連携の問題を、リモート接続の障害と取り違えないでください。

Androidで初めて接続するときは、通常システムのVPN権限を確認する必要があります。許可する前にノードを保存し、許可した後にアプリが実行状態になったか確認してください。端末で別のVPN接続が有効な場合、既存の接続を切り替えるよう求められることがあります。用途を確認し、接続が何度も切り替わることのないようにしましょう。バックグラウンド動作の制限も記録しますが、初回テストはアプリを前面に表示した状態で行います。基本接続を確認してから、電池管理や画面ロック中の動作を調整してください。

リスナーのアドレスとポートの競合

ローカルのリスナーには、通常ループバックアドレスを使い、端末内のリクエストだけを受け付けます。他の端末から接続する必要が明確な場合に限り、LAN向けのリスナー、認証、ファイアウォールの範囲を検討してください。ポート番号は入口を識別するものであり、ノード側のサーバーポートの複製ではありません。両者は異なる番号でも構いません。ログにアドレスの競合が表示されたら、別のクライアントを終了するか使用元を特定してから、ローカルのリスナーポートを変更します。そのポートを手動設定しているアプリの項目も忘れずに更新してください。

{
  "inbounds": [
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

ここに示すのは入口の設定例であり、プロキシ設定全体ではありません。リスナーの範囲、ポート、プロトコル、タグの関係を示しています。実際には、出口などを含む完全な設定をクライアントで生成してください。HTTPの入口を、SOCKS専用のアプリ欄に入力しないでください。ポート番号が近いからといって、相互に置き換えられるわけでもありません。アプリに個別のプロキシ設定がある場合は、プロキシの種類、アドレス、ポートをすべて確認してください。3項目が一致して初めて正しく接続できます。

基本環境を作る段階では、複雑なルーティング、通信の探測、TUNは有効にしません。ログに起動エラーがないことを確認し、動作が分かっているノードを1つ追加して、システムプロキシに従うアプリでテストします。成功時の設定を記録し、元に戻す方法も確保してください。複数の項目を調整して初めて動作した場合は、変更した順番と理由を記録しましょう。記録がないと、後日のアップデートや移行時に、必要な設定とトラブル対処のための一時的な変更を区別しにくくなります。

サブスクリプションの追加：入手元・形式・ノードの確認

サブスクリプションURLと共有リンクを区別する

サブスクリプションURLは複数のノード情報を取得するための入口です。共有リンクは通常、単一ノードの情報を表し、ネイティブJSONはコアの設定構造を記述します。この3つは互換性がありません。JSON全体をサブスクリプションURL欄に入力したり、共有リンクを定期更新できるサブスクリプションとして登録したりすると、追加に失敗することがあります。登録前にデータの種類を確認し、クライアントに応じたサブスクリプション管理、クリップボードからのインポート、カスタム設定の入口を使いましょう。形式の誤りをネットワーク障害と取り違えないためにも重要です。

サブスクリプションURLには、アカウントを識別できるアクセス情報が含まれることがあります。入手後は機密情報として扱い、URL全体を公開スクリーンショット、ログの相談、共有ドキュメントに載せないでください。不明な変換サイトへのアップロードも避けましょう。相談時はプロトコルの種類やエラーの発生箇所を伝え、認証情報、識別につながるドメインの一部、クエリパラメーターは伏せてください。文字列をエンコードしても元の内容に戻せる場合があるため、アクセス保護にはなりません。

グループを作成して初回更新

クライアントのサブスクリプション管理画面でグループを追加し、識別しやすい名前と取得元のURLを入力して更新します。画面によってメニュー名は異なりますが、まず取得元を保存し、その後データを取得して解析する流れは共通です。更新後は、成功の通知だけでなく、ノードが目的のグループに表示されたか確認してください。グループが空なら、取得元が有効なデータを返しているか、次に解析ログを確認します。すぐにクライアントを再インストールしたり、ネットワーク設定をすべて変更したりしないでください。

サブスクリプションの更新とプロキシ接続は、別々のネットワークリクエストです。更新に直接接続を使うか、現在のプロキシを使うかは、クライアントの設定やシステム環境によって異なります。無効になったノード経由で更新しようとすると、新しいノードを取得できないという状態が続くことがあります。その場合は更新時の接続経路を確認し、許可されたネットワーク環境で更新方法を調整して、既存のグループは残しておきましょう。ノードをすべて削除すると、後のトラブル対処で比較対象がなくなります。

解析後はノードの編集画面を開き、サーバーアドレス、ポート、プロトコル、認証情報、トランスポート方式、安全性の設定を確認します。ノード名は識別用であり、接続の正しさには関係しません。サーバー名と接続先アドレスが異なる場合があること、トランスポートのパスとリクエストヘッダーの役割も確認してください。項目が重複して見えても、安易に削除しないようにしましょう。ネットワーク上の宛先、ハンドシェイクの検証、アプリケーション層のリクエストなど、別々の役割を持つ項目があります。

追加後の検証と更新時の注意点

ノードを有効な設定にしたら、まずコアが再起動できるか確認し、決まったアプリと宛先でテストします。ノード一覧のテスト結果は、特定の方法で確認した結果にすぎず、実際のアプリすべての動作を保証するものではありません。クライアントのテストは成功してもブラウザーが動かない場合は、ブラウザー側の入口を確認します。起動時にエラーが出る場合は、まず設定項目とコアの互換性を確認してください。追加、起動、実際のアクセスを分けて観察すると、ノードを次々に切り替えるよりも問題を特定しやすくなります。

サブスクリプションを更新すると、そこから生成されたノード項目が上書きされることがあります。手動でノードを変更する前に、更新時にどの項目が元に戻るか確認してください。変更を長期間維持する必要がある場合は、クライアントが提供する独立設定や複製機能を使い、分かりやすい名前を付けましょう。元のサブスクリプション項目とローカルの複製を分けて管理すれば、意図しない上書きを防げます。グループを削除する前に、有効なノードがそのグループ由来か確認してください。更新後に選択中の項目が存在しなくなるおそれがあります。

認証エラー、内容が空、形式を認識できないといった問題は、それぞれ分けて対処します。認証エラーでは取得元の認証情報とアカウントの状態を確認し、内容が空の場合は応答に実際にノード情報が含まれているか確認します。形式エラーでは、クライアントが対応するインポート形式を確認してください。完全な設定にはローカルのパスや特定の出口タグが含まれる場合があり、単一ノードの共有リンクのようにそのまま再利用できません。形式の違いについて詳しくはサブスクリプションURLの形式を解説をご覧ください。構造を理解してから変換方法を決めましょう。

プロキシモード：アプリの接続とコアのルーティング

システムプロキシですべての通信を処理できるわけではない

システムプロキシは、この仕組みに対応したアプリにプロキシの接続先を知らせます。通常はブラウザーが利用できますが、独自の設定を持つアプリや、システムプロキシを参照しないアプリもあります。有効にしても一部のアプリしか変化しない場合は、すぐにノードを変更せず、各アプリの接続方法を確認しましょう。ローカルプロキシが動作しているかと、システムの接続先がそこを向いているかは別々に確認します。コアが正常でも、システムが古いポートを参照していれば、すべての接続が失敗しているように見えることがあります。

手動プロキシでは、アプリにローカルの入口を直接入力します。問題を切り分けたいときや、特定のアプリだけ接続したいときに便利です。この場合、システムプロキシは変更せずに使えますが、アプリに設定するプロトコル、アドレス、ポートはコアのリスナーと一致させてください。アプリに自動設定、拡張機能のプロキシ、手動プロキシが複数ある場合は、最終的にどの設定が有効か確認します。切り分け中はいったん入口を1つに絞り、画面表示と実際の動作が異なる原因となる多重設定を避けましょう。

接続範囲と出口の選択を分けて考える

クライアント画面にある「グローバル」「ルール」「直接接続」などの名称は、通常、出口の選択方法を表します。システムプロキシとTUNは主に、アプリからクライアントへ通信を渡す方法を決めます。この2つは別の軸です。グローバルプロキシにしても、すべてのアプリがシステムプロキシを参照するわけではありません。TUNで通信を取り込んでも、すべての宛先をリモート経由にする必要はありません。まず接続対象のアプリを決めてから、その通信をどうルーティングするか設定すれば、入口の問題をルーティングの問題と取り違えて変更を繰り返すことを防げます。

初回の動作確認では、プロキシ出口の設定をシンプルにし、接続済みのテストアプリから選択中のノード経由でアクセスします。成功したら日常のルーティングルールに切り替え、同じ宛先へのログを比較しましょう。シンプルな設定では成功し、ルール設定で失敗する場合は、ルールの順序、デフォルトの出口、DNSの条件を優先して確認します。どちらでも失敗する場合はノードと入口に戻って確認し、基本的な接続エラーを覆い隠すためにルールを増やさないでください。

設定の観点解決する問題よくある誤解
システムプロキシこの仕組みに対応したアプリが使うローカルの入口すべてのアプリが従うと思い込む
アプリごとの手動プロキシ個々のアプリをどのように接続するか入口のプロトコルやポートの設定ミス
ルーティング接続したリクエストにどの出口を使うかルールモードをシステム全体の通信取り込みだと思い込む
TUN仮想インターフェースで取り込んだ通信を処理する有効にすればDNSやルーティングとの連携は不要だと思い込む

実際の操作を想定して結果を確認する

検証時はテストアプリ、宛先、有効なノードを固定し、ドメインの名前解決、接続の確立、実際のコンテンツ読み込みを個別に確認します。1つのページが開けても、他のアプリのUDP通信や長時間接続が正常とは限りません。逆に、ある宛先に接続できないからといって、すべての通信が失敗しているとは限りません。動作が分かっている別の宛先と比較してください。毎回、モードかノードのどちらか1つだけ変更すれば、結果の変化を設定と結び付けられます。

独自のプロキシ機能を備えたデスクトップアプリでは、ドメイン名をプロキシ側に渡して名前解決するか確認します。リクエスト形式によって、コアからドメインが見える場合と、すでに解決されたアドレスだけが見える場合があり、その違いは後続のドメインルールに影響します。1つのアプリを動かすためだけに、すぐにシステム全体のDNSを変更しないでください。まずアプリ固有のプロキシと名前解決の動作を確認します。必要に応じてクライアントのログで、リクエストがローカルに届いたか、宛先がどの形式で記録されたかを調べましょう。

LAN内のアクセスも個別に確認が必要です。プリンター、ファイル共有、ローカルサービスはプライベートアドレスやローカルドメインに依存することがあります。こうしたリクエストをリモートへ送るルールにすると、外部サイトにはアクセスできても、LAN内のリソースが使えなくなることがあります。まずプロキシに接続していない状態でリソースが使えるか確認し、対象を明確にしたうえでローカル範囲を直接接続に設定してください。不明なアドレスをすべて直接接続にしたり、1台の問題を直すために広範なルールを追加したりすると、他の通信経路まで変わる可能性があります。

クライアントを終了する前に、クライアントが設定したシステムプロキシを元に戻すか解除してから、コアを停止します。これにより、システムが停止済みのポートを参照し続ける可能性を減らせます。アプリが予期せず終了した場合は、再起動後にプロキシの状態を確認し、必要に応じてシステム設定を元に戻してください。この章を終えたら、アプリが接続されているか、どの入口を使い、最終的にどの出口を選ぶかを説明できる状態を目指しましょう。説明できない項目があれば、複雑な通信取り込みを有効にする前に、まず状況を確認してください。

ルーティング：マッチ順序とDNSの条件

順序に根拠のあるルールを作る

ルーティングルールは通常、上から順に評価され、条件に一致すると対応する出口が選ばれます。そのため、具体的な例外は広範なルールより前に置きます。まず実現したい動作を整理しましょう。ローカルのリソースは直接接続、指定ドメインには特定の出口、残りのリクエストにはデフォルトの方針を適用します。大量のルールを集めてから結果を推測するのは避けてください。各ルールについて、対象、出口、必要な理由を説明できるようにします。同じ宛先に一致するルールが2つある場合は、先のルールを優先する理由も明確にしましょう。

以下は直接接続のみの構成例です。ルールの構造を確認するためのもので、リモートのプロキシノードは含まれていません。1つ目のルールはプライベートアドレス、2つ目は分類済みドメインを処理し、最後のルールはこの入口に届いた残りのリクエストを処理します。実際に直接接続とプロキシを使い分けるには、クライアントで有効なプロキシ出口を作り、該当するルールをその出口の実際のタグに向けてください。出口を定義せずにプロキシのタグだけを書くことはできません。タグ名がどのクライアントでも同じだと考えないようにしましょう。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

ドメインの方針とDNSサーバー設定は別

domainStrategyはroutingオブジェクトに属し、個々のルールの設定ではありません。ルーティング判定で、アドレスのルールに使うドメイン名をいつ解決するかを制御します。AsIsは元の宛先形式を維持します。IPIfNonMatchはドメインで一致しなかった場合に、アドレスによる判定を試みます。IPOnDemandはアドレス情報が必要なルールに遭遇したとき、名前解決を行う場合があります。実際の動作は、使用中のコアと設定全体を踏まえて確認してください。

ルーティングのドメイン方針は、問い合わせ先のDNSサーバーを個別に指定するものではなく、アプリの名前解決設定とも異なります。アプリがドメインをアドレスに変換してから渡した場合、コアが元の名前を復元できるとは限りません。一方、アドレスのルールを判定するためにコアがドメインを解決しても、実際の接続が同じ経路で名前解決されるとは限りません。DNSの問題を調べる際は、問い合わせ元、問い合わせの出口、応答、最終的な接続先をそれぞれ確認し、複数の段階を曖昧にまとめないようにしましょう。

geositeとgeoipは、対応するデータファイルと分類情報に依存します。分類が見つからない、またはデータの読み込みに失敗する場合は、クライアントが参照する保存先、ファイルの有無、コアが認識できる形式を確認してください。分類データは更新されるため、新しいドメインが必ず含まれるとは限りません。確実に制御したいドメインには、範囲を明確にした個別ルールを追加できます。例外を追加した理由を記録し、定期的に見直しましょう。一時的なルールが積み重なって互いに妨げ合うのを防げます。

ページだけで判断せず、ログでルールを検証

検証用にローカルアドレス、明確なドメイン、どのルールにも一致しない宛先を用意し、それぞれのリクエストが選択した出口タグを確認します。1つのページから複数のドメインへリクエストが送られ、リソースごとに異なるルールへ一致することがあります。ページが表示されても、すべての通信経路が同じとは限りません。特定のルールを調べる場合は、まず対象範囲が明確な宛先で試し、その後に実際のページで確認します。体感速度だけで比べるより、ルール変更の前後でログを比較したほうが、正しく適用されたか判断しやすくなります。

フォールバックの方法も確認してください。一部のコア設定では、ルールに一致しない場合、出口一覧の最初の出口が使われます。クライアントが別途、フォールバック用のルールを生成する場合もあります。設定画面での並び順と、最終的に生成された設定の順序が異なることがあり、プリセットのルールを有効にしている場合は特に注意が必要です。デフォルトの経路を変えるために、すべての出口を安易に並べ替えないでください。クライアントが用意するデフォルト方針の設定を優先し、再起動後の動作が意図どおりか確認しましょう。

設定に問題が起きたら、まずルールを最小限に戻し、ローカルリソースに必要なルールと明確なフォールバックだけを残します。その後、例外を1つずつ追加してください。追加した後に問題が再発した場合は、そのルールの条件と順序を重点的に確認します。ドメイン分類、アドレス分類、デフォルトのプロキシ出口の組み合わせについては、ルーティングルール設定の実践ガイドもご覧ください。ルールを増やす前に、各段階を確認でき、元に戻せる検証方法を用意しましょう。

TUNと複数プラットフォーム：通信の取り込み範囲と復旧方法

有効にする前に本当に必要か確認

TUNは仮想ネットワークインターフェースを使い、システムのルーティングで送られた通信を処理します。アプリのプロキシ設定を直接使えない場合に便利です。一方で、インターフェース、ルート、DNS、権限の依存関係が増えるため、初回接続やトラブル対処の標準手段には向きません。まず通常の入口でノードが使えることを確認し、どのアプリの通信を取り込む必要があるか判断してください。問題がシステムプロキシのポート設定だけなら、TUNを有効にしても誤りは修正されず、切り分ける条件が増えるだけです。

有効にする前に、現在のデフォルトネットワーク、DNS設定、他の仮想インターフェースの用途を記録し、不要な同種の通信取り込みツールは終了します。複数のプログラムがデフォルトルートを変更しようとすると、設定が上書きされたりループが発生したりすることがあります。複数のツールを併用する場合は、入口を担当するプログラム、DNSを処理するプログラム、通信取り込みから除外する宛先を明確にしてください。役割分担が決まっていない場合は、まず1つのプログラムだけで動作を確認し、その後で併用条件を検討しましょう。

権限、ルート、接続のループ

デスクトップ環境では、クライアントの実装やシステムによって、管理者権限、補助サービス、仮想インターフェース用コンポーネントが必要になる場合があります。起動に失敗したら、まずログに記録された失敗段階を確認してください。インターフェースの作成に失敗する場合は権限とコンポーネント、ルートの設定に失敗する場合は権限や競合、インターフェースができても通信がない場合はルートと除外条件を調べます。許可画面を完了できなかったからといって何度も再インストールしたり、関連する複数の機能を同時に有効にしてエラーを覆い隠したりしないでください。

プロキシコアがリモートサーバーへ接続する通信は、自分自身の通信取り込みルールで入口に送り返され、無限ループにならないようにする必要があります。通常、クライアントは必要な迂回設定を処理しますが、カスタムルート、インターフェースのバインド、他のネットワークツールがそれを妨げる場合があります。通常のプロキシは動作するのにTUNを有効にするとすぐにタイムアウトする場合、ループバック、出口ネットワーク、リモートアドレスへの経路を優先して確認してください。検証のためにすべての通信を直接接続へ変更すると、テスト条件と取り込み対象を同時に変えてしまいます。

DNSとLANを個別に確認

TUNの有効化後も、DNSの問い合わせ経路を確認する必要があります。環境によってシステムの問い合わせが取り込まれる場合もあれば、特定のDNSモードやクライアント設定が必要な場合もあります。既知のアドレスには接続できるのにドメインを解決できない場合は、リモートノードを疑う前に名前解決を確認しましょう。合成アドレスの仕組みを有効にしている場合は、対応付け、除外ドメイン、ルーティングの連携も確認してください。この仕組みが返すアドレスを、宛先サーバーの実アドレスと誤認して別のルールに設定しないようにしましょう。

LAN内のデバイス、ローカルサービス、リモート管理接続は個別に確認してください。通信の取り込みを有効にする前に必要な作業を保存し、ローカルから元に戻せる手段を確保します。デフォルトルートが変わる可能性のある設定を、唯一のリモート接続から直接試さないでください。プライベートアドレスの迂回設定は、他人の除外リストをコピーするのではなく、実際のネットワーク範囲に合わせます。外部の宛先だけでなく、ローカル共有、デバイスの管理画面、維持が必要なシステム機能も確認しましょう。

Androidとデスクトップで異なる確認ポイント

Androidクライアントは通常、システムのVPNインターフェースを通じてアプリの通信を取り込みます。デスクトップの独立したTUNスイッチと、項目ごとに単純比較することはできません。主な確認点は、システムの許可、対象アプリの選択、バックグラウンドの制限です。アプリごとの範囲を設定するときは、選択したアプリだけを含めるのか、選択したアプリを除外するのか、画面の説明を確認してください。保存後に接続を確立し直してテストします。チェックマークだけから意味を推測せず、説明と実際のリクエストログを照らし合わせましょう。

画面ロック後に切断される場合は、すぐにノードを変更せず、まず前面とバックグラウンドの状態を比較し、電池管理、バックグラウンド制限、ネットワーク切り替えを確認します。デスクトップでも、有線から無線への切り替えやスリープからの復帰後に、仮想インターフェースやルートを再設定する必要がある場合があります。環境の変化は1つずつ試し、接続が復旧するか記録してください。ネットワーク切り替え後だけ問題が起きるなら、すでに確認済みの認証情報を何度も編集するのではなく、インターフェースの状態と出口ネットワークの変化を重点的に調べましょう。

日常のメンテナンス：バックアップ、更新、トラブル対処

復元可能な基本設定を保存

日常のメンテナンスでは、設定を増やし続けるのではなく、内容を説明でき、復元できる動作中の設定を保管することが大切です。バックアップにはサブスクリプショングループ、手動で追加したノード、カスタムルーティング、DNSの選択、必要な画面設定を含め、クライアントが自動生成する項目も記録します。エクスポートしたデータにアクセス情報が含まれる可能性があるため、共有を制限した管理下の場所に保存してください。バックアップ後は形式と対応クライアントを確認し、実際には復元できないファイルを保護策として扱わないようにしましょう。

更新前に動作中の状態と重要な設定を記録し、重要な接続を終了してからクライアントや関連コンポーネントを更新します。更新後は、以前と同じ基本テストを行い、起動、サブスクリプション、入口、ルーティングが正常なことを確認してから新機能を有効にしてください。画面の変更で旧メニューが見つからない場合は、設定項目の構成が変わったか確認し、すべてのパラメーターをすぐに再入力しないでください。更新後に問題が起きたら、ログと設定差分を保存し、事前に用意した復元方法に沿って対処します。

失敗した段階に沿ってログを読む

トラブル対処では、まず時系列を確認します。プログラムは起動したか、設定は生成されたか、コアは動作中か、リクエストは届いたか、リモート接続は確立したか、宛先から内容が返ったかを見ていきます。ログでは、一連のエラーの中で最初に発生した関連エラーが、後続のエラーより重要なことがよくあります。赤字の単語だけを切り取らず、エラーの前後も含めて確認してください。詳細なログを有効にする場合は再現中だけにし、記録後は通常のレベルに戻します。リクエストに関する機密情報を長期間蓄積しないようにしましょう。

コアが起動しない場合は、まずJSONの構文、項目の位置、出口タグ、データファイル、ローカルポートを確認します。この段階では通信がまだ正常に処理されていないため、リモートノードを変えても解決しないことがあります。ポートの競合は同じ端末上のプログラムを、分類ファイルの不足はデータの保存先を、未対応の項目はコアの機能を確認してください。ログの詳細な確認方法はコア起動失敗のトラブル対処をご覧ください。原因を1つ特定して対処してから、再起動して状態を確認します。

症状優先して確認後回しにする操作
コアが起動しない設定構文、ポート、ファイルパス、項目の互換性リモートノードを次々に切り替える
動作中だがリクエストの記録がないアプリの入口、プロキシのポート、通信の取り込み範囲ルーティングルールの追加
ドメイン名では失敗するが、アドレス宛てのテストは応答する名前解決の経路、DNSの応答、ドメインのマッチ条件クライアントの再インストール
バックグラウンドまたはネットワーク切り替え後に切断する電池の制限、インターフェースの状態、出口ネットワークの変化認証パラメーターの書き直し

速度の問題はレイヤーごとに比較

接続できても遅い場合は、ノードの負荷、通信経路、端末側の設定を切り分けます。まずアプリと宛先を固定し、似た条件で複数のノードを比較してから、特定の時間帯やネットワーク環境だけで問題が起きるか確認します。ノード、トランスポートの設定、DNSを同時に変更すると、改善しても原因を判断できません。テスト結果が示すのは、その方法と実施時の環境での状態です。すべてのアプリで長期的に同じ使い心地になるとは限りません。

端末側では、他のダウンロード、リソースの使用状況、プロキシの重複を先に確認してから、接続の再利用などの高度な設定を検討します。再利用はすべてのプロトコルやアプリに適するとは限らず、安易に有効にすると問題の現れ方が変わることがあります。3つのレイヤーごとの具体的な確認順は接続速度が遅いときの段階的な確認方法をご覧ください。日常的にすべてのノードを何度も一括テストする必要はありません。まず普段使う設定を安定させ、必要な問題に絞って比較しましょう。

トラブルの情報を共有するときは、クライアント名、OS、発生した段階、個人情報を除いたエラーを残し、サブスクリプションURL、認証情報、不要なアクセス記録を削除します。スクリーンショットにはグループ名、サーバーアドレス、アカウント情報が含まれる場合もあるため、送信前に項目ごとに確認してください。入口やモードが分からず、タイムアウトの表示しか見えない相手は、適切に判断するのが困難です。大量の未整理なスクリーンショットより、必要な情報をまとめた短い再現手順のほうが役立ちます。

メンテナンスの記録は通常のテキストで十分です。変更項目、理由、テストした宛先、結果、元に戻す方法を記載します。一時的な設定が不要になったら早めに削除し、数年後に誰も理解できない例外ルールに依存しないようにしましょう。定期的にサブスクリプショングループの利用状況、バックアップの有効性、システムプロキシと現在のクライアントの整合性も確認してください。メンテナンスの目的は、問題の範囲を絞り、変更の理由を説明できるようにすることです。設定項目を増やし続けることではありません。

応用編：問題に応じて設定を複雑にする

動作する接続から検証可能な設定へ

前の章を終えた後の学習は、実際の必要に沿って進めましょう。通信経路を細かく制御したい場合はルーティングとDNSを、複数の端末を管理したい場合は設定の移行範囲を、特殊なプロトコルパラメーターが必要ならコアの対応状況を確認します。高度なスイッチをすべて同時に有効にすることは、学習の完了を意味しません。各ルールの役割を説明でき、テストを再現でき、いつでも元に戻せるシンプルな設定のほうが、未検証の項目を多数含む設定より長期運用に適しています。

実験のたびに、現在の基本設定、検証したい仮説、変更する項目1つ、予想する結果の4点を記録しましょう。たとえば、ドメインルールの優先順位を確認する場合、ノードと入口はそのままにし、対象範囲の明確なルールを1つ追加して、出口ログを確認します。予想と違う結果になったら、すぐに別の変更を追加せず、まず差異の理由を考えます。こうすれば学習内容を再現可能なテストとして記録でき、一度の成功を同時に変更した複数の設定に誤って結び付けることも防げます。

プロトコル機能とコアごとの差

VLESS、XTLS Vision、REALITYを詳しく調べる場合は、各パラメーターが属するレイヤーを理解し、クライアントと現在のコアが対応しているか確認してください。サーバーアドレス、サーバー名、フロー制御、公鍵、ショートIDなどの項目は、名前が似ていても互いに置き換えられません。プロトコル名だけではノードが使えるか判断できず、具体的なトランスポートの組み合わせとサーバー側の設定も関係します。現在のサービスが正常に動作しているなら、新しい用語を試すためだけに、検証済みの設定を一式書き換えないようにしましょう。

V2FlyとXrayの関係や機能の違いは、2種類のコアの機能比較もご覧ください。学習の目的は、コアを漠然と順位付けすることではありません。機能を実装するのはどちらか、設定構造はどう異なるか、現在のクライアントでどのように利用できるかを把握しましょう。コアを切り替える前に互換性のチェックリストを用意し、切り替え後は起動、ハンドシェイク、ルーティング、DNSを改めて検証します。以前のコアでの成功を、新しい環境での動作保証とみなさないでください。

カスタム設定とGUIの使い分け

カスタムJSONを使う前に、GUI設定を完全に置き換えるのか、一部の設定だけを追加するのか確認します。設定を読み込む方法は入口によって異なり、入口、出口、タグが重複すると競合することがあります。まず最小限の直接接続の例で構造を理解し、その後に有効なノードとルールを1つずつ追加しましょう。他人のローカルパスや特定のタグが含まれる完全な設定をそのまま読み込まないでください。設定がどの順序で統合されるか分からない場合は、互いに上書きし合う2種類の設定を同時に管理しないようにしましょう。

GUIが生成した設定は、実際の結果を確認するには便利ですが、長期間にわたって手動編集する場所として適切とは限りません。クライアントの次回保存やノード切り替え時に、ファイルが再生成され、手動変更が上書きされることがあります。高度な設定を維持する必要がある場合は、クライアントが正式に対応するカスタム設定の入口を使いましょう。専用の入口がない場合は、起動のたびにファイルを手動編集するのではなく、維持の負担を検討してください。データの取得元、生成方法、最終設定の関係を記録しておけば、保存したように見えて実際には反映されていない変更を見分けやすくなります。

小規模な回帰テストを用意

設定が複雑になったら、固定のチェック項目を用意します。一般的なドメインにアクセスできるか、ローカルリソースが直接接続されるか、指定したルールが意図した出口を選ぶか、どのルールにも一致しない宛先が正しく処理されるか、スリープやネットワーク切り替え後に復旧するかを確認しましょう。アップグレードやルール変更のたびに、同じ項目で結果を比較します。すべてのサイトを網羅する必要はありません。重要な用途を代表し、失敗時に関連するモジュールを絞り込めるテストセットであれば、実用的な価値があります。

自動化も、安定した手順を確立してから導入します。サブスクリプションの定期更新、自動起動、バックグラウンドでの通信取り込みは、繰り返し作業を減らす一方、誰も確認していない状態でノードやシステムの状態を変えることがあります。有効にする前に、失敗時の動作を確認してください。更新に失敗したときに古い内容が保持されるか、起動時にシステムプロキシが上書きされるか、異常終了後に復旧できるかを確認します。まず手動で一連の操作を完了し、復旧方法もテストしてから自動化を有効にしましょう。未解決の問題が定期的なバックグラウンド障害になるのを防げます。

このガイドの目標は、自分で問題を特定できる手順を身につけることです。環境の確認、入口の検証、ノードの確認、ルーティングの観察、名前解決の確認を行い、その後に通信の取り込みや高度な設定を検討します。最小限の接続を作り直す場合はクイックスタート、別の端末に適したインストール方法を探す場合はクライアントのダウンロードページ、関連する事例を読みたい場合は使い方ガイドからテーマを選んでください。追加する設定ごとに目的を明確にし、検証結果を残すことが、継続的なメンテナンスにつながります。