V2Ray 高度な設定を体系的に解説

まずサブスクリプション、設定、グループを区別する

サブスクリプションURLは単一のサーバーではなく、サーバー側で管理される設定一覧に近いものです。クライアントがサブスクリプションを更新すると一覧を読み込み、複数のサーバー項目を生成します。グループは、これらの項目を分類するためにクライアント内で使う管理層です。3者のライフサイクルは異なります。サブスクリプションは定期的に更新され、サーバー名やパラメータが変わることがありますが、ローカルグループは通常、安定したまま維持すべきです。この関係を理解すると、設定方針が明確になります。サブスクリプションは情報源の変化を受け取り、フィルタリングルールは必要な項目を選び、グループは固定の用途を担います。数十個の項目を手動で並べ替えて順序を維持する方法には頼らないでください。次回の更新で一覧が再生成され、手動の並び順が失われる可能性があります。

v2rayNでは、まず「日常用メイン」「予備」「テスト」のように情報源ごとにサブスクリプショングループを作り、各情報源に更新、フィルタリング、別名を設定する方法が堅実です。Android版のv2rayNGでは、グループを少なめに保つ方が適しています。画面が限られているため、細かく分けすぎると切り替えの手間が増えます。v2flyNGの管理方法はv2rayNGに近いものの、コアの仕組みが異なります。インポート後は、プロトコルとトランスポートのパラメータが正しく認識されているか確認してください。クライアント間で移行する際は、サブスクリプションURLまたは標準設定を移行し、特定クライアント固有の表示順を共通設定とみなさないでください。

肯定条件で予測しやすい一覧を作る

サーバーフィルタリングでは通常、表示名、プロトコル、アドレス、ポートを条件にできます。まず残したい項目を明確にする肯定条件を書き、その後に少数の除外条件を加える方法がおすすめです。サブスクリプションの備考に地域、用途、倍率が含まれる場合は、名前に「常用」や明確な地域名を含む項目を残し、「期限切れ」「メンテナンス」「テスト」など日常利用に適さない項目を除外します。肯定条件が明確であれば、提供元が命名規則を変更した際にも問題を見つけやすくなります。除外語を長く並べるだけでは、新しい異常ラベルが気づかないうちに選択肢へ入る可能性があります。

フィルタリング式は、サブスクリプション内に実際に存在する命名規則をもとに作成します。たとえば ^(?!.*(?:メンテナンス|期限切れ)).*(?:常用|予備) は、「メンテナンス」または「期限切れ」を含む項目を除外し、「常用」または「予備」を含む名前だけを残します。式内の全角記号、空白、大文字・小文字は結果に影響することがあります。初めて作成するときは、実際の備考をいくつかローカルのテキストにコピーして1つずつ照合し、その後クライアントに設定してください。いきなり複雑な式から始めず、保守しにくい複合ルールよりも、2つの単純なルールを組み合わせる方が信頼性は高くなります。

{
  "group": "日常用メイン",
  "include": "(常用|予備)",
  "exclude": "(メンテナンス|期限切れ|テスト)",
  "updateIntervalHours": 24
}

更新前後に残すべき情報

サブスクリプションを更新する前に、現在接続できる設定が1つあることを確認し、所属するサブスクリプションと備考を記録します。更新後はまず項目数に異常な変化がないか確認し、次に現在選択中の項目が残っているかを確認します。項目数が突然ゼロになった場合は、すぐにプロトコルパラメータを変更せず、サブスクリプションへのアクセス、フィルタリング条件、グループ選択を優先して疑います。大幅に減った場合は、一時的にフィルタリングを無効にして元の結果を確認してください。元の項目が揃っていれば問題はローカルの絞り込みにあり、元の結果も不完全なら、サブスクリプション自体の返却内容を確認する必要があります。

更新処理では上書き方針も重要です。サブスクリプションから生成された項目は原則としてサブスクリプション側で管理されるため、アドレス、ポート、ユーザー識別子、トランスポートパラメータを長期的に直接変更するのは適していません。次回の更新で変更が上書きされる可能性があるためです。実験が必要な場合は、項目をローカルのテストグループへコピーし、区別できるよう名前の先頭に「ローカルテスト」を付けます。テストに成功したら、変更がサブスクリプション側の設定なら情報源へ戻って修正し、ローカルのルーティングやDNSの要件なら、サーバーごとに変更せずクライアントの全体設定またはルーティングルールに配置します。

空の一覧と重複項目への対処

サブスクリプションをインポートしたのにサーバーが表示されない場合は、決めた順番で確認します。まず正しいグループを表示しているか確認し、次に手動で1回更新します。その後、含有条件と除外条件をすべて無効にし、クライアントログに解析エラーがないか確認してください。フィルタリングを無効にして復旧した場合は、ルールを1つずつ有効にして競合項目を特定します。ログに認識できない形式と表示された場合は、サブスクリプションがクライアント対応形式を返しているか確認してください。ログインページ、案内文、期限切れの応答ではありません。関連する基本的な問題についてはヘルプセンターも参照してください。

重複項目は、同じサブスクリプションを2回インポートした、2つのサブスクリプションに同じサーバーが含まれている、または更新時に上書きではなく追加を選択した場合に発生します。処理前に表示名だけで判断しないでください。同名でもアドレスやトランスポートパラメータが異なることがあります。アドレス、ポート、プロトコル、トランスポート方式、安全設定を照合します。完全に同一の項目は、安定したサブスクリプションで管理される1つだけを残し、同名でもパラメータが異なる項目は情報源が分かるよう名前を変更します。目的は一覧を最大化することではなく、すべての項目の情報源と用途を追跡可能にし、更新後も理解しやすい状態を保つことです。

ルーティングの判定は接続確立前に行われる

ルーティングルールの役割はサーバーパラメータを変更することではなく、各接続のアウトバウンドを選ぶことです。アプリがアクセスを開始すると、コアは対象ドメイン、対象アドレス、ポート、ネットワーク種別、プロセスの情報など、利用可能な情報を読み込み、ルールの順番に沿って一致する項目を探します。一致すると、接続はプロキシ、直接接続、遮断など指定されたアウトバウンドへ渡されます。どのルールにも一致しなければ、最終的なデフォルトのアウトバウンドに進みます。したがって、ルーティングを調べるときは、現在どのサーバーを選んでいるかだけでなく、「この接続はどのルールに捕捉されたか」を確認します。

ドメインとアドレスを常に同時に取得できるとは限りません。接続によってはコアへドメイン名が渡され、ルールで直接照合できます。一方、すでに解決されたアドレスだけが渡される接続では、ドメインルールが機能しないことがあります。ドメインスニッフィングを有効にすると、一部のプロトコル通信から対象ドメインを復元できますが、すべての場面で確実とは限らず、正しいDNS設計の代わりにもなりません。安定したルーティングには、ドメインルールとアドレスルールの両方を考慮し、どのルールがスニッフィングに依存するかを明確にします。

ルールの順序が最終結果を決める

多くのクライアントは上から順に照合し、最初に一致したルールでアウトバウンドを決定します。範囲が狭く優先度の高いルールを前に置き、広い範囲のフォールバックルールを後ろに置きます。たとえば特定の内部ドメインを直接接続する場合は、広範なプロキシ対象ドメインの前に配置します。LANアドレスの直接接続ルールもデフォルトのプロキシより前に置き、最後に残りの接続を処理するフォールバックを置きます。順序が逆だと広いルールが先に一致し、後の精密なルールは正しく記述されていても実行されません。

保守しやすいルールセットは通常、「特定の遮断、指定された直接接続、指定されたプロキシ、アドレス範囲、デフォルト動作」の順に並べます。遮断ルールは必要最小限にし、明確に接続不要な対象だけを記述します。直接接続にはLAN、クライアント更新に必要な対象、ローカルネットワークからアクセスすべきサービスを含めます。指定プロキシルールは、明確な要件があるドメインやアプリに使います。アドレス範囲ルールはアドレスだけを持つ接続を処理し、デフォルト動作は未分類の通信を受け持ちます。階層が明確になると、ログに表示されるアウトバウンドのラベルも説明しやすくなります。

Xrayルーティング構造の例

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

domainStrategyを理解して使い分ける

domainStrategy は、ルーティング時にドメインをいつアドレスへ解決するかを決めます。AsIs では元のドメイン名を優先して判断し、アドレスルールのために積極的な解決は行いません。IPIfNonMatch はまずドメインルールを試し、一致しなければアドレスを解決してアドレスルールを続けて照合します。IPOnDemand はアドレス情報を必要とするルールに遭遇した際、より早く解決を開始することがあります。すべてのネットワークに適した値はありません。ドメインルールが中心で追加の解決を減らしたい場合は AsIs から始め、アドレスデータベースによる振り分けが必要なら IPIfNonMatch の方が理解しやすいことが多いでしょう。

ルーティング段階の名前解決はDNSモジュールの影響も受けます。DNSクエリ自体が誤ったアウトバウンドを通ると、想定外のアドレスが返され、別のルールに一致することがあります。domainStrategy を変更した後に「同じドメインが時々別の出口を通る」場合は、DNSサーバーの選択、キャッシュ、ドメインルールの一致状況も同時に確認してください。ルーティングとDNSは前後につながる2つの仕組みであり、別々に無計画な調整をするのは適切ではありません。

ポート、ネットワーク、アプリで範囲を絞る

ポート条件は、特定のTCPポートだけを特定のアウトバウンドに担わせるなど、明確なサービスの処理に適しています。ただし、一般的なポートをドメイン分類の代わりに使わないでください。多くのサービスが443番ポートを共有するため、ポートだけでは対象を区別できません。ネットワーク条件ではTCPとUDPを分けられ、あるアウトバウンドがUDPに対応しない場合やリアルタイム通信を個別に処理する場合に適しています。アプリ条件はクライアントの機能に依存します。v2rayNGのアプリ別プロキシでは、Androidアプリ単位でVPNへ入れるプログラムを決めます。コアに入った接続は、その後もドメイン、アドレス、ポートのルーティングを利用できます。

アプリ別プロキシの包含モードと除外モードは、目的を明確にしてどちらか一方を選びます。端末上でクライアントに通したいアプリが少ない場合は包含モードが管理しやすく、ほとんどのアプリを通して少数のローカルアプリだけを除外する場合は除外モードの方が保守しやすくなります。アプリの更新やパッケージ名の変更後は古いルールが一致しないことがあるため、システム更新後に特定アプリの経路が変わった場合は、いきなりドメインルールを書き直さず、まずアプリ選択リストを確認してください。

ウェブの結果だけでなくログで一致を確認する

ルーティングを検証するときは、混乱の原因になるバックグラウンド接続をいったん閉じ、クライアントログを開いてからテスト対象を1つだけアクセスします。対象ドメインまたはアドレス、一致したルール、最終的なアウトバウンドラベルを確認します。ログにアドレスしか表示されない場合はDNSとスニッフィング設定を確認してください。アウトバウンドラベルが正しいのにアクセスできない場合は、対象サーバー、選択中のノード、トランスポートパラメータ、ローカルネットワークに問題がある可能性が高いです。ラベルが誤っている場合は、該当ルールを一時的に先頭へ移してテストし、ルール自体が一致することを確認してから適切な順序へ戻します。

ルーティングルールを変更した後は、接続を再起動して新しい設定を完全に読み込ませます。ブラウザが既存の接続を再利用したり、DNSキャッシュを保持したりするため、ページを更新するだけでは変更を検証できません。より確実なのは、クライアントを切断し、テストアプリのバックグラウンドプロセスを終了してから再接続し、新しいアクセスを開始する方法です。「接続済みなのにアクセスできない」状態を体系的に調べる場合は、プロキシポート、ルーティングモード、DNSの確認チェックリストを参照してください。

まず名前解決の経路を描く

DNSの障害が調べにくいのは、システムDNS、クライアントDNS、ブラウザの暗号化DNS、リモート名前解決が同時に存在することが多いためです。アプリがドメイン名を送信すると、クエリはOSが処理する場合もあれば、TUNが受け取る場合もあります。ブラウザで独立した暗号化DNSを有効にしていると、クライアント設定を迂回することもあります。コアがクエリを受け取った後も、ドメインルールに従ってDNSサーバーを選び、クエリを直接接続またはプロキシのどちらで送るか決めます。返されたアドレスはキャッシュされ、ルーティングモジュールでさらに照合されることがあります。どの層を変更しても、「ドメインでは開けないがアドレスなら通る」「同じドメインの結果が安定しない」といった症状につながります。

最初に行うべき最適化は、DNSアドレスを増やすことではなく、主経路を1つに定めることです。通常のシステムプロキシモードでは、プロキシが必要なドメインの名前解決をクライアントに任せ、ローカルリソースはシステムDNSで処理する方法があります。TUNモードでは、仮想NICに入るクエリをできるだけコアが一元的に処理するようにします。テスト中はブラウザ独自のDNSを一時的に無効にし、並行経路を避けてください。クライアント経路が正常だと確認してからブラウザ設定を戻し、その通信が想定どおりルーティングされるか確認します。

ローカルDNSとリモートDNSの役割

ローカルDNSは、LAN名、社内ドメイン、現在のネットワークから回答すべき対象の解決に適しています。リモートDNSは、プロキシアウトバウンドを通すドメインのクエリに適しており、解決場所とアクセス出口を一致させやすくします。これは単純に「速いDNSと遅いDNS」を選ぶ話ではなく、管轄範囲の違いです。内部ドメインをリモートサーバーへ送っても正しいアドレスが得られないことが多く、プロキシ出口と一致させる必要があるドメインを常にローカルサーバーへ送ると、現在の出口に適さない結果になることがあります。

設定ではドメイン集合ごとにサーバーを指定し、分かりやすいデフォルトのリゾルバーを残します。クライアントがDoHに対応している場合は、https://1.1.1.1/dns-query のようなHTTPSエンドポイントを使用できます。通常のUDP DNSを使う場合は、リクエストがプロキシアウトバウンドを通るか明確にしてください。DoHは転送形式にすぎず、正しいルーティングを自動的に保証するものではありません。エンドポイントのドメイン自体も最初に解決する必要があるため、厳格な環境では明確なサーバーアドレスやブートストラップ解決を組み合わせ、DNSサーバーのドメインを解決するために同じDNSサーバーへ先に接続する循環依存を避けます。

ドメイン範囲に応じてDNSサーバーを選ぶ

{
  "dns": {
    "hosts": {
      "router.internal.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategyとアドレスファミリーの選択

queryStrategy はIPv4、IPv6、または両方のアドレスを問い合わせるか制御します。UseIP を選ぶと通常は両方のアドレスが許可されますが、実際の応答はサーバーとネットワークに左右されます。IPv4だけにするとIPv6経路が使えない場合の待ち時間を減らせますが、IPv6だけにするにはローカルネットワーク、プロキシアウトバウンド、対象サービスのすべてが完全に対応している必要があります。ログにIPv6アドレスが出たからといって、すぐ無効にしないでください。まず失敗が本当にIPv6接続段階で起きているか判断します。安定したネットワークではデュアルスタックを維持し、不完全な環境では実際の接続能力に合ったアドレスファミリーを選びます。

アドレスファミリーの問題は、最初の表示だけ遅く後から回復する、または同じ対象がアプリごとに異なるという形で現れることがあります。アプリごとに異なるアドレス選択アルゴリズムを使っている場合や、一方のアドレスファミリーが先に失敗してフォールバックする場合があります。確認時はAとAAAAの結果を別々に観察し、クライアントログで最終的に試した対象アドレスを確認します。DNSの返却タイプだけを変更し、アウトバウンドの能力を見ないままでは、利用可能だった別のアドレスまで除外する可能性があります。

キャッシュ、Fallback、汚染と誤判定

DNSキャッシュは重複クエリを減らしますが、誤った結果の影響も長引かせます。サーバーや振り分けルールを変更した後は、クライアントを切断・再接続し、必要ならテストアプリを再起動して古いキャッシュを破棄します。システムに解決結果が残っている場合は、レコードの期限切れを待つか、システムが提供するキャッシュ更新方法を使います。複数のDNSを短時間に連続して切り替えて比較しないでください。ブラウザ、システム、クライアントがそれぞれ異なる段階の結果を保持し、単一設定の効果を観察できなくなります。

Fallbackは、優先サーバーが適さない場合や結果が特定条件を満たした場合に、予備のリゾルバーへ切り替える仕組みです。判定条件を明確にしないと、複数サーバーが異なる結果を返して理解が難しくなります。内部ドメインでは skipFallback を使い、内部の命名を認識しないサーバーへクエリが漏れないようにできます。通常のドメインでは、ドメイン集合やアドレス範囲に基づいてフォールバックを設計し、複数のサーバーを並べるだけでクライアントが「最適な」答えを自動選択すると期待しないでください。設定が複雑になるほど、実際にどのリゾルバーが使われたかをログで確認する必要があります。

リモートDNSが失敗したときの確認順序

リモートDNSが応答しない場合は、まずエンドポイントへの接続を確立できるか直接確認し、次にリクエストがプロキシと直接接続のどちらを通っているかを確認します。エンドポイントがドメイン名なら、ブートストラップ解決でアドレスを取得できるか確認します。HTTPSを使う場合は、端末のシステム時刻が正しいか確認してください。時刻のずれはTLS接続に影響します。その後、ルーティングルールがDNSエンドポイントを誤って遮断や未対応のカスタムアウトバウンドへ送っていないか確認します。最後にクライアントログの応答形式とタイムアウトを確認します。この順番なら、「エンドポイントに到達できない」「ルーティングが誤っている」「解決結果が適していない」を区別できます。

AndroidでVPNモードを有効にした後は、システムのプライベートDNS設定にも注意します。システムのプライベートDNS、ブラウザ独自のDNS、v2rayNGのリモートDNSが同時に動作すると、クエリ経路が想定と異なる可能性があります。トラブルシューティングでは、まずv2rayNGだけの単一経路を残し、名前解決とアクセスが安定することを確認してから、システム機能を1つずつ戻します。デスクトップのv2rayNでは、システムプロキシとTUNを区別します。システムプロキシはすべてのプログラムのDNSを受け取るとは限らず、TUNの方がネットワーク層全体を引き受ける仕組みに近いものです。両者を同じ見方で判断してはいけません。

TUNとシステムプロキシは動作する層が異なる

システムプロキシは、アプリがOSのプロキシ設定を自ら読み取ることを前提とし、ブラウザやシステムのネットワーク設定に従うソフトに適しています。TUNモードは仮想ネットワークインターフェースを作成し、より低いネットワーク層で通信を受け取るため、HTTPやSOCKSプロキシ設定に対応しないプログラムも対象にできます。対象範囲が広い分、ルーティングテーブル、DNSの引き受け、UDP、アドレスファミリー、LANアクセス、他の仮想ネットワークソフトなど、より多くの要素を扱う必要があります。TUNを「より強力なスイッチ」と考えるのは正確ではなく、別の通信入口と考えるべきです。

モードはアプリの要件で選びます。日常的なウェブ閲覧やシステムプロキシに対応したソフトは、設定が簡単で障害要因が少ないシステムプロキシから始められます。特定のプログラムがシステムプロキシを無視する、UDPを扱う必要がある、より多くのアプリを一括して受けたい場合にTUNを有効にします。基本接続を確認しないままTUNを重ねないでください。まず通常のプロキシモードでサーバー、プロトコル、サブスクリプションが正常だと確認してから入口を切り替えると、新しい問題をTUN、DNS、ルーティングテーブルの範囲に絞れます。

有効化前のシステム準備

デスクトップ版v2rayNでTUNを有効にするには、通常、仮想NICの作成とルーティング変更をシステムに許可する必要があります。権限が不足すると、スイッチは有効に見えてもインターフェースが正しく作成されないことがあります。ボタンの状態だけでなく、クライアントログでインターフェースの作成、アドレス割り当て、ルート書き込みが完了したか確認します。セキュリティソフト、ファイアウォール、他の仮想NICツールがドライバーを遮断したり、ルーティングの優先度を変えたりする場合があります。初回テストでは不要な同種のネットワークツールを終了し、変数を1つに保ってv2rayN単独で動作することを確認してください。

Android版v2rayNGはシステムVPNインターフェースを使って通信を引き受け、システムにVPN状態を表示します。このとき、アプリ別プロキシ、常時接続VPN、システムのプライベートDNS、省電力設定が結果に影響することがあります。システムが別のVPNサービスも指定している場合、通常は同じインターフェースを並行して使用できません。クライアントを切り替える前に現在の接続を切断し、状態が完全に解放されるまで待ってから新しい接続を開始します。バックグラウンド制限でクライアントが停止する場合があるため、端末のバッテリー管理設定で安定動作を許可してください。

スタック種別、MTU、UDP

TUNには複数のネットワークスタック選択肢が用意されていることがあります。システムスタックはOSの動作に近く、互換性が比較的高い傾向があります。ユーザーランドスタックはより多くのネットワーク処理をクライアント内部で行い、プラットフォーム間の動作を揃えやすくします。名称はクライアントの画面によって異なりますが、原則は同じです。まずクライアント推奨のデフォルトスタックを使い、ログで互換性問題、UDP異常、特定アプリの失敗が明確になった場合だけ切り替えます。切り替え後は接続を再確立し、同じ対象を繰り返しテストします。

MTUは、ネットワークインターフェースが一度に運べるデータ量を示します。値が大きすぎると、一部経路でパケットの分割や破棄が起き、小さなページは開くのに大きなコンテンツが止まる、アップロードに失敗する、接続確立後にデータが流れないといった症状が出ます。小さすぎると余分なオーバーヘッドが増えます。調査ではシステムまたはクライアントのデフォルト値から始め、分割が疑われる場合に少しずつ下げ、変更ごとに記録します。ネットワーク、トランスポート方式、カプセル化層によって有効な上限は異なるため、極端な値をそのまま使わないでください。

UDPには、アウトバウンドとサーバー設定の両方の対応が必要です。TUNがUDPを受け取ったからといって、リモート側が転送できるとは限りません。ウェブは正常なのにリアルタイム通信、音声、特定の名前解決が失敗する場合は、ログでUDPが正しいアウトバウンドに入っているか、現在のサーバー設定が対応しているか確認します。切り分けのため、DNSを一時的にHTTPSベースのクエリへ変更し、通常のUDP DNS障害とUDP通信全体の障害を区別できます。その後は必ず実際の利用シーンに戻して確認し、一時的な代替策を問題解決とみなさないでください。

LANを迂回させ、ルーティングループを防ぐ

TUNが通信を引き受けると、LANプリンター、ルーター管理画面、ファイル共有が誤ってプロキシへ送られることがあります。ルーティングルールの先頭付近にプライベートアドレスの直接接続を残し、必要に応じてローカルドメインを追加します。一般的なプライベートアドレス集合はコアの geoip:private で処理できますが、企業ネットワークでは追加のアドレス帯を使う場合があるため、実際の環境に応じて補完してください。確認時はゲートウェイ、LAN機器のアドレス、内部ドメインを個別にアクセスし、アドレスの直接接続と内部DNSが正常か確認します。

ルーティングループは、プロキシサーバーやDNSエンドポイントへ向かう通信までTUNが再び引き受け、自分自身へ繰り返し送り返すことで発生します。クライアントは通常、自身のプロセスやサーバーアドレスを自動的に除外しますが、カスタムアウトバウンド、チェーンプロキシ、特殊なネットワーク環境でこの保護が破られることがあります。接続直後にネットワークが失われる、ログに同じ対象が繰り返し現れる、サーバー接続が何度も再確立されるといった症状が典型です。プロキシサーバーのアドレス、必要なブートストラップDNS、クライアント自身の通信に明確な到達経路を用意し、すべての通信を無差別に同じ入口へ戻すデフォルトルールを避けます。

TUN環境の基本ルーティング構成

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

競合の診断と復旧手順

TUNを有効にして完全にアクセスできなくなった場合は、まず切断してシステムネットワークが復旧するか確認します。復旧しなければクライアントを終了し、仮想NICやシステムルートが残っていないか確認します。その後クライアントを再度開き、TUNを有効にせず通常のプロキシでサーバーを確認します。通常のプロキシが正常なら、他のVPN、仮想マシンのネットワーク拡張ツール、ルートを書き換える可能性のあるソフトを終了してTUNを再度有効にします。これで復旧すればソフトウェア競合です。失敗が続く場合は、インターフェース作成、DNSの引き受け、デフォルトルート書き込みに関するログを確認します。

一部のアプリだけ失敗する場合は、全設定をリセットしないでください。まず失敗するアプリがアプリ別ルールに含まれているか確認し、次にTCP、UDP、自前DNSのどれを使っているかを見て、対象接続のルーティングラベルを確認します。ウェブは開けるのにアプリのログインだけ失敗する場合、別のドメインや証明書検証経路を使っている可能性もあります。アプリを1つだけ起動し、ログを対象ごとに絞ることで問題を特定の接続まで縮小できます。ノードのタイムアウトと接続直後の切断については、v2rayNGノードのタイムアウトを6段階で調べる方法も参照してください。

FakeDNSが解決する問題

一部のアプリは先に自分でDNS解決を行い、対象アドレスだけをシステムへ渡します。接続がTUNに入ったとき、コアに見えるのはアドレスだけで、元のドメイン名が失われている場合があります。そのためドメインベースのルーティングルールに一致できません。FakeDNSは、管理対象のクエリに対してクライアントが仮想アドレスを返し、「ドメインと仮想アドレス」の対応を記録します。アプリがその仮想アドレスへ接続すると、コアは対応表から元のドメインを復元し、ドメインルールに従って実際のDNSとアウトバウンドを選びます。主な役割はドメイン情報の保持であり、公開DNSの代替ではありません。

この仕組みは、クエリと後続の接続が同じクライアントを通ることを前提とします。アプリが独立した名前解決を迂回して実行したり、接続がTUNに入らなかったりすると、対応付けを作成または利用できません。ブラウザの暗号化DNS、アプリ内蔵リゾルバー、一部の直接接続ネットワークライブラリが迂回路になることがあります。FakeDNSを有効にする前に、DNSの引き受け経路が明確で、TUNの基本機能が正常であることを確認してください。そうしないと、問題が対応付け、DNSの迂回、仮想NICのどこにあるのか切り分けにくくなります。

仮想アドレスプールはアクセス可能なサーバーではない

FakeDNSが返すアドレスは専用の仮想プールから割り当てられ、クライアント内部で特定のドメインを表すだけです。インターネット上で実際にアクセスできるサーバーではありません。テストツールに仮想アドレスが表示されても、名前解決の誤りとは限りません。重要なのは、後続の接続がクライアントに捕捉され、ドメインを復元できるかです。アプリが仮想アドレスをファイルや長期キャッシュに保存したり、別の端末へ共有したりしても、クライアントの対応表の外では意味がありません。そのため、FakeDNSの結果を永続設定、サーバーの許可リスト、LAN機器との共有に使うべきではありません。

アドレスプールは、実ネットワーク、LAN、他の仮想インターフェースとの衝突を避ける必要があります。クライアントのデフォルト値は一般的な状況を考慮しているため、ログにルーティング競合が出ない限り、むやみに変更しないでください。企業ネットワークが特殊なアドレス帯を使っている場合や、端末にコンテナ、仮想マシン、他のトンネルがある場合は、ルーティングテーブルに重複がないか確認します。競合すると、実アドレスが仮想マッピングと誤認されたり、仮想接続が別のNICに引き受けられたりします。

FakeDNSとDNSサーバーの組み合わせ例

{
  "dns": {
    "servers": [
      "fakedns",
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

スニッフィングとルーティングの連携

FakeDNSとドメインスニッフィングはどちらもコアによるドメイン取得を助けますが、経路は異なります。FakeDNSはDNSクエリの段階で明確な対応付けを作り、クエリが完全に引き受けられるTUN通信に適しています。スニッフィングは後続のプロトコル内容からドメインを識別しようとするため、FakeDNSを通っていない接続にも使えることがあります。両者は併用できますが、すべての問題をスニッフィングに任せないでください。暗号化が強い接続や、識別可能なドメインを含まないプロトコルではスニッフィングが成功しない場合があります。一方、FakeDNSの対応付けはより直接的です。

ルーティングルールは設定された順序で動作します。ドメインを復元した後、精密なドメインルール、ドメイン集合ルール、デフォルトルールが順に照合されます。FakeDNSがドメインを正しく復元したのに通信が誤ったアウトバウンドへ進む場合は、アドレスプールを調整し続けるのではなく、ルールの順序とアウトバウンドラベルを確認します。ログには通常、元の対象、復元後のドメイン、最終アウトバウンドが表示されます。この3つをつなげて見ることで、どの段階に問題があるか判断できます。

有効化に慎重になるべき場面

LAN内部のドメイン、機器検出、印刷サービス、実アドレスの返却に依存するアプリは慎重に扱います。内部ドメインは通常、ローカルDNSで解決して直接接続すべきで、FakeDNSへ入れるべきではありません。DNSが返したアドレスでLANスキャンやアクセス制御を行うソフトは、仮想アドレスを理解できないこともあります。ドメインルールで内部名をFakeDNSから除外し、LANのリゾルバーを直接使う方法があります。アプリが動作に実アドレスを必要とする場合は、アプリ別の迂回設定または実DNSの結果を使います。

サーバープログラム、開発・デバッグツール、実際の対象アドレスを表示する必要があるネットワーク分析では、FakeDNSをデフォルトで有効にするのが適さない場合もあります。仮想アドレスがログに記録され、分析担当者が対象サーバーのアドレスだと誤認する可能性があるためです。パケットキャプチャや再現テストでは、FakeDNSの有効・無効を記録し、ドメイン対応表のログも残してください。そうすれば仮想アドレスを実際の対象へ正しく戻せます。

キャッシュの不一致とアプリの異常

FakeDNSを無効にした後もアプリが古い仮想アドレスを保持するのは、よくある切り替え時の障害です。クライアントは対応表を維持しなくなっているのに、アプリが古いアドレスへ接続し続けるため失敗します。FakeDNSの状態を切り替えた後は、接続を再確立し、関連アプリのバックグラウンドプロセスを終了してください。必要に応じてアプリのDNSキャッシュが失効するまで待ちます。逆方向の切り替えでも同様です。有効化直後にアプリが以前の実アドレスを使い続けると、短時間はFakeDNSの効果が見えないことがあります。

あるアプリだけFakeDNSの有効化直後に異常になり、他のアプリが正常なら、まずそのアプリを一時的に除外して比較します。除外で復旧した場合は、独自DNS、長期的なアドレスキャッシュ、LAN検出への依存、アプリ層での実アドレス検証の有無を確認します。1つのアプリの非互換性だけを理由に、すべてのドメインルーティングを削除しないでください。そのアプリには実名前解決の経路を選び、他のアプリではドメインマッピングの利点を維持する方が合理的です。

各情報源に役割を定義する

多重サブスクリプションは、URLをすべて同じ一覧にインポートすることではありません。各情報源に明確な役割を持たせます。メインは日常利用、予備はメインに問題がある場合だけ使い、テストは新しいプロトコルやトランスポートパラメータの検証に使います。役割によって更新頻度、フィルタリングルール、自動選択への参加可否が決まります。3つの情報源の項目を混在させると、失敗時にどのサブスクリプションが原因か分かりにくくなり、同名サーバーを誤って選ぶこともあります。

名前には個人情報ではなく用途を含めるのがおすすめです。たとえば「メイン｜日常」「予備｜手動更新」「テスト｜一時」のようにします。v2rayNではサブスクリプショングループで情報源の境界を保ち、v2rayNGではグループ数を抑えて分かりやすい別名でモバイル端末の切り替え負担を減らします。v2flyNGをAndroidの代替クライアントとして使う場合も同じ命名原則を使いますが、2つのクライアントが完全に同じローカルグループ構造を保持すると考えないでください。

自動更新には失敗時の保護が必要

自動更新は情報源の変化をすぐ受け取れる一方、サブスクリプションが一時的に空の内容や異常な形式を返した場合、現在の一覧に影響する可能性があります。信頼できる運用では、直近の利用可能な結果を保持し、新しい結果に明らかな異常がある場合は上書きを止めます。クライアントがこの動作に対応しているかは、実際の画面とログで確認してください。判断できない場合は、メインを一定周期で更新し、予備とテストは手動更新にします。これにより不要なリクエストを減らし、すべての情報源が同時に変化するのを避けられます。

更新スケジュールはずらして設定できます。たとえばメインは毎日確認し、予備は切り替え前に手動確認し、テストは実験期間だけ更新します。更新後はまず項目数と現在の選択項目を確認し、その後に一括速度測定や接続テストを行います。速度測定はその時点での到達性しか示さず、プロトコルパラメータの確認の代わりにはなりません。大量の項目が同時に失敗した場合は、個別に削除する前にサブスクリプション形式、システム時刻、ローカルネットワークを確認します。

重複排除は表示名だけで判断しない

2つのサブスクリプションが同じ備考を使っていても、サーバーアドレス、ポート、ユーザー識別子、トランスポート方式、安全設定が異なる場合があります。本当の重複かどうかは、主要な接続パラメータを総合して比較します。逆に同一設定でも、情報源ごとに異なる名前が付くことがあります。重複排除ではまず情報源ごとの境界を保ち、完全に同一だと確認できた項目だけ、安定した情報源から1つを残します。異なるサブスクリプションから生成された項目を追跡不能なローカルコピーへまとめないでください。後続のパラメータ変更を自動同期できなくなります。

複数の端末で状態を揃えたい場合、共有に適しているのはサブスクリプションURLと少量の標準化設定であり、クライアントの完全な状態ではありません。デスクトップのウィンドウレイアウト、速度測定結果、現在の選択項目、Androidのアプリ別リストは端末固有の情報なので、同期を強制すべきではありません。同期できる層はサブスクリプション情報源、標準プロトコルパラメータ、共通のルーティング方針です。端末ごとの層では、システムプロキシ、TUN、アプリ選択、ローカルDNSを個別に管理します。より詳しい方式の比較はサブスクリプションURL、QRコード、設定エクスポートの比較を参照してください。

QRコードとエクスポートファイルの使い分け

QRコードは、自分の端末間で単一の設定をすばやく移行するのに適しています。読み取り後も、プロトコル、アドレス、ポート、トランスポート、安全項目が完全か確認し、備考名だけで判断しないでください。QRコードは、長期的に変化する多重サブスクリプション体系には適していません。生成後に自動更新されないためです。長期運用にはサブスクリプションURLが適しており、単発の移行や少数のテスト設定をオフラインで保存する場合はQRコードが手軽です。

設定ファイルをエクスポートすると、より多くの項目を保存できますが、現在の端末固有のパス、ポート、ローカルルールが含まれることもあります。別のプラットフォームへインポートする前に内容を確認し、その端末に適さないローカル設定を削除してください。アクセス資格情報を含むファイルを公開場所に置かないことも重要です。移行後は、まず新しい端末で単一接続の基準を作り、それからルーティングとDNSを戻します。デスクトップの高度な設定を一度にAndroidへ移すと、権限、ネットワーク入口、アプリ選択の違いが同時にトラブルシューティングの範囲へ入ります。

変更履歴と切り戻しポイントを作る

多重サブスクリプション環境で最も重要なのは、簡潔な変更履歴です。複雑である必要はなく、日付、変更対象、変更前の状態、変更後の状態、検証結果があれば十分です。たとえば「メインに除外語を追加」「予備を手動更新に変更」「Androidにはメインだけをインポート」のように記録します。一覧に異常が出たとき、直近の変更箇所をすぐ判断できます。接続資格情報が関係する場合は、完全な機密情報を複製せず変更の種類だけ記録します。

切り戻しポイントは、「接続できることを確認済み」の状態に基づいて作ります。フィルタリングルールを変更する前に古い式を保存し、一括更新前に現在利用できる項目を記録し、新しい設定をインポートする前に元のグループを残します。更新後に接続できなくなった場合は、まず選択項目とフィルタリング条件を戻し、その後に新しいサブスクリプション内容を判断します。サブスクリプションを戻しながらDNSやTUNも同時に変更しないでください。複数の層を同時に戻すと偶然復旧することはあっても、本当の原因を特定できません。

メインと予備を切り替える検証手順

予備サブスクリプションは、定期的に検証して初めて本当の予備として機能します。常時接続しておく必要はなく、ネットワークが安定しているときに手動更新し、1つの設定を選んで接続テストを行い、基本的なDNSとルーティングが動作することを確認します。テスト後はメインへ戻し、選択項目が意図せずテスト情報源に残らないようにします。メインと予備でプロトコルやトランスポート方式が異なる場合は、それぞれに必要なシステム条件を記録し、障害発生時に未有効の機能へ依存していたことが分かる事態を避けます。

メイン情報源に異常がある場合は、サブスクリプション更新の失敗なのか、既存サーバー接続の失敗なのかをまず判断します。サブスクリプションが一時的に更新できなくても、すでにインポート済みの設定が直ちに無効になるとは限りません。現在の一覧を残してテストを続けられます。サーバー接続も失敗した場合にだけ、予備へ切り替えます。逆に、更新は成功したのに一覧が空なら、まずフィルタリングを無効にして元の内容を確認し、ローカルの絞り込みミスを情報源の障害と誤認しないようにします。

アウトバウンドはルーティングルールの実行先

ルーティングルールは判定だけを行い、実際に接続を確立するのはアウトバウンドです。基本設定には通常、プロキシ、直接接続、遮断のアウトバウンドが含まれます。プロキシアウトバウンドは現在のサーバー接続を担い、直接接続アウトバウンドはローカルネットワークで対象へアクセスし、遮断アウトバウンドは不要な接続を拒否します。カスタムアウトバウンドでは、指定したSOCKS上流、個別の直接接続方針、特定プロトコルの接続などを追加できます。各アウトバウンドには一意で安定した tag を付け、ルーティングからこのラベルを参照します。

ラベル名は機能を表すものにします。たとえば proxy、direct、block、upstream-socks です。「回線1」「テスト2」のように、現在の画面を離れると意味を失う名前は避けます。ラベルを変更する場合は、すべてのルーティングルール、DNSアウトバウンドの参照、チェーンプロキシの関係も同時に変更してください。1箇所だけ変更すると設定の読み込みに失敗したり、一致しないときにデフォルト出口へ流れたりします。

確認しやすい基本構造を作る

カスタム設定はまず3種類の基本アウトバウンドから始め、それぞれのラベルがログに表示されることを確認してから追加の上流を加えます。直接接続には freedom プロトコル、遮断には blackhole を使い、プロキシアウトバウンドは現在のクライアントが生成するか、サブスクリプション設定が提供します。コアの完全な設定を直接編集する場合、接続時にクライアントが設定を再生成する可能性に注意してください。画面にカスタム設定の入口がある場合は、対応する上書きまたはマージ機能を使い、一時ファイルを編集して次回接続で失われる方法は避けます。

基本アウトバウンドとSOCKS上流の例

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    },
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081,
            "users": [
              {
                "user": "example-user",
                "pass": "your-password"
              }
            ]
          }
        ]
      }
    }
  ]
}

例で使うローカルSOCKSサービスは、指定したアドレスとポートで実際に動作している必要があります。そうでなければ、そのアウトバウンドへ振り分けられた接続は直ちに失敗します。上流に認証が不要なら、空文字列を残さず、コアが対応する形式に従ってユーザー項目を削除します。リモート上流へ接続する場合は、そのアドレスが同じアウトバウンドに再び引き受けられ、ループしないことを確認します。アクセス資格情報は管理された自分の設定にだけ保存し、トラブルシューティング用のスクリーンショットやログを共有する前に関連項目を削除してください。

チェーンプロキシの方向を明確にする

チェーンプロキシは、あるアウトバウンドの基盤接続を別のアウトバウンド経由で確立する仕組みです。明確なネットワーク構成が必要な場面に適していますが、遅延、障害点、ログの複雑さが増します。設計前に順序を図にしてください。アプリの通信がクライアントに入り、ルーティングが業務用アウトバウンドを選び、そのアウトバウンドが上流出口を通って対象へ接続します。チェーン内の各層は個別に到達可能であり、上流接続自体が業務用アウトバウンドへ戻らない必要があります。

チェーン構造を検証するときは、まず最外層の上流を単独でテストし、その後に内側の接続を追加します。上流がローカルSOCKSサービスなら、SOCKSに対応したツールでポートが利用できることを確認します。上流もクライアント内のアウトバウンドなら、テストドメインだけを対象にした精密なルールを先に作ります。ログで2つのラベルを想定どおり通過したことを確認してから、対象範囲を広げます。未検証の経路へデフォルト通信をすべて切り替えると、失敗時に名前解決、更新、トラブルシューティングに必要な接続まで失う可能性があります。

DNS通信にも出口を選ぶ

カスタムアウトバウンドを追加しても、DNSリクエストは従来の経路を使い続けることがあります。対象アクセスが upstream-socks を通るのに、リモートDNSが直接接続を通ると、解決場所とアクセス出口が一致しません。一致させる必要があるかは状況次第ですが、偶然に任せず明確に設計します。DNSエンドポイントに精密なルールを追加して指定アウトバウンドを通すことも、内部DNSを常に直接接続にすることもできます。変更後は、DNSエンドポイント接続と対象接続がそれぞれ想定したラベルに一致するか確認します。

DNSループも防ぐ必要があります。上流アウトバウンドのサーバーアドレスがドメイン名で、そのドメインを解決するDNSまで同じ上流へルーティングされると、上流が確立する前に依存関係が循環する可能性があります。上流アドレスに信頼できるブートストラップ解決を用意する、明確に到達可能なアドレスを使う、DNSクエリに独立した直接接続経路を設定するなどの方法があります。重要なのは、上流を確立するための基盤接続が上流自身に依存しないことです。

遮断アウトバウンドと失敗時の見え方

遮断アウトバウンドは、不要な接続を明確に拒否するために使います。見た目は「接続失敗」と似ていますが、ログには通信が block ラベルに一致したことが表示されるはずです。対象へアクセスできない場合は、特に広いドメインサフィックスやポート条件を使っているとき、遮断ルールに捕捉されていないか先に確認します。遮断ルールは適切な優先度に置き、説明可能な範囲に限定します。範囲が広すぎると、正常なリソース、ログイン処理、クライアント更新まで拒否されます。

遮断方法には、静かに破棄するものと、明示的に拒否を返すものがあります。アプリによって見え方は異なり、静かな破棄ではタイムアウトまで待たされ、明示的な拒否ではより早く失敗することが一般的です。方式は、無意味な待ち時間を減らし、アプリとの互換性を保つ観点で選びます。多数の未知の対象を遮断して、明確なアプリ別設定やルーティング設計の代わりにしないでください。説明しにくいルールほど、後の保守コストが高くなります。

クライアント生成設定と手動設定の境界

v2rayN、v2rayNG、v2flyNGはいずれも、画面の設定に基づいてコアの実行設定を生成します。手動の例は項目の関係を理解するためのもので、すべてのクライアントに完全なJSONをそのまま貼り付けられるとは限りません。クライアントがカスタム設定のインポートに対応している場合は、完全な設定、部分的な上書き、単一のアウトバウンド断片のどれを要求しているか確認します。形式が一致しないと、JSON構文が正しくてもクライアント固有の構造が不足して起動できないことがあります。

アップグレードやクライアント切り替えの前に、どの内容がサブスクリプション由来で、どれがクライアント画面由来で、どれが手動上書きか記録します。サブスクリプションのサーバーパラメータは再取得できることが多い一方、複雑なカスタムアウトバウンドとルーティングは個別にバックアップが必要です。バックアップ後はラベル参照をテキストで確認します。各 outboundTag が実在するアウトバウンドに対応し、各チェーン参照に対象があり、各DNSルートが上流確立前に必要な名前解決を完了できることを確認してください。

最小限のルールから段階的に導入する

カスタムアウトバウンドを導入するときは、まず専用のテストドメインを新しいラベルへ割り当て、他の通信はそのまま残します。ログで新しいアウトバウンドへの一致、正しいDNS経路、ループがないことを確認してから、ドメイン集合やアプリの範囲を段階的に広げます。範囲を広げるたびに変更内容を記録し、新しいルールをすぐ削除できる状態にします。失敗した場合は直近の層だけを戻し、確認済みのサブスクリプション、サーバー、基本ルーティングをリセットしないでください。

最終設定は4つの質問に答えられる必要があります。各通信種別にどのルールが一致するか、そのルールがどのアウトバウンドを選ぶか、そのアウトバウンドが基盤接続をどう確立するか、そして確立に必要なDNSがどこを通るかです。どれか1つでも推測に頼るなら、長期運用に適した設定とはいえません。複雑な障害では、まず proxy、direct、block の基本構造へ戻し、そこへカスタム出口を1つずつ追加します。プラットフォームに合うクライアントを選び直す場合は、選び方ガイドとインストールパッケージを参照してください。