v2rayN 詳細設定ガイド：サブスクリプション、ルーティング、DNS、TUN

設定モデルと元に戻せる変更手順

まず4つの設定レイヤーを区別する

v2rayNの画面設定は、最終的にコアの実行設定へ統合されます。問題を切り分ける前に、サーバー、サブスクリプション、クライアントの動作、コア設定という4つのレイヤーを区別しましょう。サーバー情報にはアドレス、ポート、ユーザー識別子、トランスポート方式、安全パラメータが含まれます。サブスクリプションはサーバー情報をまとめて提供・更新します。クライアントの動作にはシステムプロキシ、トレイ操作、自動更新、画面上のフィルターが含まれます。コア設定はインバウンドの待受、DNS、ルーティング、アウトバウンドを処理します。あるノードで遅延テストに成功しても、システムプロキシ、DNS、ルーティングが正しいとは限りません。これらはノード接続とは別の段階にあるためです。

画面上の「現在のサーバー」は通常、デフォルトのプロキシアウトバウンドの送信元にすぎません。ルーティングルールによって、一部のリクエストがダイレクト接続やブロック用アウトバウンドへ送られることもあり、TUNがシステムプロキシを参照しないプログラムの通信を引き受ける場合もあります。そのため、設定が有効かどうかをノードの色やトレイアイコンの変化だけで判断してはいけません。クライアントの稼働状態、プロキシモード、対象プログラムの接続方式、ルールのマッチ結果を同時に確認してください。

最小限の動作基準を作る

詳細設定を調整する前に、再現可能な検証用の基準を作ります。接続できることが分かっているサーバーを1台残し、ルーティングをシンプルなルールに戻し、TUNとFakeDNSを一時的に無効化してシステムプロキシだけを有効にし、ブラウザーで通常のHTTPSページを開きます。この状態で動作したら、「サブスクリプションフィルター、ルーティング、DNS、TUN、FakeDNS」の順に設定を1層ずつ追加します。一度に変更するレイヤーは1つだけにし、変更後すぐに再テストすると、原因の範囲を大幅に絞れます。

各テストでは、変更内容、変更前の値、期待する結果、実際の結果の4項目を記録することをおすすめします。複雑なツールは必要なく、ローカルのテキストに書くだけで十分です。接続できなくなった場合は、ノードの切り替え、DNS変更、クライアントの再インストール、システムネットワークの初期化を同時に行うのではなく、最後の変更をまず取り消します。複数の操作を一度に行うと再現性が失われ、本当の原因も分からなくなります。

自動生成設定と手書き設定の境界を理解する

v2rayNは一般的なパラメータを画面から管理するのに適しており、画面で生成された設定はサーバー切り替え時にも自動更新されやすいという利点があります。手書きJSONは追加のアウトバウンド、特殊なDNSポリシー、細かなルーティングが必要な場合に向いていますが、クライアントが設定を再生成した際に変更内容が上書きされないかを確認する必要があります。ルーティング設定、DNS設定、カスタム設定の入口で実現できる機能なら、対応する入口を優先し、一時的な実行ファイルを直接編集しないでください。

設定の断片はJSON構文を完全に保つ必要があります。プロパティ名と文字列には半角の二重引用符を使い、配列の項目間にはカンマを入れ、最後の項目には余分なカンマを付けません。ドメイン、パス、正規表現ではバックスラッシュのエスケープも必要になる場合があります。保存後すぐにコアが終了した場合は、ログで最初に現れた解析エラーを優先して確認します。その後の接続失敗は、最初の解析エラーによる連鎖結果であることが多いためです。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

現象から確認すべき入口を決める

ブラウザーは使えるのに他のプログラムが使えない場合は、まずそのプログラムがシステムプロキシを参照しているかを確認し、その後にTUNを検討します。ドメインを開けないのに対象アドレスへ直接アクセスできる場合は、まずDNSを確認します。一部のサイトだけに問題がある場合は、ルーティングの順序とドメインルールを確認します。サブスクリプション更新後にノードが消えた場合は、フィルター式とグループを確認します。FakeDNS有効後にLAN名に問題が出た場合は、除外範囲とDNSの引き受け範囲を確認します。現象に応じて入口を選ぶ方が、すべての設定を最初からリセットするより確実です。

安定した設定が完成したら、設定のエクスポートや画面のスクリーンショットを保存し、使用したモードも記録しておきます。設定バックアップに保存されるのはローカル設定であり、サブスクリプションサービスそのものではありません。サブスクリプションURLが無効になっても、バックアップから新しいサーバー情報を生成することはできません。サブスクリプションURL、サーバー認証情報、カスタム設定ファイルは機密情報として扱い、公開文書に載せたり、実行ログをそのまま公開したりしないでください。

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

グループ分けで管理を整理する

サブスクリプショングループは、サーバーの提供元、用途、更新ペースを区別するためのもので、プロトコル自体を変更するものではありません。複数のサブスクリプションをインポートしてすべてのサーバーを1つのリストに混在させると、重複するノード名、統一されない地域表示、倍率情報などで絞り込み結果を判断しにくくなります。安定した運用には、提供元ごとにグループを作り、各サブスクリプションに分かりやすいメモを付け、フィルター条件で一時的な表示を作る方法が適しています。グループ名は提供元や用途を表すものにし、変わりやすいノード数には依存しないでください。

サブスクリプションURLは、クライアントのサブスクリプショングループ設定から保存します。追加後はまず手動で1回更新し、サーバー情報が正しく解析できることを確認してから自動更新間隔を設定します。初回更新に失敗した場合は、URLが完全か、コピー時に空白が混入していないか、ネットワークからサブスクリプションのエンドポイントへアクセスできるかを確認します。初回失敗後に同じグループを何度も作成しないでください。後の更新で重複サーバーが発生し、整理の手間が増えます。

メモ、グループ名、サーバー名にはそれぞれ役割がある

グループメモはユーザーが管理し、提供元の目印に適しています。グループ名はリストの分類に使い、サーバー名は通常サブスクリプション提供元が生成するため、更新時に変わる可能性があります。長期的に安定した絞り込みを行う場合、完全なサーバー名だけに依存せず、地域略称、プロトコル名、用途タグなど比較的変わりにくいキーワードの組み合わせを選びます。提供元が命名規則を変更すればフィルター結果も変わるため、大規模更新の後は、絞り込み表示に想定したサーバーが残っているか確認してください。

サーバーフィルターは通常、包含と除外の2種類に分かれます。包含条件は、名前に特定の地域表示があるものだけを表示するなど、表示範囲を絞るために使います。除外条件は、メンテナンス、残り通信量、期限切れのお知らせなど、サーバーではない項目を取り除くために使います。フィルターが表示だけに影響する場合、元の記録は削除されません。削除操作はローカルのサーバー情報を直接消します。一括削除の前に、現在の操作対象がフィルター結果なのか、グループ全体なのかを確認してください。

フィルター式は簡単な条件から始める

クライアントの入口が正規表現に対応している場合は、まず通常のキーワードで範囲を確認し、その後に組み合わせ条件を少しずつ追加します。正規表現では丸括弧、角括弧、ドット、プラス記号などに特殊な意味があります。サーバー名をそのままコピーすると、マッチ結果が変わることがあります。複数の通常キーワードのいずれかに一致させる場合は、縦線を使います。たとえば HK|SG|JP のように記述します。「残り通信量」「プラン期限」などのお知らせを除外する場合は、まず各キーワードを個別にテストしてから条件をまとめます。

包含例：
HK|SG|JP

除外例：
残り通信量|プラン期限|公式サイト|メンテナンス

プロトコルによる絞り込み例：
VMess|VLESS|Trojan

フィルター条件に自動経路選択まで担わせてはいけません。フィルターは表示リストを絞るためのもので、ノードの品質を継続的に判定したり、実接続による遅延テストを代替したりするものではありません。絞り込み後は対象集合に対して実接続遅延テストを行い、ハンドシェイクに失敗した記録を除外します。そのうえで実際のダウンロードやウェブアクセスを組み合わせてサーバーを選びます。ICMP Ping、実接続遅延、ダウンロード速度の違いについては遅延テストの解説を参照してください。

更新、上書き、削除の方針

サブスクリプションは通常、グループ単位で情報を更新します。更新後に大量の重複項目が現れた場合は、同じURLを複数のグループに登録していないかを確認し、次にクライアントの更新動作が古い記録を上書きするのか、手動変更を残すのかを確認します。サブスクリプションから生成されたサーバーの名前やパラメータを直接変更すると、次回更新で上書きされる可能性があります。長期的に残したい手動サーバーは独立したグループに置き、自動更新のサブスクリプションと混在させないでください。

サブスクリプションを削除するときは、「サブスクリプション設定の削除」と「そのサブスクリプションが生成したサーバーの削除」を区別する必要があります。URLだけを削除すると古いサーバーが残り、パラメータ更新も受けられなくなります。サーバーだけを削除してサブスクリプションを残すと、次回更新時に再生成されます。提供元を停止する場合は、自動更新を止め、対応するサーバーを削除し、最後にサブスクリプショングループを削除します。完了後は現在のアクティブサーバーを確認し、削除済みの記録を指していないことを確認してください。

v2rayNGとv2flyNGではサブスクリプション管理の入口や画面レイアウトがデスクトップ版と異なりますが、処理の順序は同じです。提供元にメモを付け、個別に更新し、解析結果を確認してからアクティブな設定を選びます。モバイルネットワークの切り替えが多い場合は、自動更新間隔を短くしすぎないでください。更新に失敗した場合は既存のサーバーを残し、ネットワークが一時的に到達不能なのか、サブスクリプションURL自体が変わったのかを先に判断します。

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

ルールの順序でアウトバウンドが決まる

ルーティングの役割は、接続を指定したアウトバウンドへ渡すことです。一般的なアウトバウンドにはプロキシ、ダイレクト接続、ブロックがあり、カスタム設定では他のプロキシ経路を追加することもできます。ルールはマッチ条件と送信先アウトバウンドで構成されます。ドメイン、アドレス、ポート、ネットワーク種別、インバウンドタグが条件を満たすと、接続は対応する outboundTag へ渡されます。多くの実装では上から順にマッチするため、具体的なルールを一般的なルールより前に置きます。そうしないと、前方の広すぎる条件が先にリクエストを引き受けます。

保守しやすい基本的な順序は、まず明確にブロックしたい対象、次にLANとプライベートアドレスのダイレクト接続、その後に業務上明確なドメインやアドレスのルール、最後にフォールバック動作です。フォールバックはデフォルトのアウトバウンドに任せられるため、すべての対象を覆うルールを必ず書く必要はありません。ルールの先頭に範囲の広すぎるドメインマッチを置くと、後続の振り分けルールは有効になりません。

ドメインマッチとアドレスマッチは同じ段階ではない

ドメインルールは、接続にドメイン情報が残っている場合に最も分かりやすく機能します。たとえば domain:example.com はそのドメインとサブドメインの範囲にマッチし、full:example.com は完全一致のホスト名に使います。regexp: は本当にパターンマッチが必要な場合に適しています。正規表現は解析・保守コストが高いため、通常のドメイン指定で表現できる場合は優先しないでください。サイトが複数の静的リソース用ドメインに依存している場合は、個別に確認し、トップページのドメインだけからすべてのリクエストが同じルールにマッチすると推測しないでください。

アドレスルールは、対象がすでにIPへ解決されている場合に使い、単一アドレス、CIDRネットワーク、組み込みカテゴリにマッチさせられます。geoip:private はプライベートアドレスをダイレクト接続にする用途でよく使われ、LANプリンター、ストレージ、ルーター管理画面がプロキシへ送られるのを防ぎます。ドメインの解決結果は時間や地域で変わるため、動的サイトの現在のアドレスを恒久的なルールにするのは不安定です。ドメインで表現できる条件は、ドメインルールを優先してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:telemetry.example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:docs.example.com",
          "full:api.example.net"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategyがマッチング過程に与える影響

AsIs はリクエストに含まれる元のドメインを優先し、ルーティングのためにアドレスを積極的には解決しません。IPIfNonMatch はドメインルールにマッチしなかった場合にアドレスを解決し、アドレスルールを試します。IPOnDemand はルール判定でアドレスが必要になった時点で、より早く解決を開始します。選択時はDNS設定との組み合わせを考慮してください。アドレスカテゴリに依存するルーティングで、戦略が常にアドレスを解決しない場合、該当ルールにマッチしないことがあります。逆に早すぎる解決はDNSクエリを増やしたり、ドメインの振り分け経路を変えたりする可能性があります。

一般的な用途では AsIs から始め、解決後のアドレスに基づく判定が明確に必要な場合だけ IPIfNonMatch を使います。変更後は、同じドメインで異なるDNSリクエストが発生していないか、想定したアウトバウンドにマッチしているかを確認します。戦略名を「速度モード」と捉えてはいけません。変わるのはマッチング段階と解決のタイミングであり、すべてのネットワーク環境で特定の値が速くなるとは限りません。

ルール検証ではリクエスト全体を確認する

ルーティングの検証で、トップページが開くかどうかだけをテストしてはいけません。1つのページがメインサイト、画像、API、認証ドメインへ同時にリクエストし、リクエストごとに異なるアウトバウンドを通ることがあります。まず具体的な対象に対して単一ルールを作り、コアを再起動したうえで、ログの対象、マッチ結果、アウトバウンドタグを確認します。単一ルールが有効だと分かってからドメイン範囲を広げてください。ログにアドレスしか表示されずドメインがない場合は、DNSとスニッフィング設定に戻り、ドメイン情報を取得できる状態か確認します。

ルールが有効にならない場合は、次の4点を順に確認します。ルールの順序が正しいか、マッチ構文がコアの形式に合っているか、対象のアウトバウンドタグが存在するか、実際の接続を現在のコアが処理しているかです。ブラウザー内蔵のセキュアDNS、アプリ内蔵プロキシ、既存の長時間接続が、変更した経路を迂回する場合があります。テスト前に対象プログラムを終了して再起動し、必要なら接続キャッシュを消去します。ページを更新するだけでは不十分です。

ルーティングルールは読みやすく保つ必要があります。ばらばらなドメインを何十件も並べるより、用途ごとにまとめた少数のルールの方が確認しやすく、前後の上書きも起こりにくくなります。設定後は上から順に、「何にマッチし、どのアウトバウンドへ渡し、なぜここに置くのか」を説明できるか確認します。明確に答えられない項目は、分割、改名、削除が必要なことが多いです。

DNS設定の最適化と解決経路の切り分け

まず誰がクエリを発行しているかを明確にする

DNSの異常は、ノードの障害と誤認されがちです。実際の経路には、システムリゾルバー、ブラウザーのセキュアDNS、v2rayNコアのDNS、TUNによるDNS引き受け、リモート側の名前解決が含まれる場合があります。プログラムごとに入口が異なると、同じドメインでも異なる結果が返ります。最適化の前に、対象プログラムがシステム解決を使うのか、クエリがコアへ入るのか、コアがどのサーバーへ送るのか、解決結果がルーティングにどう使われるのかを確認します。

システムプロキシだけを有効にしている場合、ブラウザーが自分でドメインを解決することも、ドメインをプロキシ入口へ渡すこともあります。これはプロキシの種類とプログラムの実装によって異なります。TUNを有効にするとシステムDNSリクエストを一元的に引き受けやすくなりますが、DNSアドレス、ルーティング、除外項目を正しく設定する必要があります。ブラウザーでセキュアDNSを個別に有効にすると、クエリが通常のHTTPS通信として送信され、従来の53番ポートへのリクエストが見えないこともあります。

コアDNSのサーバーとクエリルール

コアのDNS設定では複数のサーバーを定義し、ドメイン範囲に応じて使い分けられます。通常のUDP DNSは設定が簡単ですが、リクエスト経路はネットワークとルーティングに左右されます。HTTPSベースのDNSはHTTPS接続でクエリするため、サーバーのドメインを最初に解決する問題を先に解決する必要があります。固定アドレスを使えば起動時の依存を減らせますが、アドレス変更時にはメンテナンスが必要です。方式は名前だけで優劣を判断せず、到達性と依存関係を考慮して選んでください。

DNSサーバーにはドメインのフィルター条件を付けることもできます。目的は通常、すべてのクエリを複数サーバーへ無作為に振り分けることではなく、特定のドメインを指定したリゾルバーで解決することです。複数サーバーのドメイン範囲が重なる場合は、優先関係を明確にします。デフォルトサーバーには特殊な要件のないドメインを処理させ、専用サーバーは必要な範囲だけを担当させると、設定を検証しやすくなります。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["domain:service.example"]
      },
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

例に登場するドメインは構造を示すためのものです。実際の設定では、アクセス可能なDNSサービスへ置き換えてください。hosts は少数の固定マッピングに使い、ローカル機器やテスト環境には適していますが、多数の公開ドメインの管理には向きません。誤った固定マッピングは通常の更新を迂回するため、設定後に用途を記録しておきます。localhost はシステムリゾルバーへ戻ります。システムリゾルバーがさらにクエリをコアへ戻す構成ではループが起こる可能性があるため、使用前に経路の向きを確認してください。

クエリ戦略とアドレスファミリー

queryStrategy は返すアドレスの種類を制御します。UseIP は環境に応じて利用可能なアドレスを取得し、UseIPv4 はIPv4のみ、UseIPv6 はIPv6のみを要求します。返されたアドレスが意味を持つのは、ネットワークに対応する接続能力がある場合だけです。システムがIPv6アドレスを取得できても、アウトバウンド経路がすべてのIPv6宛先へ安定してアクセスできるとは限りません。一部のサイトだけが待機後にフォールバックする場合は、一時的にIPv4へ限定し、アドレスファミリーとの関係を確認できます。

アドレスファミリーの問題は、どちらかを恒久的に無効にするのではなく、比較テストで確認します。解決結果、接続先、失敗した段階をそれぞれ記録してください。DNSがアドレスを返せるのにTCPまたはUDPの接続確立に失敗するなら、問題は解決後の段階にあります。特定のリゾルバーだけがタイムアウトする場合は、そのリゾルバーへのアクセス経路を確認します。ログの「解決失敗」と「接続拒否」は異なる段階を示すため、分けて対処してください。

キャッシュ削除は検証目的に限る

DNS変更後も、システム、ブラウザー、コアが古い結果を保持していることがあります。Windowsではターミナルで ipconfig /flushdns を実行してシステムキャッシュを消去できますが、このコマンドはブラウザー独自のキャッシュを消去せず、既存の接続も終了させません。より確実なテストでは、設定を保存し、コアを再起動し、対象プログラムを終了し、必要なキャッシュを消去してから、リクエストを新たに発行します。キャッシュの頻繁な削除で誤った設定は直せません。古い結果がテストに影響しているかを確認する場合だけ使ってください。

ipconfig /flushdns

nslookup example.com

nslookup example.com 1.1.1.1

nslookup はシステムのデフォルトリゾルバーと指定リゾルバーの結果を比較するのに適していますが、アプリが実際に使うコアDNS経路を通るとは限りません。そのため、コマンド結果が正常なのにブラウザーが失敗する場合は、ブラウザーとプロキシ入口を引き続き確認します。TUNやFakeDNSが有効な場合、通常の問い合わせツールに表示される結果が、引き受け後のマッピングアドレスであることもあります。従来のDNS結果だけで判断せず、対応する章と合わせて確認してください。

v2rayN TUNモード：引き受け範囲とシステムごとの差異

TUNでプロキシを読み取らないプログラムに対応する

システムプロキシは、アプリが自発的にプロキシ設定を読み取ることを前提とします。ブラウザーや一部のデスクトップアプリは通常この方式に対応していますが、ゲームランチャー、コマンドラインツール、バックグラウンドサービス、独自のネットワークスタックを使うプログラムは直接接続する場合があります。TUNモードは仮想ネットワークインターフェースを通じてシステム通信を引き受け、こうしたプログラムの接続もコアへ送ります。変わるのは通信の入口であり、サーバーのプロトコルではありません。もともと接続できないノードを復旧させる機能でもありません。

TUNを有効にするかどうかは、アプリの要件で決めます。システムプロキシを正しく読み取れるプログラムだけを使うなら、システムプロキシの方が設定は簡単で、切り分け範囲も狭くなります。特定のプログラムがプロキシ入口を通らないことが明確な場合、またはTCP、UDP、DNSを一括して処理したい場合に限ってTUNを有効にします。TUNを初期のトラブルシューティング手段にすると、ルーティング、権限、仮想インターフェース、DNSの問題を同時に持ち込むことになります。

有効化前に権限と競合項目を確認する

TUNは仮想ネットワークインターフェースを作成・制御し、ルーティングを変更します。Windowsでは権限の昇格が必要になる場合があり、macOSやLinuxでも対応するネットワーク操作をシステムが許可している必要があります。インターフェースの作成に失敗したと表示されたら、ノードを何度も切り替えるのではなく、権限とドライバーの状態を確認します。企業ネットワーク管理ソフト、他の仮想ネットワークツール、起動中の同種プロキシが同時にルーティングを変更する場合があるため、テスト時は引き受け役を1つだけにしてください。

有効化前にシステムのデフォルトゲートウェイとDNSを記録し、他の通信管理ツールを終了してから、v2rayNのTUNモードを起動します。成功したら、まず通常のウェブページをテストし、その後にシステムプロキシを読み取らなかったプログラムをテストします。ネットワークがすべて直ちに切断された場合は、まずTUNを無効にして基本接続を戻し、仮想インターフェースの作成、デフォルトルートの変更、DNSの接続先が想定どおりかを確認します。ネットワークが切断された状態でFakeDNSや複雑なルーティングを重ねてはいけません。

厳格ルーティング、自動ルーティング、MTU

自動ルーティングは、引き受け対象の通信をTUNインターフェースへ送るために使います。厳格ルーティングは通常、そのインターフェースを迂回し得る経路をさらに制限します。具体的な項目名はビルドによって異なる場合がありますが、判断の原則は同じです。まずデフォルトの自動ルーティングで基本的な引き受けを確認し、漏れの経路やLANの要件に応じて厳格さを調整します。厳格ルーティングを有効にした後にLANリソースへアクセスできなくなった場合は、全体をプロキシへ送るルールを追加するのではなく、プライベートネットワークがダイレクト接続として残っているかを確認します。

MTUは仮想インターフェースが扱えるパケットサイズを決めます。値が大きすぎると、経路によってはウェブページの一部だけが読み込まれる、アップロードが止まる、特定の接続がタイムアウトするといった問題が起きます。小さすぎると、分割や追加のオーバーヘッドが増えます。「接続はできるが大きなリクエストだけ失敗する」場合は、元の値を記録してから段階的にMTUを下げて比較します。1回の速度テストだけで判断せず、小さなウェブページ、大きなファイル転送、持続接続を必要とするアプリを少なくともテストしてください。

LANとクライアント自身の通信を除外する

TUNのルーティングでは通常、プライベートネットワークをダイレクト接続に残す必要があります。そうしないと、プリンター、ゲートウェイ管理画面、LANサービスが誤ってプロキシへ送られる場合があります。一般的なプライベートアドレス範囲は geoip:private ルールでまとめて処理できます。ローカルネットワークが一般的でないアドレス範囲を使っている場合は、実際のネットワークを追加してください。LANサービスがドメイン名で提供されている場合はローカルDNSにも依存するため、アドレスだけをダイレクト接続にして、DNSをリモート解決にすると、名前では利用できないことがあります。

クライアント自身からプロキシサーバーへの接続も、同じプロキシアウトバウンドへ再び入らないようにする必要があります。成熟したデフォルト設定では通常この点が処理されていますが、カスタムルーティングやカスタムアウトバウンドでは、サーバーアドレスがダイレクト経路を使うことを確認してください。コア起動後に再接続を繰り返し、ログに同じサーバー宛ての接続が何度も現れる場合は、自分自身をプロキシするループを確認します。カスタムポートも、v2rayNが使用するローカルHTTP、SOCKS、APIポートと競合させないでください。

TUNを無効にした後の復旧確認

クライアントを正常に終了すると、仮想インターフェースと一時的なルートも解除されるはずです。異常終了後にネットワークが使えない場合は、まずクライアントを再度開き、TUNを正常に無効にしてから、システムのデフォルトルートとDNSが戻っているか確認します。システムの再起動で一部の一時状態は消せますが、原因の特定に代わるものではありません。残留が繰り返される場合は、複数のネットワークツールが同じインターフェースを管理していないか確認し、ログで終了処理にエラーがないか確認します。

モバイル版のv2rayNGとv2flyNGは、システムが提供するネットワーク引き受けインターフェースを通じて動作します。アプリの除外、バックグラウンド制限、省電力設定が持続接続に直接影響します。デスクトップ版のTUN設定をAndroidへそのまま適用することはできませんが、ルーティングとDNSの分析方法は同じです。まず通信がクライアントへ入っているかを確認し、次にルールのマッチとアウトバウンドを確認し、最後にシステムがバックグラウンドで接続を終了していないかを確認します。

FakeDNSの仕組み、適した用途、限界

FakeDNSはドメインと接続の対応関係を保持する

FakeDNSはDNSクエリを引き受けると、予約アドレスプールから一時アドレスをドメインへ返し、そのアドレスと元のドメインの対応関係を記録します。アプリがこの一時アドレスへ接続すると、コアは対応関係からドメインを復元し、ドメインルーティングとリモート接続を実行します。主な利点は、ローカルで先に名前解決し、その後アドレスだけで接続するプログラムでもドメイン情報を保持し、ドメインルールを有効にできることです。

FakeDNSが返すアドレスは対象サーバーの実際の公開アドレスではないため、コアから切り離して単独で使うことはできません。クエリと後続の接続が同じ引き受け経路へ入って初めて、対応関係が成立します。DNSクエリがFakeDNSを通っても接続がTUNを迂回すれば、アプリは一時アドレスへ直接アクセスして失敗します。逆に接続がTUNへ入っても、クエリが別のリゾルバーで処理されれば、対応関係からドメインを復元できません。

有効化に適した場面

TUNが安定して動作しているのに、ログにアドレスだけの接続が大量に現れ、ドメインルーティングがマッチしにくい場合は、FakeDNSを検討できます。ローカルで実際の名前解決を減らし、プロキシ経路内でドメイン処理を続けたい場合にも適しています。有効化の前に、通常のTUN、DNSの引き受け、基本ルーティングが動作することを確認してください。そうでなければ、アドレスプールとマッピング機構が加わり、障害の説明がさらに難しくなります。

通常のシステムプロキシ環境では、「より速くする」ためだけにFakeDNSを有効にする必要はありません。多くのプロキシ入口はもともとドメインを受け取れるため、ドメイン情報は失われません。FakeDNSはキャッシュによる高速化機能でもなく、中心的な役割はマッピングと復元です。改善するかどうかは元のドメイン処理の問題に左右され、すべての環境で有効にすべき性能オプションではありません。

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

例は一般的な構造を示すもので、実際の対応方式はクライアントが使用するコアと設定入口によって異なります。198.18.0.0/15 はベンチマークでよく使われる予約ネットワークで、マッピングプールとして利用できます。ただし、ローカルネットワーク、他の仮想ネットワーク、企業ルーティングが同じ範囲を使用していないか確認してください。アドレスプールが競合すると、特定のイントラネットサービスへ接続できない、ルーティングが実際の対象をFakeDNSアドレスと誤認するといった問題が起こります。

LAN、振り分け、除外

LAN名、プリンターの検出、ルーター内部のドメインは通常ローカルDNSに依存するため、まとめてFakeDNSへ渡すのには向きません。プライベートドメインとローカルドメインのサフィックスはローカル解決にし、プライベートアドレスはダイレクト接続にします。LANが独自のサフィックスを使っている場合は、除外範囲へ明示的に追加してください。プライベートアドレスだけを除外しても十分とは限りません。名前解決はアドレス取得より前に行われるためです。

FakeDNSをドメイン振り分けと組み合わせる場合、ルールはドメインが復元された後に判定される必要があります。接続ログに常にマッピングアドレスだけが表示されるなら、復元経路が完了していません。DNSクエリと接続が同じインスタンスで処理されているか、アドレスプールが一致しているか、TUNが対象アプリを引き受けているかを確認します。マッピングアドレス範囲にプロキシルールを追加して問題を隠さないでください。すべての一時アドレスがプロキシへ送られるだけで、元のドメインによるルールの利点は失われます。

キャッシュの有効期間とテスト方法

FakeDNSのマッピングには容量と有効期間があります。アプリが古いマッピングアドレスを保持したまま、コアが再起動したりマッピング記録が置き換えられたりすると、古い接続が失敗することがあります。設定変更をテストするときは対象プログラムを再起動し、必要ならDNSキャッシュを消去して、同じ実行セッション内でクエリと接続を再構築させます。コアだけを再起動してアプリの古い接続を残すと、一貫しない結果になりやすいです。

検証では、明確なドメインルールを設定できるテスト対象を1つ選びます。まずFakeDNSを無効にした状態で、ログに表示される対象形式を記録します。その後FakeDNSを有効にして新しい接続を開始し、DNSがマッピングアドレスを返す、コアがドメインを復元する、ルールが想定したアウトバウンドにマッチする、という3段階を確認します。どれか1段階でも欠けていれば、ルールを増やすのではなく、その段階を修正してください。

FakeDNSを無効にした後は、対応するDNSサーバー設定も戻し、アプリにドメインを再解決させます。アドレスプールだけを削除して fakedns の解決入口を残すと、設定が不完全になります。有効化と無効化を長期的に切り替える必要がある場合は、複数の項目を毎回手動で変更するのではなく、完全な設定を2種類保存することをおすすめします。

複数サブスクリプションの管理、更新ペース、競合処理

各提供元のライフサイクルを独立させる

複数サブスクリプション管理の目的は、同じリストにサーバーを大量に詰め込むことではありません。異なる提供元を個別に更新、停止、確認できる状態にすることが目的です。各サブスクリプションには固有のメモとグループを使い、2つのURLに同じ名前を設定しないでください。こうすれば、ある提供元の更新失敗、ノード名の変更、一時停止が必要な場合でも、他の検証済みサーバーに影響を与えず対応できます。

手動サーバーは「ローカル管理」グループに分けることをおすすめします。サブスクリプションの更新は通常リモートの内容を基準とするため、生成されたサーバーを直接変更すると次回更新で上書きされる可能性があります。パラメータを一時的に調整したい場合は、まずサーバーを手動管理グループへコピーしてから変更し、名前に用途を記載します。元のサブスクリプション記録は変更せず、リモートのパラメータと比較できるように残してください。

頻繁にポーリングせず、更新時刻をずらす

自動更新間隔は、サブスクリプションの変化頻度に応じて設定します。間隔が短すぎると無駄なリクエストが増え、ネットワーク切り替え時に失敗記録が連続して発生することもあります。複数のサブスクリプションを同時刻に更新する必要はありません。まず各提供元を個別に手動更新できることを確認し、その後に適切な周期を設定します。ノートパソコンがスリープから復帰した直後、ネットワークを切り替えた直後、プロキシコアがまだ接続していない状態では、最初の自動更新が失敗することがあります。ネットワークが安定してから手動で再試行してください。

サブスクリプション更新時のリクエストがダイレクト接続になるかプロキシを通るかは、クライアント設定と現在のネットワークによって決まります。あるサブスクリプションが現在のプロキシ経由でしかアクセスできない場合、既存の利用可能なノードに依存することになります。その場合は、更新前に削除されない検証済みサーバーを少なくとも1台残してください。新しい内容を取得する前に古い記録をすべて削除すると、一時的な更新失敗だけで復旧経路を失います。

同名サーバーと重複内容を処理する

異なる提供元が同じサーバー名を使ったり、同じパラメータの記録を提供したりすることがあります。名前が同じでも設定が同じとは限らないため、表示テキストだけで一括削除してはいけません。グループ、アドレス、ポート、プロトコル、トランスポートパラメータを組み合わせて判断します。クライアントがグループ表示に対応している場合は、まず1つの提供元に対象を限定して操作します。グループをまたいで重複削除する前に、重複記録が予備の提供元として必要か確認してください。

同じサブスクリプションを重複インポートすると、更新のたびに似た記録が2組生成されるのが最も分かりやすい兆候です。処理前に該当グループの自動更新を停止し、残すサブスクリプション設定を確認してから、余分なグループと生成されたサーバーを削除します。完了後、残したグループを再更新し、現在のアクティブサーバーがまだ存在するか確認します。総合リストから1件ずつ削除するだけでは、重複登録の根本原因は解決しません。

サーバー選択とグループ管理を分ける

グループは提供元の管理に使い、遅延テストは接続段階の判断に使います。実際の利用では帯域、安定性、対象サービスも考慮してください。最近更新されたグループだからといって、すべてのサーバーが利用できるとは限りません。更新後はまず実接続遅延テストを行い、プロキシのハンドシェイクを完了できない記録を除外します。その後、少数の候補を実際にアクセスして選びます。具体的な選び方はノード選択の解説を参照してください。

自動選択機能が定期テストに依存する場合は、テスト対象、タイムアウト、切り替え条件を理解して使います。テスト先に到達できないと、すべてのサーバーが誤って利用不可と判定されます。タイムアウトが短すぎると、高遅延でも利用できる回線を除外し、切り替えが頻繁すぎると既存接続が中断されます。まず複数のサーバーからテスト先へアクセスできることを手動で確認してから、自動化を検討してください。継続セッションが必要なアプリでは、毎回の最低遅延より安定性が重視されることが多いです。

サブスクリプションの移行とローカル記録

デバイスを変更する場合は、サブスクリプションURL、手動サーバー、ルーティングルール、DNS設定を分けて扱います。サブスクリプションだけを移行すればリモートサーバーは再生成できますが、ローカルのカスタムルールは自動的に戻りません。実行設定だけをコピーすると、一時的に生成された内容まで含まれ、後の更新が難しくなる可能性があります。移行後は提供元ごとに順番に更新し、グループとサーバー数が妥当であることを確認してからカスタムルールをインポートします。

サブスクリプションURLとサーバー認証情報はどちらも機密設定です。トラブルシューティング用のスクリーンショットでは、完全なURL、ユーザー識別子、トークンを隠してください。ログを送る前にも、リクエストパラメータとサーバー情報を確認します。公開例には https://example.com/sub?token=xxxx のような明らかなダミー値を使い、実際のサブスクリプション内容をスクリプト、ウェブページ、共有メモに書かないでください。

複数サブスクリプションの構成が安定したら、日常のメンテナンスでは更新失敗、異常な重複、長期間使えない記録だけを確認すれば十分です。リストを整えるために、すべてのグループを頻繁に作り直す必要はありません。提供元の境界を明確にし、戻せるアクティブサーバーと少量の説明を残す方が、完全な自動化を目指すより長期的に管理しやすくなります。

カスタムアウトバウンド、チェーン接続、総合診断

アウトバウンドタグはルーティングと接続方式をつなぐインターフェース

コアはアウトバウンドによって、接続が本機からどのように外へ出るかを定義します。一般的な proxy、direct、block は、それぞれ現在のプロキシサーバーを使う、直接接続する、ブロックすることを示します。カスタムアウトバウンドではローカルSOCKSサービス、特定のダイレクト接続パラメータ、その他の対応プロトコルを追加し、ルーティングルールからタグで選択できます。タグは一意でなければならず、ルール内の outboundTag はアウトバウンドの tag と完全に一致している必要があります。

アウトバウンドを追加する前に、用途を明確にします。特定のリクエストを本機上の別サービスへ渡すのか、特定の対象に独立した接続経路を設定するのかを決めてください。対応するルーティングルールがないカスタムアウトバウンドは、自動的に通信を引き受けません。タグの綴りを誤ると、コアが設定の読み込みを拒否したり、リクエスト時にエラーを出したりします。名前には安定して読みやすい短い英単語を使い、サブスクリプション更新で変わる可能性のあるサーバー名をタグにしないでください。

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

例では、特定の通信を本機の 127.0.0.1:1081 で待ち受けるSOCKSサービスへ渡します。使用前に、そのポートで実際にサービスが待ち受けていることと、通信が現在のv2rayNインバウンドへ戻されないことを確認してください。2つのローカルサービスが互いを指すとループになり、接続が確立してすぐ失敗する状態を繰り返します。カスタムポートは、v2rayNが使用するローカルHTTP、SOCKS、APIポートとも競合させないでください。

チェーン接続では各ホップを明確にする

チェーン接続は障害点とハンドシェイクのコストを増やすため、明確な必要性がある場合だけ設定します。各ホップは個別に検証できなければなりません。第1ホップは本機から中間アウトバウンドへ到達でき、中間アウトバウンドは次の対象へアクセスでき、DNS解決は想定した場所で行われる必要があります。チェーン内のいずれかのホップが前のホップのDNSやルーティングに依存する場合は、依存関係を記録し、起動時に互いを待ち続けないようにします。

チェーン接続をテストするときは、まず単純な対象を使い、複雑なドメインルールを同時に有効にしないでください。ログには、リクエストがどのインバウンドに入り、どのルールにマッチし、どのアウトバウンドを選び、どの段階で失敗したかが表示されるべきです。接続タイムアウトは範囲が広く、ポートが待ち受けていない、ルーティングに到達できない、次の対象が応答しないなどの可能性があります。認証失敗なら、該当アウトバウンドの認証情報とプロトコルパラメータを優先して確認します。すべてのタイムアウトを延長して、明確な設定ミスを隠してはいけません。

ログをレイヤーごとに読む

総合診断は6つの層に分けられます。クライアントプロセスが起動しているか、コア設定が解析できているか、インバウンドポートまたはTUNがリクエストを引き受けているか、DNSが利用可能な結果を返しているか、ルーティングが想定したアウトバウンドを選んでいるか、アウトバウンドが接続を完了しているかです。ログで最初に現れるエラーが、通常は根本原因に最も近い位置にあります。コア設定の解析に失敗しているとき、その後の「プロキシが利用できない」には独立した診断価値がありません。DNSが失敗しているなら、先にサーバーの速度テストパラメータを調整すべきでもありません。

トラブルシューティング中だけログレベルを一時的に上げ、問題を確認したら通常のレベルへ戻します。詳細ログには対象ドメイン、サーバーアドレス、ローカルパスが含まれる場合があるため、共有前に機密情報を削除してください。ログを抜き出すときは、エラー前後の時間帯と操作手順を残し、最後の1行だけをコピーしないでください。無関係なログを大量に集めるより、明確に再現できる手順の方が原因を特定しやすくなります。

再現可能な診断手順を作る

「V2Rayに接続できない」場合は、発生時刻、現在のサーバー、プロキシモード、TUNの有効・無効、FakeDNSの有効・無効、影響を受けるプログラムをまず記録します。次に最小限のテスト対象を1つ選び、問題と無関係なカスタムルールを無効にして接続を再試行します。基本接続が戻ったら、元の順序で設定を1項目ずつ有効にし、再びエラーが出る箇所を特定します。この方法なら、複雑な問題を1つの変更へ絞り込めます。

すべてのサーバーが同時に失敗する場合は、各サーバーのパラメータを変更する前に、本機のネットワーク、サブスクリプションを直前に更新していないか、システム時刻、DNS、クライアントの稼働状態を確認します。特定のサーバーだけが失敗する場合は、同じグループの他の記録とそのサーバーのプロトコルパラメータを比較します。特定のアプリだけが失敗する場合は、まずそのアプリが現在のプロキシ入口へ入っているか確認します。短い質問への回答はよくある質問で項目ごとに確認できます。

長期運用とアップデート時の確認

クライアントやコアを更新した後は、まず従来の基本設定で起動し、カスタムフィールドが引き続きサポートされているか確認します。クライアント更新と同時にルーティングやDNSをすべて作り直さないでください。設定を読み込めない場合は、フィールドの非推奨化や形式変更に関するログを確認し、問題を特定の断片へ絞り込みます。ダウンロードとクライアント選びは当サイトのダウンロードページから行えます。デスクトップではv2rayNを優先し、Androidではコアの要件に応じてv2rayNGまたはv2flyNGを選択してください。

定期的にサブスクリプショングループ、フィルター条件、ルーティング項目、DNS専用ルール、カスタムアウトバウンドを確認します。用途を説明できなくなった一時的なルールを削除し、LANの除外設定が現在のネットワークと一致しているか、自動更新が継続して成功しているかも確認してください。詳細設定の目的は項目数を増やすことではなく、各レイヤーの動作を説明・検証・復旧できる状態にすることです。