V2Ray 上級設定ガイド

CHAPTER 01 / BASELINE

設定の基準：クライアント、コア、システムネットワークを分けて考える

上級設定で起こりやすい問題は、パラメータの入力ミスではなく、異なるレイヤーの設定を混同することです。v2rayN、v2rayNG、v2flyNGはサブスクリプションのインポート、サーバー選択、設定生成、接続状態の制御を担うGUIクライアントです。XrayやV2Flyなどのコアは、プロトコル、ルーティング、DNS、アウトバウンドの処理を実行します。システムプロキシ、仮想NIC、アプリ自身のネットワーク設定は、通信が実際にコアへ入るかどうかを決めます。切り分けでは、まず障害がどのレイヤーにあるかを確認してください。そうしないと、サーバーを何度も替えて症状を隠すだけになります。

復元できる設定の起点を作る

調整を始める前に、クライアントで現在利用できる設定をエクスポートするか、サブスクリプションの取得元、使用中のサーバー、プロキシモード、ルーティング方式、DNS設定を記録します。v2rayNのサブスクリプション情報、サーバー一覧、ルーティング方式はクライアントが管理するデータです。一方、コアの実行時設定は画面の選択内容によって変わるため、一時的なJSONの一部だけを完全なバックアップとして扱うべきではありません。モバイル端末では、VPNサービス、アプリごとのプロキシ、LANバイパスの有効状態も記録してください。これらは実際の通信範囲を変えます。

設定の基準は3つの条件を満たす必要があります。通常のブラウザーが想定どおりネットワークへアクセスできること、クライアントログに起動エラーが繰り返し出ていないこと、選択したサーバー項目に完全なアドレス、ポート、ユーザー識別子、転送方式、セキュリティパラメータが含まれていることです。基準が利用可能であって初めて、ルーティングとDNSの比較に意味が生まれます。基本接続がまだ完了していない場合は、入門ガイドに戻り、サブスクリプションのインポート、サーバー選択、接続開始、通信確認の順で進めてください。

ログを読むときは最初のエラーを探す

コアのログでは、同じ障害の後に複数のメッセージが続けて出力されることがあります。本当に重要なのは、起動後に最初に現れる設定エラー、名前解決エラー、接続エラーです。たとえば、ルーティングルールが存在しないアウトバウンドタグを参照していると、その後の接続がすべて失敗します。DNSサーバーに到達できなければ、後続の症状はドメインのタイムアウトとして現れることがあります。システムプロキシが有効でなければ、クライアントログに該当リクエストがまったく出ない場合もあります。最後の行だけを見たり、通常の接続終了記録を根本原因とみなしたりしないでください。

「クライアントがコアを起動したか—リクエストがローカルの入口に入ったか—ドメインの名前解決が完了したか—ルーティングが想定したルールに一致したか—対象アウトバウンドが接続を確立したか」の順に確認するのがおすすめです。クライアントがコアを起動していない場合は、設定生成とポート競合を確認します。リクエストがローカルの入口に入っていない場合は、システムプロキシ、ブラウザー独自のプロキシ、TUNの状態を確認します。ドメインだけが失敗し、IPアドレスへの直接アクセスに応答がある場合は、DNSを重点的に調べます。一部のサイトだけ経路が誤る場合は、ルーティングの順序とドメイン集合を確認します。

パラメータの出所と優先順位

サブスクリプションはサーバー接続パラメータを提供し、クライアントはローカルの上書き項目を保存します。ルーティングとDNSの方式が実行ロジックを決め、システムネットワークが通信の入口を決めます。サブスクリプションの更新でサーバー項目が再構築されることがあるため、長期的なルールを1つのサーバーのメモだけに書くのは適切ではありません。継続して保持するグループ、フィルター、ルーティング方針は、クライアントのサブスクリプション設定、ルーティング方式、または独立した設定に置きます。元の設定を編集する場合は、次回起動時にクライアントが上書きしないことを先に確認してください。

この章を終えると、現在の問題がデータ管理、コアの実行、システムによる通信の引き継ぎのどれに属するかを判断できるようになります。この判断によって、次に使うべき手段が決まります。サーバー項目が混乱しているならサブスクリプション、アクセス先の経路が違うならルーティング、ドメインに異常があるならDNS、システムプロキシに従わないアプリだけを接続したい場合に限りTUNを検討します。レイヤーを分けて考えることが、本ガイドの設定を安定して再現する前提です。

CHAPTER 02 / GROUPS

サブスクリプショングループとサーバーフィルター

1つのサブスクリプションにも大量の項目が含まれることがあります。すべてのサーバーを1つの一覧に並べると、選択、更新、トラブルの切り分けが次第に難しくなります。グループ化の目的は複雑な階層を作ることではなく、「データの取得元」「項目の用途」「一時的に隠す内容」を分けて示すことです。v2rayNはデスクトップで複数のサブスクリプションをまとめて整理するのに適しています。v2rayNGとv2flyNGをモバイルで使う場合は、切り替えの負担を減らすため、意味が明確で少数のグループに絞るとよいでしょう。

まず取得元で分け、次に用途で絞り込む

サブスクリプションの取得元は、最も安定した第1レベルの境界です。各取得元に「日常用」「テスト用」「予備用」などの明確な名前を付け、地域、プロトコル、倍率、用途を1つのグループ名に詰め込まないでください。取得元ごとに分けると、更新失敗の影響範囲を判断しやすくなり、使えなくなった取得元だけを停止できます。用途はメモのキーワードとフィルター条件で処理するのが適しています。たとえば名前に「オフィス」や「低倍率」を含む項目を残し、「期限切れ」「残量」「公式サイト」などの通知用項目を隠します。

フィルターには通常、残す方向と除外する方向があります。残すルールは「日本」や「シンガポール」を含むサーバーだけを表示するなど、明確な小集合に適しています。除外ルールは通知項目や一時的に使わないプロトコルの整理に向いています。両方を使う場合は、クライアントの処理順を確認してください。一般的には、サブスクリプションから全項目を取得してから絞り込みます。フィルターはクライアントの一覧表示またはインポート結果だけを変え、リモート側のサブスクリプション自体は変更しません。

正規表現フィルターを安全に書く

通常のキーワードで条件を表現できない場合は、正規表現を使えます。地域名は縦線で「いずれか」を表し、通知語もまとめて除外できます。正規表現は短く保ち、まず少数の項目で検証してください。複雑な先読みやバックトラッキング条件は保守しにくく、クライアントごとの実装差によって結果が変わる可能性もあります。

残す例：
日本|東京|シンガポール|アメリカ

除外例：
期限切れ|残量|告知|URL|トラフィック

地域の一般的な接頭辞に完全一致：
^(日本|シンガポール|アメリカ)[-_ ]

中国語、英語の略語、旗の記号がメモに同時に現れることもあります。サブスクリプション名が統一されていない場合は、まず一覧全体を確認してからキーワードを決め、ネット上の長い正規表現をそのまま使わないでください。フィルター後に項目が突然ゼロになったら、まず条件を空にして元のサブスクリプションが正常か確認し、その後に正規表現を少しずつ戻します。一部の名前だけ一致しない場合は、全角スペース、ハイフン、大文字・小文字の違いを確認します。

速度測定の結果だけで可用性を判断しない

サーバーの絞り込みは速度測定と併用されますが、遅延テストが示すのは、特定の探測リクエストが到達できたかどうかだけです。実際のプロトコル接続、対象サイトへのアクセス、継続的な転送性能を完全に表すものではありません。TCPで到達できても認証パラメータが正しいとは限らず、1回の遅延が低くても混雑時に安定するとは限りません。まず明らかに接続できない項目を除外し、候補回線は実際のアクセスで検証してください。1つの数値だけで恒久的に並べ替えるべきではありません。

より安定した手順は、1つのサブスクリプションを更新して項目数とメモの構造を確認し、除外ルールを適用して通知項目を整理し、少数の候補サーバーで接続テストを行い、そのうち1つを起動して普段使う対象へアクセスし、最後に現在のネットワークに適した順序を保存することです。ネットワーク環境が変わったら再測定し、古い結果を固定的な属性として扱わないでください。ノード速度測定の誤差や判断方法については、サイト内の記事一覧にあるトラブルシューティング記事も参照できます。

更新後の差分チェック

サブスクリプション更新後は、少なくとも3点を確認します。取得元の名前が元のグループと対応しているか、サーバーのメモが変わってフィルターが無効になっていないか、現在使用中のサーバーが置き換えられたり削除されたりしていないかです。提供側が命名形式を変更すると、古いキーワードによって新しい項目がすべて除外されることがあります。その場合はまずフィルターを無効にして元の結果を確認し、正規表現を更新してください。取得元の1つが更新に失敗しても、すぐに全サブスクリプションを上書き更新しないでください。リンクの状態、既存の接続経由で更新する必要があるか、返された内容がクライアントで認識できる形式かを個別に確認します。

グループ化の完成基準は、一覧が整って見えることではありません。現在のサーバーがどのサブスクリプション由来か、なぜそのフィルター結果に現れるのか、更新に失敗したときどの取得元を操作すべきかの3点に答えられることです。これらが明確なら、複数サブスクリプション管理とルーティングの紐付けに安定した基盤ができます。

CHAPTER 03 / MULTI-SUBSCRIPTION

複数サブスクリプション管理と更新方針

複数のサブスクリプションがある場合、主なリスクは項目数ではなく、取得元同士の上書き、重複名、更新タイミングの衝突です。適切な構成では、各取得元を個別に更新、停止、トラブルシューティングでき、不要な場所にサブスクリプションURLを複製しません。デスクトップでは通常、v2rayNを集中管理の入口にします。Androidでは外出先で使う取得元だけをインポートし、更新のたびに大量の重複サーバーを処理しないようにします。

取得元ごとに独立した識別情報を持たせる

サブスクリプションを追加するときは、完全なURLを露出させるのではなく、「メインデスクトップ」「モバイル予備」「プロトコルテスト」のように用途を名前で示します。2つの取得元に同名サーバーが含まれる可能性がある場合は、サブスクリプション名に短い接頭辞を加え、クライアントが提供する取得元識別子も残します。サーバーのメモは変わっても、サブスクリプションの識別情報は変えないでください。「サブスクリプション1」「サブスクリプション2」のように出所を思い出せない名前や、長期名称として現在の日付を使うのも避けます。

同じURLを複数のグループに重複登録しないでください。重複した取得元は更新後に似た項目を生成し、選択時に実際の所属を判断できなくなります。重複に気づいたら、まずURLと更新日時を比較し、管理記録を1つだけ残します。クライアントがサブスクリプション単位でサーバーを削除できる場合は、全体一覧から1件ずつ削除するのではなく、取得元単位の操作を使います。そうしないと次回更新で再びインポートされる可能性があります。

更新順序を決め、失敗を分離する

安定した方法は、現在使用中のメイン取得元を先に更新し、接続できることを確認してから予備の取得元を順番に更新することです。すべてを並列更新すると操作は減りますが、どれか1つが異常な内容を返したときに原因を特定しにくくなります。自動更新間隔を短くしすぎないでください。サブスクリプションの内容は通常リアルタイムの状態情報ではなく、頻繁なリクエストで回線自体が安定するわけではありません。自動更新を使う場合は日常的な変更をカバーできる周期を選び、障害復旧用に手動更新の入口も残します。

更新失敗は4つの方向から判断できます。URL自体が無効、現在のネットワークからURLへ直接アクセスできない、サーバーがリクエストの特徴を理由に返却を拒否している、返却形式がクライアントと互換性がない、の4つです。まずクライアントでその取得元だけを更新して表示を確認します。次に、既存の利用可能な接続を通じて更新を試します。その後、URLのコピー時に余分な空白、改行、途中での切断がないか確認し、返されたものがサブスクリプションデータか通常のWebページかを調べます。より詳しい分岐はサブスクリプション更新失敗のトラブルシューティングと自動更新設定を参照してください。

マージ、変換、ローカルルールの境界

サブスクリプション変換は、クライアント間の形式差、フィールドの絞り込み、統合出力の処理に適しています。ただし変換チェーンが長くなるほど、問題の切り分けは難しくなります。v2rayN、v2rayNG、v2flyNGが元の取得元を直接認識できるなら、まず直接インポートしてください。変換が必要な場合は、カプセル化形式だけを変えるのか、プロトコルパラメータ、サーバー名、ルーティングルールまで書き換えるのかを明確にします。接続パラメータを変える工程は、元のサブスクリプションは使えるのに変換結果だけ失敗する原因になり得ます。

ローカルの長期的なルーティングルールを、リモートサブスクリプションの一時的なメモに依存させないでください。メモはサーバーの絞り込みには使えますが、ドメインの分岐条件には適していません。ルーティングは対象ドメイン、IP、ポート、プロセス、インバウンドタグに基づいて記述し、サーバー一覧の取得元から分離します。こうすればサブスクリプションを切り替えてもアクセス方針を維持できます。特定の対象を特定サーバーへ固定的に送る必要がある場合だけ、ルーティングルールを安定したアウトバウンドタグに関連付けます。

モバイルとデスクトップで同期する範囲

複数の端末でサーバー一覧を完全に同じにする必要はありません。デスクトップでは複数のアウトバウンド、複雑なルーティング、TUNによる引き継ぎが必要になることがありますが、モバイルでは取得元を絞り、アプリごとのルールを簡素にする方が適しています。サブスクリプションの取得元名と基本的なフィルター方針は同期しても構いませんが、システムに依存する設定は端末ごとに保存してください。特に、ローカル待受ポート、プロセスルール、デスクトップ向けDNSアドレスを含む完全な設定を、そのままモバイル端末へコピーしないでください。

古い取得元を整理する順序

取得元を停止するときは、まず自動更新を解除し、次に検証済みの別サーバーへ切り替え、その後で取得元からサーバーを削除し、最後にサブスクリプションの記録を削除します。現在使用中の取得元を直接削除すると、クライアントには古い接続状態が残っているように見えても、次回起動時に復元できなくなることがあります。整理後は、アクティブサーバー、デフォルトのアウトバウンド、ルーティングタグを再確認し、削除したオブジェクトを参照するルールが残っていないことを確認します。

複数サブスクリプション管理が安定した状態では、各取得元に明確な用途と更新方法があります。どれか1つが失敗しても他の取得元を妨げず、ルーティングとDNSは一時的なサーバーメモに依存せず、デスクトップとモバイルは必要なデータだけを共有します。これは単純に1本の長大なサブスクリプションへ統合するより保守しやすく、後からカスタムアウトバウンドを追加する場合にも適しています。

CHAPTER 04 / ROUTING

ルーティングルール実践：一致条件、順序、アウトバウンド

ルーティングは、コアへ入った接続を対象ドメイン、対象IP、ポート、ネットワーク種別、プロセス、インバウンドタグに基づいて指定のアウトバウンドへ送ります。アプリの通信を自動的にクライアントへ入れる機能ではなく、サーバー接続パラメータを修正するものでもありません。システムプロキシまたはTUNが入口を担当し、ルーティングは入口の後で方向を選びます。この境界を理解すると、「アプリがクライアントを経由していない」ことを「分岐ルールが一致していない」と誤認せずに済みます。

まず3種類のアウトバウンドから始める

基本構成には、プロキシアウトバウンド、ダイレクトアウトバウンド、ブロックアウトバウンドがよく含まれます。プロキシアウトバウンドは現在選択中のサーバーまたはカスタムプロキシチェーンを指し、ダイレクトアウトバウンドはローカルネットワークから対象へ直接アクセスします。ブロックアウトバウンドは明確に不要な接続を拒否するために使います。各アウトバウンドには、proxy、direct、blockのように安定して意味の分かるタグを付けます。ルーティングルールはタグでアウトバウンドを参照するため、タグを変更したらすべての参照も変更してください。

ルールの順序は通常、具体的なものから一般的なものへ並べます。明確なブロック、内部ネットワークへのダイレクト、指定ドメイン、指定プロセスのルールを先に置き、その後に大きなドメイン集合やIP集合を置き、最後にデフォルトのアウトバウンドで未一致の通信を受けます。広すぎるルールを先に置くと、後続の精密なルールは実行されません。たとえば、すべてのTCP通信を先にプロキシへ送ってから特定ドメインをダイレクトにしても、そのルールは無効になる可能性があります。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.cn", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.net"],
        "outboundTag": "proxy"
      }
    ]
  }
}

上の例では、まずプライベートアドレスをダイレクトにし、次に指定ドメインとドメイン集合を処理します。domain:はそのドメインとサブドメインに一致し、full:は完全なホスト名だけに一致させたい場合に適しています。keyword:は指定した文字列を含むドメインに一致するため、範囲が最も広く、誤一致のリスクも高くなります。ルールの意味はコアの設定形式によって変わります。日常の保守には、通常、クライアント画面で生成した方式が適しています。JSONを直接編集する場合は、各フィールドが現在のコアで対応している設定構造に属することを確認してください。

ドメイン一致とIP一致をどうつなぐか

ルーティングがドメインを受け取る場合、ドメインルールで直接判定できます。IP集合による一致が必要な場合、コアは先にドメインを解決することがあります。domainStrategyは、その処理をいつ行うかを決めます。ドメインルールだけで処理するなら、追加の名前解決を避けられます。「ドメインルールに一致しなければIPで判定」したい場合は、対応するオンデマンドの名前解決方式を使用します。すべてのドメインを無条件に先に解決すると、DNSリクエストが増え、ルーティングが使う解決結果とアプリの想定が一致しなくなる可能性があります。

GeoSiteはドメイン集合、GeoIPはIPアドレス集合です。どちらもローカルのデータファイルに依存するため、ルールの書き方が正しくてもデータが古いと、新しいドメインが含まれなかったり、アドレスの分類が変わったりします。更新後はコアを再起動し、実行設定にデータを再読み込みさせてください。具体的な更新方法と誤った分岐の調べ方は、GeoIP・GeoSiteデータベース更新ガイドを参照してください。

内部ネットワーク、LAN、プライベートアドレス

家庭用ルーター、プリンター、ファイル共有、ローカル開発サービスは通常プライベートアドレスを使うため、優先してダイレクトにします。そうしないと、ローカル機器へのアクセスがリモートのアウトバウンドへ送られて失敗することがあります。プライベートIP集合だけでなく、localhost、.local名、社内ドメインにも注意してください。内部ドメインはLANのDNSでしか解決できないことが多いため、DNSの分岐でローカルの名前解決サーバーを指定し、ルーティングではダイレクトにします。

TUNモードではクライアントが引き継ぐ範囲が広くなるため、内部ネットワークへのダイレクトルールが特に重要です。TUNを有効にしてルーターの管理画面へアクセスできなくなったら、まずプライベートアドレスがプロキシを迂回しているか、仮想NICのルートがLANのサブネットを覆っていないかを確認し、次にシステムファイアウォールを調べます。1つのローカルアドレスを復旧するために、すべてのルーティングルールを無効にしないでください。対象を精密にダイレクトへ追加する方が検証しやすくなります。

ルールが有効にならない場合の項目別確認

まずリクエストが本当にコアへ入っていることを確認し、ログで対象がドメインかIPかを確認します。IPしか見えない場合、純粋なドメインルールは一致しない可能性があります。対象ドメインが先行する広範なルールに一致している場合は順序を調整します。GeoSiteまたはGeoIPを参照している場合は、データファイルが読み込まれているかを確認します。ルールがカスタムアウトバウンドを指している場合は、タグが完全に一致しているか確認します。クライアントに「LANをバイパス」「グローバル」「ルール」などのモードがある場合は、現在のモードがカスタム方式を上書きしていないか確認してください。

検証では1つの対象を選び、ダイレクト、プロキシ、ブロックの3つの観測可能な結果を個別にテストします。複数のサイトを同時に使って判断しないでください。Webページはメインリソース、画像、APIなど別のドメインを読み込むため、同じリクエストが複数の経路を通ったように見えることがあります。ブラウザーのキャッシュや持続接続も結果に影響するため、ルール変更後はコアを再起動し、新しい接続を確立します。ルーティングの安定基準は、ルールの意図、一致順序、アウトバウンドタグを1つずつ説明できることであり、たまたま更新に成功することではありません。

CHAPTER 05 / DNS

DNS設定の最適化：問い合わせ経路、分岐、漏れの確認

DNSはドメインをアドレスへ変換する方法を決め、ルーティングがドメインまたはIPに正しく一致できるかにも影響します。上級設定で最も混乱しやすいのは、システムDNS、アプリ内蔵DNS、クライアントDNS、リモートアウトバウンドの名前解決が同時に存在し、どのレイヤーがどのドメインを担当するか不明確になることです。最適化の目的はサーバーを増やすことではなく、説明可能な問い合わせ経路を作ることです。リクエストがどこから入り、どのサーバーが解決し、問い合わせ自体がどのアウトバウンドを通り、結果がどのルーティングに渡るかを明確にします。

システムの問い合わせとコアの問い合わせを区別する

通常のシステムプロキシモードでは、一部のアプリがシステム側で先にドメインを解決し、IPをプロキシへ渡すことがあります。一方、プロキシプロトコルに対応したアプリはドメインをクライアントへ渡します。TUNモードはより多くのDNS通信を引き継げますが、暗号化DNSや独自のリゾルバーを使うアプリが残ることもあります。ログに対象IPしか現れない場合、コアへ入る前にドメイン情報が失われている可能性があり、ドメインによる分岐の効果が制限されます。

コアのDNSサーバーには従来のIPアドレスだけでなく、暗号化通信に対応したサービスアドレスも指定できます。利用できる機能はコアとクライアントの生成方式によって異なります。選択時は到達性とアウトバウンド経路を同時に考慮してください。解析サーバー自体がプロキシ経由を必要とし、ルーティングもその解析結果に依存すると、循環依存が起こることがあります。基本となる名前解決の入口は現在のネットワークから明確に到達できるものにし、特定ドメインだけ別のサーバーへ振り分けます。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  }
}

この例は、ドメインごとに名前解決サーバーを選ぶ方法を示すもので、すべてのネットワークでそのまま使うことを求めるものではありません。domainsはそのサーバーが担当するドメイン集合を限定し、expectIPsは返却アドレスが想定範囲に入るか確認し、queryStrategyは問い合わせるアドレス種別の傾向を決めます。現在のネットワークから特定の名前解決入口へ到達できない場合は、タイムアウトの再試行を増やすのではなく、到達可能なサービスへ置き換えてください。

DNSの分岐とルーティングの分岐を一致させる

ドメインをダイレクトにする場合、通常はローカルネットワークに適した名前解決経路を使います。ドメインをプロキシアウトバウンドへ送る場合は、問い合わせも同じアウトバウンドを通すと、名前解決場所とアクセス場所の差を小さくできます。2つのルールを1件ずつ完全に重複させる必要はありませんが、大きな方針は一致させるべきです。ルーティングではダイレクトなのにDNS問い合わせだけリモートアウトバウンドを通すと、接続は動作しても遅延と切り分けの難しさが増します。

内部ドメインは、分岐を明確にすべき代表的なケースです。企業や家庭LANの内部名は通常、ローカルDNSだけが応答できます。該当するドメインサフィックスにローカルの名前解決サーバーを指定し、ルーティングでは対応アドレスをダイレクトにします。パブリックDNSが「存在しない」と返しても、クライアントが内部サーバーへ自動的に再試行するとは限りません。逆に、パブリックドメインをすべてLAN内だけで有効なサーバーへ渡すと、現在のネットワークを離れたときに全体が失敗します。

キャッシュ、TTL、切り替え後の古い接続

DNSの結果は、アプリ、システム、クライアント、コアにそれぞれキャッシュされることがあります。名前解決設定を変更してすぐにページを更新しても、新しい問い合わせが行われるとは限りません。確立済みの接続も、DNSが変わったからといって自動的に移行しません。検証時は古い接続を閉じ、コアを再起動し、必要に応じてシステムのDNSキャッシュを削除します。「リアルタイム」を求めてキャッシュ時間を極端に短くしないでください。問い合わせ数が増えるだけで、サーバー自体が誤った結果を返す問題は解決しません。

サーバーアドレスが頻繁に変わるサービスでは、適切なTTLを尊重し、失敗時の再試行を用意します。固定的な内部サービスでは、適度なキャッシュを保持できます。同じドメインがネットワークごとに異なるアドレスを返す場合は、ネットワーク切り替え後に古いキャッシュへ特に注意してください。モバイル端末でWi-Fiからモバイルネットワークへ切り替えた場合、すべてのキャッシュが自然に期限切れになるのを待つより、接続を再起動する方が制御しやすいことがあります。

DNS漏れの判断と修正

DNS漏れとは、本来指定した経路を通るはずの問い合わせが、システムや別のアプリによって想定外の名前解決サーバーへ送られることです。判断時はWebページに表示されたDNSアドレスだけでなく、現在のネットワーク、プロキシモード、想定する経路も併せて確認します。システムプロキシモードだけで、すべてのアプリのDNSを自動的に引き継げるわけではありません。TUNモードはより広い範囲をカバーしますが、DNS通信を正しく横取りする必要があります。ブラウザーで独自の暗号化DNSを有効にすると、システムやクライアントの設定を迂回することもあります。

修正は、まず想定する経路を明確にし、次に迂回経路を減らす順で行います。アプリ独自のリゾルバーを無効化または調整し、システムDNSのリクエストをクライアントへ入れ、コアDNSに明確なアウトバウンドを指定し、ルーティングが問い合わせを誤った方向へ送っていないか確認し、最後に再テストします。特定のアプリだけで起こる場合は、システム全体を変更する前にそのアプリの設定を確認してください。詳しい手順はDNS漏れの検出と修正方法を参照してください。

DNS設定の完成基準は、各種類のドメインを誰が解決し、問い合わせがどのアウトバウンドを通り、結果がどのようにルーティングへ使われるかを説明でき、ログでその過程を確認できることです。サーバーの数が多いほど良いわけではありません。短く明確な問い合わせチェーンの方が、ランダムな予備アドレスを複数置くより安定することが一般的です。

CHAPTER 06 / TUN

TUNモード：システム通信の引き継ぎと境界制御

TUNモードは仮想ネットワークインターフェースでシステム通信を受け取ります。システムプロキシに従わないアプリ、個別にプロキシを設定できないアプリ、UDPリクエストを含むアプリに適しています。解決するのは通信入口のカバー範囲であり、正しいサーバーを自動選択したり、ルーティングやDNSを置き換えたりするものではありません。TUNを有効にすると、クライアントは仮想NIC、システムルート、DNSの引き継ぎを設定するため、障害範囲が1つのアプリからシステム全体のネットワークへ広がります。通常のプロキシモードが安定してから有効にしてください。

有効化前の確認

まず、v2rayNまたはAndroidクライアントが通常モードで現在のサーバーを利用できることを確認し、既存の設定を保存します。デスクトップでは、仮想NICの作成とルート変更に必要なシステム権限が必要です。セキュリティソフトや企業ポリシーがこれらの操作を制限することもあります。現在のLANサブネット、使用中のVPN系ソフト、仮想マシンのネットワーク、コンテナネットワークも記録してください。複数の仮想インターフェースがデフォルトルートを奪い合う可能性があるためです。

TUNを起動する前に、システムルートを変更する他の接続ツールを停止し、同時に引き継がないようにします。共存させる必要がある場合は、各インターフェースのルート優先度と対象サブネットを明確にし、起動順に任せないでください。クライアントの異常終了後にネットワークが切れた場合は、まず関連プロセスを終了してシステムネットワークを復元し、その後に残った仮想インターフェースとDNSを確認します。ブラウザーを何度も再起動するだけでは解決しません。

スタックモードとMTU

クライアントやコアによっては、system、gVisor、mixedなどのネットワークスタックを選択できます。systemスタックはOSのネットワーク動作に近く、互換性と性能はプラットフォームの実装に左右されます。ユーザー空間スタックはクライアント内部でパケットを処理しやすく、環境によっては安定しますが、特定のプロトコルやアプリと差異が生じることもあります。明確な障害がない場合はクライアントの推奨値を使い、UDP、LAN、特定アプリに異常がある場合だけ切り替えて比較してください。

MTUは1つのパケットの最大サイズを決めます。大きすぎると複雑なネットワーク経路でフラグメント化やパケットロスが発生し、ページは開くのにアップロード、動画、特定のAPIだけが止まることがあります。小さすぎるとオーバーヘッドが増えます。接続が遅いからといって、すぐにMTUを下げないでください。まずTUN使用時だけ発生する問題か確認し、段階的に変更して比較します。変更ごとに接続を再確立し、デフォルト値も比較対象として残します。

LANと予約アドレスのバイパス

TUNで引き継いだ後は、プライベートアドレス、ループバックアドレス、現在のLANで直接接続する必要があるサブネットを明確にバイパスします。プリンター、ネットワークストレージ、ルーターの管理画面、ローカル開発サービスはこの設定に依存します。「LANをバイパス」スイッチだけでは足りない場合、実際のアドレス範囲を確認し、対象のIPまたはサブネットを精密なルールで追加します。企業ネットワークには一般的でない内部アドレスが存在することもあるため、実際のルーティングテーブルに基づいて処理してください。

ローカル機器へホスト名でアクセスする場合は、内部DNSも併せて設定します。対象IPだけをダイレクトにしても、ドメインをパブリックDNSへ渡せば、存在しないアドレスや誤ったアドレスが返ることがあります。LANの問題は「名前を解決できるか」と「アドレスへ直接接続できるか」の2段階に分けて検証します。まずIPで接続を確認し、その後にドメインを試せば、問題がDNSかルーティングかを判断できます。

アプリ単位の制御とUDP

モバイルでは、どのアプリを接続に入れるかをアプリごとのプロキシで制御することがよくあります。包含モードは少数のアプリだけを通すのに適し、除外モードは大半のアプリを通しつつローカルサービスをダイレクトにするのに適しています。アプリの更新やパッケージ名の変更で、以前の選択が無効になることがあります。定期的に一覧を確認してください。デスクトップのプロセスルーティングはコアと権限に依存します。同じプロセス名でも異なるパスに対応することがあるため、実際のログでルールを検証します。

UDP通信には、一部のDNS、リアルタイム通信、新しい転送プロトコルが含まれます。サーバーやプロトコルチェーンが必要なUDP動作に対応していない場合、TUNがパケットを受け取っても対象へ到達できるとは限りません。切り分けでは、すべてのUDPが失敗するのか、特定のアプリや対象だけが失敗するのかを確認し、その後にアウトバウンドの能力、ルーティング、MTUを調べます。UDP障害を単純に仮想NICの問題と決めつけないでください。

無効化後のネットワーク復旧

クライアントを正常終了すると、自動ルーティングとDNSは元に戻るはずです。異常終了後もネットワークが使えない場合は、まずTUNインターフェースが残っていないか確認し、次にデフォルトルートとシステムDNSに一時的な値が残っていないか調べます。クライアントを再度開き、正常起動と正常停止を1回行うと、クリーンアップ処理が実行されることがあります。それでも戻らない場合は、システムのネットワークリセット機能を使い、現在のネットワークへ再接続します。

TUNの安定基準は、すべての通信を引き継ぐことではありません。想定した範囲だけを引き継ぎ、LANの境界が明確で、DNSが迂回せず、無効化後にシステムが復旧できることです。ブラウザーとシステムプロキシに対応したアプリだけを使う場合は、通常のプロキシモードの方が簡単です。入口のカバー範囲が必要な場合に限り、TUNを選択します。

CHAPTER 07 / FAKEDNS

FakeDNS：仮想IPマッピング、適用条件、互換性

FakeDNSはアプリへドメインの実アドレスを直接返さず、予約アドレスプールから仮想IPを割り当て、内部に「仮想IP—元のドメイン」の対応を保存します。アプリがこの仮想アドレスへ接続すると、コアはマッピングからドメインを復元し、ドメインルーティングと実際の名前解決を行います。主な価値は、TUN環境でドメイン情報を保持し、アプリが先に実IPを取得した結果、コアがアドレスだけで判断する状態を避けられることです。

マッピングの仕組み

アプリがDNS問い合わせを開始すると、リクエストはTUNまたはDNSハイジャックルールによってコアへ入ります。FakeDNSはドメインに仮想アドレスを割り当てて返し、アプリはそのアドレスを対象として接続を確立します。コアはそのアドレスがFakeDNSプールに属することを認識し、マッピング表からドメインを取り出して、ドメインルールに従ってアウトバウンドを選択します。必要に応じて、対象アウトバウンドを通じて実アドレスを解決します。この一連の処理には、DNS問い合わせと後続の接続が同じマッピングを認識できるコアインスタンスを通る必要があります。

DNS問い合わせがFakeDNSに入っても、アプリの接続がTUNを迂回すると、システムはインターネット上に存在しない仮想アドレスへアクセスしようとします。逆に、接続がTUNへ入ってもDNSがアプリ独自のリゾルバーで直接処理されると、コアには実IPしか見えず、FakeDNSは関与しません。有効化する前に、DNSの引き継ぎと通信の引き継ぎが一つの閉じた経路を形成していることを確認してください。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

この例では、テスト用途の予約アドレス範囲を仮想プールとして使い、指定したドメイン集合だけにFakeDNSを適用します。実際のフィールドと配置場所はコアの設定形式とクライアントの生成方式によって異なるため、まずクライアントが提供するスイッチとテンプレートを使ってください。アドレスプールは、ローカルLAN、企業ネットワーク、他の仮想インターフェース、既存のルートと重複させないでください。プールは大きければよいわけではなく、通常利用中のアクティブなマッピングを収容できれば十分です。

有効化に適した場面

TUNが安定して動作し、ドメインルールが多く、アプリがローカルで先にドメインを解決することが多い場合、FakeDNSはコアがドメインの意味を保持するのに役立ちます。実際の名前解決を先行させたくない場合にも適しています。ルーティングで先にドメインからアウトバウンドを選択し、その経路で実際の名前解決を行えるためです。これにより、ローカルの解決結果が早い段階で対象アドレスを決めてしまうことを避けられます。

主にリモート名前解決に対応したシステムプロキシを使い、ログですでに完全なドメインを確認できる場合、FakeDNSの効果は通常限定的です。単純なネットワークで、設定項目を増やすためだけに有効化する必要はありません。FakeDNSはドメイン情報の欠落を解決するための機能であり、汎用的な高速化スイッチではなく、サーバー自体の接続品質を改善するものでもありません。

そのまま有効化すべきでない場面

実IPの表示、アドレスの許可リスト、LAN機器の検出、DNS結果の直接比較に依存するアプリは、仮想アドレスを受け入れられない可能性があります。一部のセキュリティソフトは予約アドレス範囲への接続を異常と判断し、ゲーム、機器制御プログラム、企業クライアントがシステムDNSを迂回してマッピングが不完全になることもあります。内部ドメインは通常、引き続きLANのDNSへ渡し、実アドレスへ直接接続してください。FakeDNSへ入れるべきではありません。

IPルールで精密に制御する必要がある対象にも注意が必要です。ドメインを復元する前にルーティングが仮想IPを通常のアドレスとして処理すると、誤ったルールに一致する可能性があります。設定では、FakeDNSアドレスの認識が正しい段階で行われることを確認し、仮想アドレスプールに通常のダイレクトルールを設定しないでください。仕組み、適用範囲、アプリ互換性については、FakeDNSの仕組みを詳しく解説も参照してください。

キャッシュとマッピングの無効化

アプリが仮想IPをキャッシュし、コアの再起動後にマッピング表が空になることがあります。この状態でアプリが古い仮想アドレスへ接続し続けると、コアは元のドメインを復元できず、クライアント再起動後に一部サイトが短時間だけ失敗します。古い接続を閉じ、アプリのDNSキャッシュを削除するか、アプリを再起動すると通常は復旧します。コアを頻繁に再起動するとこの現象が増えるため、デバッグ時は変更ごとに完全な問い合わせをやり直してください。

アドレスプールが枯渇したり、マッピング数が異常に増えたりする場合は、プログラムがランダムなサブドメイン問い合わせを継続的に生成していないか確認します。むやみにプールを拡大しても問題を先送りするだけです。まずリクエスト元を特定し、必要に応じてその種別のドメインをFakeDNSから除外するか、アプリの引き継ぎ範囲を制限します。有効化後は、通常のドメイン、内部ドメイン、IPだけでアクセスする対象、再起動後のキャッシュ復旧を個別に検証します。この4種類の挙動を説明できて初めて、FakeDNSは安定して組み込まれたといえます。

CHAPTER 08 / OUTBOUNDS

カスタムアウトバウンド、プロキシチェーン、体系的なトラブルシューティング

カスタムアウトバウンドは、対象ごとに異なる接続経路へ送り分けたり、ダイレクト、プロキシ、ブロックに加えてDNS専用、前置プロキシ、特定サーバー用のアウトバウンドを追加したりするために使います。これはサブスクリプション、ルーティング、DNSの構造が合流する場所です。サーバーパラメータがアウトバウンドの接続可否を決め、ルーティングタグが入るリクエストを決め、DNS経路が対象の解決方法を決めます。カスタムアウトバウンドが増えるほど、タグと依存関係を明確に記録する必要があります。

タグは設定間のインターフェース

各アウトバウンドには、重複せず、安定して用途だけを表すタグを付けます。サブスクリプション更新で変わりやすいサーバーアドレス、地域、日付をすべてタグに含めないでください。proxy-main、proxy-backup、direct、block、dns-outなどの名前が使えます。ルーティングルール、DNSサーバー、プロキシチェーンはタグだけで参照し、表示名はより詳しくしても構いません。

アウトバウンドを削除または名前変更する前に、すべての参照箇所を検索してください。設定を解析できても、参照が有効とは限りません。一部のエラーは、該当ルールが初めて一致したときにだけ現れます。最も安全な方法は、まず新しいアウトバウンドを追加して単独でテストし、精密なドメインルールを1つだけ切り替え、成功を確認してから範囲を段階的に広げ、最後に古いアウトバウンドを削除することです。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ]
}

この例は、ダイレクト、ブロック、DNSアウトバウンドの基本的なタグ関係を示します。プロキシサーバーのアウトバウンドは通常、サブスクリプションとクライアントが生成するため、認証パラメータを複数のローカル設定へ重複して貼り付けないでください。クライアントが現在のサーバーをデフォルトのプロキシアウトバウンドとして使える場合は、その動的参照を残し、サーバーを切り替えてもルーティングを書き換えずに済むようにします。特定の回線を固定したい場合だけ、独立したアウトバウンドを作成します。

プロキシチェーンの方向と依存関係

プロキシチェーンは、あるアウトバウンドが別のアウトバウンドを通じて接続を確立する仕組みです。たとえば対象通信をまず業務用アウトバウンドへ入れ、そのアウトバウンドで前置アウトバウンドを転送経路として指定します。設定では「誰が誰を経由して接続するか」を区別し、方向を逆に書かないでください。チェーンの各層で接続確立の手順と切り分け範囲が増えるため、前置経路が明確に必要な場合だけ使います。

プロキシチェーンで最も多い障害は循環依存です。アウトバウンドAがBを経由し、BがAを経由する場合や、Aのサーバーアドレスの名前解決がA自身を必要とする場合です。チェーンの最終地点は、直接接続を確立できる出口にしてください。直接解決できる、または固定的に到達できるサーバーアドレスを使うのも有効です。検証では、まず最外層の基本アウトバウンドをテストし、その後に上位層を1つずつ追加します。チェーン全体を一度に有効化しないでください。

インバウンド、ポート、プロセスでアウトバウンドを選ぶ

ドメインやIPのほか、インバウンドタグ、対象ポート、ネットワーク種別、プロセスに基づいて分岐することもできます。インバウンドタグは、異なるローカル待受ポートを別々のアウトバウンドへ結び付けるのに適しています。たとえば一方のポートをメイン回線、もう一方を予備回線のテスト用にできます。ポートルールは明確なプロトコルサービスに適しますが、現在のアプリは同じポートで複数のサービスを扱うことがあるため、ポートだけで内容を判断しないでください。プロセスルールはデスクトップでアプリ単位の制御に適しますが、実際の対応範囲と権限はコアとシステムによって異なります。

ルールの組み合わせでは、対象範囲の重複を避けます。プロセスルールとドメインルールが同時にある場合、順序で結果が決まります。最も明確なインバウンドまたはプロセスルールを先に置き、次に対象ドメイン、最後に汎用集合を置くのがおすすめです。各ルールの横に用途を記録すると、複雑な名前だけに頼るより保守しやすくなります。クライアント画面にメモ機能がある場合は、一致条件と対象アウトバウンドを記載します。

再現可能なトラブルシューティング手順

最初に最小構成へ戻します。検証済みサーバー1つ、プロキシアウトバウンド1つ、ダイレクトアウトバウンド1つだけにし、複雑なルーティング、TUN、FakeDNSは無効にします。基本接続を確認したら、2段階目でDNS設定を読み込み、ドメイン解決を検証します。3段階目で精密なルールを1つ追加して一致を確認し、4段階目でTUNを有効にしてシステム通信とLANを検証します。5段階目で初めてFakeDNSまたはプロキシチェーンを追加します。各段階でログと結果を保存してください。

問題がサブスクリプション更新後だけ発生する場合は、まずアクティブサーバーとプロトコルパラメータを比較し、ルーティングを変更しないでください。特定のドメインだけが失敗する場合は、DNSの分岐とGeoSiteデータを確認します。システムプロキシに対応しないアプリだけが失敗する場合は、TUNの入口を確認します。FakeDNSを有効にして広範囲で失敗した場合は、通常のDNSへ戻してマッピング経路を確認します。カスタムアウトバウンドが失敗した場合は、まず精密なルールでそのアウトバウンドをテストし、全通信を一度に切り替えないでください。

ログには操作日時、変更項目、現在のモード、最初のエラーを記録します。接続終了の重複ログを大量に保存する必要はありません。2つの設定を比較するときは、実際に変更した部分だけを比較してください。DNS、ルーティング、アウトバウンドを同時に変更すると、差分の価値が失われます。用語や画面の意味が分かりにくい場合は、まず設定・トラブルシューティング記事を確認してください。クライアントを再インストールする必要がある場合は、ダウンロードページでWindows、macOS、Android、Linuxの対応バージョンを選択します。

長期保守の最小チェックリスト

定期メンテナンスのために、毎日設定を作り直す必要はありません。サブスクリプション層では取得元が有効か、フィルターが必要な項目まで除外していないかを確認します。ルーティング層ではGeoIP・GeoSiteデータとタグ参照を確認します。DNS層では名前解決サーバーの到達性とアプリの迂回を確認します。TUN層では仮想インターフェース、LANバイパス、無効化後の復旧を確認します。FakeDNS層ではアドレスプールの競合とアプリ互換性を確認します。アウトバウンド層ではチェーンがまだ必要かを確認します。コアを切り替える場合は、設定フィールドとプロトコル機能の互換性も確認してください。XrayとV2Flyの違いについては、XrayコアとV2Flyコアの違いを比較を参照してください。

保守しやすい上級設定では、各コンポーネントの役割を短い言葉で説明できる必要があります。サブスクリプションはサーバーを提供し、グループは取得元を管理し、フィルターはノイズを減らし、DNSはアドレスを返し、ルーティングは方向を選び、TUNは入口を広げ、FakeDNSはドメインを保持し、カスタムアウトバウンドは対象への経路を作ります。用途を説明できない、単独で検証できない、削除しても影響がないルールは、再検討する価値があります。設定がこのように明確な構造に近いほど、クライアントの更新、サーバーの切り替え、端末の移行で制御不能になりにくくなります。