V2Ray設定応用ガイド

切り戻せる設定モデルを先に作る

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

応用設定の第一歩はルールを増やすことではなく、各設定をどの階層が担当するかを明確にすることです。v2rayN、v2rayNG、v2flyNG はいずれもGUIクライアントで、サブスク管理、サーバー選択、コアの起動、システムネットワーク設定の書き込みを担当します。Xray または V2Fly コアはプロトコル接続、DNSクエリ、ルーティング判定、インバウンドとアウトバウンドの処理を担います。OSはデフォルトルート、システムプロキシ、仮想NIC、アプリごとのネットワーク権限を管理します。3つの階層が同時に動作している場合、画面に「接続済み」と表示されても、クライアントとコアのプロセスが起動したことを示すだけです。ドメイン解決、ルーティングのヒット、システム通信の取り込みまで正しいとは限りません。

トラブル対応ではデータの流れに沿って確認します。アプリがまずドメインまたは宛先アドレスを生成し、OSが通信をローカルプロキシまたは仮想NICへ渡すか判断します。続いてコアがDNSとルーティングを実行し、最後にダイレクト、プロキシ、ブロックのいずれかのアウトバウンドを選びます。ブラウザーは使えるのにコマンドラインツールが使えない場合は、システムプロキシの継承方法を重点的に確認します。ドメインだけ使えずアドレスへ直接アクセスできる場合はDNSを確認します。特定サイトの一部だけに問題がある場合は、ルールの順序、プロトコル対応、対象サイトのアドレスファミリーを確認します。階層ごとに判断すれば、情報量の少ないクライアント再インストールを繰り返さずに済みます。

基準設定と変更履歴を作る

調整を始める前に、接続できることを確認した基準設定を1つ保存します。基準設定には、利用可能なサブスク1つ、現在のサーバー1つ、デフォルトDNS、デフォルトルート、システムプロキシモードだけを含め、TUN、FakeDNS、複雑なカスタムアウトバウンドは有効にしません。その後、クライアントの種類、現在の設定ファイル、選択中のサーバー、システムプロキシの状態、テスト対象アプリを記録します。v2rayN のデスクトップ版では用途ごとに設定を分けて保存すると便利です。Android では選択中の設定、アプリごとのプロキシ状態、バッテリー設定も記録し、バックグラウンド制限をコアの障害と誤認しないようにします。

変更は毎回1つのテーマだけ扱います。まずサブスクのフィルタリングを完了してテストし、次にルーティングを追加します。ルーティングが安定してからDNSを調整し、最後にTUNとFakeDNSが必要か評価します。DNS、ルーティング、仮想NICを同時に変更すると、失敗しても原因を特定できません。変更履歴は複雑なツールを使わなくても、「変更前、変更内容、期待結果、実際の結果、切り戻し方法」を記した表で十分です。ルールが増えるほど切り戻しが重要になります。サブスク更新、ネットワーク切り替え、OSアップデートによって、これまで表面化しなかった境界条件が現れるためです。

再現可能な検証手順を決める

検証手順は固定してください。そうしないとテスト結果を比較できません。基本確認には、クライアントログで再試行が継続していないこと、テスト用ドメインを解決できること、ブラウザーとブラウザー以外のアプリが接続できること、クライアント停止後にシステムプロキシまたは仮想NICの状態が正しく戻ることを含めます。ルーティングの検証では、ダイレクト、プロキシ、ブロックのルールに明確に該当する3つの対象を選び、普段使うWebページ1つだけで判断しないでください。DNSはクエリ結果と最終的な接続経路を同時に確認し、ブラウザーキャッシュを設定成功と取り違えないようにします。

Windowsでは Get-NetIPInterface でインターフェースの優先度を確認でき、macOSでは scutil --dns でシステムリゾルバーを確認できます。Linuxでは ip route でルーティングテーブルを確認します。コマンドの出力はシステム状態を確認するためのもので、クライアント内部のルールが必ずヒットしたことを示すものではありません。Androidでは、クライアントログ、ネットワーク切り替え、アプリごとのテストを組み合わせて判断するのが適しています。適切なクライアントをまだインストールしていない場合は、クライアントページでプラットフォームに合うものを選んでください。デスクトップでは v2rayN、Androidではコアの要件に応じて v2rayNG または v2flyNG を推奨します。

サブスク分けとサーバーフィルター

分けるのは管理のため、ルーティングは通信のため

サブスク分けはルーティングの振り分けと誤解されがちです。分ける機能が担当するのはサーバーの整理、選択範囲の縮小、更新範囲の指定であり、どのサイトがどのアウトバウンドを通るかは決めません。通信経路を実際に制御するのはルーティングとアウトバウンドタグです。構成としては、まず提供元ごとにサブスクを保存し、次に用途や機能でビューを作り、最後にルーティングから安定したアウトバウンドを参照します。サブスク名、サーバー名、アウトバウンドタグを同じ階層として扱わないでください。サブスク更新で名前が変わると、名前に依存したフィルターとルールが同時に機能しなくなる可能性があります。

「提供元グループ」と「作業グループ」の2つの軸を分けて管理することをおすすめします。提供元グループはサブスクURLに対応し、個別の更新、一時停止、削除をしやすくします。作業グループはプロトコル、通信方式、地域名、手動で決めた用途などで絞り込みます。v2rayN のサーバー一覧では、備考、サブスクの所属、フィルター式を使って範囲を絞ると便利です。v2rayNG と v2flyNG のモバイル画面では、複雑な条件を小さな画面で管理しないよう、グループ数を少なめに保つのが適しています。グループ名は安定して読みやすいものにし、一時的な状態を書き込まないでください。

保守しやすいフィルター条件を設計する

サーバーフィルターは通常、備考の文字列をもとに動作するため、正確さは命名品質に左右されます。「含める条件を優先し、除外条件で補う」方法がおすすめです。まず明確なプロトコルや用途を限定し、その後テスト項目、期限切れ項目、不要な通信方式を除外します。フィルター式はできるだけ短くし、サブスク更新後に結果を抜き打ち確認します。提供元が命名形式を変更した場合は、手作業で1件ずつ名前を直すのではなく、フィルター条件を更新してください。次回の更新でローカルの変更が上書きされる可能性があるためです。重要なサーバーにローカル備考を追加する場合は、更新時にその項目が保持されるか確認します。

正規表現は命名形式が安定している場合に適しており、曖昧な文字列の推測には向きません。次の例は、名前に「VLESS」または「REALITY」を含み、「テスト」と「期限切れ」を除外します。クライアントによって正規表現入力欄の対応状況が異なるため、まず少数の項目で結果を確認してから一覧全体に適用してください。画面が通常のテキスト検索にしか対応していない場合は、複数の単純なビューに分け、1つのキーワードですべての条件を表そうとしないでください。

^(?=.*(?:VLESS|REALITY))(?!.*(?:テスト|期限切れ)).*$

フィルター結果が空の場合は、まず除外条件を外し、その後に式を少しずつ追加します。結果が多すぎる場合は、大文字と小文字、全角記号、提供元の命名が一致しているか確認します。フィルターはサーバーの接続可否を検証するものではなく、実際の接続テストの代わりにもなりません。遅延は特定時点の往復時間を示すだけで、スループット、安定性、プロトコル適合性を完全に表すものではありません。サーバーを選ぶときは、ログのハンドシェイク結果、継続アクセスの状況、ネットワーク切り替え後の復旧状況も確認し、1回の順位だけで判断しないでください。

更新、削除、重複項目の扱い

サブスクは提供元ごとに1つずつ更新します。まず1つを更新し、サーバー数、名前、現在選択中の項目が変わったか確認してから、次の提供元に進みます。すべてを同時に更新すると、重複や異常な命名が一気に広がり、原因を特定しにくくなります。サブスクを削除する前に、現在使用中のサーバーやカスタムルーティングがその提供元に依存していないか確認してください。クライアントによってはサブスク由来の過去のサーバーを保持し、別のクライアントでは更新時に上書きします。操作前に画面の更新方針を確認し、必要ならクライアント設定を先にエクスポートします。

重複サーバーは表示名だけで判断できません。同じ名前でもアドレス、ポート、プロトコルパラメーターが異なる場合があり、同じパラメーターでも別のサブスク由来の場合があります。安全に処理するには、プロトコル、サーバーアドレス、ポート、トランスポート層、セキュリティパラメーターを比較してから残すか決めます。複数の提供元が同じ項目を継続的に提供している場合は、より安定し命名が整っている提供元のものを残し、他は停止グループに入れるとよいでしょう。すぐに削除しなければ、更新に問題が起きたときの切り戻し経路を確保できます。

自動選択機能にも明確な範囲設定が必要です。候補集合内の手動切り替えを減らせますが、候補は事前に絞り込み、テスト方法も実際の利用状況に近づける必要があります。プロトコル性能やネットワーク経路が異なるサーバーをすべて同じ自動グループに入れると、接続動作が頻繁に変わり、DNSキャッシュ、長時間接続、トラブル対応に影響します。安定性を優先する場合は、一定期間サーバーを固定してログとアプリの動作を観察します。候補の互換性を確認してから自動化を有効にしてください。

ルーティングのマッチ順序と実践的な構成

上から順に最初の一致を理解する

V2Rayルーティングの要点はルール数ではなく、マッチ順序です。多くの設定ではリストを上から順に判定し、接続が最初に条件へ一致すると、その後のルールは確認しません。具体的なルールは汎用ルールより前に置き、ブロックルールは明確で安定した対象に限定し、最後にフォールバック経路を設定します。範囲の広いドメイン、アドレス、ポートのルールを先頭に置くと、後続の細かなルールは構文が正しくても機能しません。

保守しやすい順序は、通常、まず内部アドレスとローカルサービス、次に明確なブロック対象、その後に指定経路が必要なドメインまたはアドレス集合、続いてよく使うダイレクト接続集合、最後にデフォルトアウトバウンドです。ルール内の条件の組み合わせと、複数ルール間の順序を区別してください。同じルールに複数のフィールドを記述すると、通常は各条件をすべて満たす必要があります。同じフィールドの複数値は、いずれかに一致すればよいことを示します。設定前に意図を自然言語で書き、それをルールへ置き換えてください。

ドメイン、アドレス、プロセス条件の境界

ドメインルールは、コアが宛先ドメインを取得できる場合にだけ機能します。アプリが先に自分で名前解決し、アドレスへ直接接続すると、コアに見えるのは宛先アドレスだけになることがあります。その場合はアドレスルール、DNSスニッフィング、TUNの併用が必要です。アドレスルールは比較的安定しますが、大規模サービスのアドレス範囲は変化するため、手動管理の負担が高くなります。GeoSiteはドメイン分類、GeoIPはアドレスの所属によるマッチに適しています。どちらのデータも更新が必要です。具体的な更新方法はGeoIP・GeoSiteデータベース更新ガイドを参照してください。

プロセス条件はOSとクライアントの実装に依存するため、唯一の判定材料にしないでください。インストール方法、補助プロセス、アプリの更新によってプロセス名が変わる場合があり、同じアプリでもシステムサービス経由で通信することがあります。デスクトップではプロセスルールを細かな振り分けの補助に使えますが、基礎としてドメインまたはアドレスルールも用意してください。Androidのアプリごとのプロキシは、どのアプリを仮想ネットワークへ入れるかをシステム層で選択します。これはコアのルーティングとは前後2段階の判定で、前者が進入可否、後者が進入後のアウトバウンドを決めます。

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

例にある IPIfNonMatch は、まずドメインルールで判定し、ドメインに一致しなければアドレスルール用に名前解決することを示します。アドレスルールの適用範囲を広げられますが、コアDNSが判定に参加するため、DNS章のサーバーとクエリ方針を一緒に設計する必要があります。常にアドレスで判定する設定では、ドメインリクエストの解決回数が増えます。まったく解決しなければ、ドメイン情報だけを持つ接続はアドレス集合に一致しません。すべてのネットワークに適した固定値はないため、GeoIPへの依存、アプリがドメインを提供するか、DNS経路をもとに選択してください。

ページの結果を推測せず、ログでルールを検証する

ルール検証では、対象、マッチ条件、最終アウトバウンドの3点を確認します。まずブラウザーのDNSと接続キャッシュを消去し、接続を再利用するテストページを閉じて、新しいリクエストを送ります。ログで対象がすでにアドレスになっていれば、アプリの名前解決またはスニッフィングを確認します。対象ドメインが正しいのに誤ったアウトバウンドへ入る場合は、ルール順序とドメイン表記を確認します。アウトバウンドが正しいのに接続できない場合は、プロトコルパラメーター、サーバー状態、ネットワーク経路を確認し、ルーティングをさらに変更しないでください。

ドメインの記述方法にも違いがあります。完全修飾ドメインは1つのホスト名だけに一致し、ドメインサフィックスはサブドメインまで対象にし、キーワード一致は範囲が最も広く誤判定しやすい方法です。完全なドメイン名または適切に管理されたドメイン集合を優先し、キーワードは対象の命名が安定していて列挙できない場合だけ使います。ポートルールにはプロトコルを明記してください。同じポートでTCPとUDPの両方が使われる場合があります。UDPをブロックする際は、アプリがTCPへ自動フォールバックする可能性も考慮します。表面上アクセスできても、ブロックルールが機能していないとは限りません。

ルーティングを変更したら、内部サービス、明確なダイレクト対象、明確なプロキシ対象、ブロック対象、未一致対象の順にテストします。内部アクセスの異常は、プライベートアドレスルールの位置が誤っていることが多く、すべての対象が同じ経路を通る場合はフォールバックルールが早すぎる可能性があります。ドメインだけ失敗する場合は、DNSとルーティングが循環している可能性があります。接続後にWebページが開かない場合は、12項目のトラブル対応チェックリストに沿って、ローカル設定、ノード、ルーティング、名前解決の4層を確認してください。

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

クエリがどこから送信されるかを先に描く

DNSの問題が特定しにくいのは、システムリゾルバー、ブラウザーのセキュアDNS、クライアントコアのDNS、リモート側の名前解決が同時に存在するためです。アプリはドメインをシステムへ渡すこともあれば、自ら暗号化クエリを送ることもあります。システムプロキシモードでも、一部のアプリはシステムDNSを直接利用します。TUNモードはより広い範囲のクエリを取り込めますが、ハードコードされたリゾルバーや特殊プロトコルが残る場合もあります。設定前にテスト対象アプリがどの経路を使うかを確認し、コアに処理させるか決めてください。クライアントにDNSアドレスが入力されているだけで、すべてのクエリがそこを通ると考えてはいけません。

名前解決の経路には、少なくとも3つの判断があります。どのサーバーへクエリを渡すか、クエリ通信をどのアウトバウンドで送るか、返された結果をルーティングに使うか接続だけに使うかです。DNSサーバーのアドレス自体をプロキシ経由にする必要があり、そのプロキシ接続も同じDNSに依存すると、起動時の循環が発生します。基礎接続用に直接アクセスできるリゾルバーを残すか、解決済みの固定ドメインと独立した経路を使ってください。最適化は、まず起動経路を閉じたうえで、キャッシュ、並列処理、アドレスファミリーの優先度を検討します。

ドメイン範囲でリゾルバーを選ぶ

ドメインごとに異なるDNSサーバーを使えますが、振り分けの基準は明確にします。内部ドメインやLAN機器は、検索ドメイン、プライベートゾーン、ローカルアドレスに依存することがあるため、通常はシステムまたはLANのリゾルバーへ渡します。パブリックドメインはコアのリゾルバーへ渡せます。特定のアウトバウンドと経路を揃える必要があるドメインは、名前解決も同じ経路から送ると、解決結果と接続出口の不一致を減らせます。すべてのクエリを複数サーバーへ並列送信し、最初の応答を採用する方法は避けてください。結果の出所が不安定になり、トラブル対応が難しくなります。

設定内の hosts は、ローカルのテストサービスや固定エイリアスが必要な内部リソースなど、少数の安定したマッピングに適しています。大規模なドメインルールデータベースではなく、通常の名前解決の代わりにもなりません。頻繁に変わるマッピングは静的項目が古くなりやすい点に注意してください。1つのドメインにIPv4とIPv6の両方のレコードがある場合は、システムネットワークに対応するアドレスファミリーの経路があるか確認します。片方の応答だけを無効にすれば表面的な障害を回避できますが、システムのルーティングや上流ネットワークの問題を隠す可能性があります。

{
  "dns": {
    "hosts": {
      "router.home.arpa": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "domain:router.home.arpa",
          "domain:service.example.invalid"
        ]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

この例はフィールド間の関係を示すものです。ローカルドメインは優先してローカルリゾルバーへ渡し、それ以外のクエリには後続のサーバーを使います。実際の環境では、現在のネットワークから到達でき、用途が明確なリゾルバーを選んでください。queryStrategy は返すアドレスファミリーの範囲を制御し、UseIP は利用可能なアドレスを問い合わせます。IPv4またはIPv6だけを問い合わせるかどうかは、実際のネットワーク性能にもとづいて決めます。クライアントが生成する設定ではフィールド形式が異なる場合があります。GUIにDNSモードがある場合は、同じ設定を重ねてインポートしないでください。後から生成されたフィールドが先の設定を上書きする可能性があります。

キャッシュ、ブラウザー、汚染の見分け方

DNSを変更した直後に同じページへ再アクセスしても、古いキャッシュが使われていることがあります。キャッシュはブラウザー、システムサービス、コア、対象アプリの4か所に存在します。検証時は新しい接続を作り、まだ問い合わせていないテスト用ドメインを使うか、システムの方法でDNSキャッシュを更新してください。ブラウザーで独立したセキュアDNSが有効になっている場合は、一時的に無効化するか、クライアントの設計と一致するよう明示的に設定します。そうしないと、ブラウザーが正常でも他のアプリが失敗する理由は、異なる名前解決経路を使っていることだけになります。

異常な結果を判断するときは、「システムの問い合わせ結果、コアの問い合わせ結果、最終接続アドレス」の3つを比較し、1つのコマンド出力だけで判断しないでください。システムの問い合わせは正常でもコアが失敗する場合は、コアDNSのアウトバウンドとルーティングを確認します。コアの問い合わせは正常でもアプリが失敗する場合は、アプリがプロキシを迂回していないか、古い接続を再利用していないか確認します。アドレスが正しいのに接続がタイムアウトする場合、問題はDNS層を離れているため、ルーティング、プロトコル、サーバーを確認します。名前解決が一時的に遅くなっただけで、すぐにサーバーを変更する必要はありません。まずネットワーク切り替え、初回ハンドシェイク、キャッシュミスが原因でないか観察します。

DNSとルーティングは一緒に検証してください。IPIfNonMatch などの方針では、ルーティング判定が名前解決を開始することがあります。DNSクエリ自体もルーティングシステムを通ります。DNSサーバーのドメインが、解決結果に依存するルールに一致すると、再帰が発生する可能性があります。リゾルバーに明確なアウトバウンドを設定し、基礎サーバーのアドレスを直接到達可能にし、関連ルールを汎用ルールより前に置くことで、循環のリスクを下げられます。設定が安定してから、ドメインごとにリゾルバーを割り当てる細かなルールを追加します。

TUNモードの有効化手順と適用範囲

TUNとシステムプロキシは処理対象が異なる

システムプロキシは、OSのプロキシ設定に従うアプリへプロキシアドレスを提供します。設定が簡単で切り戻しも明確ですが、システムプロキシを無視するプログラムや一部のUDP通信は対象外です。TUNモードは仮想ネットワークインターフェースを作成し、より広い範囲のIP通信をクライアントへ取り込み、コアでDNS、ルーティング、アウトバウンドを選択します。これは「より強力なスイッチ」ではなく、システムのデータ経路を変更するネットワークモードです。そのため、ルーティングテーブル、DNSの取り込み、インターフェース優先度、ローカルネットワークアクセスを追加で扱う必要があります。

TUNを有効にするかどうかは、アプリの要件で決めます。ブラウザー、一般的なデスクトップソフト、開発ツールがシステムプロキシを正しく利用できるなら、設定を複雑にするためだけに切り替える必要はありません。プロキシ設定を読み取らないアプリ、UDP通信、統一した振り分けを扱う必要がある場合にTUNを検討します。Androidクライアントは通常、システムの仮想ネットワーク機能で通信を取り込み、アプリごとの選択も組み合わせられます。デスクトップでは、インターフェースの作成とルートの書き込みにシステム権限が必要になることがあります。プラットフォームによって権限の見え方は異なりますが、検証の考え方は同じです。インターフェースの作成、デフォルト経路の変更、DNSが想定経路に入ること、クライアント停止後のネットワーク復旧を確認します。

最小構成で有効化する

有効化する前に、仮想NICを作成したり、デフォルトルートを変更したり、DNSを取り込んだりする他のネットワークツールを停止します。2つのルーティングが競合するのを避けるためです。検証済みのサーバーを1つ残し、最小限のルーティングだけを使い、FakeDNSは有効にせず、システムファイアウォールも同時に変更しないでください。TUNを起動したら、まずクライアントログでインターフェース作成の成功を確認し、次にローカルゲートウェイ、通常のドメイン、明確にプロキシ経由にする対象をテストします。最初からローカルゲートウェイへアクセスできない場合は、プライベートアドレスのダイレクト接続とルート除外を優先して確認し、リモート側のプロトコルパラメーターを変更し続けないでください。

WindowsではPowerShellでインターフェースとルートの優先度を確認できます。macOSでは現在のデフォルトルートとDNSリゾルバーを確認します。Linuxではルーティングテーブル、ポリシールーティング、DNSサービスの状態を同時に確認してください。以下のコマンドは状態を読み取るだけで、システム設定は変更しません。出力にはクライアントが作成した仮想インターフェースが現れるはずですが、名前はクライアントとOSによって決まるため、固定名を前提に自動判定を記述しないでください。

# Windows PowerShell
Get-NetIPInterface | Sort-Object InterfaceMetric

# macOS
route -n get default
scutil --dns

# Linux
ip address
ip route
ip rule

LAN、ループバック、ルーティングループを扱う

TUNで最も多い障害は、取り込むべきでない通信を再び仮想インターフェースへ送ってしまうことです。プロキシサーバー自身の接続はTUNルートから除外する必要があります。そうしないと、コアがアウトバウンドを確立するとき、その通信が再びインバウンドへ送られて循環します。LANセグメント、ループバックアドレス、ローカルサービス、必要なシステムネットワークの検出も、要件に応じてダイレクト接続にします。プライベートアドレスルールは基本ですが、企業ネットワークではより複雑な内部セグメントやドメインを使うことがあります。実際のルーティングテーブルに合わせて補い、汎用リストだけに依存しないでください。

有効化後、クライアントは接続済みなのにすべてのアプリがタイムアウトする場合は、まずサーバーアドレスがTUNに再捕捉されていないか確認します。インターネットは正常なのにLAN機器へ届かない場合は、プライベートアドレスのダイレクト接続とローカルインターフェースのルートを確認します。UDPアプリだけが異常な場合は、コアのアウトバウンドが対象通信に対応しているか、ルーティングがUDPを許可しているか、システムファイアウォールが仮想インターフェースを遮断していないか確認します。TUN停止後も接続できない場合は、クライアントが正常終了し、システムDNS、デフォルトルート、システムプロキシを復元したか確認します。

モバイルネットワークと無線ネットワークの切り替えでは、基盤となるインターフェース、アドレス、DNSが変わります。TUNクライアントは現在のネットワークへ再バインドする必要があり、短時間の中断は経路再構築の過程です。失敗が続く場合は接続を再起動し、古いインターフェースを参照していないか確認します。ノートPCがスリープから復帰した後にも同じ問題が起こることがあります。トラブル対応では、障害が「初回起動、ネットワーク切り替え、スリープ復帰、長時間稼働」のどの段階で発生したかを記録してください。「接続できない」とだけ説明するより、はるかに有用です。

性能とMTUを判断する

TUNはユーザー空間の処理を1層追加しますが、性能問題を直接仮想NICのせいにしてはいけません。同じサーバー、同じネットワーク、同じルーティングルールで、システムプロキシとTUNの動作を比較し、CPU使用率、ログの再試行、特定サイトの挙動を観察します。小さなリクエストは正常なのに大きなページやファイル転送が止まる場合は、MTUや経路上のフラグメントが関係している可能性があります。すべてのリクエストが均等に遅い場合は、DNS、サーバー経路、プロトコルのハンドシェイクを優先して確認します。比較テストなしにMTU、同時実行数、バッファーを同時に変更しないでください。

MTUはクライアントのデフォルト値から始めます。「大きなパケットだけ異常で、小さなパケットは正常」という現象が安定して再現し、サーバーやネットワークを変えても続く場合にだけ、少しずつ下げてテストします。値を変更したら接続を作り直し、古い接続が再利用されていないことを確認してください。仮想NICの仕組み、プラットフォームごとの操作、競合事例についてはV2Ray TUNモード詳解も参照できます。この章の要点は、TUNを独立したスイッチではなく、設定全体の連鎖の中に置いて考えることです。

FakeDNSの仕組みと適用条件

FakeDNSが解決するのはドメイン情報の欠落

一部のアプリはローカルでドメインを解決してから、宛先アドレスへ接続します。コアが通信を受け取ったときに見えるのがアドレスだけだと、ドメインルーティングを直接適用できません。FakeDNSはドメインに専用アドレスプール内の一時アドレスを返し、ドメインとそのアドレスの対応を記録します。接続がコアに到達すると、マッピングから元のドメインを復元してドメインルーティングを実行します。目的はルーティングに必要なドメイン情報を保持することであり、パブリックDNSを高速化することではありません。

FakeDNSは通常、TUNまたはDNSを取り込めるインバウンドと組み合わせます。アプリのDNSクエリがコアに入らなければ専用アドレスを取得できず、マッピングも作成されません。クエリがコアに入っても、その後の接続がTUNを迂回すると、システムは専用アドレスへ直接アクセスしようとして失敗します。そのため、DNSクエリの経路と接続経路を同時に取り込む必要があります。有効化する前に、通常のTUNと実DNSが正常に動作することを確認してください。そうしないとFakeDNSの追加で変数が増えるだけです。

アドレスプール、マッピング、フォールバック

専用アドレスプールは、実際のLAN、企業ネットワーク、他の仮想ネットワークが使うセグメントと重複させないでください。重複すると、実在する内部サービスがFakeDNSへ誤送信されたり、一時アドレスが誤ったインターフェースへ渡ったりします。アドレスプールの容量は同時に保持できるマッピング数を決めますが、むやみに大きくする必要はありません。容量不足では古いマッピングが回収され、長時間接続やキャッシュを使うアプリで不一致が起こることがあります。適切なキャッシュ期間を保ち、クライアント再起動やネットワーク切り替え後には新しい接続でテストすることを優先します。

すべての通信がFakeDNSに適しているわけではありません。LAN機器の検出、内部ドメイン、システムの検索ドメインが必要なサービス、実アドレスで判定するアプリは、実DNSを残すかバイパスを設定します。専用アドレスを正しく扱えないアプリには、アプリごとの除外を使うか、該当ドメインを通常のDNSへ送ります。互換性の問題を単純にサーバー障害と考えないでください。FakeDNSを無効にすると同じサーバーがすぐ復旧し、通常のTUNは常に正常なら、ドメインマッピング、スニッフィング、アドレスプールの競合を確認します。

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

この断片は一般的なフィールド間の関係を示すものです。実際のクライアントでは、画面から対応する設定が生成される場合があります。198.18.0.0/15 はベンチマーク用ネットワークに使われることが多く、専用マッピングプールに適していますが、ローカル環境で使用されていないことを確認してください。設定後、外部ネットワークからプール内のアドレスへ直接アクセスしてはいけません。これらのアドレスはローカルコアのマッピング内でのみ意味を持ちます。ログでそのアドレスへのリクエストが確認できるのにドメインが復元されない場合、DNSクエリと接続が同じマッピングコンテキストを使っていないか、マッピングが失効している可能性があります。

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

スニッフィングは、一部のTCP、TLS、HTTP通信からドメインを復元できます。FakeDNSは、制御下にあるDNSマッピングからドメインを復元します。両者は似た問題を解決しますが、情報源が異なります。スニッフィングは通信内に識別可能な情報があることに依存し、すべてのプロトコルに適用できるわけではありません。FakeDNSはクエリと接続の両方がコアを通ることに依存します。クライアントのデフォルト方針に従って併用できますが、最終的にどの対象をルーティングに使うかを明確にしてください。ログの対象ドメインがアプリのリクエストと一致しない場合は、対象の上書き方針を確認し、誤ったスニッフィング結果で元の対象を置き換えないようにします。

FakeDNSが一時アドレスを返しても、実DNSが完全に不要になるわけではありません。コアが最終的に対象サーバーへ接続するとき、実アドレスの取得が必要になることがあります。ルーティングでGeoIPを使う場合も、実際の解決結果が必要になる場合があります。そのため、設定には通常FakeDNSと通常のリゾルバーが同時に存在し、段階ごとに役割を分担します。通常のリゾルバーのアウトバウンド設定に誤りがあると、ドメインの復元は成功したのに最終接続だけ失敗することがあります。ログではマッピングのヒットと実アドレスの解決を分けて確認してください。

有効化後の検証は4段階に分けます。まずアプリが専用アドレスを取得したことを確認し、次に接続がTUNへ入ったことを確認します。その後、コアのログで元のドメインが復元されたことを確認し、最後にドメインルーティングが想定アウトバウンドに一致して実接続が完了したことを確認します。最初の段階だけでは設定完了とはいえません。ブラウザーは使えるのに特定のアプリが失敗する場合は、そのアプリがアドレスをキャッシュしていないか、独自DNSを使っていないか、仮想ネットワークを迂回していないか確認します。古いマッピングの影響を避けるため、アプリを完全に終了して接続状態を消去してから再テストしてください。

切り戻すときは、FakeDNSサーバー、アドレスプール、対象上書きに依存する設定を同時に無効化し、通常のDNSへ戻します。1つだけ停止すると専用アドレスのキャッシュが残り、しばらく無効な対象へアクセスし続ける可能性があります。切り戻し後はクライアントとテスト対象アプリを再起動し、解決結果が実アドレスへ戻ったことを確認します。FakeDNSは明確なドメインルーティングが必要で、通常のスニッフィングでは不十分な場合に適しています。すべての設定で必須にするものではありません。

多重サブスク管理と更新方針

サブスクを外部設定ソースとして扱う

多重サブスク管理の要点は、一覧により多くのサーバーを入れることではなく、外部設定の変化を制御することです。各サブスクは名前、プロトコルパラメーター、項目数、利用可能範囲を変更する可能性があるため、個別の名前、更新ペース、停止状態を設定します。サブスクURLはクライアントのサブスク管理だけに保存し、ルーティングの備考、スクリプト出力、共有スクリーンショットへコピーしないでください。複数の端末で使う場合は端末ごとにインポートし、用途に応じたローカルグループを作ります。デスクトップとモバイルでまったく同じサーバー集合が必要だと考えないでください。

各提供元について、用途、対象クライアント、最後に正常更新できた日時、異常時の対応方法を記録することをおすすめします。ここでいう更新日時はローカル管理用で、サーバー名に書く必要はありません。長期間使わないサブスクは、まず自動更新を停止し、依存関係がないことを確認してから削除します。直接削除すると、現在のサーバーが消えたりグループ構成が崩れたりすることがあります。v2rayN は大きな一覧画面で差分を確認できるため、デスクトップの多重サブスク管理に適しています。v2rayNG と v2flyNG では、モバイルで本当に必要な提供元だけを残し、バックグラウンド更新と手動選択の負担を減らします。

時間をずらした更新と変更確認

複数のサブスクを同じ時刻に一括更新しないでください。まずリスクの低い提供元を更新し、追加、削除、名前変更、プロトコル変更を確認してから次へ進みます。更新後に現在のサーバーが置き換わった場合は、同じ提供元の確認済み項目を選んでテストします。項目が大量に消えた場合は、すぐに再更新したり一覧を消去したりせず、現状を残してクライアントログを確認してください。繰り返し操作すると、切り戻しに使える情報まで上書きされる可能性があります。自動更新の間隔も短くしすぎないでください。頻繁すぎる更新は、ネットワーク切り替えや提供元の一時的な障害で一覧を何度も変化させます。

変更確認では少なくとも4項目を確認します。項目数に異常な急増や急減がないか、表示名がフィルターで引き続き認識できるか、現在選択中のサーバーが残っているか、プロトコルとトランスポートパラメーターが変わっていないかを確認してください。名前の変更は整理に影響しますが、パラメーターの変更は接続に影響します。提供元が異なるプロトコル性能を使い始めた場合は、表示名だけでなく作業グループも調整します。サブスク形式の識別と変換範囲についてはV2Rayサブスク形式完全解説を参照し、共有リンク、エンコード済みリスト、ネイティブ設定を同じ構造として扱わないようにしてください。

重複排除、優先度、障害分離

重複排除は表示名だけでなく、接続の識別情報にもとづいて行います。プロトコル、アドレス、ポート、ユーザー識別子、通信方式、セキュリティパラメーターを比較してください。別のサブスクに由来する完全一致の項目にも、提供元としての価値があります。片方の更新が失敗しても、もう片方が維持される可能性があるためです。重複項目を低優先度グループに入れ、普段の一覧を整理しながら切り戻し能力を残す方法もあります。クライアントが複雑なビューに対応していない場合でも、少なくともサブスク名で提供元を明確に分けてください。

優先度は安定性のために設定します。固定用途のアプリには継続的に検証したサーバーを使い、臨時のテスト項目と混在させません。テスト用の提供元は独立したグループに入れ、自動的にデフォルト選択されないようにします。多重サブスクの自動選択は、互換性のある候補集合内でのみ使ってください。プロトコル、トランスポート、ネットワーク経路に大きな差がある項目は、同じ高速切り替えグループに適しません。接続の変化をDNS、ルーティング、アプリの問題と誤認しやすくなるためです。

障害を分離するときは、まず自動更新と自動選択を停止し、既知の正常なサーバーを1つに固定してから、提供元を1つずつ確認します。すべての提供元が失敗するなら、ローカルネットワーク、システムの取り込み、共通設定に原因がある可能性が高くなります。1つの提供元だけが失敗するなら、その提供元の名前解決、パラメーター変更、項目状態を重点的に確認します。同じ提供元が v2rayN では正常でAndroidクライアントでは異常な場合は、コアファミリー、トランスポート対応、システムネットワーク権限、モバイルネットワークの制限を比較します。デスクトップ設定をそのまま全部コピーしないでください。

バックアップ範囲と復元順序

バックアップには、サブスク定義、手動サーバー、カスタムルーティング、DNS、アウトバウンド、クライアント設定を含めます。ただし復元時にすべてを一度にインポートしないでください。まずサブスクとサーバー1つを復元して基礎接続を確認し、次にルーティングとDNSを戻し、最後にTUN、FakeDNS、カスタムアウトバウンドを復元します。クライアント間で移行する場合は、共通する接続パラメーターとルールの意図を優先し、画面からエクスポートした固有フィールドが別クライアントでも認識されるとは考えないでください。

バックアップファイルは機密性の高い設定なので、管理された場所だけに保存し、公開共有しないでください。問題を示す必要がある場合は、サブスクURL、サーバーアドレス、ユーザー識別子、認証フィールドを削除し、構造に関係する断片だけを残します。ログにも対象ドメインや接続情報が含まれることがあるため、トラブル対応資料を提出する前に確認してください。復元後は変更履歴を作り直し、古いバックアップと現在のサブスク状態を混在させないようにします。

多重サブスク管理の最終目標は3つあります。どの提供元に異常があっても全設定へ影響しないこと、更新後に変更点をすぐ把握できること、提供元を削除または停止してもルーティングとアウトバウンドが壊れないことです。これを実現するのは、安定した命名、階層的なグループ分け、時間をずらした更新、明確な切り戻しであり、自動化スイッチを増やすことではありません。提供元が増えるほど、暗黙の動作を減らしてください。

カスタムアウトバウンド、チェーン経路、統一トラブル対応

安定したタグでルーティングとアウトバウンドをつなぐ

カスタムアウトバウンドは、ルーティングルールが実行する対象です。一般的な基本アウトバウンドにはプロキシ、ダイレクト、ブロックがあり、複雑な設定では指定サーバー、DNS専用経路、チェーンの前置き経路を追加することもあります。各アウトバウンドには、proxy、direct、block、dns-out のように、安定して意味の明確なタグを付けてください。ルーティングルールが参照するのはタグであり、画面上の一時的な表示名ではありません。タグを変更する前に、すべてのルーティング、DNS、チェーン関係を確認し、構文は正しくても参照先が存在しない状態を避けます。

アウトバウンドの数は最小限に保ちます。名前が違うだけでプロトコルと経路が完全に同じ2つのアウトバウンドは、統合してルーティングで対象を分けてください。接続パラメーター、前置経路、アドレスファミリー、ネットワーク方針が実際に異なる場合だけ、独立したアウトバウンドを作ります。似たアウトバウンドが多いとログの読み取りが難しくなり、サブスク更新後に期限切れのサーバーを指す原因にもなります。GUIクライアントが自動生成する主プロキシアウトバウンドは、現在のサーバーに応じて変わることがあります。カスタムルールでは、置き換えられる内部タグではなく安定した入口を参照しているか確認してください。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

この例は、ダイレクトとブロックの基本的なアウトバウンド構造を示します。実際のクライアントでは通常、プロキシアウトバウンドが自動生成されるため、手動の断片でクライアントが管理するサーバー設定を上書きしないでください。freedom アウトバウンドのドメイン方針は、ダイレクト接続時の宛先解決方法を決めます。グローバルDNSとシステムのアドレスファミリーに合わせてください。blackhole は一致した通信を明示的に拒否するために使います。ブロック後にアプリがタイムアウトや接続失敗を表示するのは想定された結果です。ルールが機能したかどうかは、アプリの表示文言ではなくアウトバウンドタグで確認します。

チェーン経路の前提条件

チェーンアウトバウンドでは、1つの接続を前置きアウトバウンドへ通してから、後続のアウトバウンドを確立します。明確な経路要件がある場面に適していますが、ハンドシェイク層、障害点、ログの複雑さが増します。設定前に、前置きサーバーと最終サーバーをそれぞれ単独で確認し、どの区間がDNS解決を担当するかを明確にしてください。前置き接続自体が最終経路に依存すると循環が起こります。2段階で異なる名前解決を行うと、最終対象アドレスが想定と異なる可能性もあります。

チェーン経路は安定性を高める万能策ではありません。1段追加するたびに、接続確立、タイムアウト、パラメーター一致の処理が増えます。まず単一アウトバウンドでアプリ、ルーティング、DNSを検証し、その後に前置き経路を追加してください。テストでは、1段目のハンドシェイク成功、2段目の開始、最終対象の確立をそれぞれ記録します。ログに「接続失敗」とだけ表示される場合は、最初の段階から確認し、すぐに最終サーバーのせいにしないでください。

すべての候補が同じプロトコル性能とネットワーク動作を検証済みでない限り、チェーンの前置きに動的な自動選択を使わないでください。前置き経路が頻繁に変わると、長時間接続が切れ、DNSと出口の関係も変わります。より安定した方法は、前置きアウトバウンドを固定し、一定期間観察してから自動方針を評価することです。チェーン設定で問題が起きた場合、最初の切り戻しはチェーン関係を解除して単一アウトバウンドへ戻すことであり、ルーティング例外をさらに増やすことではありません。

DNS専用アウトバウンドと通信の分離

DNS専用アウトバウンドを作るとクエリ経路を明確にできますが、ブートストラップの循環を避ける必要があります。専用アウトバウンドが使うサーバーアドレスは、基礎ネットワークで解決できるか、直接アクセスできなければなりません。ルーティングルールも、DNS通信がそのDNSなしでは確立できないプロキシへ戻らないようにします。設定後はログでDNSクエリと通常の接続を分け、解決通信が dns-out を使い、業務通信が従来どおりのルーティングで選択されていることを確認してください。

通信の分離は、特定のプロトコルやポートを独立したアウトバウンドへ送る用途にも使えますが、条件は安定して識別できなければなりません。ポートはアプリそのものではなく、プロセス名もすべての接続を表すとは限りません。対象ドメイン、アドレス集合、明確なネットワーク種別を優先します。複数条件を組み合わせる場合は、まずテストルールに1条件だけ書き、ヒットを確認してから制限を追加します。最初から複雑な条件をすべて書くと、未ヒット時にどのフィールドが不一致なのか判断しにくくなります。

統一したトラブル対応の順序

複雑な設定で障害が起きたら、統一した切り戻しを行います。自動サーバー選択を停止して既知の正常なサーバーを固定し、チェーンアウトバウンドを解除し、FakeDNSを無効化し、通常のDNSを残し、TUNからシステムプロキシへ戻し、ルーティングをプライベートアドレスのダイレクト接続とデフォルトプロキシへ戻します。それでも失敗するなら、原因はサーバーパラメーター、ローカルネットワーク、クライアント起動層にある可能性が高くなります。基準設定で復旧した場合は、元の順序で1つずつ追加し、障害が発生した最初の段階を重点的に確認します。

ログは時系列で読みます。まず設定の読み込みと構文エラーを確認し、次にインバウンドが接続を受け取ったか、DNSが結果を返したか、どのタグにルーティングがヒットしたか、該当アウトバウンドがハンドシェイクを開始したかを確認します。エラーが発生した段階と、その直接の依存項目だけを確認してください。アウトバウンドのハンドシェイクが成功しているのにページ内容が異常な場合は、アプリのプロトコル、アドレスファミリー、対象サービスを確認し、サブスク分けへ戻って変更しないでください。ログレベルは一時的に上げても構いませんが、原因を確認したら通常レベルへ戻し、不要な記録を長期間残さないようにします。

トラブル対応資料には、クライアント名、OS、システムプロキシとTUNのどちらを使っているか、問題発生前に行った単独の変更、重要なログ段階、切り戻し結果を含めます。サブスク全体や設定全体をそのまま提出しないでください。大量のスクリーンショットより、比較実験のほうが効果的です。同じサーバーが基準設定で正常か、同じ設定がネットワークを変えても正常か、新しく追加したモジュールを無効にすると復旧するかを確認します。この3つの結果で、ローカルシステム、コア設定、サーバー経路のどこに問題があるかを大きく絞り込めます。

設定が完了したら、サブスクの提供元、作業グループ、ルーティング順序、DNS経路、TUNの除外項目、FakeDNSのアドレスプール、カスタムアウトバウンドの依存関係を一覧にした構成説明を保存します。その後クライアント、コアデータ、サブスクを更新するときは、説明に沿って1項目ずつ再確認してください。クライアント選びを改めて整理する場合は、v2rayN、v2rayNG、v2flyNGの比較を参照できます。基本操作はクイックスタートに従い、このページは長期的なメンテナンスとシステムのトラブル対応に使ってください。