Clash DNS リークの検出と対策設定:fake-ip、nameserver-policy の実践

DNS リークの判断基準：名前解決経路と接続の出口

Clash でウェブページを開けても、すべての DNS リクエストが想定した経路を通るとは限りません。ブラウザーは HTTP プロキシ経由で接続を送る一方、事前にシステムのリゾルバーを呼び出すこともあります。バックグラウンドのアプリはシステムプロキシを無視する場合があり、ブラウザーのセキュア DNS が独自に HTTPS 接続で名前解決することもあります。調査では、ドメインをどのリゾルバーが解決したか、またそのリクエストがどの経路から送信されたかを分けて記録してください。

この記事では「DNS リーク」を、本来は指定した名前解決経路に送るべきドメインの問い合わせが、実際にはローカルネットワーク、通信事業者、その他の想定外のリゾルバーに渡っている状態と定義します。中国本土向けの直接接続にローカルのリゾルバーを明示的に指定している場合、検査ページに中国国内のアドレスが表示されたというだけでリークと判断すべきではありません。判断の基準は、事前に定めたルーティング方針であり、結果に特定の国名が含まれているかどうかではありません。

確認できた結果	実際の意味	次に確認すること
ウェブサイトへの接続出口が変わった	現在のウェブ接続はプロキシを経由している	DNS は別途確認する。これだけでは名前解決の出口は判断できない
通信事業者のリゾルバーが検出された	テスト用ドメインが最終的にその再帰リゾルバーから問い合わせられた	システム DNS、ブラウザーのセキュア DNS、ルーティング方針を確認する
複数のリゾルバーが検出された	並列問い合わせ、転送、または複数の出口が存在する可能性がある	nameserver、fallback、テスト条件を照合する
198.18 の範囲のアドレスが返された	Fake-IP のマッピングに一致している可能性がある	通信が同じカーネルに戻っているかを確認する

検査前の準備：クライアント、ブラウザー、ネットワーク条件を固定する

以下の設定例は mihomo カーネルを対象としています。Clash Meta はその旧称です。旧版の Clash や更新が停止したクライアントでは、すべての項目に対応しているとは限りません。まずクライアントの「バージョン情報」またはカーネル情報で、カーネル名とバージョンを記録してから、現在の設定をエクスポートしてください。クライアントとカーネルのバージョンは別々に記録し、「Clash 最新版」のようにまとめないでください。

元に戻せる状態を確保する。サブスクリプション設定とローカル上書きをエクスポートし、システムプロキシ、TUN、ブラウザーのセキュア DNS の元の設定を記録します。
テスト条件を固定する。同じネットワーク、ノード、ブラウザーで比較し、テスト中は他の VPN やプロキシツールを一時停止します。
ブラウザー独自の名前解決を先に除外する。Chrome では「設定」→「プライバシーとセキュリティ」→「セキュリティ」から「セキュア DNS を使用する」を確認します。Firefox では「設定」→「プライバシーとセキュリティ」から「HTTPS 経由の DNS」を確認します。メニュー名はバージョンによって異なる場合があります。
設定が反映される場所を確認する。サブスクリプションの元ファイルは更新時に置き換えられることがあります。クライアントのローカル上書きやマージ機能を使って変更を保持し、最終的な実行設定を確認してください。

オンライン DNS リーク検査：地理情報だけでなく結果を比較する

DNSLeakTest を開き、まず Standard test、次に Extended test を実行します。検査サイトはランダムなサブドメインを使って、再帰リゾルバーから権威 DNS サーバーへの問い合わせを確認します。そのため、結果に表示されるのは通常、名前解決サービスの出口です。システムに設定したサーバーアドレスやプロキシノードのアドレスとは限りません。

3種類の結果を記録する

基準値：クライアントによる通信の取り込みを無効にして検査し、リゾルバーの IP、運営主体、使用中のネットワークを記録します。
システムプロキシ：TUN を無効にしたまま、クライアントのシステムプロキシを有効にして再検査します。結果が変わらなくても、テストの経路が元の名前解決経路を使っている可能性が残ります。
TUN で取り込む：後述の DNS と TUN の設定を有効にして検査し、同じ項目を記録します。クライアントの接続パネルで名前解決の接続も確認してください。

各条件で2回実行することをおすすめします。結果が一致しない場合は、キャッシュ、ブラウザーのセキュア DNS、複数の上流への並列問い合わせを先に確認し、すぐにノードを変更しないでください。パブリックリゾルバーはエニーキャストや分散型の出口を利用することがあります。検査ページに表示される国や都市は正確でない場合があります。運営主体が想定どおりか、特定の名前解決経路を無効にしたときに結果も変わるかを重視してください。

オンライン検査で確認できるのは、ブラウザーが発生させたテスト用の問い合わせだけです。システム内のすべてのアプリが通信を取り込まれている証明にはなりません。ローカルでの問い合わせも確認し、必要に応じて物理ネットワークインターフェースの通信を観察してください。サブスクリプションリンク、アクセス先のドメイン、アクセストークンを含むログ全体を、公開のフォーラムにアップロードしないでください。

fake-ip の基本設定：ドメインと接続を対応づける

Fake-IP モードでは、アプリに仮想アドレスを返し、カーネルがマッピングからドメインを復元してルールに照合します。接続確立前に実際の名前解決を必要とするケースを減らせますが、暗号化プロトコルではなく、すべての DNS を自動的に遮断するものでもありません。アプリが仮想アドレスを受け取った後にカーネルを迂回して接続すると、タイムアウトが発生することもあります。

以下は設定の一部をマージする例であり、サブスクリプション設定全体ではありません。既存のプロキシノード、ポリシーグループ、ルールは残してください。実行設定に dns: がすでにある場合は、子項目をマージし、ファイル末尾に同名のトップレベルキーを重複して追加しないでください。

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

listen は DNS サービスをローカルの 1053 番ポートに限定します。通常、システム DNS の設定ではポートを指定できません。127.0.0.1 を入力しただけで DNS が取り込まれたと考えないでください。
default-nameserver は DNS サーバー自身のドメインを解決するための項目です。つまりブートストラップ用の名前解決であり、通常のドメインを解決する主な上流ではありません。
proxy-server-nameserver はプロキシノードのドメインを解決する経路を指定し、ノードの名前解決とプロキシ確立の間で循環依存が起きるのを抑えます。
nameserver-policy の +.qq.com は、そのドメインとサブドメインに一致し、指定した上流へ渡します。別のルールで名前解決の動作が変わらない限り、その他のドメインは nameserver を使います。
fake-ip-filter に一致するドメインには実際の名前解決結果を返します。これらが直接接続に設定されるわけではなく、パブリック DNS で LAN 内の名前を解決できる保証もありません。

この例では、トラブルシューティング時の変数を減らすため、DNS の AAAA 応答を一時的に無効にしています。これは OS の IPv6 を無効にする設定ではなく、アプリがキャッシュ済みの IPv6 アドレスを使うのを防ぐものでもありません。IPv6 が必要な環境では機能を戻し、IPv6 のルーティング、DNS、プロキシによる通信の取り込みがすべて適切に動作することを確認してください。経路の問題を単一の設定項目で隠したままにしないでください。

fallback-filter：応答を選ぶ設定であり、問い合わせの外部送信を防ぐものではない

fallback は「メインのリゾルバーがタイムアウトした場合にだけ予備サーバーへ問い合わせる」と誤解されがちです。一般的な設定では、メインの上流と fallback が並行して問い合わせを行い、フィルター条件によって採用する応答を決める場合があります。そのため同じドメインが複数のサービスに知られる可能性があり、「単一の名前解決サービスだけを許可している」証明にはなりません。

以下は中国本土の IP アドレスを優先する独立した設定例です。この方法を使う場合は、各項目を同じ dns: の下にマージしてください。前述の単一上流の設定とは用途が異なります。まず基本設定を検証し、その後で fallback を導入するか判断してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

この例では GeoIP 条件に基づいてメインの名前解決結果を判定します。CN 条件に一致しない結果や、指定したアドレス範囲に含まれる結果では、fallback の応答が採用されます。実際の動作は地理情報データとカーネルの実装に依存します。IP の地理的な分類は、ドメインの信頼性を判断する基準にはなりません。国際 CDN、企業向けサービス、データ更新の遅延によって、選択結果が想定から外れることがあります。

「指定したいくつかのドメインだけに専用のリゾルバーを使う」要件なら、fallback の条件を広げるより nameserver-policy を優先してください。その方が検証しやすくなります。専用の名前解決ポリシーに一致したドメインが、デフォルトのメイン上流と fallback の組み合わせで処理されるとは限りません。使用中のバージョンのドキュメントと実際の問い合わせログを確認してください。

TUN による DNS 横取り：システムプロキシでは対象にならない問い合わせを補う

システムプロキシは主にプロキシ設定に従うアプリ向けであり、システム DNS を取り込む仕組みとは異なります。TUN は仮想ネットワークインターフェースで通信を受け取り、一致した DNS リクエストをカーネルの名前解決モジュールに渡します。以下の設定は前述の DNS 基本設定とマージできますが、仮想ネットワークインターフェースを作成できるかどうかは、システム権限、クライアントのサービス、プラットフォームの対応状況によります。

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

any:53 は TUN に入る UDP 53 のリクエストに一致し、2つ目の項目は TCP 53 を補います。これらはシステムのファイアウォールルールではありません。実際にカーネルの取り込み経路に入った通信だけが処理対象になります。複数のネットワークインターフェース、仮想マシン、コンテナー、他の VPN、特定のシステムルートによって、この前提が変わる場合があります。

53 番ポート以外の経路

DoH：通常は HTTPS の 443 番ポートを使うため、DNS 53 の横取りだけでは従来型の問い合わせとして検出できません。アプリのセキュア DNS を管理するか、接続のルートを明示してください。
DoT：通常は TCP 853 を使います。モバイル端末のプライベート DNS がこの経路を使う場合があるため、個別に確認が必要です。
LAN 内のデバイス検出：mDNS は通常 UDP 5353 を使い、ここで扱う一般的な DNS 横取りの対象外です。プリンター、画面共有、ローカルドメインの検出は別途テストしてください。

有効化後に端末全体がネットワークに接続できなくなった場合は、まず TUN を無効にして接続を復旧し、管理者権限またはサービスモード、デフォルトの出口インターフェース、ルートの競合を確認してください。複数のクライアントで同時に TUN を有効にしないでください。また、ポート競合を解決するためだけに DNS サービスを 0.0.0.0 で公開しないでください。待ち受けアドレスの変更には、LAN 内アクセスの制御も関係します。

ローカルでの検証と受け入れ確認：設定の反映、通信の取り込み、サブスクリプション更新

まず 1053 の待ち受けと Fake-IP の応答を確認する

dig がインストールされたシステムで、次のコマンドを実行します。ポートを明示すれば、OS のリゾルバーが切り替わっているかどうかに依存せず、カーネルの DNS を直接テストできます。ツールがインストールされていない場合は、クライアントの DNS 診断機能を使ってください。通常の nslookup は既定で 53 番ポートに接続します。

dig @127.0.0.1 -p 1053 www.wikipedia.org A
dig @127.0.0.1 -p 1053 www.qq.com A
dig @1.1.1.1 www.wikipedia.org A

最初の2つのコマンドは、カーネルの DNS を直接確認します。例の Fake-IP 設定では、フィルターに一致しない A レコードの問い合わせに対して、通常は 198.18.0.0/16 の範囲内のマッピングアドレスが返されます。ただし、実際にどの上流が使われたかの証明にはなりません。TUN が有効で 53 番ポートの横取りが機能している場合、3つ目のコマンドもカーネルに捕捉される可能性があります。ツールにサーバーとして 1.1.1.1 と表示されても、リクエストが本当にそのアドレスに到達したとは限りません。

次に物理ネットワークインターフェースと実際の接続を確認する

さらに確認する場合は、Wireshark で実際に接続しているネットワークインターフェースを選び、udp.port == 53 || tcp.port == 53 || tcp.port == 853 でフィルターしてください。テスト中に、想定外の平文問い合わせが物理インターフェースから出ていないかを確認します。このフィルターは DoH を対象にしません。また、53 番ポートの通信が見えなかっただけでは、すべての問い合わせがプロキシ経由である証明にはなりません。暗号化された上流への接続出口は、クライアントのログや接続パネルと合わせて確認してください。

古いキャッシュを消去する。Windows では ipconfig /flushdns を実行します。systemd-resolved を使用する Linux では resolvectl flush-caches を実行します。その後、古い接続の影響を避けるため、テスト用ブラウザーを再起動します。
オンライン検査を再実行する。同じノードとブラウザー設定を保ち、リゾルバーの運営主体と基準値との差を比較します。
実際のサービスを再テストする。中国本土のウェブサイト、海外のウェブサイト、企業内ネットワーク、LAN 内のデバイスを確認し、専用 DNS ポリシーによって内部ドメインの名前解決が妨げられていないことを確認します。
設定の保持を確認する。サブスクリプションを更新してクライアントを再起動し、実行設定に dns、tun、ポリシー関連の項目が残っていることを確認します。