v2rayN 設定ガイド初歩から応用まで

1. 基本概念：通信経路を把握する

クライアント、コア、サーバーの役割

まず、グラフィカルな画面と実際に接続を処理するプログラムを分けて考えましょう。v2rayNはサーバー情報の保存、サブスクリプションの管理、ルーティングの選択、コアの起動を担当します。コアはローカルポートを待ち受け、設定を読み込み、接続を確立します。画面が開いていても、コアが正常に動作しているとは限りません。接続できないときは、ブラウザーを何度も設定し直す前に、起動ログにエラーがないか確認してください。設定の構文ミス、ポートの競合、コンポーネント不足などがあると、画面は正常でもプロキシの入口が作られないことがあります。

Project Vは関連するプロキシ技術のエコシステムを支えるプロジェクトです。その中で、V2FlyとXrayは区別して扱う必要のあるコアの系統です。対応プロトコル、設定項目、機能の実装はコアによって異なるため、名前が似ていても動作が同じとは限りません。GUIクライアントは通常、画面上の設定をコアの設定に変換します。一般ユーザーが最初から設定ファイルをすべて手書きする必要はありませんが、現在どのコアを使っているかは把握しておきましょう。説明を参照するときは、クライアントの設定とコアのパラメーターを分けて確認し、別の実装向けの項目をそのまま貼り付けないようにしてください。

サーバー情報には、アドレス、ポート、認証情報、プロトコル、通信パラメーターなど、接続先の情報が含まれます。クライアント自体がこれらの情報を提供するわけではなく、インストールしただけで接続先が自動的に使えるようになることもありません。共有リンクには通常、1つの接続に必要な項目が含まれます。サブスクリプションURLは、複数の接続情報を取得・更新するためのものです。どちらにも機密情報が含まれることがあります。サブスクリプションURLを公開の掲示板に貼ることは、接続用の入口を公開するのと同じです。スクリーンショットを共有する前に、認証情報やURL全体を隠してください。

アプリからアウトバウンドまで、通信の方向を理解する

一般的な通信経路は次のとおりです。アプリがまずローカルのプロキシ入口に接続し、コアがルーティングルールに従ってアウトバウンドを選び、リモートサーバーまたは接続先へ直接接続します。「インバウンド」は通信がローカルのコアに入る方法、「アウトバウンド」はコアが外部へ接続する方法を指します。直接接続もアウトバウンドの一種であり、すべての処理を迂回するという意味ではありません。ログにローカルの送信元アドレスが表示されても、それをリモートサーバーのアドレスと取り違えないでください。接続先のドメイン名が表示されていても、想定したDNSリゾルバーで名前解決されたとは限りません。

システムプロキシは、その設定に従うアプリにプロキシの場所を知らせます。一方、TUNは仮想ネットワークインターフェースを通じ、ルーティング条件に合う通信を取り込みます。ルーティングルールは、通信がコアに入った後の行き先を決めるもので、取り込み方法の代わりにはなりません。システムプロキシを参照しないアプリは、「中国本土を迂回」などのルールを変更しても、突然プロキシ入口を使うようにはなりません。トラブル時は、まず「通信がコアに入っているか」、次に「入った後にどのアウトバウンドが選ばれたか」を確認してください。順序を逆にすると、誤った判断につながりやすくなります。

プロトコル、トランスポート、暗号化を混同しない

VMess、VLESS、Trojanは接続プロトコルの名称です。TCP、WebSocket、gRPCなどはトランスポート方式を表し、TLSなどのセキュリティ設定はさらに別の層です。接続情報をインポートしたら、プロトコル名だけを見て互換性があると判断せず、各項目の組み合わせを確認してください。たとえば、サーバー側で特定のパスやサービス名が必要な場合、クライアント側に対応する値がなければ、認証情報が正しくても接続に失敗することがあります。サーバーから指定されたトランスポート設定を、経験だけで変更しないでください。

ドメイン名の解決も接続経路の一部です。アプリが先にドメイン名をIPアドレスへ変換する場合もあれば、プロキシ経由でドメイン名を処理する場合もあります。実際の動作はアプリとプロキシプロトコルによって異なります。ドメイン名でルールを適用できるかどうかは、コアがどの情報を受け取るかに左右されます。「Webページが開かない」という情報だけでは、DNS、認証、ルーティングのどこに問題があるか判断できません。接続先の種類、アプリでの接続方法、ログに記録されたエラーの段階を確認すれば、その後の調査対象を絞れます。

2. クライアント比較：デバイスとコアで選ぶ

デスクトップではまずv2rayNを選ぶ

デスクトップではv2rayNをまず検討しましょう。最初にOS、次にCPUアーキテクチャを確認し、最後に対応するインストール形式を選びます。Windows版にはクロスプラットフォームのGUI版と、別のデスクトップ画面を備えた従来のWPF版があります。これはプロキシプロトコルの違いではありません。初めて使う場合は、ダウンロードページの説明に従ってどちらかを選びましょう。設定が安定している場合は、画面の違いだけを理由に移行する必要はありません。トラブルシューティング中に両方をインストールして同時に起動すると、待ち受けポートやシステムプロキシの制御が競合することがあります。

macOSではApple SiliconとIntelを区別する必要があります。外観だけで判断せず、「このMacについて」でチップ情報を確認してから、対応するダウンロード先を選んでください。Linuxではディストリビューションのパッケージ形式とCPUアーキテクチャを確認します。debとrpmのどちらを使うかは、好みではなくディストリビューションによって決まります。アーキテクチャの不一致や依存関係の不足はインストール段階の問題です。まだ接続段階に進んでいないため、サブスクリプションやサーバー設定を変更しても解決しないことがほとんどです。

クライアントを選ぶ際は、ブラウザーのプロキシだけでよいのか、システムプロキシを参照しないアプリも取り込みたいのか、仮想ネットワークインターフェースに必要な権限があるのかも検討してください。まずは必要最低限の機能で使い始め、必要に応じて高度な設定を追加しましょう。設定項目が存在するからといって、利用中のデバイスで必ず使えるとは限りません。OSの権限、コアの対応状況、ネットワーク環境が実際の動作に影響します。

Androidではまずv2rayNGを選び、必要に応じてv2flyNGを検討

AndroidではXrayコアを使用するv2rayNGが第一候補です。v2flyNGはV2Flyコアを使用するため、そのコア固有の動作が必要な場合に適しています。どちらも、実際に対応しているプロトコルとトランスポートの組み合わせを確認してください。インポートできたからといって、接続まで確立できるとは限りません。新しいスマートフォンの多くはarm64ですが、購入年だけではアーキテクチャを正確に判断できません。不明な場合は、デバイス情報とダウンロードページの説明を確認してから、アーキテクチャ別のパッケージか汎用パッケージかを選びましょう。

モバイル端末では、システムのVPNインターフェースを許可してローカルの通信経路を作ります。初回の接続時にシステムの確認画面が表示されるのは、通常の権限確認です。別のサービスがすでにこのインターフェースを使用している場合、同時に有効化できないことがあります。アプリに「起動中」と表示されても、それはローカルサービスが動作していることを示すだけで、リモート接続や接続先へのアクセスが正常とは限りません。ログ、実際のアプリでのアクセス、ルーティング結果を確認してください。

移行前に互換性の範囲を確認

別のクライアントへ移行するときは、プログラムのフォルダー全体をコピーせず、サブスクリプションURLまたは標準の共有リンクを移行してください。画面設定、ルーティングのテンプレート、ローカルデータベースの形式は、必ずしも共通ではありません。同じプロトコルに対応していても、拡張パラメーターを認識する範囲は異なる場合があります。移行後は、動作確認済みの接続情報を1つ選び、トランスポート設定を変えずに基本的なアクセスを確認してから、独自ルールやアプリ別のルーティングを戻してください。

サブスクリプションの内容が、汎用の共有リンク一覧なのか、特定のプログラム向けの完全な設定なのかも確認しましょう。後者には専用の項目、スクリプト、テンプレートが含まれることがあり、ファイルの拡張子を変えただけでは汎用サブスクリプションとして使えません。形式に対応していない場合は、むやみに変換せず、情報の提供元に出力形式を確認してください。クライアント選びで重要なのは機能の数ではなく、接続情報、デバイスの権限、メンテナンス方法を安定した形で組み合わせられるかどうかです。

この章を終えたら、デバイスのOS、CPUアーキテクチャ、クライアント名、使用コアを明記できるようにしましょう。これらを個人のトラブルシューティング記録に残しておけば、後でドキュメントを調べる際に異なるプラットフォームの説明を混同せずに済みます。3つのクライアントの操作の違いを詳しく比較したい場合は、クライアント比較レビューをご覧ください。インストーラーはダウンロードセンターから選べます。紹介記事を具体的なインストーラー一覧と取り違えないようにしてください。

3. インストールと初期設定：ローカルサービスを確認

インストール形式に合わせて初回起動する

ダウンロード前にOSとアーキテクチャを確認し、インストール後は初期設定のまま起動してください。インストーラーを使う場合は、画面の案内に従って保存先を選び、インストールを完了します。ダウンロードしたものが圧縮ファイルの場合は、書き込み可能な固定フォルダーへ完全に展開してから、メインプログラムを起動してください。圧縮ファイルのプレビュー画面から直接実行したり、実行ファイルだけを取り出したりしないでください。コアやリソース、設定ファイルが同じフォルダー内にあることがあり、それらが不足すると画面は起動してもバックグラウンドのコンポーネントが動作しない場合があります。

プログラムのフォルダーは、後でバックアップしやすい場所に置きましょう。一時的なダウンロードキャッシュや、自動削除される場所は避けてください。複数のデバイスで設定を同期する場合、実行中のデータベースを同期ツールが同時に書き換えないようにします。フォルダーに書き込めないという警告が表示されたら、すべてのセキュリティ機能を無効にするのではなく、フォルダーの権限とインストール先を確認してください。通常の起動では一般ユーザー権限を使い、仮想ネットワークインターフェースなど、機能上必要な場合にのみ権限を付与します。

macOSではダウンロード形式に合わせてインストールし、システムの「プライバシーとセキュリティ」で信頼できる開発元に関する警告を確認してください。Linuxではディストリビューションに対応した方法でインストールし、依存関係のエラーが出た場合はパッケージマネージャーの情報を読みます。異なるディストリビューションの手順をそのまま流用しないでください。初回起動後は、ウィンドウを正常に閉じて再度起動できること、設定が保存されることを確認します。これにより、サブスクリプションを追加する前に、読み取り専用のフォルダー、不完全なインストール、実行環境の不足を特定できます。

ポート、コア、ログを確認

v2rayNの設定画面と実行ログでローカルの待ち受け情報を確認してください。一般的な設定ではSOCKSポートに10808、HTTPポートに10809を使いますが、リリースや既存の設定によって異なるポートや混合プロキシを使う場合もあります。チュートリアルにある数字だけを入力せず、現在の画面と起動ログを基準にしてください。リモートサーバーのポートは接続情報に記載されているもので、ローカルの待ち受けポートとは別の項目です。一方を変更しても、もう一方が自動的に変わることはありません。

ログにアドレスがすでに使用中と表示された場合は、別のクライアントや同種のローカルサービスが動作していないか確認してください。重複しているプロセスを終了して再起動するか、競合しない待ち受けポートを設定し、アプリ側のプロキシ設定も合わせて変更します。エラー表示を隠すだけでは解決になりません。待ち受けに成功していなければ、ブラウザーの接続先が正しくても接続できません。この段階では通信がローカルのプロキシ入口から出ていないため、サーバーを変更しても意味がありません。

最小限の初期設定を保つ

初回設定では、TUN、LAN共有、不要なカスタムルーティングをオフにし、ローカルの入口と接続情報を1つだけ残してください。こうすれば、問題が発生したときに、コアの起動、認証、リモートサーバーへの到達性に原因を絞れます。基本の通信経路が正常だと確認してから、機能を1つずつ追加しましょう。最初から大量のルールを読み込み、DNSを変更し、複数の通信取り込み機能を有効にすると、アクセスに失敗した際にどの変更が経路に影響したのか判断しにくくなります。

Androidではインストール後にアプリを開いて初期設定を済ませ、接続情報を1つ追加してから接続を開始し、システムの許可を確認します。ログを待つ代わりに起動ボタンを何度も押さないでください。別のアプリに切り替えた後に接続が停止する場合は、バックグラウンド動作やバッテリー管理の設定を確認しますが、変更は必要なアプリだけにしてください。バックグラウンド制限、システム権限、リモート認証は別々の問題です。「接続先が使えない」とひとまとめにせず、それぞれ記録しましょう。

初期設定の完了とは、設定を保存でき、コアが起動し、ローカル入口のポートが競合せず、ログの保存場所も確認できている状態です。この段階で、すべてのアプリがプロキシを使える必要はありません。現在の待ち受けアドレスとポート、デフォルトのルーティング名を記録して、初期状態の基準にしておきましょう。後で変更に失敗したら、この状態に戻します。初期状態でも起動できない場合は、プログラムファイルとシステム環境を確認してください。よくある起動エラーは、よくある質問を参照して調べられます。

4. サブスクリプションの追加：URL、更新、接続情報の管理

入力内容を見分けてから追加方法を選ぶ

手元にあるものがサブスクリプションURL、単一の共有リンク、完全な設定ファイルのどれかを確認してください。サブスクリプションURLは、通常、ネットワーク経由で情報を取得するためのアドレスです。共有リンクには、接続情報を示すプロトコル固有のプレフィックスがあります。完全な設定ファイルには、インバウンド、アウトバウンド、ルーティングなどの構造が含まれます。これら3種類を同じ入力欄に貼り付けないでください。コピー時には前後の空白、改行、チャットアプリが付けた句読点にも注意します。特に長いURLが複数行に分かれている場合、見た目は完全でも一部の項目が欠けていることがあります。

v2rayNでサブスクリプションを管理するには、「サブスクリプショングループ」を開き、新しいグループを追加して、識別しやすい名前とサブスクリプションURLを入力します。保存後、「すべてのサブスクリプションを更新」または該当グループの更新を実行してください。URLの保存とコンテンツの取得は別の操作です。保存直後に一覧が空でも、URLが無効とは限りません。更新を実行したかを確認し、その後ログで内容の取得に成功したかを確認してください。提供元ごとにグループを分けると、更新する範囲や保持方法を管理しやすくなります。

単一の共有リンクは、「クリップボードから共有リンクをインポート」を使って追加できます。デスクトップ版で対応している場合は、Ctrl+Vも使えます。追加後は編集画面を開き、プロトコル、アドレス、ポート、トランスポート方式を確認してください。リストに接続名が表示されたからといって、すべての項目が正しく読み込まれたとは限りません。追加のトランスポート設定が含まれるリンクでは、セキュリティ設定、サーバー名、パス、サービス名が元の情報と一致するか、特に注意して確認してください。空欄をよくある例の値で勝手に埋めないでください。

更新エラーは取得と解析に分けて調べる

サブスクリプションの更新は、主に2段階で行われます。まずURLにアクセスし、次に返された内容を解析します。アクセスのタイムアウト、証明書エラー、DNSの失敗は取得段階の問題です。URLにはアクセスできても形式に対応していないと表示される場合は、内容の解析段階の問題です。ログインページ、期限切れの通知、通常のWebページ本文は有効なサブスクリプションではありません。サーバーが成功ステータスを返していても、そのまま追加できるとは限りません。ログのエラーが簡略表示される場合は、URLの提供元と有効期限を確認してください。URL全体を関係のない相手に送らないようにしましょう。

画面によっては、サブスクリプションを直接更新する方法と、プロキシ経由で更新する方法を選べます。プロキシ経由の更新が有効なのは、使用可能なプロキシがすでにある場合だけです。初回インストール後、まだ使える接続がないのに、更新をその接続に依存させると循環してしまいます。提供元が許可する方法で内容を取得するか、先に有効な共有リンクを追加して基本の接続を確立してください。更新方法を変更した後は、原因を特定しやすいよう、グループごとに1回ずつ再試行します。

更新後にサブスクリプション内の接続情報が追加、削除、改名されることがあります。また、ローカルで手動変更した項目が次回更新時に上書きされる場合もあります。重要なカスタム接続情報は別に管理し、クライアントに保持や複製の機能があるか確認してください。サブスクリプションから生成された項目を直接編集し、長期的に使い続ける方法は避けましょう。グループを削除する前に、グループ内の接続情報も一緒に削除されるか確認してください。更新エラーを解決するために一覧を消去する必要はありません。既存の有効な情報を保存しておくと、復旧しやすくなります。

追加後の確認とプライバシー

Androidのv2rayNGとv2flyNGでも、「サブスクリプションURLを管理し、更新して内容を取得する」という基本的な流れは同じです。具体的なメニューは現在のアプリ画面で確認してください。追加後に接続情報を1つ選択して接続を開始し、実行ログを確認します。リストの並び順、速度測定の結果、現在の選択状態はそれぞれ別のものです。先頭にある接続情報が必ず使用されるとは限りません。接続情報を切り替えた後は、接続サービスに新しい設定が適用されたか確認し、必要に応じて画面の案内に従って接続を再起動してください。

確認には、提供元が明確で、必要な項目がそろった接続情報を1つ使いましょう。複数の提供元から一度にインポートし、名前だけを頼りに選ばないでください。接続に失敗したときは、認証情報を公開せず、エラーが発生した段階を記録します。サブスクリプションURLにはアクセストークン、共有リンクには識別情報、エクスポートした設定にはサーバーの認証情報が含まれる場合があります。バックアップファイルも機密情報として扱い、公開共有フォルダーや内容を確認していない同期領域に置かないでください。

5. プロキシモード：アプリがコアに接続する方法を確認

システムプロキシの3つの操作は、3種類のルーティングではない

デスクトップでは、まずシステムプロキシを使って基本の接続を確認します。v2rayNの「システムプロキシを自動設定」は、システム関連の設定にローカルプロキシの入口を書き込み、その設定に従うアプリで使えるようにします。「システムプロキシを解除」はプロキシ設定を削除し、「システムプロキシを変更しない」は既存の設定を保ち、積極的に書き換えません。最後の操作は自動的に既定値へ戻すものでも、システムが直接接続を維持することを保証するものでもありません。切り替える前に他のプログラムがプロキシを設定していた場合、その設定が残ることがあります。

システムプロキシと、「全般」「中国本土を迂回」などのルーティング選択は別の層の設定です。システムプロキシは、アプリが通信をローカルの入口に送るかどうかを決めます。ルーティングは、コアに入った後のアウトバウンドを決めます。ルーティングを全般に設定しても、すべてのアプリが通信を取り込まれるわけではありません。ブラウザーは使えるのに別のプログラムが使えない場合は、そのプログラムがシステムプロキシを参照するか、独自のネットワーク設定を持つか確認してください。プロトコルを変更したり、サブスクリプション全体を作り直したりするのは後にしましょう。

アプリによっては起動時にだけシステムプロキシを読み込むため、設定変更後に完全終了して再起動する必要があります。すでに確立した長時間接続も、新しい経路にすぐ切り替わるとは限りません。切り替えの効果を確認するには、関連する接続を閉じるかテストアプリを再起動してから、新しいリクエストを送ってください。古いタブに内容が表示されているだけで接続が正常と判断しないでください。キャッシュの可能性があります。古い接続が残っていることを、新しい設定が反映された証拠と取り違えないようにしましょう。

手動プロキシではプロトコルと待ち受けアドレスを確認

アプリに独自のプロキシ設定がある場合は、ローカルアドレスと実際の待ち受けポートを指定できます。アプリとクライアントが同じデバイスで動作している場合、通常はループバックアドレス 127.0.0.1を使用します。HTTPプロキシとSOCKSプロキシでは、入口に対応するプロトコルを選ぶ必要があります。ポートを入力すれば同じものとして使えるわけではありません。現在のコアが混合プロキシを提供している場合は、その入口が対応する方式を確認します。個別に待ち受けている場合は、それぞれのプロトコルに対応したポートを入力してください。

アプリの「リモートDNS」などの設定は、ドメイン名をローカルとプロキシ経路のどちらで解決するかに影響します。その設定がないからといって、必ず一方で解決されるとは限りません。ドメイン名ではアクセスに失敗し、IPアドレスでは挙動が異なる場合は、アプリのプロトコルと名前解決の方法を記録してからDNSを調べてください。WebサイトのIPアドレスで代用してテストする方法にも限界があります。HTTPS証明書やバーチャルホストはドメイン名に依存することがあるため、失敗してもネットワークが通じていないとは限りません。

接続確認と正しい終了方法

一般的なブラウザーから新しいリクエストを送り、同じ時刻のクライアントログを確認します。新しい接続が入っているかをまず確認し、その後、認証、トランスポートのハンドシェイク、接続先への接続でエラーが起きていないかを調べてください。ブラウザー拡張、自前のプロキシプラグイン、アプリ内設定がシステムプロキシを上書きすることがあります。テスト中は入口を明確に1つだけ使いましょう。ログに該当する通信がまったくない場合は、リモートサーバーだけを原因と決めつけず、まずアプリ側の入口を確認してください。

クライアントを終了する前に、クライアントが設定したシステムプロキシを解除してから、通常の方法で終了してください。異常終了後もシステムプロキシが停止済みのローカルポートを指していると、その設定を使うアプリは接続に失敗し続けます。復旧するには、クライアントを再度開いて設定を解除するか、システムのネットワーク設定でプロキシアドレスを確認します。元の環境が分からないまま、企業プロキシなどの設定を消去しないでください。使用前に元の値を記録しておけば、テスト後に正しく戻せます。

Androidは通常、デスクトップのシステムプロキシ設定を使わず、アプリが作成するVPNインターフェースで通信を取り込みます。アプリごとのルーティングや迂回設定も、使用中のクライアント内で確認してください。この章を終えたら、テスト対象のアプリがシステムプロキシ、独自プロキシ、仮想インターフェースのどれを使うか説明できる状態が目標です。まだ明確でなければ、入口の確認に戻りましょう。入口が分かって初めて、次章のルール順序や直接接続の設定を検証できます。

6. ルーティングとDNS：ルールと名前解決を整える

まず内蔵の設定を使い、例外は後から追加

初めてルーティングを設定する場合は、まずクライアントに用意されたルーティング設定を使い、実際の接続先に応じて必要なルールだけを追加しましょう。「中国本土を迂回」は通常、該当するドメイン名やIPアドレスを直接接続にし、それ以外の通信は設定に応じたアウトバウンドを使うことを意味します。ただし、ルールセットやテンプレートの動作がすべて同一とは限りません。設定を選んだら、ルールの説明とログの結果を確認し、ローカルサービス、中国本土の接続先、それ以外の接続先が実際にどの経路を通るか確かめてください。画面に設定名が表示されても、各ドメインが正しく分類されているとは限りません。

ルールの順序は非常に重要です。上から順に一致判定するルール一覧では、上位の一致が下位のルールに影響します。一般に、具体的な例外は広範囲に適用されるルールより前に置きます。ルールを追加するときは、条件とアウトバウンドのラベルを両方確認してください。ドメイン名が正しくてもラベルが存在しなければ動作せず、ラベルが正しくても上位の広範なルールに先に一致すれば、期待した結果になりません。接続先を1つずつ追加し、保存して反映した後に新しい接続を試し、どのルールに一致したか確認してから対象を広げましょう。

以下はXray形式のルーティング例で、テスト用ドメインを完全一致させる方法を示しています。これは単体で起動できる完全な設定ファイルではなく、directという名前のアウトバウンドがすでに必要です。full:はドメイン名との完全一致を表し、domain:はそのドメインとサブドメインを対象にします。例示されたドメイン名を実際のサービス一覧として扱わないでください。また、ルーティング設定のオブジェクトをGUIの共有リンク入力欄に貼り付けないでください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNSは接続性とルール判定の両方に影響する

DNS設定では、まず「どのドメイン名をどのサーバーで解決するか」を決めます。ローカルネットワークからアクセスできるリゾルバーは、直接接続する一部の接続先に適しています。ほかの接続先では、指定された経路でDNSサーバーにアクセスする必要がある場合があります。重要なのはサーバーアドレスを入力するだけでなく、DNSクエリ自体がどうやってそのサーバーに届くかです。リゾルバーへのアクセスがプロキシに依存し、そのプロキシサーバーのアドレス解決も同じリゾルバーを待つ場合、起動時に依存関係の循環が発生することがあります。まずサーバーアドレスを初期解決できる状態にしてから、対象ドメインごとの設定を行いましょう。

ルーティングのドメイン名解決方針と、DNSモジュールの問い合わせ方針は別の設定です。前者は、ルーティング判定のためにドメイン名をアドレスへ変換するかどうかに影響します。後者は、問い合わせるアドレスの種類などに影響します。以下のDNS例は、ドメイン名に応じてサーバーを指定し、問い合わせる種類を制限する構文を示すものです。すべてのネットワークに適した推奨設定ではありません。使用前にDNSサーバーへ到達できることを確認し、完全な設定でDNS通信がどのアウトバウンドを通るかも確認してください。一部分をコピーしただけでDNS通信が取り込まれたと判断しないでください。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["full:example.com"]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

IPv6は別途確認が必要です。アプリがIPv6アドレスを優先して使う一方、プロキシまたは直接接続の経路をIPv4でしか確認していないと、断続的な失敗や接続まで時間がかかる問題が起きることがあります。システムのアドレス、DNSの結果、アウトバウンドの対応状況、ルールの適用範囲をそれぞれ確認してください。特定のアドレスファミリーを無効化する方法を、恒久的で汎用的な解決策とみなさないでください。問い合わせる種類を一時的に制限すれば原因特定に役立つことがありますが、その理由を記録したうえで再検討し、本来修正できるネットワークやルーティングの問題を隠さないようにしましょう。

接続先を決めてルールを検証

直接接続すべき接続先と、プロキシ経由にすべき接続先を1つずつ選び、それぞれ新しいリクエストを送ってログを確認してください。ブラウザーのキャッシュ、既存の接続、システムのDNSキャッシュに以前の結果が残ることがあります。必要に応じてアプリを再起動するか、キャッシュが失効するまで待ってください。1つのルールを検証するためにすべての設定を一度に消去しないでください。特定のサブドメインだけに問題がある場合は、ドメイン全体の経路を変えるのではなく、完全一致とサフィックス一致の範囲を確認しましょう。

ドメイン情報を取得するスニッフィング機能は、アプリがアドレスだけを渡す場合に役立つことがあります。ただし、あらゆるプロトコルを認識できるわけではなく、元のドメイン名を必ず復元できるとも限りません。LANサービスでは、ローカルDNSとプライベートアドレスへの到達性も確保してください。ルールが増えるほど、提供元、用途、優先順位の記録が重要になります。項目の詳しい説明はDNSの分流と名前解決の解説をご覧ください。この章では、まず少数の検証可能なルールで基準を作ります。

7. TUNモード：アプリのプロキシからネットワークの取り込みへ

TUNが本当に必要か確認

対象アプリがシステムプロキシを参照しない場合や、より多くの通信を共通のネットワーク経路で処理したい場合にTUNを検討してください。TUNは仮想ネットワークインターフェースとシステムのルーティングを使って通信を取り込む機能であり、リモートサーバーの性能を上げる高速化スイッチではありません。まず通常のローカルプロキシで正常にアクセスできる状態にしてからTUNを有効にすると、追加された権限、インターフェース、ルーティング、名前解決に調査範囲を絞れます。基本の接続が失敗している状態でTUNを有効にすると、調査要因が増えるだけです。

v2rayNの「Tunを有効にする」の実際の動作は、選択中のコアコンポーネントやクライアント設定に左右されます。Xrayの通常のインバウンド設定例を、あらゆるTUN設定にそのまま使うことはできません。まず画面で関連コンポーネントが利用可能か確認し、案内に従って権限を付与してください。システムが許可を求めたら、現在使っているクライアントからの要求であることを確認します。起動に失敗した場合は、インターフェース作成、ルート追加、権限に関するログを確認し、関係のないコンポーネントを何度も再インストールしないでください。

TUNで通信を取り込んでも、すべてのプロトコルが自動的に使えるようになるわけではありません。アプリのUDP利用方法、サーバー側の対応、ネットワーク経路、使用中のコアの転送能力が結果に影響することがあります。Webページは開くのに特定のリアルタイム通信が失敗する場合は、ブラウザーのテスト結果をそのまま当てはめず、対象アプリが使うプロトコルを確認してください。「有効にすると使えない」という説明だけでなく、UDPだけで起きるのか、特定の接続先に限られるのかを記録すると、原因を特定しやすくなります。

ルーティングループと名前解決の依存関係を防ぐ

有効化する前に、デフォルトルートを変更する別のサービスや、仮想インターフェースを使用するサービスを停止し、現在のネットワーク状態を記録してください。TUNを使っても、プロキシプロセスからリモートサーバーへ接続する通信は、基盤となるネットワークから送信される必要があります。そうでないと、自身の通信が再び仮想インターフェースへ送られ、ループが発生することがあります。クライアントが該当する除外設定を処理する場合が多いものの、複数のネットワークアダプター、企業ネットワーク、手動の静的ルートを使う環境では追加確認が必要です。ログの根拠なしにシステムルートを削除しないでください。

DNSもよく問題になる箇所です。TUNがネットワーク通信を取り込んでも、システム、アプリ、コアがそれぞれ名前解決のキャッシュを持つ場合があります。アプリによっては独自の名前解決方法を使います。システムのDNSクエリがどこへ送られるか、コアがどう処理するか、DNSサーバーへどのアウトバウンドで接続するかを確認してください。仮想アドレスのマッピング機能を使う場合は、対応するアドレス範囲を正しいインターフェースで処理する必要があります。無効化した後に古い名前解決結果が残っていたら、アプリの接続を作り直し、キャッシュが更新されるまで待ってください。

LANへのアクセスも個別に検証してください。プリンター、ファイル共有、ローカルの管理画面は、プライベートアドレスやローカルドメイン名を使うことが多く、広範なルールに誤って取り込まれると、外部サイトにはアクセスできても内部サービスが使えなくなる場合があります。まずプライベートネットワークとローカルDNSの扱いを確認し、必要に応じて除外ルールを追加しましょう。LANでのプロキシ共有とTUNは別の用途です。TUNを有効にしても、ローカルの入口が自動的に他のデバイスへ公開されるわけではありません。ローカルアクセスの問題を直すためだけに共有を有効にしないでください。

有効化と切り戻しを順番にテスト

テストは3段階で進められます。まずブラウザーからの新しい接続を確認し、次にシステムプロキシを参照しないアプリを確認し、最後にLANサービスとスリープからの復帰を確認します。各段階で、同じ時刻のログとアプリの挙動を見てください。システムプロキシとTUNを同時に有効にすると通信経路が分かりにくくなります。初回テストでは既存環境に影響しないことを確認したうえで、システムプロキシを一時的に解除し、TUN経路だけを検証してから、日常の組み合わせを決めましょう。

ネットワーク全体に接続できなくなったら、まずTUNを無効にしてクライアントを正常に終了し、通常のネットワーク接続が復旧するか確認してください。それでも異常が続く場合は、プロキシ設定の残り、仮想インターフェース、DNS設定を確認します。別のプロキシサービスをさらに追加しないでください。スリープ、ネットワークの切り替え、ネットワークアダプターの再接続で基盤のインターフェースが変わることがあります。復帰後は再度動作を検証してください。長期間使う前に、有線から無線への切り替えや切断後の再接続も一度テストし、起動直後だけ正常な状態ではないことを確認しましょう。

8. 日常のメンテナンス：バックアップ、更新、トラブル記録

復元できる状態を保存する

接続、ルーティング、アプリの通信取り込みが安定したら、まず設定の基準となる状態を保存してください。クライアント名、使用コア、ローカルポート、ルーティング設定、DNSの変更、TUNの状態を記録します。エクスポート機能や設定フォルダーの場所はインストール形式によって異なります。まずクライアントのバックアップ機能を利用し、どの設定が含まれるか確認してください。サブスクリプションURLだけではローカルルールを復元できず、画面のスクリーンショットだけでは認証情報も復元できません。どちらも完全な復旧手順の代わりにはなりません。

クライアントが設定を保存した後にバックアップしてください。必要に応じて正常に終了してから作業し、書き込み中のデータベースをコピーしないようにします。ファイル名に用途とバックアップ日時を記載してもかまいませんが、サブスクリプションのトークンは含めないでください。復元方法を試しておくことも重要です。インポート先を確認し、既存の設定がどこまで上書きされるかを理解し、古い設定をどう残すか把握しておきましょう。確認していないバックアップは、ファイルが存在することを示すだけで、再インストール後に同じ動作へ戻せる保証にはなりません。

サブスクリプションURL、共有リンク、エクスポートしたファイルはすべて機密情報として保管してください。トラブルシューティング情報を共有する場合は、エラーの種類と関連する項目名を残しながら、識別情報、サーバーの認証情報全体、プライベートアドレスを隠します。ログにアクセス先やサブスクリプションのリクエスト内容が含まれることもあるため、そのまま公開しないでください。形式について他の人に相談する場合は、実際の接続情報を広めず、値を置き換えた構造の一部だけを示し、どの値を置き換えたか説明しましょう。

すべての条件を同時に変えず、種類ごとに更新

クライアント、コア、サブスクリプション、ルールデータの更新は、それぞれ別の操作です。クライアントの更新でメニューや設定生成の方法が変わることがあり、コアの更新で対応する項目が変わることもあります。サブスクリプションの更新は主に接続先情報を変更します。安定して動作している環境では、それぞれを分けて実施し、更新前にバックアップし、更新後に基本動作を再確認してください。すべてを一度に変更すると、問題が起きたときに原因を特定しにくくなります。復元の準備がないまま、更新頻度を優先して実行中のプログラムファイルを置き換えないでください。

クライアントを更新する前に正常に終了し、バックグラウンドプロセスがファイルを使用していないことを確認してください。その後、インストール形式に合わせて更新します。複数のインストール先がある場合は、実際にどのフォルダーのプログラムを起動しているか確認してください。古いショートカットから旧設定が読み込まれることがあります。更新後の初回起動では、画面が開くかどうかだけでなく、まずログを確認し、システムプロキシ、ルーティング、TUNをテストしてください。設定項目が移行されている場合は画面の説明を読み、従来のカスタム値を確認します。既定値が変わったことをリモート側の障害と混同しないでください。

ルールのデータにも有効期間があります。ドメインの分類やアドレス一覧が変更されると、以前の一致結果が変わる場合があります。しかし、特定の接続先に問題が起きたからといって、すべてのルールを出所不明のものに置き換えないでください。まず一致したルールを確認し、分類、名前解決、接続先自体の変更のどれが原因か判断します。長期間使っていない例外ルールは整理し、削除する前に理由を記録しておきましょう。ルールが増え続け、後から誰も優先順位を説明できなくなるのを防げます。

何度も再インストールせず、通信経路に沿って記録

トラブルの記録には、少なくとも発生時刻、影響を受けたアプリ、現在の入口方式、選択中の接続情報、エラー内容、直近の変更を含めてください。すべての接続先で失敗するのか、特定の接続先だけなのか。すべてのアプリで起きるのか、1つのアプリだけなのかをまず確認します。全体的な障害では、コアの起動、入口、基盤となるネットワークを優先して確認します。特定の接続先だけの障害では、ドメイン名、ルーティング、接続先サービスを調べます。接続先を何度も切り替えるより、範囲を絞るほうが再現可能な結論を得やすくなります。

ログレベルを上げるのは必要な間だけにし、原因を特定したら通常のレベルへ戻してください。出力が増えすぎると読みづらくなり、アクセス記録が長期間残るおそれもあります。認証エラーでは接続情報とシステム時刻を、ハンドシェイクエラーではセキュリティとトランスポートの設定を、接続拒否ではアドレス、ポート、サービスの到達性を優先して確認します。タイムアウトだけでは情報が限られるため、どの段階で失敗したかと合わせて判断してください。1つのエラーワードだけで、サーバー側かローカルネットワーク側か決めつけないでください。

9. 応用設定：設定を説明可能な実験にする

生成された設定の読み方から始める

応用設定に進むからといって、すぐにGUIを使わなくする必要はありません。まず、現在の設定からクライアントがどのようなインバウンド、アウトバウンド、ルールを生成しているか確認し、画面の項目と設定ファイルの対応を理解しましょう。生成ファイルは、次回の設定反映時に上書きされることが多く、長期的な編集場所としては適しません。カスタマイズする場合は、クライアントが明示的にサポートする方法を使い、項目の追加、部分的な置き換え、設定全体の引き継ぎのどれに当たるか確認してください。各モードの適用範囲は異なります。編集欄にテキストを入力できるというだけで、同じ方法として扱わないでください。

設定ファイルは決まった順序で読むと理解しやすくなります。まず、インバウンドがどのアドレスとポートを待ち受けているかを確認します。次にアウトバウンドのラベルとプロトコルを見てから、ルーティングがそれらのラベルをどう参照しているか調べます。その後、DNS、ログ、その他の補助モジュールを確認してください。実際の接続を1つ選び、その通信経路から読み始めれば、すべての項目を一度に理解する必要はありません。ファイルに項目がない場合でも、コアの既定動作を使っている可能性や、別のコンポーネントが処理している可能性があります。機能が無効だと単純に判断しないでください。

以下は構造を理解するための、完全なXray最小設定例です。ローカルのSOCKS入口を1つ作り、直接接続するもので、リモートプロキシは含まれません。インバウンドのラベル、ルーティングでの参照、アウトバウンドの関係を示すための例であり、使用中の完全なプロキシ設定を置き換えるものではありません。実行前にポートが使用中でないことを確認し、クライアントがサポートするカスタム設定の入口から使用してください。実行後の通信はローカルネットワークから直接行われます。これは例の想定どおりの動作です。

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

実験ごとに検証する問いを1つに絞る

有効な実験には、明確な問い、1つだけの変更、観察できる結果が必要です。たとえば、特定のドメインが直接接続ルールに一致するか調べる場合は、クライアントと接続情報を固定し、ドメインルールを1つだけ変更して、新しい接続で選ばれるアウトバウンドを確認します。DNSの変更、スニッフィングの有効化、トランスポート方式の変更を同時に行わないでください。失敗したらまず元の値に戻し、基準となる状態が正常に動作することを確認してから、次の仮説を試します。こうして得られるのは偶然動く複雑な設定ではなく、原因と結果の関係です。

学習は、ルールの一致判定、ドメイン名の解決、アプリの通信取り込み、LAN共有の順に進められます。それぞれをまず1台のデバイスで検証してから、利用範囲を広げてください。たとえばLANからの接続を許可する場合は、スイッチを1つオンにするだけでなく、待ち受けアドレス、ファイアウォール、クライアントと同じネットワークにあるかを確認します。ほかのデバイスには、PC自身のループバックアドレスではなく、LAN上のPCのアドレスを入力してください。PCのアドレスが変わった場合は、接続する側の設定も更新する必要があります。

LAN共有では、アクセス範囲にも注意が必要です。信頼できるネットワーク内で、必要なポートだけを開放してください。認証による保護がない入口を、信頼できないネットワークに公開しないでください。共有中もファイアウォールの制限を維持し、スリープ、切断、アドレス変更後の挙動を確認します。共有が不要になったら、関連する設定を無効にしてください。詳しい手順はLAN接続を許可する方法をご覧ください。まず待ち受けの範囲を理解し、長期間有効にするか判断しましょう。

プロトコルの違いを理解し、元に戻せる状態を保つ

プロトコルは、実際の設定項目とエラーが起きる段階を中心に学びましょう。VMessとVLESSでは認証、時刻要件、セキュリティの組み合わせが異なります。プロトコル名を変更するだけで変換できるわけではありません。トランスポート、セキュリティ、サーバー設定を一式で一致させる必要があります。まず現在の接続情報を理解してから、別の設定を調べてください。概要をすばやくつかみたい場合は、VMessとVLESSの違いをご覧ください。その後、実際のクライアントで対応状況を確認し、名前だけから機能全体を推測しないようにしましょう。

最終的な目標は、説明、検証、復元ができる設定です。各例外ルールが必要な理由、DNSクエリの経路、アプリがコアへ接続する方法、クライアント終了後にシステムをどう戻すかを把握しておきましょう。新しい要件が出たら、現在の基準状態に必要最小限の設定を追加し、検証してから残します。初回接続の手順はクイックスタートガイドで確認できます。インストール形式を選び直す場合はダウンロードセンターに戻ればよく、1つの問題を解決するために全段階をやり直す必要はありません。