ClashのDNSリークを確認する方法｜検査結果の見方とfake-ip・nameserver-policyによる対策

1. まずDNSリークの判断基準を確認

ブラウザーにプロキシ経由のIPアドレスが表示されても、名前解決まで同じ経路を通っているとは限りません。アクセス時には、ドメインを解決するDNSリクエストと、接続先サーバーへ送る通信の少なくとも2種類が発生します。Clashのシステムプロキシ、TUNによる通信の取り込み、コアのDNS機能、ブラウザーのセキュアDNSはそれぞれ異なる部分に作用するため、原因を調べる際は分けて確認しましょう。

この記事ではDNSリークを、本来指定したリゾルバーやプロキシ経路に送るはずの問い合わせが、想定外のリゾルバーへ送信される状態と定義します。たとえば、海外サイトのドメインをプロキシ経由で解決する設定なのに、検査結果に日本国内のブロードバンド事業者の再帰DNSが繰り返し表示される場合は、原因を調べる必要があります。一方、国内ドメインを事業者のDNSで解決する設定なら、その結果が表示されても不自然ではありません。

先に想定する経路を決めてから、検査結果を確認しましょう。国内で解決してよいドメイン、プロキシ経由で解決するドメイン、ブラウザーが独自にDoHを使ってよいかを整理します。この3点が決まっていなければ、「複数の国が検出された」というだけではリークと判断できません。

DNSリーク検査で分かること

パブリックDNSでは、Anycastや分散型の再帰DNSクラスターが一般的に使われています。クライアントが接続するサービスアドレスと、検査ページに表示される再帰DNSの送信元は異なる場合があり、国の判定情報が古いこともあります。そのため、プロキシの出口が日本なのにDNSの結果が米国と表示されても、それだけではリークの証拠になりません。DNS事業者、設定した上流DNS、実際の接続ログをあわせて確認してください。

2. 手順に沿って再検査し、システムとブラウザーを切り分ける

現在のコア名、クライアントのバージョン、有効な設定、プロキシモード、システムプロキシとTUNの状態を記録します。以下はmihomoを対象にした設定です。旧Clashコアでは一部の項目に対応していない場合があります。Clash Nyanpasuでは、バージョンによって設定項目の分類が異なることがあります。項目が見つからない場合は、サブスクリプションの元ファイルだけでなく、最終的に適用された設定を確認してください。

1. 基準となる結果を記録：直接接続でテストできるネットワークでシステムプロキシとTUNを無効にし、DNS検査を実行します。Webサイトから見えるIPアドレス、リゾルバーのIP、DNS事業者を記録してください。問い合わせのプライバシーを厳重に守る必要がある場合は、直接接続での検査を省略できます。
2. システムプロキシだけを有効化：ブラウザーの設定は変えずに、もう一度検査します。システムプロキシが適用されるのは、プロキシ設定に従うアプリが中心です。システムのUDP 53番ポートへの問い合わせまで取り込む機能ではありません。
3. TUNとDNSのリダイレクトを有効化：コアが正常に起動したことを確認してから、再度検査します。この段階で初めて結果が変わる場合は、それまでコアを経由していなかったDNS通信を優先して調べてください。
4. ブラウザーのDNS設定を一時的に統一：元の設定を記録したうえで、ブラウザーのセキュアDNSを一時的に無効にして再検査します。Chromeでは「設定」→「プライバシーとセキュリティ」→「セキュリティ」から「セキュアDNSを使用する」を確認できます。組織のポリシーによって項目が固定されている場合があります。
5. 2回繰り返して検査：古い結果ページを更新するだけでなく、毎回検査を新たに実行します。必要に応じてキャッシュを削除してブラウザーを再起動し、過去の名前解決結果を現在の経路と誤認しないようにしてください。

ブラウザーのDoHは、HTTPSを使ってドメインを解決します。mihomoのDNS機能を経由しない場合がありますが、そのHTTPS接続自体はプロキシやTUNを経由することがあります。「コアのDNSを経由しない」ことと「問い合わせが日本国内の通信事業者へ直接送信される」ことは別です。それぞれ分けて確認してください。

コマンドでコアのDNS応答を確認する

コアのDNSが127.0.0.1:1053で待ち受けている場合は、次のコマンドで直接問い合わせできます。WindowsのPowerShellでDNSキャッシュを消去するコマンドは、必要なシステム権限で実行してください。digをインストール済みの環境では、2つ目のコマンドで問い合わせます。ここで使うexample.comは確認用のドメインであり、プロキシノードではありません。

# Windows PowerShell：システムのDNSキャッシュを消去
Clear-DnsClientCache

# digをインストール済みのmacOS / Linux：コアのDNSに直接問い合わせ
dig @127.0.0.1 -p 1053 example.com A

# IPv6レコードも問い合わせ、結果を個別に確認
dig @127.0.0.1 -p 1053 example.com AAAA

fake-ipモードでは、通常のAレコード問い合わせに対して198.18.0.0/16の範囲内のアドレスが返ることがあります。これは通常のマッピングであり、DNS汚染ではありません。fake-ipの除外ルール、特殊なドメイン処理、キャッシュなどにより、応答が異なる場合もあります。コマンドで問い合わせに成功しても、確認できるのはその待ち受けポートが利用可能だということだけです。ブラウザーやシステムの既定の問い合わせ先が同じポートだとは証明できません。

3. fake-ipとredir-hostの違いは名前解決のタイミング

fake-ipでは、アプリからの接続を受けたコアが仮想アドレスからドメインを特定し、ルールに従って通信の出口を決めます。接続先をリモートプロキシ側で解決する場合、ローカルで接続先の実IPアドレスを先に取得しなくてもよいことがあります。ただし、直接接続やIPルールによる判定、一部のプロトコルでは名前解決が必要です。fake-ipを有効にすれば、すべてのDNSが自動的にプロキシ経由になるわけではありません。

redir-hostは、従来型の実アドレスによる名前解決に近い方式です。信頼できる暗号化DNS上流と組み合わせて使えますが、このモードを選んだだけでリークが起きるとは限りません。モード名をプライバシーのレベルと捉えるのではなく、アプリとの互換性、通信が確実に取り込まれているか、ルールの要件を基準に選びましょう。

特定のアプリのために広範囲を除外しない

LAN内のサービス、ゲーム、デバイス検出などがfake-ipと互換性を持たない場合は、対象ドメインだけをfake-ip-filterに設定します。よく使われるパブリックドメインの範囲全体を、最初から除外するのは避けてください。除外範囲が広いほど、実際のアドレスを使う名前解決に戻る問い合わせが増え、仮想アドレスを前提とした動作も変わります。モードを切り替えたあとは、古い仮想アドレスがキャッシュに残らないよう、関連するアプリを再起動してください。

4. nameserver・fallback・ポリシーによるDNS設定

まず、3つの項目の役割を分けて考えましょう。nameserverは通常の名前解決に使う上流DNS、nameserver-policyは一致するドメインに対して指定する上流DNS、fallbackはフィルター条件と組み合わせて採用する応答を選ぶ設定です。これらが決めるのは「どこに問い合わせるか」であり、「どの出口から問い合わせるか」まで自動的に決まるわけではありません。暗号化DNSは通信方式を、プロキシのルーティングは接続経路を制御します。それぞれ個別に設定してください。

検証可能なDNS設定の基準を作る

以下は既存の設定に追加するDNSの抜粋であり、サブスクリプション全体ではありません。IPアドレス形式のDoHを使うことで、上流DNSのホスト名を解決するための事前問い合わせを減らせます。記載したサービスへ直接接続できないネットワークでは、プロキシ経路も設定してください。タイムアウトをYAMLの構文エラーと誤認しないようにしましょう。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

• default-nameserverは主にDNS上流のホスト名を解決するための設定で、すべての接続先ドメインをこのDNSに問い合わせるという意味ではありません。ここでの223.5.5.5は暗号化されていないブートストラップ用リゾルバーです。ブートストラップの問い合わせも暗号化したい場合は、現在のコアが対応し、実際に接続できる暗号化DNS上流を使い、動作を検証してください。
• listenはループバックアドレスだけで待ち受ける設定です。この例をそのままLANに公開されたDNSサーバーにしないでください。通常、OSのDNS設定では1053のような任意のポートを指定できないため、通信を取り込む仕組みかローカル転送が必要です。
• ipv6: falseはコアのDNSが返すAAAAレコードを制御します。OSのIPv6機能を無効化する設定ではなく、アプリが既知のIPv6アドレスへ接続することも防げません。IPv6通信もルーティングまたはTUNで適切に処理する必要があります。

nameserver-policyでLAN内ドメインとパブリックドメインを振り分ける

次の設定は、同じdnsオブジェクト内に記述します。例ではルーターのDNSを192.168.1.1としています。実際のアドレスは現在のネットワークで確認してください。PROXYは既存の設定にある実際のポリシーグループ名に置き換えます。大文字・小文字も一致させてください。

  nameserver-policy:
    "+.lan":
      - 192.168.1.1
    "+.github.com":
      - "https://1.1.1.1/dns-query#PROXY"

+.github.comは、このドメインとサブドメインに一致します。引用符で囲まれた#PROXYはmihomoがサポートするDNS上流の送信先指定で、このDoH接続に指定したポリシーを適用します。そのグループでDIRECTが選ばれていれば、問い合わせは直接接続されます。利用できないノードが選ばれているとタイムアウトします。ポリシーによる名前解決が適用されるのは指定したドメインだけで、すべてのパブリックサイトに自動で適用されるわけではありません。

fake-ipの除外リストとポリシーによる名前解決は別の機能です。前者は仮想アドレスを返すか実アドレスで解決するかを制御し、後者は問い合わせ先の上流DNSを選びます。*.lanを除外リストに追加する場合は、対応するLAN内のリゾルバーがそのレコードを実際に把握していることも確認してください。

fallbackは単なるタイムアウト時の予備ではない

fallbackを設定すると、コアが複数のDNSへ並行して問い合わせ、fallback-filterの条件に従って採用する応答を選ぶ場合があります。メインのリゾルバーが利用可能なら、fallbackには問い合わせが届かないと考えないでください。以下はGeoIPデータを利用して応答を選別する一例です。前述の最小構成と同時に有効化する必要はありません。

  fallback:
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

この例ではGeoIPのCN判定と指定したIP範囲のフィルターを使って、採用する応答を選びます。データベースが古い場合やCDNのIPアドレスの割り当てが変わった場合は、判定に影響することがあります。fallbackも既定のプロキシ経路ではありません。HTTPS接続は実際の出力設定に従います。問い合わせ先を絞りたい場合は、まず明確な単一の上流DNSで動作を確認し、そのうえでfallbackが必要か検討してください。

5. TUNとDNSの出力経路を設定する

経路は2段階に分かれます。1つ目はアプリからコアまで、2つ目はコアから上流DNSまでです。dns.enableを設定しただけでは、すべてのアプリがコアのDNSを使うようにはなりません。TUNを有効にした場合も、DNSのリダイレクトが実際に動作しているか確認してください。以下はmihomoでよく使われるTUN設定です。有効にする前に、クライアントに必要なシステム権限があり、ほかのVPNとルートが競合していないことを確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

ここで取り込むのは、TUNに入った通常のUDP/TCP 53番ポートの通信です。ブラウザーのDoHは通常HTTPSの443番ポートを使い、DoTでは853番ポートがよく使われます。53番ポートをリダイレクトする設定だけでは、これらがコアのDNSへ自動的に転送されることはありません。OSのLANルート、インターフェースのバインド、複数ネットワークアダプターの動作が取り込みに影響する場合もあります。ログと再検査で確認してください。

DNSもルーティングルールに従わせる場合

mihomoのrespect-rulesを使うと、DNS上流への接続もルーティングルールに従います。有効にする場合は、プロキシノードのホスト名を解決するための独立した入口としてproxy-server-nameserverも設定してください。「プロキシに接続するにはDNS解決が必要だが、DNS解決にはプロキシが必要」という循環依存を避けられます。

  respect-rules: true
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

この2行もdnsオブジェクト内に記述します。例にあるノードのホスト名を解決するDNSには、プロキシ接続を確立する前から到達できる必要があります。現在のネットワークから直接接続できない場合は、到達可能なDNSに変更し、それに伴って問い合わせを把握できる範囲も確認してください。まだ接続できないプロキシグループに、すべてのDNS上流を無理に向けないでください。

設定を統合するときは、トップレベルのdnsキーを1つだけ残してください。同じ名前のセクションを複数追加しないでください。サブスクリプションの更新で手動変更が上書きされることもあるため、クライアントが提供する上書き・マージ機能を使って保存し、再読み込み後に最終設定を確認してください。設定画面の場所はクライアントのバージョンによって異なります。操作方法は使い方ガイドも確認してください。

6. 症状から原因を絞り込み、最後に再検査する

ログを確認するときは、問い合わせを実行した直後に次の3点を追います。コアがリクエストを受信したか、どの上流DNSを選んだか、その上流への接続にどのポリシーを使ったか。DoHのリクエストは接続パネルでDNSサービスへのHTTPS接続として表示されることが多く、443番ポートへの接続が1件あるだけでWebサイトの通信経路が誤っているとは判断できません。必要な場合のみ一時的にログレベルを上げ、調査後は元に戻してください。ログを共有する前に、サブスクリプションURL、認証情報、個人用ドメインを削除しましょう。

1. 設定を保存してコアを再読み込みし、不明な項目、YAMLのインデント、ポートの競合によるエラーがないか確認します。
2. dig @127.0.0.1 -p 1053でDNSの待ち受けを確認した後、実際のブラウザーでアクセスし、通信が取り込まれているか検証します。
3. DNSリーク検査を再度実行し、通常のウィンドウ、別のブラウザー、IPv4とIPv6それぞれの結果を記録します。
4. ブラウザーのセキュアDNS、アプリ、ネットワーク環境を一つずつ元に戻し、結果が変わる原因となった設定を特定します。
5. クライアントを再起動するかサブスクリプションを更新して再検査し、上書き設定が今回の実行中だけでなく保持されることを確認します。

目標は検査ページに表示されるアドレスを1つだけにすることではありません。あらかじめ決めた経路に各種問い合わせが沿うことが重要です。LAN内のドメインは内部リゾルバーへ、プロキシが必要なドメインは指定したポリシーで解決し、ノードのホスト名には利用可能なブートストラップ用のDNSを用意します。通信の取り込み、上流DNS、出力経路を個別に確認するほうが、fake-ipとredir-hostを何度も切り替えるより原因を特定しやすくなります。