Clash DNS漏洩チェックと修正:漏洩防止設定の実践手順

DNS漏洩とは:プロキシは起動中でも、クエリはローカルへ流れている

ドメイン解決はネット接続の最初の一歩です。ブラウザはドメイン名を取得すると、まずそれをIPアドレスに変換する必要があり、この処理を担うのがDNSです。いわゆるDNS漏洩とは、プロキシが「接続済み」と表示されていても、解決リクエストが実際には自分の本来のネットワークから直接発信され、ISPやルーターのDNSサーバーに届いてしまう状態を指します。結果は二つの側面で問題になります。一つはプライバシーで、どのドメインにいつアクセスしたかがローカルネットワークの提供者に丸見えになります。もう一つは可用性で、ローカルDNSが改ざんされた結果を返すと、ブラウザは誤ったIPを受け取り、「Clashは接続済みなのにページが開かない、または表示内容が間違っている」という典型的な症状が現れます。

プロキシを起動しているのに漏洩するのはなぜでしょうか。よくある原因は次の4つです。

システムプロキシモードはブラウザなどアプリのWebリクエストしか処理せず、システムのDNS設定は変更しないため、ISPが自動配布するDNSはそのまま動作を続けます。
Clashの内蔵DNSが無効になっている、または有効でもリスニングアドレスがシステムが実際に使う解決経路をカバーしていない。
ブラウザ標準の「セキュアDNS」(DoH)機能がシステムのリゾルバーを迂回し、DoHサーバーへ直接アクセスしているため、検証結果自体が正確でなくなる。
IPv6経路が処理対象になっておらず、AAAAクエリがIPv6用DNSサーバー経由で漏れる。IPv4側のDNSだけを変更してもこの経路は塞げません。

ステップ1:まずチェックして漏洩の有無を確認する

修正の前に事実を確認しましょう。以下の順に実施し、漏洩が発生しているか、どの経路で発生しているかを見極めます。

Clashクライアントを開き、プロキシが接続済みであることを確認し、現在のモード(ルール/グローバル/ダイレクト)を記録します。
ブラウザのセキュアDNSを一時的に無効化します。Chromeは「設定 → プライバシーとセキュリティ → セキュリティ → セキュアDNSを使用する」でオフに、Edgeも同様の手順です。Firefoxは「設定 → 一般 → ネットワーク設定」で「HTTPS上のDNSを有効にする」をオフにします。無効化しないと、検証結果はブラウザのDoHの通信経路を反映するだけで、システム側の経路を示しません。
公開されているDNS漏洩検証サイト(dnsleaktest、ipleak、browserleaksのDNSチェックなど)を開き、まず標準テスト、続いて拡張テストを実行します。
結果を照合して判定します。一覧に自分の地域のISP(通信キャリア)のDNSノードが表示されていれば漏洩あり、Cloudflare・Googleなど海外のパブリックDNSかプロキシ出口拠点のリゾルバーしか表示されなければ漏洩なしです。
システムプロキシモードとTUNモードそれぞれで一度ずつ検証してください。両モードでは処理範囲が異なるため、結果が変わることがよくあります。

注意

検証前に一度システムのDNSキャッシュをクリアし、古いキャッシュが結果に影響しないようにしてください。Windowsは管理者権限で ipconfig /flushdns を実行し、macOSは sudo dscacheutil -flushcache の後に sudo killall -HUP mDNSResponder を実行します。

誤判定しやすいポイントがあります。nameserverに現地のパブリックDNS(例:アリババの223.5.5.5)を設定している場合、検証サイトにはそのDNSプロバイダーのノードが表示されることがあります。これはクエリが実ネットワークから直接そのDNSプロバイダーへ届いたことを意味し、厳密には実IPがそのDNSサービス事業者に見えている状態ですが、ISPレベルの漏洩とは異なります。ここを追求するかどうかは「一般的な振り分け」か「厳格な漏洩防止」のどちらを目指すかによります。以下で両方の設定例を示します。

修正1:nameserverを正しく設定する

ClashのDNS動作は設定ファイル内の dns セクションで制御されます。まず各項目の意味を理解してから変更しましょう。

enable:内蔵DNSのメインスイッチ。漏洩防止には true が必須です。
listen:リスニングアドレスとポート。0.0.0.0:53 と設定すると、ローカルの53番ポートへのクエリを処理対象にします。
enhanced-mode:fake-ip または redir-host。fake-ipは198.18.0.1/16帯の仮想アドレスを返し、Clashが接続を処理する際に内部でドメインを逆引きするため、解決処理が一切Clashの外に出ず漏洩防止としては最も確実です。redir-hostはクライアント側が先に実IPを解決してから接続を開始します。
nameserver:デフォルトの上流DNSで、直接接続するドメインの解決を担います。IPを含むDoHアドレスの利用を推奨します。例:https://223.5.5.5/dns-query、https://119.29.29.29/dns-query。
fallback:海外ドメインにマッチした際の上流DNSで、通常は https://1.1.1.1/dns-query、https://8.8.8.8/dns-query を設定します。クエリはプロキシ経由で送信されます。
default-nameserver:上記のDoHサーバー自体のドメインを解決するための「ブートストラップDNS」です。純粋なIP(223.5.5.5、119.29.29.29など)を指定し、「DoHサーバーのドメインを解決するのにさらにDNSが必要」という循環を避けます。
proxy-server-nameserver(mihomo):ノードサーバーのドメイン解決専用の設定で、信頼できるローカルDoHを指定し、ノードのドメインが改ざんされて接続不能になるのを防ぎます。

一般的な振り分け構成の完全な設定例です。

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://223.5.5.5/dns-query
    - https://119.29.29.29/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query

厳格な漏洩防止の設定では、nameserverからローカルの上流DNSを外し、すべてfallback経由でプロキシを通して解決させます。代償として、ローカルサイトへの初回アクセスがやや遅くなります。折衷案として、nameserver-policyでドメイン単位に振り分ける方法もあります。

  nameserver-policy:
    "geosite:cn":
      - https://223.5.5.5/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

ヒント

サブスクリプションファイルには通常dnsセクションが含まれており、直接編集しても次回更新時に上書きされてしまいます。推奨する方法は、まず元の設定をバックアップしてから、クライアントの設定オーバーライド機能(Clash Verge Revの「グローバル拡張設定」、Clash Nyanpasuの Merge機能など)を使ってdnsセクションを注入することです。これによりサブスクリプションを更新しても設定が維持されます。

修正2:クエリを確実にClashへ通す(ハイジャック・リスニング)

設定が正しくても、システムがクエリをClashへ送らなければ意味がありません。処理方式は3種類あり、手間の少ない順に紹介します。

方式1:TUNモード(推奨)

mihomo(Clash Meta)コアのTUNモードは仮想ネットワークカードを作成し、UDP 53のDNSクエリを含む端末全体の通信を処理対象にします。dns-hijackは任意のアドレスの53番ポートへのクエリを内蔵DNSへリダイレクトします。Clash Verge Rev、Clash Nyanpasu、FlClashなどのクライアントでは設定内でワンクリック有効化でき、有効化後はシステムDNSの設定内容はもはや重要ではなくなります。

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

方式2:システムDNSを手動で変更する

ネットワークカードのIPv4 DNSを 127.0.0.1 に、IPv6 DNSを ::1 に変更します(あるいはIPv6を無効化)。dns.listenで53番ポートをリスニングさせる必要があります。WindowsのInternet接続共有や一部の仮想マシンのネットワークサービスが53番ポートを占有しClashの起動時にエラーが出ることがある点に注意してください。この場合、占有しているプロセスを特定して停止するか、TUNモードに切り替えるのが確実です。リスニングポートを無理に変更してはいけません。WindowsのネットワークカードDNS設定は53番以外のポート指定に対応していません。

方式3:システムプロキシ+redir-hostのみ

処理範囲が最も限定的な方式です。プロキシを通過するアプリの通信のみが処理対象になり、システム内の他プロセスのDNSクエリは従来どおりの経路を通ります。TUNを有効化できない場合は、少なくともブラウザのDoHを無効化し、「ブラウザだけを制御できる」という限界を受け入れる必要があります。

修正3:ルールによる兜底と再検証チェックリスト

最後の防衛線はルールです。DNS設定は「どう解決するか」を決め、ルールは「取り漏れたクエリ通信をどこへ流すか」を決めます。

ルール末尾の MATCH がDIRECTではなくプロキシ系ポリシーグループを指していることを確認してください。これにより、どのルールにもマッチしない通信(アプリ内蔵のDoHリクエストを含む)が直接接続されるのを防げます。
53番ポートにDIRECTルールを追加しないでください。TUNモードではdns-hijackが既に処理を行っているため、余分なルールは混乱の元になるだけです。
アプリ内蔵のDoHは最もよくある取り漏れ経路です。dns.google、cloudflare-dns.com、mozilla.cloudflare-dns.com などのパブリックDoHドメインをREJECTに指定し、アプリをシステム解決へフォールバックさせ、Clashに一括処理させることができます。

すべて変更し終えたら、次のチェックリストで再検証してください。

漏洩検証を再度実行し、結果に海外のリゾルバーしか残っていないことを確認する。
別のネットワーク環境(自宅の固定回線からスマホのテザリングに切り替えるなど)でもう一度テストし、単一経路での偶然の結果でないことを確認する。
サブスクリプションを手動で更新し、dnsのオーバーライドがまだ有効であることを確認してから、もう一度テストする。
その後数日はアクセスできないサイトがないか気を付けてください。一部のサービスはfake-ipと相性が悪いことがあり、その場合は対象ドメインを fake-ip-filter に追加すれば済み、redir-hostに戻す必要はありません。

DNS漏洩は一度直せば終わりという問題ではありません。クライアントの切り替え、ネットワークの変更、サブスクリプションの更新によって設定が元に戻ってしまうことがあります。「変更したら検証する、更新したら再検証する」を習慣にすることで、初めて漏洩防止が本当に完成します。