REFERENCE / DESKTOP CONFIGURATION

V2Ray 応用設定ガイド

サブスクリプションのグループ分け、ルーティング、DNS、TUN、カスタムアウトバウンド。

初回接続後の設定を体系的に確認するためのページです。インストールからサブスクリプションの追加、プロキシの有効化までの手順は、まずクイックスタートガイドをご覧ください。インストーラーを選ぶ場合はクライアントのダウンロードへ。以下では主にデスクトップ版 v2rayN を例に説明します。画面上の名称はクライアントの更新により変わることがあります。設定の適用状況は、実際に生成されたコア設定、クライアントのログ、アプリの通信結果を確認してください。

サブスクリプションのグループ分けとサーバーの絞り込み

サブスクリプションの提供元とサーバー選択を区別する

サブスクリプションは、提供元から配布されるサーバー設定の集合です。グループは、クライアント上で設定を整理するための区分で、選択中のサーバーは実際の接続で使われる出口です。この3つは互いに置き換えられません。提供元ごとに別のグループへ分けておけば、更新に失敗した際に問題のある提供元を特定しやすくなり、似た名前のサーバーが同じ一覧に混在するのも防げます。サブスクリプションを追加するときは、まず識別しやすいグループ名を付け、URLを登録して手動で一度更新します。更新後は、成功メッセージの有無だけでなく、そのグループ内のサーバー数とプロトコルも確認してください。

v2rayNのサブスクリプション設定やサーバー一覧からグループを選択できます。画面のバージョンによって、グループがサイドバー、上部メニュー、サブスクリプション設定のいずれに表示されるかは異なります。操作の順序は同じです。グループを選択し、更新を実行して、一覧を絞り込んでからサーバーを選びます。更新後も古い項目が表示される場合は、更新したグループを正しく開いているか確認してください。グループの切り替えで変わるのは通常、一覧の表示範囲です。現在接続中のサーバーが自動で切り替わるとは限らないため、使用中の項目は別途確認します。一覧の先頭にあるサーバーが接続中だと思い込まないでください。

フィルタリングで変わるのは表示だけ

サーバーのフィルタリングは、項目数の多いサブスクリプションを扱うときに便利です。たとえば、サーバー名に含まれる地域名で候補を絞り、その後プロトコルや備考から目的の項目を見分けます。サーバー名は提供元が管理しており、命名規則も統一されていません。フィルターの語句はローカルな検索条件にすぎず、サーバーの所在地、稼働状況、安全性を示すものではありません。絞り込み後に項目が見当たらない場合は、更新時に削除されたと判断する前に、検索語を消してグループの絞り込みも解除してください。複数のサブスクリプションに同じ名前のサーバーがある場合は特に、検索結果だけを根拠にまとめて削除しないようにしましょう。

サーバーを比較するときは、同じテスト方法とネットワーク環境を使います。TCP接続テストで確認できるのは、接続確立の一部に限られます。Webページの読み込みには、TLSハンドシェイク、名前解決、ルーティング、接続先サービスの状態も影響します。1回の遅延測定の順位だけで安定性を判断すると、こうした違いを見落とします。まず遅延テスト方法の比較を確認し、候補のサーバーで実際にアクセスして比べてください。速度測定の結果は選択の参考情報です。長期間変わらない指標としてサブスクリプションの備考に記載するのは避けましょう。

ローカルでの変更範囲を明確にする

サブスクリプションに含まれるサーバーのアドレス、ポート、認証情報は提供元が管理しています。サブスクリプション管理下の項目を直接変更すると、次回の更新で変更が上書きされることがあります。サーバーを一時的に調整する場合は、まず独立したローカル項目として複製し、変更の目的を備考に記録してください。接続を確認してから、その項目を残すか判断します。複製した項目は、元のサブスクリプションと一緒に更新されません。元の項目と検証用の項目を区別しましょう。特に通信設定を調べるときは、一度に変更するパラメーターを1つに絞り、サブスクリプションの変更とローカルでの検証を混同しないようにしてください。

サブスクリプションの更新後に同名の項目が多数表示された場合は、すぐに削除せず、同じ提供元を重複して追加していないか確認します。2つのグループが同じサブスクリプションURLを参照しながら、異なる更新設定を使っている場合もあれば、提供元が同じ名前を繰り返し使っている場合もあります。グループの提供元と各項目の所属先を照合してから対処してください。グループを整理する前に、接続中のサーバーがどのグループに属しているか記録し、戻せる選択肢も用意します。一覧から項目を削除する操作と、サブスクリプションの提供元を削除する操作では影響が異なります。実行前にクライアントの確認メッセージをよく読んでください。

更新リクエスト自体が失敗する場合は、まずサブスクリプションURLにアクセスできるか確認し、現在のシステムプロキシが更新通信を利用できない出口へ送っていないか調べます。クライアントによっては、サブスクリプション更新用の接続方法を個別に指定できます。現在のネットワーク環境に合った方法を選んでください。エラーが名前解決や接続タイムアウトを示す場合は、まずネットワーク経路を解決します。更新は成功してもサーバーが追加されない場合は、返された内容がクライアントの認識するサブスクリプション形式か確認してください。エラーメッセージを確認せず、更新ボタンを何度も押すのは避けましょう。提供元への接続を復旧した後、再度更新し、項目の変化を確認して一連のトラブル対処は完了です。

複数サブスクリプションの管理と更新範囲

提供元をまとめず、用途ごとにグループを作る

複数のサブスクリプションを管理する際、困りやすいのは項目数の多さよりも、設定の提供元が分からなくなることです。利用する作業、端末、提供元の管理方法などに応じてグループを分け、それぞれに独自の名前と更新設定を持たせましょう。名前から提供元の違いが分かるようにし、「デフォルト」や「よく使う」だけで済ませないでください。2つのサブスクリプションに同名のサーバーが含まれていても、グループが識別の手掛かりになります。デスクトップ版では主に v2rayN を使います。Android版の v2rayNG と v2flyNG はそれぞれ独自にサブスクリプションを管理するため、デスクトップ版のグループがモバイル端末にも自動同期されるとは限りません。

新しい提供元を登録したら、まずそのグループだけを更新します。想定した数の項目が追加されたか、サーバーのプロトコルが認識されているか、以前から使っているサーバーが引き続き利用できるかを確認してから、自動更新を検討してください。初回登録時のミスと、後から発生した提供元側の変更を切り分けられます。自動更新の間隔は短ければよいとは限りません。頻繁にリクエストすると、失敗ログが増えて状況を把握しにくくなるほか、利用中に一覧が置き換わる可能性もあります。提供元の変更頻度が低い場合は、手動更新を行い、設定の変更前後に結果を確認するほうが追跡しやすいでしょう。

更新による変更範囲を把握する

サブスクリプションの更新では、その提供元に属するサーバーが追加、変更、削除されることがあります。クライアント全体の設定が元に戻るわけではありません。ローカルのルーティング、DNS、システムプロキシの状態、ほかのグループはそれぞれ個別に確認してください。反対に、ローカルのルーティングを変更してもサブスクリプションには反映されません。更新後にアクセスできなくなった場合は、サーバー設定が変わったのか、ルーティングやDNSも同時に変更したのかを切り分けます。以前は使えていたローカル項目を比較対象にし、更新ログと接続中の項目を確認すれば、クライアントを再インストールするより早く原因を見つけられることがあります。

提供元によっては項目名をそのまま使いながら、実際のアドレスや通信パラメーターを変更することがあります。そのため、「名前が変わっていない」ことは、設定に変更がない証拠にはなりません。複雑なルーティングを試している場合は、更新前にクライアント設定をエクスポートするか、機密情報を含まない変更記録を保存しておきましょう。更新後は、接続中サーバーが依存する設定項目を重点的に確認します。エクスポートした設定全体には、サブスクリプションURLやサーバーの認証情報が含まれる場合があります。管理された安全な場所に保存し、公開の場にそのまま貼り付けないでください。トラブル対処の情報を共有するときは、問題に関係する項目だけを切り出し、認証情報を削除します。

無効な提供元と重複項目への対処

ある提供元の更新が長期間失敗しても、それによってほかの提供元のトラブル対処が妨げられないようにします。まずURLにアクセスできるか、返された内容が空でないかを個別に確認し、その後、更新を一時停止するかグループを削除するか判断してください。一時停止と削除は異なる操作です。一時停止なら、比較用に既存のサーバーを残せます。削除すると、そのグループのローカル一覧も一緒に消えることがあります。削除する前に別の利用可能なサーバーへ切り替え、そのグループを使う自動選択やルーティングルールに依存が残っていないか確認してください。一度のネットワークタイムアウトだけで、サブスクリプションが恒久的に無効になったと判断しないでください。

サーバーの重複が必ずしも誤りとは限りません。同じ名前でもプロトコル、ポート、通信方式が異なる場合があります。同じアドレスでも、提供元によってパラメーターが違うことがあります。整理するときは表示名だけで一括削除せず、項目ごとに比較してください。本当に同じ提供元が重複している場合は、更新が安定し、内容が分かりやすいほうを残し、もう一方を更新対象から外します。作業後は一覧の絞り込みを解除し、接続中の項目が残したグループに属していることを確認してから、実際にアクセスしてください。この順序なら、「整理はできたが接続が切れた」という事態を避けやすくなります。

変更のたびに、グループ、実行した操作、接続中のサーバー、検証結果を1行にまとめて記録すれば十分です。サーバーの認証情報を記録する必要はありません。複数サブスクリプションを使う環境では、この記録により、どの更新から問題が始まったのか、元に戻すにはどのグループを選べばよいのかを確認できます。問題が特定の端末でだけ発生する場合は、両方の端末でサブスクリプションの更新時刻とローカルのルーティングを個別に確認してください。同じURLを使っていても、各クライアントの項目が常に同じ状態とは限りません。

ルーティングルールの実践：マッチ条件とアウトバウンドの順序

まず通信がクライアントに届いているか確認する

ルーティングルールは、コアに届いた接続をどのアウトバウンドに渡すかを決めます。クライアントに届いていないアプリの通信を、自動的にプロキシへ通す機能ではありません。システムプロキシを使うブラウザーは、通常、ローカルのHTTPまたはSOCKS入口にリクエストを送ります。システムプロキシに従わないプログラムは個別設定するか、TUNで通信を取り込む必要があります。ルールを書く前に、対象アプリの通信がどの入口を通るのか確認してください。そうしなければ、ルールが正しくても期待した結果は得られません。ルールのマッチングはドメインを識別できるかどうかにも左右されます。接続先IPしか分からない通信に対して、ドメイン分類を適用することはできません。

一般的なルーティングモードは、ルールに従うモード、すべてプロキシ経由にするモード、すべて直接接続するモードに分けられます。ただし、実際の挙動はクライアントが生成する設定にも左右されます。ルールに従うモードでは、通常、上から順にルールを確認し、条件に一致すると対応するアウトバウンドを使います。一致するルールがない通信はデフォルトのアウトバウンドに送られます。ルールを確認するときは、条件、順序、アウトバウンドの識別子、デフォルトの経路をあわせて見てください。広範囲に一致するルールを前に置くと、後続の詳細なルールが適用されなくなります。試すときは、内容を説明できる少数のルールから始め、異なる提供元のルールセットを一度にまとめて読み込まないようにしましょう。

明確なマッチ条件から始める

以下の断片では、ドメイン分類、特定ドメイン、LAN内アドレスの使い分けを示します。設定構造の例であり、クライアントで使うには、proxy と direct の2つのアウトバウンド識別子が存在すること、またコアにルールで使うドメイン分類データがあることを確認してください。geosite: は分類データに基づいてマッチし、文字列の部分一致検索とは異なります。domain: と full: ではマッチする範囲が異なります。特定の宛先を正確に指定する場合は、まず full: で確認するとよいでしょう。

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

AsIs は、ドメインルールで判定できるよう、ドメイン名を保持する動作です。名前解決後のアドレスで判定する場合は、選択したドメイン戦略でいつ名前解決が行われ、その結果がIPルールに渡されるかを理解しておきましょう。この設定を変えると、DNSリクエスト数とルールのマッチ結果の両方に影響することがあります。あるWebサイトへのアクセス結果だけで、すべての通信の挙動を判断しないでください。geoip:private はプライベートアドレス範囲を対象とします。LAN機器にアクセスできない場合は、このルールに加えて、DNSが返したアドレスと、システムがLAN通信をクライアントへ送っているかも確認してください。

比較しながらルールの競合箇所を特定する

新しいルールが適用されない場合は、まず前にあるルールがすでにマッチしていないか確認し、ルールで参照しているアウトバウンド識別子も照合します。ドメインルールがマッチしない場合は、リクエストがドメイン名付きで届いているか、アプリが先に独自で名前解決していないか、必要な分類データを利用できるかを確認してください。IPルールがマッチしない場合は、接続先アドレスとドメイン戦略の処理結果を確認します。ログに記録されたルーティング先は、「Webページが開かない」という情報より原因の特定に役立ちます。異なるレイヤーの問題を混同しないことも重要です。DNSの失敗は接続先への通信を始める前に起こります。一方、プロキシサーバーへの接続失敗は、接続先ドメインのルールとは無関係な場合があります。

特定のサイトを一時的にテストする場合は、正確なドメインルールを広範囲な分類ルールより前に置き、元の順序を記録しておきます。テスト後は順序を元に戻し、直接接続する宛先、プロキシ経由の宛先、LAN内アドレスをそれぞれ確認してください。そのうち一種類だけ失敗するなら、該当するアウトバウンドやルールを調べます。すべて失敗する場合は、通信の入口とシステムプロキシの状態を優先して確認します。接続テストと実際のアクセスの違いについては、遅延テストの解説を参照してください。速度測定に成功しても、そのテストで使われた経路の一部が動作したことしか分からず、すべてのルーティング分岐が正しいとは限りません。

ルールセットを更新するときは、ファイルが読み込まれたかだけでなく、分類の意味や対象範囲にも注意してください。広範囲な分類が、個別に処理する予定のドメインまで含むことがあります。アクセス結果が急に変わったら、サーバーを変更する前に、最近更新されたルールとマッチ順を確認します。重要な宛先には診断用の正確なルールを用意しておくと、多数の例外を積み重ねるより管理しやすくなります。ルーティング設計では、各ルールが何にマッチし、どの出口を使うのか説明できることが大切です。ルール数を増やすこと自体を目的にしないでください。

DNS設定の最適化と名前解決の経路

名前解決・ルーティング・接続を分けて確認する

DNSはドメイン名をアドレスに変換しますが、プロキシクライアントでは、どこが名前解決を行うか、リクエストがどの出口を通るか、結果がルーティング判定に使われるかも決める必要があります。ブラウザーでサイトを開けても、すべてのアプリが同じDNSを使っているとは限りません。アプリが独自の名前解決方式を使う場合や、古い結果をキャッシュしている場合があります。トラブル対処では、まず対象アプリの接続方法を記録し、クライアントのログにあるドメイン名、名前解決エラー、アウトバウンドの選択を確認します。通信の入口を把握しないまま、システムDNS、クライアントDNS、ルーティングモードを一度に変更しないでください。どの変更で結果が変わったのか分からなくなります。

v2rayNでは、画面上の設定が最終的なコア設定へ変換されることがあります。DNS設定を保存したら、コアが再読み込みされたことを確認し、生成された設定の dns と routing を確認してください。システムプロキシモードが主に処理するのは、プロキシ設定に従うアプリです。OS自身のDNSリクエストがプロキシ入口を通るとは限りません。TUNモードはより広い範囲を取り込めますが、アプリ独自の名前解決方式の影響を受ける場合があります。つまり、「システムプロキシを有効にした」だけで、すべてのDNSをクライアントが処理するわけではありません。実際の経路を判断するには、リクエストがコアに届いているか、コアがどのアウトバウンドに渡しているかを確認します。

使用するDNSサーバーを明確に指定する

以下は、Xrayコア設定のDNSフィールドを簡略化した例です。予備の問い合わせ先と、特定ドメインに適用するルールの構造を示しています。例のアドレスはフィールド間の関係を説明するためのものです。実際に使う際は、ネットワーク環境に応じて、到達可能で要件に合ったDNSサービスを選んでください。LAN内の名前、社内ドメイン、一般のドメインでは、異なる問い合わせ経路が必要になる場合があります。domains はDNSサーバーの適用範囲を決める項目で、対象ドメインの最終的なプロキシ出口を指定するものではありません。

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:private"]
      },
      "1.1.1.1"
    ]
  }
}

LAN機器がローカルの名前解決サービスを利用している場合、すべての問い合わせをパブリックDNSへ送ると、内部名を解決できなくなることがあります。反対に、内部名しか認識しないDNSにすべての一般ドメインを送ると、タイムアウトの原因になります。このような問題では、対象ドメインとLAN内の名前をそれぞれテストし、どちらで障害が起きるか確認してください。DNSサーバーのアドレスへ、想定した出口から接続できるルーティングルールかどうかも確認します。DNSサーバー自体に接続できない場合、ドメインのマッチ条件を変更してもネットワーク経路は直りません。

キャッシュと重複した名前解決による誤判定を防ぐ

DNSを変更した後も、既存の接続やアプリのキャッシュが以前のアドレスを使い続けることがあります。検証するときは対象アプリの接続を閉じてからリクエストを再送し、必要に応じてシステムのキャッシュとブラウザーの挙動を個別に確認してください。ページを再読み込みするだけでは不十分な場合があります。名前解決できてもアクセスできない場合は、解決された宛先アドレスを記録し、ルーティングで直接接続とプロキシのどちらが選ばれたか確認します。ブラウザーだけが失敗し、ほかのアプリは正常なら、ブラウザー独自のプロキシ設定やセキュアDNSを確認してください。コマンドラインツールだけが失敗する場合は、環境変数とローカルのSOCKS/HTTPポートを確認します。

DNSとルーティングには、もう1つよくある接点があります。IP分類ルールにはアドレスが必要で、ドメイン分類ルールには識別可能なドメイン名が必要です。名前解決が早すぎると、適用する予定だったドメインルールの条件が失われることがあります。反対に、まったく名前解決を行わなければ、アドレスに基づく判定ができません。ドメイン戦略を選ぶ前に、ドメイン分類が必要な宛先とIP分類が必要な宛先を明確にし、生成された設定の実際の挙動を確認してください。どのネットワークでも使える固定の正解があるとは考えないでください。

設定を変更した後は、安定して使えるテスト対象をいくつか用意します。LAN内の名前、明示的に直接接続するドメイン、明示的にプロキシ経由にするドメインです。それぞれについて、名前解決の成否と接続に使われたアウトバウンドを記録してください。サブスクリプションやルールセットを更新した後も、同じ対象で再テストします。これにより、変化が名前解決、ルールのマッチング、リモート接続のどの段階で起きたかを確認できます。問い合わせに成功しても期待と異なるアドレスが返る場合は、ローカルネットワークのDNS結果、アプリのキャッシュ、ドメイン適用ルールを確認してください。1回ページを開けなかっただけで、DNSの仕組み全体を変更しないようにしましょう。

TUNモードとシステムプロキシの使い分け

通信の取り込み方法を選ぶ

システムプロキシは、この設定に対応したアプリにローカルプロキシの入口を通知します。ブラウザーや一部のデスクトップアプリはその入口へ接続しますが、すべてのプログラムがシステムプロキシを参照するわけではありません。TUNモードでは仮想ネットワークインターフェースを作成し、対象範囲内のIP通信をクライアントに取り込みます。より多くのアプリを対象にできる一方、ルーティングテーブル、仮想インターフェース、DNSの取り込み、権限など、追加の要因も発生します。まずシステムプロキシでサーバー、サブスクリプション、基本的なルーティングを確認してください。アプリがシステムプロキシを使っていないことが分かった場合や、より広い範囲の取り込みが必要な場合に、TUNを有効にします。

デスクトップ版 v2rayN のTUN設定は、システム権限や追加のネットワークコンポーネントを必要とすることがあります。実際の設定画面はOSやクライアントのバージョンによって異なります。有効にする前に、接続中のサーバー、システムプロキシモード、DNS設定、ルーティングモードなど、現在正常に動作している状態を記録してください。起動時は、スイッチがオンかどうかだけでなく、仮想インターフェースの作成に成功したというクライアントの報告を確認します。OSによっては、ネットワーク拡張機能や管理者権限の許可が必要です。権限を拒否した後でスイッチを何度も切り替えても、インターフェースの作成失敗は解決しません。まずログに示された権限やコンポーネントの問題に対処してください。

プラットフォームごとにネットワーク環境を確認する

プラットフォーム重点的に確認する項目無効化後に確認する項目
Windows仮想ネットワークコンポーネント、起動時の権限、既存のネットワークツールによるルーティングシステムプロキシとデフォルトのネットワーク接続
macOSシステムネットワーク権限、仮想インターフェースの状態、現在のネットワークサービスネットワークサービスとDNSの状態
LinuxTUNデバイスの権限、ルーティングテーブル、ファイアウォールルールデフォルトルートとローカルでの名前解決

表にあるのはトラブル対処の観点であり、どのOSにも同じコマンドを適用できるという意味ではありません。ほかの仮想ネットワークツールが動作中の場合、複数のプログラムがデフォルトルートやDNSを同時に変更しようとすることがあります。その場合は、まず各ツールを個別に終了し、v2rayNだけを起動して確認してください。システムプロキシモードでは使えるアプリが、TUNに切り替えると使えなくなる場合は、すぐにサーバーを変更せず、両モードの通信入口とDNS経路を比較します。サーバーは同じで通信の取り込み方だけが変わったのであれば、ローカルネットワークを取り込む部分に問題がある可能性が高いでしょう。

取り込み範囲を最小限で検証する

TUNを有効にしたら、まず一般のWebページ、LAN内機器、これまでシステムプロキシに従わなかったアプリをテストします。この3種類はそれぞれ異なる原因を示します。Webページの失敗には名前解決やデフォルト出口、LAN接続の失敗にはプライベートアドレスが誤ってプロキシに送られていること、特定アプリの失敗には独自のネットワークスタックやプロトコルが関係する場合があります。テスト中は接続中のサーバーを変えないでください。TUNのスイッチだけで問題を再現できる場合は、サブスクリプションを再登録するのではなく、インターフェースの起動ログ、ルーティングテーブル、DNSの状態を確認します。

TUNを有効にしても、ほかのプログラムがローカルプロキシの入口を使う場合があります。ただし、同じアプリに複数の接続方法を重ねて設定するのは避けてください。アプリに手動SOCKSを設定したうえでTUNでも取り込むと、通信経路を特定しにくくなります。トラブル対処中は入口を1つに絞り、正常に動作することを確認してから、アプリごとの設定を戻すか決めましょう。ターミナルのプログラムも同様です。環境変数がローカルのHTTPまたはSOCKSポートを参照したままになっていないか確認します。TUNを停止した後は、仮想インターフェースとそのルートが削除されたことを確認し、システムネットワークが正常に戻ったか調べてください。

TUNを無効にした後もネットワークに接続できない場合は、停止したローカルポートをシステムプロキシが参照したままになっていないか、DNSが到達できないアドレスを使っていないか、デフォルトルートが復旧したかを順に確認してください。ネットワーク設定を一度にすべてリセットせず、残っている変更を先に特定します。職場と自宅のネットワークを頻繁に切り替える端末では、LANへの接続をそれぞれのネットワークでテストしてください。プライベートアドレスや内部DNSの構成は異なる場合があります。TUN設定の完了は、スイッチがオンになることではありません。取り込み範囲、LANの例外、無効化後の復旧動作を予測できることが大切です。

FakeDNSの用途と制限

合成アドレスの役割を理解する

FakeDNSは、対応する通信経路でドメイン名の問い合わせを受けると、一時的な合成アドレスを返し、そのアドレスと元のドメイン名の対応を保存します。その後、アプリが合成アドレスへ接続すると、コアは保存した対応関係から元のドメイン名を復元し、ドメインルールによるルーティングを続けられます。これは一部の通信経路でドメイン名の情報が失われる問題に対処する機能であり、あらゆるDNSサーバーに代わるパブリックな名前解決サービスではありません。合成アドレスは接続先サイトの実際のアドレスでもありません。クライアントを経由しない別のネットワークツールにそのアドレスを入力しても、同じ結果が得られるとは限りません。

FakeDNSを有効にする前に、現在の問題が本当にドメインルールでドメイン名を認識できないことなのか確認してください。ログにすでに接続先のドメイン名が記録され、ルールも正常にマッチしているなら、FakeDNSを追加すると設定が複雑になるだけです。典型的な確認順は、アプリの通信がコアに届いていること、DNSリクエストも対象の経路で処理されていること、その後のアプリの接続が再びコアを通ることです。DNS問い合わせだけを取り込んで後続の接続を取り込まない場合や、接続だけを取り込んでシステムの別のDNSが実アドレスを返す場合は、対応関係の連鎖が完成しません。

アドレスプールとルーティングを確認する

以下はXrayのFakeDNSアドレスプールの構造例です。fakedns フィールドだけの例であり、クライアント設定全体ではありません。IPv6アドレスプールを使うかどうかは、現在の通信取り込み方式とネットワーク環境に合わせてください。例のアドレスプールが実際に使っているネットワークと競合しないようにする必要があります。該当するDNSリクエストをFakeDNSへ送り、合成アドレスへの後続接続もクライアントが取り込むようにしてください。この部分を追加しただけでは、通信の入口を設定していない限り機能しません。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

アドレスプールを決めるときは、現在のネットワークと、ほかの仮想ネットワークツールが使うルーティング範囲を確認してください。合成アドレスが既存の業務用ルートの範囲に入ると、アプリの接続が誤ったインターフェースへ送られることがあります。検証中は元のDNS設定とTUN設定を保存し、FakeDNSに関係する設定を一度に1つだけ有効にします。有効にしたら、ドメイン名を使う宛先とIPアドレスを直接指定する宛先をそれぞれテストしてください。FakeDNSは主にドメイン名とアドレスの対応付けに使うため、すべてのIP接続の問題をFakeDNSのせいにしないでください。誤った名前解決経路で内部サービスにアクセスできなくなるのを防ぐため、LAN内の名前もテストします。

対応関係の消失とアプリの挙動を調べる

アプリが古い合成アドレスを長期間キャッシュしていると、クライアントの再起動後や対応関係が変わった後に、一時的に接続できなくなることがあります。まずアプリに名前解決をやり直させ、新しいリクエストが想定した入口を通るか確認してください。アプリによっては独自の名前解決を行ったり、固定IPへ直接接続したりするため、FakeDNSの効果が限られることがあります。特定のアプリだけ失敗する場合は、そのアプリのネットワーク設定とDNSの挙動を確認します。すべてのドメインで失敗する場合は、DNSの取り込みとコアのログを確認してください。ブラウザーに表示されたアドレスだけで対応関係の正しさを判断せず、コアが接続先のドメイン名を復元できているかを確認します。

ドメイン分類ルールとFakeDNSを組み合わせる場合は、ルールの順序に注意してください。合成アドレスが広範囲なIPルールに先に処理されると、想定していたドメインによる振り分けが適用されないことがあります。ログでは、問い合わせ、対応関係の復元、ルールのマッチ、アウトバウンド接続の4段階を個別に確認します。欠けている段階があれば、その段階の入口と設定を優先して調べてください。DNSが合成アドレスを返したことから分かるのは、問い合わせ処理が動作したという点だけです。最終的に目的の接続ができるかどうかは、後続の通信がコアに届き、アウトバウンドから接続先へ到達できるかにも左右されます。

通常のDNSと既存のルーティングで安定して使えるなら、設定はシンプルなままにできます。FakeDNSはドメイン名を認識できない特定の問題に対処するための機能であり、常に有効にしておくべきパフォーマンス設定ではありません。使い続ける場合は、アドレスプール、通信の取り込みモード、テストしたアプリ、元に戻す方法を記録してください。TUNやDNSを変更したときは、経路全体をあらためて確認します。無効にする場合も、アプリに名前解決をやり直させてください。キャッシュされた合成アドレスが残ると、以前からのキャッシュを無効化後の新しい障害だと誤認することがあります。

カスタムアウトバウンドとルールからの参照

アウトバウンドはルーティングの出口

アウトバウンドは、コアから通信を外へ送る方法を定義します。一般的な freedom アウトバウンドは直接接続に、blackhole アウトバウンドは通信の遮断に使います。プロキシサーバー向けアウトバウンドの接続方法は、サーバーのパラメーターで決まります。ルーティングルールでは、outboundTag を使ってアウトバウンドの tag を参照します。カスタムアウトバウンドを追加するときは、識別子が一意か、ルールが正しく参照しているか、デフォルトのアウトバウンドが想定どおりかを確認してください。用途が分かる名前を付けると、曖昧な番号を使うよりログを調べやすくなります。

v2rayNは通常、選択したサーバーに応じてプロキシアウトバウンドを生成します。生成済みのファイルを直接編集しても、サーバーの切り替え、サブスクリプションの更新、コアの再起動後に変更が消えることがあります。カスタム動作を長期間維持するには、クライアントが提供するカスタム設定やマージ機能を使い、保存後に最終的な生成結果を確認してください。設定の追加方法によって、フィールドのマージ方法が異なります。配列全体を置き換えるものもあれば、特定の部分だけを変更するものもあります。作業前に元の設定をバックアップし、変更後はまずJSON構造がコアに受け入れられることを確認してから、実際の通信を検証してください。

確認しやすい直接接続と遮断の出口を用意する

以下の断片は、2つのアウトバウンドと1つの正確なドメインルールの参照関係を示します。プロキシサーバーのパラメーターやインバウンドは含まれていないため、単独で動作する完全な設定ではありません。例のドメイン名はルール構造を説明するためのものです。特にトラブル対処中は、通信を遮断するルールを慎重に使ってください。範囲の広すぎるルールがDNSサービスや業務用インターフェースに先にマッチすると、後続のルールでは接続を元に戻せません。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "blocked"
      }
    ]
  }
}

カスタムアウトバウンドをテストするときは、まず正確な条件のルールを1つ使い、ログに想定したアウトバウンド識別子が表示されることを確認します。その後でマッチ範囲を広げてください。遮断ルールにマッチすると、アプリではタイムアウトや接続失敗として現れることがあります。その結果からプロキシサーバーの障害だと判断することはできません。直接接続ルールがマッチしても、ローカルDNSやネットワークの状況によって接続先に到達できない場合があります。正しいアウトバウンドが選ばれたことは、通信がその出口へ渡されたことを示すだけです。接続先まで通信できるかどうかは別に確認してください。

サーバーとアウトバウンドの識別子が重複しないようにする

クライアントで接続中のサーバーを切り替えると、自動生成されるプロキシアウトバウンドの内容が変わることがありますが、ルールから参照する識別子は解決可能な状態に保つ必要があります。独自のアウトバウンドを追加する前に、最終設定にすでにある識別子を確認し、定義が重複しないようにしてください。同じ識別子が重複するとログの解釈が難しくなり、ルールが想定外の出口に適用されることもあります。カスタムのプロキシ出口を複数使う場合は、一般の宛先用と特定ルール専用の出口を明確にし、参照先のサーバー設定が残っているか確認します。実際のサーバーアドレスや認証情報を公開用の例にコピーしないでください。

接続経路にあるローカルSOCKS入口も、アウトバウンドとは分けて考える必要があります。入口はアプリの通信を受け取るもので、リモートサーバーではありません。以下の断片では、待ち受け範囲とポートのフィールド位置だけを示します。待ち受けアドレスをローカルに限定すれば、意図せずLANにプロキシ入口を公開するのを防げます。実際のポート番号は、クライアント画面と、そのポートを使うアプリの設定に合わせてください。ポートがほかのプロセスに使用されている場合、コアを起動できないことがあります。対処方法はローカルポートの競合に関する解説を参照してください。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

カスタム設定を元に戻すときは、まず追加したルールを無効にし、それらのルール専用のアウトバウンドを削除してから、コアを再読み込みしてください。先にアウトバウンドを削除すると、有効なルールが存在しない宛先を参照してしまいます。元に戻した後は、直接接続する宛先とプロキシ経由の宛先をそれぞれテストし、デフォルト経路にルールが残って影響していないか確認します。クライアントが起動しない場合は、エラーが示すフィールドや識別子を確認してください。エラーが残ったまま、新しい設定を追加し続けないでください。設定が大きくなるほど、追加する各ルールに明確な目的と個別の検証結果が必要です。

設定の検証、ロールバック、日常のメンテナンス

通信経路に沿ってトラブル対処する

応用設定には複数のレイヤーが関わるため、接続経路に沿って順に確認します。アプリが通信をクライアントへ渡しているか、ローカル入口が起動しているか、DNSで期待した結果が得られたか、正しいアウトバウンドが選ばれたか、その出口から接続先へつながるか、という順です。前の段階を飛ばしてサーバーを切り替えると、状況が一時的に変わっても元の問題は特定できません。観察できる変数を一度に1つだけ変更し、同じ接続先で変更前後の結果を記録してください。すべてのアプリからアクセスできない場合は、まずクライアントの起動状態とシステムプロキシを確認します。特定のドメインだけ失敗する場合は、DNSとルールを調べてください。

ログはWebページのエラーより具体的な手掛かりを示しますが、操作した時刻と合わせて読む必要があります。問題を一度はっきり再現してから、その時間帯の入口、名前解決、ルーティング、接続の記録を確認してください。起動時にクラッシュしたりコアが読み込まれなかったりすると、接続先への通信ログはすべて残りません。その場合は実行環境とシステム権限を確認し、起動時のクラッシュ対処も参照してください。ログに対象リクエストがない場合は、ドメインルールを変更する前に、アプリのプロキシ設定やTUNの取り込み範囲を見直します。

再現可能なテスト項目を決める

次の4種類のテスト対象を固定することをおすすめします。一般のWebページ、ルール上は直接接続する宛先、ルール上はプロキシ経由にする宛先、LAN内サービスです。それぞれについて「アプリの入口、DNSの結果、マッチしたルール、アウトバウンド、最終結果」を記録し、「開ける／開けない」だけで済ませないようにします。DNSを変更した場合は、名前解決とその後の接続を比較します。ルーティングを変更した場合は、マッチしたルールとアウトバウンドを比較します。TUNを変更した場合は、リクエストがクライアントに届いているかを比較してください。テスト対象を変えなければ、結果を比較しやすくなります。

現象まず確認する項目次に行うこと
ログに対象リクエストがないアプリのプロキシ設定、システムプロキシ、TUNの取り込み範囲ローカル入口が待ち受け状態か確認する
ドメインの名前解決がタイムアウトするDNSサーバーとそのネットワーク出口ドメインの適用ルールを確認する
ルーティングの出口が想定と異なるルールの順序とマッチ条件アウトバウンド識別子を確認する
出口は正しいが接続に失敗するアウトバウンドからの接続と接続先への到達性選択中のサーバーの状態を確認する

この表はトラブル対処の出発点であり、現象だけから原因を断定するものではありません。たとえば、名前解決に成功していても、ルーティングで誤った出口が選ばれる場合があります。出口が正しくても、接続先ネットワークやサーバーとの接続に問題があれば失敗します。1回の遅延測定だけでは実際のアクセスを判断できません。代表的な3つの測定方法が確認する範囲については、接続テストとダウンロード速度測定の比較を参照してください。判断する前に、テストで使ったサーバーと、ブラウザーでアクセスするときの出口が同じであることを確認します。

最小限のロールバック手順を用意する

変更を始める前に、現在正常に動作している状態を保存します。接続中のサーバーが属するグループ、ルーティングモード、DNS設定、TUNの状態、追加したカスタム設定などを記録してください。設定項目の記録だけで十分です。認証情報を含む設定全体のエクスポートは、安全に保管してください。変更後に問題が起きた場合は、変更と逆の順序で戻します。まず追加したルールや機能を無効にし、次にDNSと接続方式を復旧して、最後にシステムプロキシの状態を確認します。一度に1項目ずつ戻し、同じテスト対象で確認すると、どの変更が原因か特定できます。

クライアント、サブスクリプション、ルールデータの更新は、それぞれ別のイベントとして記録してください。影響する対象が異なります。クライアントの更新は画面や設定生成の仕組みを変えることがあり、サブスクリプションの更新はサーバー一覧を変え、ルールデータの更新は分類マッチに影響します。同じ日に3種類すべてを連続して更新すると、その後にルーティングの問題が起きても原因を絞れません。まず1種類だけ更新し、決めておいたテスト項目を実行して問題がないことを確認してから、次の更新へ進みます。デスクトップ版またはAndroid版のクライアントが必要な場合は、ダウンロードページから対応するプラットフォームを選んでください。ダウンロード作業をルールのトラブル対処に混ぜないようにしましょう。

問題を他の人に説明するときは、OS、クライアント名、通信の取り込み方法、障害が起きた段階、関連するエラーメッセージ、実施済みの比較テストを伝えてください。v2rayN、v2rayNG、v2flyNGでは画面やコアの選択肢が異なるため、使用しているクライアントを明記します。ログを共有する前に、サブスクリプションURL、サーバーの認証情報、個人のネットワーク情報をマスキングしてください。初回の登録や接続で問題が起きた場合は、クイックスタートガイドに戻り、基本手順を確認します。サブスクリプション、ルーティング、TUNを組み合わせた設定の問題は、このガイドに沿って段階ごとに範囲を絞り込みます。

v2rayNをダウンロード