Clash DNSのリーク検出・対策｜確認手順と漏えい防止設定

DNSリークと判断する基準

DNSリークとは、ドメイン名の問い合わせが想定した経路から外れてしまうことです。たとえば、すべてのインターネット向けドメインをプロキシ経由で名前解決する設定なのに、実際には自宅のルーターから接続事業者のDNSへ転送されるケースがあります。Webサイトへの接続元IPが変わっていても、DNSの経路まで変わったとは限りません。アプリが先にシステムのリゾルバーへ問い合わせ、取得したIPアドレスを後からプロキシに渡す場合があるためです。

まず目的を明確にしてから結果を判断しましょう。ここでは2つの目的を区別します。1つ目は、システムのDNS問い合わせをすべてClashのコアに通し、指定した暗号化DNSを使うこと。2つ目は、DNS上流への接続もプロキシの出口経由にすることです。前者では暗号化DNSへの直接接続を許容しますが、後者では許容しません。この2つを同じ「テスト合格」という結果で判断することはできません。

• システムプロキシ：システムプロキシ設定に従うアプリにのみ適用され、すべてのUDP問い合わせを自動的に取り込むわけではありません。
• TUN：仮想ネットワークアダプターを使い、ルーティング条件に合うIP通信を取り込みます。ただし、ルートの除外、権限、ほかのVPNの影響を受けます。
• fake-ip：アプリに対応するマッピングアドレスを返し、コアがドメイン名の情報を保持しやすくします。DNS暗号化プロトコルではありません。
• DoH / DoT：DNSリゾルバーへの接続を暗号化しますが、接続は直接でもプロキシ経由でも可能です。

基準値を記録する：接続出口とDNSリゾルバーを確認

テスト条件をそろえる

1. 使用中のクライアント、コアのバージョン、OS、ネットワークインターフェース、ほかのVPNを同時に使用しているかを記録します。
2. ほかのプロキシアプリを終了し、ブラウザーの「セキュア DNS」を一時的に無効にして、複数の名前解決方式が混在しないようにします。後で個別に有効へ戻してテストしてください。
3. プロキシを無効にした状態、システムプロキシのみ有効な状態、TUNを有効にした状態のそれぞれで、Web接続の出口IPとDNSテスト結果を記録します。
4. 各テストの前に、システムとブラウザーのキャッシュを消去してから新たにテストします。テストページでは、同じキャッシュ済みドメインを繰り返し使わず、新しく生成されたドメインを使用してください。

ブラウザーで https://www.dnsleaktest.com/ または https://browserleaks.com/dns を開いてテストできます。これらの外部サービスには、接続元IPやテスト用の問い合わせ情報が送信されます。テストで確認できるのは通常、再帰リゾルバーが権威DNSサーバーへ問い合わせる際の出口です。アプリからリゾルバーまでの通信にどのプロトコルが使われたかを、これだけで証明することはできません。

「複数のDNS IPが表示された」だけでは、リークの十分な証拠にはなりません。パブリックDNSサービスが複数の出口を使う場合や、設定された複数の上流が問い合わせに関与する場合があります。確認すべきなのは、表示されたリゾルバーが想定どおりか、問い合わせが予定していたプロキシ経路を迂回していないかです。

システム側を確認する：インターフェースのDNS、キャッシュ、53番ポート

Windows：Wi-Fiだけでなく、各インターフェースを確認する

PowerShellで以下のコマンドを実行します。1つ目はインターフェースのDNS設定、2つ目はキャッシュの消去、3つ目はDNS問い合わせを行います。イーサネット、Wi-Fi、仮想アダプターがある場合は、現在動作中のすべてのインターフェースを確認してください。

Get-DnsClientServerAddress
Clear-DnsClientCache
Resolve-DnsName example.com -Type A

Resolve-DnsName が成功しても、応答を取得できたことを示すだけで、プロキシを経由した証明にはなりません。nslookup example.com に表示される既定のサーバーも、透過的なリダイレクト後に使われる最終的な上流とは限りません。コアのログ、ルーティング、物理インターフェース上の通信も併せて確認してください。

macOSとLinux：ローカルDNSスタブを確認する

# macOS：各スコープのDNS設定を確認
scutil --dns
# macOS：システムのDNSキャッシュを更新
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# systemd-resolvedを使用するLinux
resolvectl status
resolvectl flush-caches
resolvectl query example.com

Linuxの /etc/resolv.conf が 127.0.0.53 を参照している場合、通常はsystemd-resolvedのローカルスタブを使用しています。上流もローカルにあるという意味ではありません。続けて resolvectl status を実行し、各リンクのDNS ServersとDNS Domainを確認してください。systemd-resolvedを使わないディストリビューションでは、対応するネットワーク管理ツールで確認します。

パケットキャプチャでは物理インターフェースを選ぶ

Wiresharkでは、表示フィルター dns || tcp.port == 853 を使うと、一般的なDNSとDoT接続を確認できます。macOSやLinuxでは次のコマンドも使えます。en0 は実際にネットワークへ接続しているインターフェース名に置き換えてください。

sudo tcpdump -ni en0 '(udp port 53 or tcp port 53 or tcp port 853)'

物理インターフェースで、ルーターや接続事業者宛ての平文によるパブリックドメインの問い合わせが見つかった場合は、発信元をさらに追跡してください。DoHは通常443番ポートを使うため、上記のフィルターでは除外できません。TUN仮想インターフェースで見える問い合わせは、取り込み前の通信である可能性があります。物理ネットワークから送信済みのリークと決めつけないでください。

mihomoの設定：TUN、fake-ip、DNS hijack

以下は既存の設定にマージするための断片であり、完全なサブスクリプションではありません。既存の proxies、proxy-groups、rules は残してください。すでに tun または dns がある場合は既存の項目を編集し、YAMLキーの重複を避けます。クライアントのオーバーライドまたはマージ機能で変更を保存し、次回のサブスクリプション更新で上書きされないようにしてください。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

主な設定項目の役割

• auto-route: true：TUNの自動ルートを設定します。デスクトップクライアントでは通常、管理者権限またはサービスモードが必要です。
• strict-route: true：ルーティングの動作を厳格化します。Windowsでは、複数ネットワーク接続時のDNS迂回を抑えるのに役立ちますが、仮想マシン、LAN、ほかのVPNに影響する場合があります。OSによって動作は異なります。
• dns-hijack：TUNに入るTCP/UDPの53番ポート宛てDNS通信を、コアのリゾルバーに渡します。任意のHTTPSリクエストは対象外で、すべてのアプリ内DoHを自動的に検出できるわけでもありません。
• listen: 127.0.0.1:1053：ローカルループバックアドレスの1053番ポートだけで待ち受けます。通常、システムのDNS設定では標準以外のポートを指定できないため、「127.0.0.1:1053」をシステムDNSのアドレス欄に入力することはできません。
• ipv6: false：内蔵DNSでのAAAA問い合わせの処理を制御します。システム全体のIPv6を無効にする設定でも、IPv6のリーク防止スイッチでもありません。
• proxy-server-nameserver：プロキシノードのホスト名を解決するために使います。「ノードへの接続に、そのノード経由の名前解決が必要」という循環依存を防ぎます。

fake-ipで返されることが多いアドレスは 198.18.0.0/16 の範囲です。このアドレスが表示された場合はマッピング機能が使われたことを示しますが、接続先Webサイトの実際のアドレスが予約済みアドレス帯に変わったわけではありません。fake-ipを受け取ったアプリがコアを迂回して直接接続すると、接続に失敗することがあります。その場合は通信の取り込みを修正し、すぐに fake-ip-filter を広げないでください。ドメインを除外リストに追加すると返されるアドレスの方式は変わりますが、DNS上流の出口が自動的に変わるわけではありません。

DNS上流もプロキシ経由にする：ルールとブートストラップDNS

パブリックドメインの問い合わせに使うDNS上流への接続もノード経由にする場合は、DNSの送信経路に関する設定を追加します。mihomoでは respect-rules: true を指定すると、DNS上流への接続にルーティングルールを適用できます。この項目を使う場合は、ノードのホスト名を独立した経路で解決できるよう、proxy-server-nameserver も設定してください。

以下の例では、既存の設定に PROXY という名前のプロキシグループがあり、DIRECT ではなくプロキシノードが選択されていることを前提としています。先ほどの設定例の dns セクションに1つ目の項目を加え、2つ目のルールを既存の rules の上位に挿入してください。既存のルール一覧を置き換えないでください。

# 既存の dns セクションにマージ
dns:
  respect-rules: true

# 既存の rules リストに追加し、先に一致する可能性のあるルールより上に配置
rules:
  - IP-CIDR,1.1.1.1/32,PROXY,no-resolve

このルールは 1.1.1.1 宛ての接続に PROXY を選択します。同じIP宛てのほかの通信にも影響します。例にあるIPv4の上流だけが対象です。ほかのDNSアドレスを使う場合は、ルールを改めて設計してください。保存後はコアの接続記録を確認し、DNS上流への接続に想定したポリシーが適用されていることを確かめます。設定ファイルに respect-rules があることだけで判断してはいけません。

ノードのホスト名を解決するブートストラップ経路も別途確認が必要です。通常のドメイン名解決がプロキシ経由でも、起動時にノードのホスト名を解決する際はDNSへ直接接続する可能性があります。起動時の直接接続も避けたい場合は、サービス提供元がサポートする安定したノードIP、または管理されたブートストラップ方式を使い、必要なTLSサーバー名の設定も維持してください。一時的に取得したIPを長期間固定すると、ノードのアドレス変更後に接続できなくなるおそれがあります。

システムDNSへのフォールバックと独立した名前解決経路を無効にする

fallbackをシステムのフォールバック設定と混同しない

Clashの fallback はコア内の別の上流を指定し、fallback-filter と組み合わせて結果の使い方を決める設定です。OSの予備DNSではありません。削除しても、DHCPで通知されたリゾルバーへの通信は止まりません。反対に、fallback のアドレスを安易に増やすと、問い合わせ先のDNSサービスが広がる可能性があります。

• すべての上流設定を確認：nameserver だけでなく、default-nameserver、fallback、nameserver-policy、direct-nameserver と、それぞれの実際の用途も確認してください。1つの一覧だけを変更しないでください。
• Windowsの複数インターフェースを確認：「設定」→「ネットワークとインターネット」で、現在有効な各インターフェースのDNS割り当てを確認します。管理対象端末でグループポリシーが設定されている場合は、「スマートなマルチホーム名前解決を無効にする」などのポリシーについて管理者に相談し、企業ネットワークの設定を無断で変更しないでください。
• ブラウザーを確認：Chromeの「設定」→「プライバシーとセキュリティ」→「セキュリティ」→「セキュア DNS を使用する」では、使用するDNSサービスを個別に選べる場合があります。調査中は無効にし、再び有効にした後は接続が想定した出口を通るか確認してください。
• Androidを確認：システム設定で「プライベート DNS」を検索します。指定したプライベートDNSプロバイダーは通常、暗号化接続を使うため、53番ポートのDNS hijackで自動的に取り込めるとは限りません。設定画面の場所やVPNの動作はメーカーによって異なります。
• IPv6と通信の振り分けを確認：物理インターフェースのIPv6 DNS、TUNの除外ルート、アプリごとのバイパス、ほかのVPNが迂回経路になることがあります。原因の切り分けのために一時的に無効にするのは構いませんが、長期的な対策では必要なIPv4とIPv6のルートをどちらもカバーしてください。

「プロキシが使えない場合は名前解決を停止する」という厳格な方針が必要な場合は、DNS経路を確認したうえで、ルーティングまたはファイアウォールのルールを使って直接接続を制限し、ノードへの接続と必要なネットワークサービスは明示的に許可してください。TUNを有効にしただけで、通信を遮断する保護が成立するわけではありません。リモート端末、企業内ネットワーク、ポータル認証が必要なネットワークでは、特に事前に復旧手段を用意してください。

手順に沿って再テストし、問題を切り分ける

1. 設定の読み込みを確認：設定を再適用し、未知の項目、重複キー、YAMLのインデントエラーがないことを確認します。起動ログにTUNの確立成功が表示されていることも確認してください。
2. 古い応答を消去：システムのキャッシュを更新し、ブラウザーを完全に終了してから再起動します。各テストでは新しいドメインを使い、キャッシュで実際の経路が隠れないようにしてください。
3. システムの名前解決を確認：まずOSのコマンドで名前解決を実行し、その後ブラウザーのDNSテストを行います。テストページの表示だけでなく、両方の結果を現在の設定で説明できることを確認してください。
4. 上流の接続出口を確認：コアの接続情報とログで、DNSの宛先、適用ルール、最終的に選択されたプロキシグループを確認します。プロキシ経由を求める場合は、DIRECT が選ばれていないことを確認してください。
5. 物理ネットワークを確認：TCP/UDPの53番ポートと、必要に応じて暗号化DNS接続をキャプチャします。送信元が不明な443番ポートの接続は、プロセス情報と照合して判断してください。「平文パケットが見えない」ことだけを根拠にしないでください。
6. 状態変化後も確認：Wi-Fiの切り替え、スリープからの復帰、ノードの切り替え、サブスクリプションの更新後にもテストを繰り返します。オーバーライドが維持されているか、ルートが再設定されているか確認してください。
7. 障害時の動作を確認：復旧できるローカル環境で、選択中のプロキシを一時的に利用できなくします。システムが想定どおり接続に失敗するか、別のDNS経路へ気付かないうちに切り替わるかを確認してください。

Webページがすべて開けない場合

まずDNSのタイムアウトとプロキシ接続の失敗を切り分けます。ログにDoH上流への接続失敗がある場合は、1.1.1.1:443 への送信ルールとノードの状態を確認してください。ノードのホスト名を解決できない場合はブートストラップDNSを確認します。fake-ipを取得できても接続がタイムアウトする場合は、TUNのルート、除外対象のプロセス、ほかのVPNとの競合を確認してください。一度に変更するのは1か所だけにし、変更前の設定を保存して、複数の変更が原因を分かりにくくしないようにします。