V2Ray高度な設定ガイド

画面設定、コア設定、システムのネットワーク状態を切り分ける

高度な設定で起こりやすい問題は、特定のパラメーターを完全に間違えることより、複数の階層を同時に変更してしまうことです。v2rayNの画面はサブスクリプション、サーバー選択、システムプロキシ、TUNの切り替え、設定生成を担当します。XrayまたはV2Flyのコアはインバウンド、アウトバウンド、DNS、ルーティングを実行し、OSはデフォルトルート、ネットワークインターフェース、名前解決の順序、アプリがプロキシを迂回するかどうかを決めます。3つの階層は相互に影響しますが、切り分ける際は分けて考える必要があります。「クライアントは起動済み」と表示されても、プロセスが実行状態になったことを示すだけで、システムの通信が想定どおりコアへ流れているとは限りません。

変更を始める前に、正常動作が確認できる通常のシステムプロキシ設定を1つ保存します。正常に接続できるサーバーを選び、デフォルトのルーティングモードを使用し、TUNとFakeDNSを無効にして、ブラウザーとよく使うデスクトップアプリから対象サイトへアクセスできることを確認します。その後、現在のサブスクリプショングループ、使用中のサーバー、システムプロキシの状態、DNS設定、ルーティングモードを記録します。これにより比較対象ができ、後から機能を有効にして異常が起きても、複数の未知の要因を試行錯誤するのではなく、すぐ基準線へ戻せます。

設定ファイルは役割ごとに理解します。一般的な構造では、inboundsがシステムプロキシやTUNからの通信を受け取り、outboundsがプロキシ、ダイレクト、ブロックなどの出口を定義し、routing.rulesが通信をどの出口へ送るかを決め、dnsがドメイン名の解決方法を定めます。ルーティングルールのoutboundTagは、アウトバウンドのtagと完全に一致していなければなりません。DNSサーバーの選択もルーティングルールの影響を受ける場合があります。一部分だけをコピーして関連するタグを無視すると、読み込みはできても動作が不完全な設定になりがちです。

変更を最小限にして問題の範囲を確認する

「サブスクリプション整理 → ルーティング → DNS → TUN → FakeDNS → カスタムアウトバウンド」の順に進めることをおすすめします。サブスクリプションやサーバーフィルターは選択可能なサーバーの集合だけに影響するため、リスクは比較的低めです。ルーティングとDNSはリクエストの行き先を変え、TUNはより広い範囲を引き受け、FakeDNSはTUNや透過プロキシの経路にも依存します。順序を逆にすると、ドメイン解決やネットワークインターフェースに問題が起きたとき、原因がサーバー、ルーティング、DNS、仮想NICのどれなのか判断しにくくなります。

変更のたびに、少なくとも3種類の確認を行います。1つ目はドメインへのアクセスで、明確なWebページを選びHTTPとTLS接続を確認します。2つ目はIPアドレスへの直接接続で、DNS障害と通信障害を切り分けます。3つ目はアプリの違いで、システムプロキシに従うアプリと、システムプロキシを参照しないアプリをそれぞれ確認します。ドメインだけ失敗してIPは正常なら、まずDNSを確認します。ブラウザーは正常で他のアプリが失敗するなら、そのアプリがシステムプロキシやTUNの対象になっているかを確認します。すべて失敗する場合は、使用中のサーバー、アウトバウンドタグ、コアのログを確認します。

ログの確認にも明確な目的が必要です。起動時は設定の解析、ポート使用中、権限、仮想NICのエラーを重点的に確認します。接続時はドメイン、宛先ポート、適用されたアウトバウンドタグ、上流とのハンドシェイク結果を確認します。停止時はシステムプロキシとルーティングが復元されたかを確認します。ログレベルを長期間もっとも詳細な状態にすると、大量の正常な接続記録が重要なエラーを隠すため、避けるべきです。切り分けが終わったら通常のレベルに戻し、問題発生前後の短いコンテキストだけを残せば十分です。

購読元と利用目的を分けて表現する

サブスクリプションのグループ化は「サーバーがどこから来たか」を整理し、サーバーフィルターは「今どのサーバーを表示するか」を決めます。この2つの概念を1つの名前に混ぜないでください。グループ名には「日常用」「テスト用」「予備回線」のように、提供元や用途を記録するのが適しています。サーバー名には地域、プロトコル、提供元の情報をそのまま残します。こうすれば購読を更新してサーバー名が変わっても、全体の構造は崩れません。グループ名は短く安定させ、期限、臨時状態、長い説明をすべて詰め込まないようにします。

v2rayNでサブスクリプションを追加するときは、まず各リンクに独立したグループを作成し、1グループずつ更新します。初回インポートでいきなり全選択更新するのは避けてください。形式に問題のある購読が1つあると、結果を判断しにくくなるためです。更新後は、サーバー数が想定どおりかを確認し、いくつかを無作為に開いて、アドレス、ポート、プロトコル、トランスポートの項目が揃っているかを確認します。サブスクリプションはサーバー設定を渡すだけで、ルーティング戦略、システムプロキシモード、DNS方式を自動的に決めるものではありません。

フィルターは、名前に安定した目印が含まれているサーバーの整理に適しています。たとえば「低倍率」や特定地域の略称を含む項目だけを表示したり、「メンテナンス」「残り通信量」など接続用ではない項目を除外したりできます。正規表現は柔軟ですが、誤選択も起こりやすくなります。式を適用する前に、まず通常のキーワードで範囲を絞り、本当に正規表現が必要かを判断してください。括弧、全角記号、スペース、大文字・小文字の違いも一致結果に影響します。

いずれかのキーワードを含む
HK|SG|JP

状態を示す名前を除外
メンテナンス|期限切れ|残り通信量|公式サイト

名前の先頭にある地域マークに一致
^(HK|SG|JP)[-_ ]

上の式はフィルタリングの考え方を示す例です。実際の名前は現在のサブスクリプション内容に合わせてください。フィルターはサーバー自体を変更せず、一覧や一括操作の対象範囲だけを変えます。フィルター後に一覧が空になったら、まず条件を解除し、名前に別の略称が使われていないか確認します。フィルターを機能させるために大量のサーバーを手動で1つずつ改名するのは避けてください。次回の更新で一覧が再生成され、手動名と元データの対応が失われる可能性があります。

更新、重複排除、無効項目の扱い

同じサーバーが複数のサブスクリプションから重複して提供されることがあります。重複を判断するときは表示名だけでなく、アドレス、ポート、プロトコル、トランスポート層のパラメーターも比較します。同じ名前でも入口が異なる場合があり、名前が違っても同じ接続情報を指すことがあります。最も安全なのは、グループごとに提供元の境界を保ち、インポート後にグループをまたいで大規模な統合を行わないことです。日常の一覧を簡略化したい場合は、フィルター表示や固定のお気に入りを使い、更新可能な構造を壊さないようにします。

サブスクリプション更新後にサーバーが消えた場合、提供元から削除されたのか、フィルターで非表示になったのか、別のグループへ移ったのかを確認します。更新後に項目が完全になくなった場合は、購読リンクが完全か、ネットワークリクエストが成功したか、返された内容をクライアントが認識できるかを確認します。基本操作は入門ガイドでも確認できます。一部のサーバーだけ接続できない場合は、サーバー設定またはネットワーク経路の問題として扱い、サブスクリプション全体を何度も削除して追加し直さないでください。

サーバーの並べ替えにも目的を持たせます。名前順は地域マークを固定したい場合に、グループ順は提供元を分けたい場合に適しています。速度測定の結果は測定時刻と測定対象を反映するだけで、すべての用途における実際の体感速度を示すものではありません。測定前に大量のダウンロードが動作していないことを確認し、同じ方法で比較します。測定に失敗しても、すぐにサーバーを削除する必要はありません。ICMP、TCPプローブ、実際のプロトコル接続では経路が異なるため、特定のプローブに応答しなくても正常に接続できるサーバーがあります。

Androidでは、v2rayNGとv2flyNGの画面構成がデスクトップ版と異なりますが、原則は同じです。購読元を分けて管理し、更新前に対象グループを確認し、更新後に選択中の設定が残っているかを確認します。モバイルではシステムのバックグラウンド制限にも注意が必要です。サブスクリプション更新の中断と、バックグラウンド接続の停止は別の問題です。VpnServiceの権限とバッテリー最適化の除外については、v2rayNG Android版の利用ポイントも参照してください。

メイン、予備、実験用の提供元を分離する

複数購読の管理で重要なのは、購読数を増やすことではなく、異なる提供元が互いに上書きしないようにすることです。少なくともメイン、予備、実験の3つに分けることをおすすめします。メインは日常の接続を担うため、変更頻度を最小限にします。予備はメインに問題があるときだけ使用します。実験用は新しいプロトコルや一時的な設定を試すためのもので、日常のサーバー一覧に直接混在させないでください。役割を決めたら、更新、選別、削除はグループ単位で行います。

各サブスクリプションには、安定した名前と明確な用途を設定します。グループ名に提供元の略称と役割を含めても構いませんが、アクセス認証情報、完全なリンク、その他の機密情報は記録しないでください。購読リンクはクライアントのサブスクリプション設定だけに保存し、スクリーンショット、公開ログ、共有設定例へコピーしないようにします。端末を移行するときは、ローカル状態、過去のログ、画面設定を含むデータディレクトリ全体をコピーするのではなく、新しい端末でサブスクリプションを再追加することをおすすめします。

更新計画は提供元の安定性を考慮して決めます。頻繁に手動更新しても回線そのものが速くなるわけではなく、提供元が一時的に不調なときに既存の結果を上書きするおそれがあります。日常利用では、まずメインの購読を1つ更新し、返却内容が正常であることを確認してから他のグループを更新します。クライアントが更新前の内容を保持できる場合は、失敗時の保護機能を有効にします。その項目がない場合は、重要な変更前に購読認証情報を含まないローカルサーバー設定をエクスポートするか、現在利用できる項目を記録します。

同名、改名、提供元移行への対応

サブスクリプション提供元が命名規則を変更すると、お気に入り、フィルター式、手動メモが機能しなくなることがあります。表示名だけでなく、アドレス、ポート、プロトコル、トランスポートの組み合わせなど、安定した項目を基準にサーバーを再識別します。同じ接続設定だと確認できてから、フィルター条件を更新します。提供元全体が新しい購読リンクへ移行した場合は、まず新しいリンクを新規グループとして追加して1回更新し、サーバーが使えることを確認してから旧グループを停止します。これにより移行中の戻り道を確保できます。

同じ接続が複数のグループから提供されていても、すぐに冗長と判断しないでください。サブスクリプションごとに更新周期、パラメーターの細部、利用範囲が異なる場合があります。まず名前フィルターで重複項目を非表示にし、複数回の更新で内容が一致することを確認してから、提供元を削除するか判断します。サブスクリプション設定を削除する前に、「購読入口の削除」と「インポート済みサーバーの削除」を区別してください。クライアントによっては別々に処理されます。

一括操作の前に、対象グループを限定します。一括速度測定、一括削除、一括変更は他の提供元まで誤って変更しやすく、特にフィルターが有効な場合は、画面に表示される範囲と実際の操作対象が一致しないことがあります。実行前に現在のグループ、フィルター条件、選択数を明確に確認します。購読に含まれるパス、ホスト名、TLS、REALITY公開鍵、短い識別子はサーバー側と対応しているため、トランスポートパラメーターの一括変更は通常おすすめしません。似た名前だけを根拠に入れ替えないでください。

保守しやすい変更履歴を作る

複数購読の環境では、複雑なバックアップより簡単な変更記録のほうが実用的です。毎回、日付、変更したモジュール、変更前の状態、変更後の状態、検証結果だけを記録します。たとえば「メイングループの地域フィルターを有効化。ルーティングは変更せず、ブラウザーとデスクトップアプリは正常に接続」のように書きます。問題が起きたとき、影響範囲の大きい最後の変更をすぐに特定できます。記録には完全な購読リンク、サーバーキー、再利用可能な認証情報を保存しないでください。

サーバー一覧が突然増減したら、まず各グループの更新時刻と返却状態を比較し、その後でフィルター条件を確認します。1つの提供元だけに問題がある場合は、その提供元の自動更新を一時停止し、すべての設定をすぐに作り直さないでください。すべての提供元で更新できない一方、既存サーバーには接続できるなら、サブスクリプションリクエスト、システムプロキシ、DNS経路の問題である可能性が高いです。更新は正常なのに全サーバーへ同時に接続できない場合は、ローカルネットワーク、使用中のアウトバウンド、システム時刻を確認します。

入口、条件、出口を先に理解する

ルーティングルールは3つの問いに答えます。通信はどの入口から入るのか、どの条件に一致するのか、最終的にどの出口へ渡すのか、です。よく使う条件には、ドメイン、IP、宛先ポート、ネットワーク種別、インバウンドタグ、プロセス情報があります。出口には通常、プロキシ、ダイレクト、ブロックの3種類以上を用意します。クライアントはルールを上から順に読み、最初に一致した結果で出口を決めます。そのため、具体的なルールを前に、広いフォールバックルールを後ろに置きます。

ドメインルールは、コアがドメイン名を取得できる場合にだけ機能します。アプリが先にローカルで名前解決し、IPだけをプロキシへ渡す場合、ドメインルールだけでは一致しないことがあります。逆に、IPルールには解決結果または直接指定されたIPが必要です。domainStrategyは、ルーティングモジュールがドメインに対してIP判定を行うか、いつ行うかを決めます。一般的には、まずドメインルールを使い、IPルールとの一致が必要な場合にだけ解決します。常にIPだけで処理する設定にすると、ドメインルールの可読性と制御性が一部失われます。

ルールは大量のリストを積み重ねるのではなく、用途から設計します。まず必ずダイレクトにするローカルアドレスとLANを列挙し、次に明確にプロキシへ送るドメイングループを記述し、その後で特定のIP範囲を処理し、最後にデフォルトの出口を設定します。ブロックルールは、接続不要と明確に判断できる対象やプロトコルにだけ使います。ルールが増えるほど、名前、コメント、順序を安定させないと、通信がなぜ特定の出口へ送られたのか判断できなくなります。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "full:assets.example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domain:は通常、指定したドメインとそのサブドメインへの一致を表し、full:は完全なドメイン名との一致に使います。通常の文字列ルールの具体的な解釈は、コアの形式によって異なります。明確な単一ホストには完全一致を、サービスの複数サブドメインにはドメインサフィックス一致を優先します。短すぎるキーワードによる広範な一致は避けてください。一般的な単語を1つだけ書くと、無関係なドメインまで大量に一致する可能性があります。

シンプルな3段構成から段階的に拡張する

最初の段階では、「プライベートアドレスはダイレクト、明確なドメインはプロキシ、それ以外はデフォルト出口」の3段階だけを残します。結果を確認してから、ダイレクトにする業務ドメインや特定UDPの処理を追加します。クライアントに定義済みのルーティング方式がある場合は、まず複製してから変更し、唯一の方式を何度も上書きしないでください。各ルールには明確な検証目標を設定します。たとえば完全なドメインルールを1つ追加したら、そのドメインと影響を受けない比較用ドメインだけをテストします。

プロセスルーティングはクライアント、コア、OSの機能に依存するため、すべてのプラットフォームで共通の基礎ルールにはできません。インストール方法や子プロセスの構成によって、プロセス名が変わることもあります。アプリが独自にプロキシを設定できる場合は、まずアプリ内で明示的に設定します。プロキシを参照しないアプリを引き受ける必要がある場合に、TUNとプロセス条件を検討します。Androidのアプリ別プロキシはシステムVPNの管理範囲に属し、デスクトップ版のプロセスルーティングとは別の実装です。

ポートルールはプロトコルが明確な場面に適していますが、「よく使われるポート」だけで用途を推測しないでください。現在のアプリは443を共有したり、動的ポートを使ったりするため、ポートだけではサービスを正確に区別できません。UDPも一律にブロックできません。DNS、リアルタイム通信、一部のトランスポートでUDPが使われます。ルール追加後にWebページは開くのにメディア、音声、ログインだけが失敗する場合は、UDP、QUIC、関連ドメインを誤って処理していないか確認します。

ルーティングが機能しているか判断するとき、出口IPだけを見ないでください。コアのログに記録された宛先、ルール条件、アウトバウンドタグを組み合わせるほうが確実です。ログで誤った出口に送られているなら、ルールの順序とタグを確認します。該当する接続記録がなければ、通信がそのインバウンドへ入っていない可能性があります。IPしか表示されずドメインが見えない場合は、アプリの名前解決方法、スニッフィング設定、FakeDNS経路を確認します。ルーティング設定とDNSは密接に関係するため、次の章では現在のルーティングを安定させたうえで進めます。

どこでドメイン名を解決しているか確認する

DNS設定の最初の手順は、すぐにサーバーを変更することではなく、どこで名前解決が行われているかを確認することです。ブラウザーが独自の暗号化DNSを使う場合もあれば、OSにシステムリゾルバーがあり、クライアントのコアにも独立したDNSを設定できます。3つが同時に存在すると、実際のリクエストが変更した階層を迂回することがあります。切り分けでは一時的に経路を統一します。ブラウザー独自の解決を無効にするか状態を記録し、テスト用ドメインをクライアントのコアへ通して、ログの問い合わせと返却結果を確認します。

DNS障害は、ドメインを開けない、IPへ直接接続できる、同じドメインでもアプリによって結果が異なる、といった形で現れます。接続タイムアウトが必ずDNS障害を意味するわけではありません。ドメインが正しく解決されていて、TLSや通信段階で接続に失敗しているなら、サーバーとルーティングを確認します。逆に、アドレスが返ってきても現在のネットワークに適しているとは限りません。キャッシュ、問題のある上流、分岐経路によって、意図しないアドレスへ接続されることがあります。

上流DNSは用途ごとに分け、複数のアドレスを無秩序に一覧へ入れないことをおすすめします。システムDNSはLAN内のホストやローカルネットワーク関連のドメインを処理し、指定した通常のDNSまたはDoHはその他の問い合わせを処理します。ドメインごとに上流を割り当てる場合は、各サーバーに明確なdomains範囲を設定します。DNSリクエスト自体にも適切な出口が必要です。ダイレクトで到達する上流はダイレクト出口から、プロキシ経由が必要な上流はルーティングルールでプロキシ出口へ送ります。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "https://dns.example.com/dns-query",
        "domains": [
          "domain:example.net"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

例にあるドメインは構造の説明用です。実際の設定では、利用可能なDNSサービスのアドレスに置き換えてください。queryStrategyはIPv4、IPv6、または両方を問い合わせる方式を制御し、現在のネットワーク環境に合わせる必要があります。安定したIPv6経路がないのにIPv6アドレスを優先すると、アプリが失敗を待ってからフォールバックするため、初回接続が遅くなることがあります。特定のアドレス種別を無条件に無効にすることも絶対的な解決策ではありません。まず利用可能な経路があるかを確認し、そのうえで問い合わせ方式を決めます。

分岐、キャッシュ、フォールバックの関係

DNSの分岐は、ドメインごとに適した上流を使い、正しい出口から問い合わせを送ることを目的とします。ドメインルールはできるだけ具体的にし、同じドメインが複数の重複範囲に入らないようにします。フォールバックサーバーは、主な一致で結果が得られない場合や、設定によって追加の問い合わせが許可されている場合に使うものです。ランダムな負荷分散として扱わないでください。skipFallbackを設定した場合は、そのドメインを本当に現在の上流だけで処理できるか確認します。主な上流が一時的に失敗しても、他のサーバーへ自動で切り替わらなくなるためです。

キャッシュのため、設定を変更しても結果が変わらないように見えることがあります。コア、OS、ブラウザーがそれぞれDNSをキャッシュしている可能性があります。設定変更後はまずコアを再起動または再読み込みし、次にシステムとアプリのキャッシュを消去し、最後に最近アクセスしていないサブドメインを比較に使います。短時間に複数の上流を何度も切り替え、同じドメインだけをテストするのは避けてください。新しい結果と古いキャッシュを区別しにくくなります。

DoHはDNS問い合わせをHTTPS接続に載せるため、転送方式を統一できます。ただしDoHサーバーのドメイン名自体を解決する必要があり、ブートストラップ解決の問題が発生します。一般的には、DoHサービスへ直接到達できるブートストラップアドレスを用意するか、システムリゾルバーで先にホスト名を解決します。ルーティングによってDoHホストが、同じDNSに依存する循環経路へ送られると、コアが問い合わせを待ち続けることがあります。DNSサーバーのアドレス、ルーティングルール、アウトバウンドタグが再帰的な依存関係になっていないか確認します。

中国本土と海外の分岐DNS、DoH、DNS汚染の切り分けを詳しく知りたい場合は、V2Ray DNS設定詳解を参照してください。実際の調整は現在のネットワークとコアのログを基準に行い、1つの上流アドレス群をすべての端末へ機械的にコピーしないでください。デスクトップの固定回線、モバイル回線、企業ネットワークではDNSの制限が異なります。安定した構成は、サーバー数を増やすことより明確な役割分担から生まれます。

TUNとシステムプロキシは異なる問題を解決する

システムプロキシは、アプリが自らプロキシ設定を読み取ることを前提とし、ブラウザーやOSのプロキシに従う多くのデスクトップソフトに適しています。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のIP通信を受け取り、システムプロキシを参照しないアプリも対象にできます。両者は単純な「通常モード」と「強化モード」ではなく、異なる接続方式です。ブラウザーのプロキシだけが必要なら、システムプロキシのほうが保守しやすくなります。独自のネットワークスタック、ゲームランチャー、コマンドラインアプリを扱う場合にTUNを検討してください。

TUNを有効にする前に、通常のシステムプロキシが安定し、現在のサーバーへ正常に接続でき、DNSとルーティングルールも個別に機能していることを確認します。その後、競合する可能性のある他の仮想NICソフトを停止し、システム本来のデフォルトルートとDNSの状態を記録します。v2rayNでTUNを有効にすると、仮想インターフェースの作成、ルート設定、DNS変更のためにOSの権限が必要になることがあります。権限が拒否されると、画面上のスイッチだけが変わり、仮想インターフェースは作成されない場合があります。クライアントの状態とシステムのネットワークインターフェースを両方確認してください。

TUNが受け取るのはネットワーク層の通信であり、コアがそれを変換してルーティングとアウトバウンドへ渡す必要があります。一般的な設定には、インターフェースアドレス、MTU、自動ルーティング、厳格ルーティング、プロトコルスタックの実装が含まれます。自動ルーティングは対象通信を仮想インターフェースへ送り、厳格ルーティングは迂回経路を減らしますが、LAN、コンテナ、仮想マシンのネットワークへ影響することがあります。初回はデフォルトパラメーターを維持し、明確な互換性問題がある場合だけ調整します。

LAN、仮想マシン、コンテナの扱い

LANアドレスは通常ダイレクトにし、広範なプロキシルールより前に置きます。そうしないと、プリンター、ルーターの管理画面、ファイル共有、ローカル開発サービスがプロキシ出口へ送られることがあります。一般的なプライベートアドレス範囲には、コアが提供するgeoip:privateルールを使えます。ただし、ローカルで使う特殊なネットワーク、仮想マシンのブリッジ範囲、コンテナネットワークにも注意してください。企業ネットワークでは追加の内部アドレスやドメインを使うことがあるため、実環境に合わせて追加します。

仮想マシンがNAT、ブリッジ、ホストオンリーのいずれを使うかによって、通信の入口と送信元アドレスは変わります。ホストのTUNがブリッジ接続された仮想マシンのすべての通信を自動的に引き受けるとは限りません。コンテナの通信もデスクトップアプリと同じ経路を通るとは考えないでください。切り分けでは、まずホスト上でテストし、その後に仮想環境内でDNS、デフォルトルート、出口を確認します。仮想環境だけが失敗するなら、ホストのルーティングを広げるのではなく、その環境自身のネットワーク設定を確認します。

MTUが適切でない場合、小さなページは開けるのに、大きなファイル、画像、TLSハンドシェイクが特定の段階で止まることがあります。接続が遅いからといって、すぐにMTUを下げないでください。まずTUNでのみ起こるか、特定のネットワークに限られるかを確認し、その後少しずつ調整します。変更後はWebページ、ダウンロード、UDPアプリをテストし、1つのサイトだけで判断しないでください。

Windowsでインターフェースとルートを確認
ipconfig /all
route print

macOSでインターフェースとデフォルトルートを確認
ifconfig
route -n get default

Linuxでアドレスとルートを確認
ip address
ip route

これらのコマンドはシステム状態を確認するためのもので、設定を直接修復するものではありません。仮想インターフェースが存在するか、デフォルトルートが想定どおりか、LANへの経路がまだ到達可能か、TUNを無効にした後に関連項目が復元されたかを確認します。用途を理解しないままルーティングテーブル全体を手動で削除しないでください。クライアント停止後もネットワークに問題がある場合は、まずクライアントを完全に終了して現在のネットワークへ再接続し、その後に残ったインターフェースとDNSを確認します。

通信ループと制御接続の取り込みを避ける

TUNで最も重要な境界は、プロキシプロセス自身とサーバー接続を迂回させることです。プロキシサーバーへ接続する通信が再びTUNへ入り、同じプロキシアウトバウンドへ戻されるとループが発生します。成熟したクライアントは通常、サーバーアドレス、プロセス、インターフェースの迂回を自動処理しますが、カスタムルールでこの保護が壊れることがあります。起動直後に切断する、同じ宛先への接続がログに繰り返し現れる、通信量が急増するといった場合は、まずループを確認します。

DNSも同様のループを作ることがあります。TUNがDNSリクエストをコアへ送り、コアがDoHサーバーへアクセスする際に、未完了の名前解決へ依存するケースです。ブートストラップ解決、DNSの出口、TUNの除外範囲を明確に設定します。互換性を高めるために複数のシステムVPNや透過的な接管ツールを同時に有効にしないでください。デフォルトルート、DNS、仮想インターフェースが競合し、動作が不安定になります。

AndroidのVpnServiceもシステムレベルの接管を行いますが、操作方法、権限モデル、デスクトップのTUNとは完全には同じではありません。v2rayNGまたはv2flyNGで初めて接続するときは、システム権限を許可し、必要に応じてアプリ別プロキシを設定します。バックグラウンドで頻繁に停止する場合は、デスクトップ版のTUNパラメーターではなく、バッテリー最適化の設定を確認します。

ドメイン名に仮想アドレスを割り当てる理由

一部のアプリは先に自らドメイン名を解決し、対象IPだけをシステムネットワークへ渡します。TUNに入った後、コアから見えるのはIPだけで、元のドメイン名は失われるため、ドメインベースのルーティングルールが一致しにくくなります。FakeDNSは問い合わせに仮想アドレスを返し、「仮想アドレスと元のドメイン名」の対応を保存します。アプリがその仮想アドレスへ接続すると、通信がTUNによって回収され、コアが元のドメイン名を復元してドメインルーティングを実行します。

したがって、FakeDNSは通常のパブリックDNSの代替ではなく、単独で有効にすれば動作する高速化機能でもありません。完全な経路には少なくとも、アプリの問い合わせがコアDNSへ入る、FakeDNSが仮想アドレスを返す、アプリが接続を開始する、接続が管理対象のインバウンドへ入る、コアが仮想アドレスを認識してドメイン名を復元する、ルーティングが実際のアウトバウンドを選ぶ、アウトバウンド側が実際の名前解決または接続を行う、という段階が含まれます。どこか1つでもクライアントを迂回すると、仮想アドレスを復元できないか、ドメインルールが機能しなくなります。

有効化する前に、TUNと通常のDNSをそれぞれ安定させます。その後、LAN、仮想マシン、コンテナ、企業ネットワークと競合しない仮想アドレスプールを選びます。アドレスプールはローカルのマッピング専用で、実ネットワークへ送信してはいけません。ルーティングが仮想アドレスを誤ってダイレクトへ送ると、アプリは継続的なタイムアウトを起こします。プールの容量はアクティブなドメイン数をカバーする必要がありますが、既存ネットワークと重なる範囲まで無制限に広げる必要はありません。

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

198.18.0.0/15はベンチマーク用ネットワークでよく使われ、仮想アドレスプールの例にできます。ただし、現在のネットワークで該当範囲が使われていないか確認してください。設定項目はコアの設定方式によって異なるため、クライアントが生成した構造を基礎にし、互換性のない設定へ断片を直接置き換えないでください。FakeDNSはDNSサーバーの順序にも関係します。すべてのドメインが仮想アドレスを返す必要はありません。ローカルドメイン、LAN内ホスト、実IPを必要とすることが明確なアプリには、通常の解決を残せます。

仮想アドレスの漏洩とマッピング失敗を見分ける

アプリが仮想アドレスを受け取った後、TUNへ入らず物理ネットワークへ直接送信すると、仮想アドレスが漏洩します。ドメイン解決は成功したように見えるのに接続がタイムアウトし、コアのログにも対応するリクエストがないのが典型です。この場合、上流DNSをさらに変更するのではなく、アプリがTUNの対象か、アプリ別ルールで除外されていないか、自動ルーティングが機能しているか、仮想アドレス範囲を別のルートが先に処理していないかを確認します。

マッピングの失敗は、コアの再起動、キャッシュの保持、アドレスプールの再利用後に起こることがあります。アプリは古い仮想アドレスをキャッシュしているのに、新しいコアには元のマッピングがないため、ドメイン名を復元できません。設定を再読み込みし、アプリとシステムのDNSキャッシュを消去して、アプリに再問い合わせさせます。長時間の稼働後だけ発生する場合は、アドレスプールの容量、キャッシュの有効期間、短時間のドメインリクエストが大量に発生していないかも確認します。

アプリによっては、返されたアドレスを検証したり、内蔵DNSを使ったり、固定IPへ直接接続したり、アプリ内で暗号化された名前解決経路を構築したりします。こうした通信はFakeDNSに適さない場合があります。特定のアプリだけに問題があるなら、まずそのアプリをFakeDNSのテスト範囲から外し、実際の名前解決を使ってIPまたはプロセスルールで処理します。1つの特殊なアプリのために、すべてのドメインをより複雑な経路へ変更しないでください。

FakeDNSを有効にする価値は、TUN環境でドメイン名を維持する必要が本当にあるかで決まります。通常のシステムプロキシですでにドメイン名を渡せるなら、追加しても大きな効果は通常ありません。設定後は、LAN内ホスト、よく使うWebページ、長時間接続、スリープからの復帰もテストし、仮想マッピングがローカルの通常解決へ影響しないことを確認します。機能の多さより安定性を優先してください。

ダイレクト、ブロック、ローカルプロキシから始める

カスタムアウトバウンドは、通信がコアから外へ出る方法を定義します。最も基本的な構成には、通常プロキシのアウトバウンド、ダイレクトアウトバウンド、ブロックアウトバウンドが含まれます。サブスクリプションから生成されたプロキシアウトバウンドはクライアントが管理するため、ローカルルールではタグを参照するだけで構いません。アウトバウンドを追加するときは、タグを一意で分かりやすくし、クライアントが自動生成するタグとの衝突を避けます。direct、block、local-socksのような役割名を推奨します。「回線1」「臨時2」のように、長期的に意味を理解しにくいタグは使わないでください。

ダイレクトアウトバウンドは通信をローカルネットワークへ渡すため、システムのルーティングとDNS機能の影響を受けます。ブロックアウトバウンドは一致した通信を明示的に拒否します。ローカルSOCKSアウトバウンドは、同じ端末または信頼できるLAN上で動作する別のプロキシサービスへ通信を渡せます。カスタムのチェーン出口は障害箇所を増やすため、上流の役割が明確で個別に検証できる場合だけ使います。通常のサブスクリプションサーバーで要件を満たせるなら、多層の転送を追加する必要はありません。

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    },
    {
      "protocol": "socks",
      "tag": "local-socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    }
  ]
}

例にあるローカルポートは、別のSOCKSサービスが実際に127.0.0.1:1081で待ち受けている場合だけ使えます。追加後はまずポートの待ち受けを確認し、テスト用ドメインだけに一致するルーティングルールを作成してlocal-socksへ送ります。デフォルトの通信をいきなりすべて切り替えると、上流が起動していない場合に全接続が失敗し、原因がルールなのか上流なのかも判断しにくくなります。

アウトバウンド経路におけるDNSとループを理解する

カスタムアウトバウンドがドメインへアクセスする場合も、名前解決が必要です。解決をローカルシステム、コアDNS、上流プロキシのどこが担当するかを確認します。上流プロキシにドメインを解決させたい場合は、ドメイン形式を維持し、リモート解決に対応した接続方式を使います。コアが先に解決する場合は、ルーティングとDNSの方針が得られるアドレスに影響します。この点を設定説明に明記しておくと、「正しいタグにルーティングされたのに、誤ったアドレスへ接続する」問題を避けられます。

ローカルチェーンプロキシは特にループが起こりやすい構成です。たとえばv2rayNのアウトバウンドがローカルの1081を指し、1081を同じ設定のインバウンドが使用している場合や、上流プログラムの通信が再びTUNに捕捉され、現在のアウトバウンドへ戻される場合があります。切り分けでは、ポートを所有するプロセス、インバウンドの待ち受けアドレス、TUNの迂回範囲を確認します。1つのポートを安定して待ち受けられるプロセスは1つだけであり、インバウンドとアウトバウンドの宛先が閉路を形成してもいけません。

サーバーアウトバウンドのプロトコル、トランスポート、TLS、REALITYパラメーターは、実際のサーバー設定またはサブスクリプション内容に基づく必要があります。プロトコル名だけを見てパラメーターを組み立てないでください。VLESS、VMess、Trojanなどのプロトコルは、認証やトランスポートの構成を異なる方法で扱います。WebSocket、gRPC、TCPなどのトランスポートにも、パス、サービス名、ホスト情報が含まれます。REALITYとXTLS Visionの関係はREALITYとXTLS Visionの仕組みを参照できますが、設定値はサーバー側と項目ごとに一致させる必要があります。

「入口—解決—ルーティング—出口」の順に障害を特定する

体系的な切り分けは、常に通信の流れに沿って行います。1段階目は入口です。アプリがシステムプロキシを読み取っているか、通信がTUNへ入っているかを確認します。2段階目は名前解決です。ログにドメイン名が残っているか、DNSが利用可能な結果を返しているかを確認します。3段階目はルーティングです。どのルールとどのアウトバウンドタグに一致したかを確認します。4段階目は出口です。上流のアドレス、ポート、プロトコル、トランスポートで接続を確立できるか確認します。入口が接管していない状態でサーバーを何度も変更しても現象は変わらないため、最後の段階から始めないでください。

コアが起動できない場合は、まず直近の正常な設定へ戻し、JSON構文、タグ参照、ポート競合、権限を確認します。起動できても接続記録がない場合は、システムプロキシ、TUN、アプリの設定を重点的に確認します。接続記録はあるがルールが誤っている場合は、いったん3段構成のルーティングへ縮小します。ルールは正しいのにDNSが失敗する場合は、単純な上流へ戻してFakeDNSを無効にします。名前解決とルーティングが正しいのにアウトバウンドが失敗する場合は、サーバー設定、システム時刻、ローカルネットワークを再確認します。

切り分けが終わったら、一時的なログレベル、テストルール、テスト用アウトバウンドを日常設定へ戻します。基準線、現在使用する設定、簡単な変更履歴を1つずつ残せば十分で、ほとんど同じ設定のコピーを大量に長期保存する必要はありません。クライアントを選び直したり、対応するプラットフォーム版をインストールしたりする場合は、クライアントダウンロードページへ進んでください。デスクトップではv2rayNを、Androidではコアの要件に応じてv2rayNGまたはv2flyNGを使用します。