プライバシーと安全 読了目安 13分

ClashのDNSリーク検出と防止設定：テスト結果からルール修正まで

よくある検出結果の違いを解説し、DNSモード・上流サーバー・システム設定を見直して、ドメイン問い合わせの迂回を抑える方法を紹介します。

まずDNS問い合わせの迂回に当たるケースを確認する

ドメインにアクセスする前に、通常はドメイン名をIPアドレスへ解決する必要があります。Clashはこの処理を引き受けることもできますが、解決後のTCPまたはUDP接続だけをプロキシする構成も可能です。Web通信がプロキシを通過している一方、ドメイン問い合わせがローカルネットワークのDNSサーバーへ直接送信されると、問い合わせと実際の通信の経路が分離します。検出サイトでは通常、この状態をDNSリークとして表示します。

ただし、検出結果に現地の通信事業者、パブリックDNS、または異なる地域のリゾルバーが表示されても、必ずしも設定が失敗しているとは限りません。パブリックDNSではAnycastネットワークがよく使われ、同じサーバーアドレスでも都市ごとに異なる拠点へ接続されることがあります。また、DNSサービスが問い合わせを別の出口ノードへ転送する場合もあります。検出ページに表示されるのは再帰リゾルバーや出口インフラであり、設定ファイルに記載したアドレスそのものとは限りません。

正確に判断するには、次の3点を確認する必要があります。アプリが問い合わせを誰に渡したのか、Clashコアが上流リゾルバーへどのように接続したのか、解決後の通信がどのプロキシルールに一致したのか、です。検出ページの国名・都市名・サーバー名だけでは、この経路全体を復元できません。

検出される現象 考えられる原因 優先して確認する項目
ローカルネットワークのDNSが表示される システムの問い合わせがClashに入っていない、またはDIRECTポリシーがシステムリゾルバーを使用している システムDNS、TUN DNSハイジャック、現在の動作モード
複数のパブリックリゾルバーが同時に表示される 複数の上流サーバーを設定している、またはブラウザーで独自のセキュアDNSが有効になっている ブラウザー設定、nameserverとfallback
ノードを切り替えてもDNSの地域が変わらない 上流接続が常に直接接続になっている、またはDNS接続がプロキシルールに従っていない respect-rules、プロキシポリシー、コアのバージョン
一部のプログラムだけ結果がおかしい プログラム内蔵のDoH、キャッシュ、または独自のネットワークスタック アプリ内DNS、キャッシュ、プロセスの接続

再現可能なClash DNSリーク検出手順を作る

切り分ける前に、テスト条件を固定します。設定やノードを切り替えたり、ブラウザー設定を変更したりしながら何度もページを更新すると、どの変更が結果に影響したのか分かりにくくなります。現在の設定ファイルを保存し、コアの種類、動作モード、システムプロキシの状態、TUNの状態、ブラウザーのセキュアDNSの状態を記録しておくとよいでしょう。

手順1：プロキシ未使用時の基準値を取る

一時的にシステムプロキシとTUNを無効にし、検出ページを開いてリゾルバー名、数、概算の位置を記録します。この結果が、現在のネットワークにおける通常のDNS経路です。続いてClashを有効にし、新しいプライベートウィンドウでテストします。2回の結果が完全に同じ場合、システムの問い合わせが従来の経路を使い続けている可能性がありますが、キャッシュやアプリ内蔵DoHも含めて確認する必要があります。

手順2：キャッシュを削除し、新しいドメインを使う

システム、ブラウザー、Clashコア、上流サーバーのいずれも解決結果をキャッシュする可能性があります。同じページを更新するだけでは、新しいDNS問い合わせが発生しないことがあります。テスト時はOSのDNSキャッシュを削除し、ブラウザーを終了して再起動したうえで、検出ツールが提供する新しいランダムドメインを使用します。クライアントにDNSキャッシュの削除やコアの再起動機能がある場合は、設定変更後に実行してください。

手順3：システムプロキシとTUNを区別する

システムプロキシは、HTTPまたはSOCKSプロキシ設定に従うプログラムに主な影響を与えます。通常のUDP 53番ポートへの問い合わせは、システムプロキシを有効にしただけで自動的にClashへ入るわけではありません。TUNモードはネットワーク層でより多くの通信を受け取り、DNSハイジャックルールによって従来のDNS問い合わせをコアへ渡せます。そのため、同じ設定でもシステムプロキシモードとTUNモードでは検出結果が異なる場合があります。

手順4：コアのログと接続記録を確認する

検出中にクライアントのログを開き、テストドメイン、DNS、UDP、DoH、ルール一致に関する記録を検索します。ログには、ドメインがfake-ipへマッピングされたこと、問い合わせが特定のnameserverへ送られたこと、接続がDIRECTやPROXYなどのポリシーに一致したことが記録されます。こうした証拠は、検出ページの地理情報より直接的です。ログにテストドメインがまったくない場合、問い合わせが現在のコアに入っていない可能性が高いでしょう。

  1. 設定ファイルとプロキシノードを1つずつ固定する。
  2. システムプロキシ、TUN、IPv6、ブラウザーのセキュアDNSの状態を記録する。
  3. キャッシュを削除してから1回検出する。
  4. 1回の検証では1つの項目だけ変更する。
  5. コアのログ、接続一覧、検出結果を照合する。

fake-ipとredir-hostの経路の違い

Clashでよく使われる拡張DNSモードにはfake-ipとredir-hostがあります。どちらもコアがドメイン解決に関与できますが、仕組みは異なります。モードを選ぶ際は、ルール一致、LAN機器との互換性、アプリの動作を同時に考慮し、検出ページに表示されたリゾルバー数だけで判断しないでください。

fake-ip：予約アドレスを返し、コアがドメインを復元する

fake-ipモードでは、Clashが専用アドレス範囲からマッピング用のアドレスを返します。アプリがそのアドレスへ接続すると、コアがマッピングテーブルから元のドメイン名を復元し、ドメインルールに基づいてポリシーを選択します。これにより、システムが実際の宛先IPを先に取得してからプロキシへ渡す状況を減らし、ドメインルールも適用しやすくなります。

fake-ipだからといって、すべてのDNS通信が自動的に引き受けられるわけではありません。アプリがClashのDNS待ち受けポートへ問い合わせを送るか、TUNのDNSハイジャックルールがコアへ転送する必要があります。ブラウザーが外部DoHサービスへ直接アクセスする場合、問い合わせはHTTPSに包まれるため、通常の53番ポートのハイジャックではDNSの内容を識別できません。

LAN名、プリンター検出、ネットワーク接続確認、一部のゲームプラットフォームでは、fake-ipが適さない場合があります。このようなドメインはfake-ip-filterに追加し、コアから実アドレスを返すようにします。フィルターは実際に問題があるドメインだけに設定してください。範囲を広げすぎると、fake-ipによるドメインマッピングの効果が弱まります。

redir-host：実アドレスを返しつつドメイン処理を維持する

redir-hostは、実際に解決されたアドレスをアプリへ返します。実IPに依存する一部のプログラムとは互換性を保ちやすい一方、解決処理が早い段階で行われるため、上流DNSへの到達性と応答内容により強く左右されます。旧Clashクライアントではこのモードがよく使われました。mihomoでも関連設定を扱えますが、新しい設定ではクライアントの対応状況とネットワーク環境を組み合わせて検証してください。

上流DNSとルール経路を修正する

以下の設定は各フィールドの役割を説明するためのもので、既存のサブスクリプションをそのまま置き換えるものではありません。Clashの各派生版では対応フィールドが完全には一致しません。オリジナルClashの旧コアでは通常、基本的なenable、enhanced-mode、nameserver、fallback、fake-ip-filterに対応しています。proxy-server-nameserver、direct-nameserver、nameserver-policy、respect-rulesなどは、主に新しいmihomoコアで利用できます。

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
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

  nameserver-policy:
    "geosite:private":
      - system
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

  fake-ip-filter:
    - "*.lan"
    - "localhost"

default-nameserverは起動時の名前解決を担当する

暗号化DNSのアドレスには、通常dns.alidns.comのようにドメイン名が含まれます。コアはDoH接続を確立する前に、そのドメインのアドレスを取得しなければなりません。default-nameserverはこの初期解決を主に担当し、プロキシサーバーのドメインを起動時に解決するためにも使われます。すべての通常のドメイン問い合わせで使われる最終的な上流サーバーではないため、設定後もnameserverを指定してください。

nameserverは通常の問い合わせ先

nameserverは、通常のドメイン問い合わせに使う上流サーバーを定義します。複数のサーバーを指定すると到達性を高められますが、テスト時には複数のDNSインフラが確認されることもあります。問い合わせ元の経路を特定したい場合は、まず安定した上流サーバーを1つだけ残し、経路を確認してから予備を追加するとよいでしょう。

DoHやDoTを使うと、従来のDNSパケットがローカル経路上を平文で流れることを避けられます。ただし、暗号化しただけで接続がDIRECTになるかプロキシを通るかが決まるわけではありません。上流接続が直接接続なら、出口は依然として現在のネットワークです。ルールに従って出口を選ばせたい場合は、コアが対応する追従機能をサポートし、有効化していることを確認してください。

proxy-server-nameserverはノードのドメインを解決する

サブスクリプション内のプロキシサーバーは、固定IPではなくドメイン名で指定されている場合があります。コアはプロキシ接続を確立する前に、ノードのドメインを解決しなければなりません。この解決処理がまだ確立していないプロキシに依存すると、循環が発生します。mihomoのproxy-server-nameserverでは、この種の問い合わせに使うリゾルバーを明示できます。現在のネットワークから直接アクセスでき、安定した上流サーバーを選んでください。

nameserver-policyはリゾルバーだけを選択する

nameserver-policyでは、ドメインやルールセットに応じて上流サーバーを選べます。たとえば、プライベートドメインをシステムDNSへ渡し、特定地域のドメインには対応するリゾルバーを使う設定が可能です。これは「どのDNSサーバーへ問い合わせるか」を制御するもので、「Webサイトへの接続を最終的にどのポリシーグループへ送るか」を決めるものではありません。実際の通信は、rules内のドメイン・IP・ルールセット・フォールバックルールによって決まります。

例にあるgeositeは、コアが対応するルールデータを読み込んでいることが前提です。クライアントにルールセットがない、データのバージョンが古い、ルール名が存在しないといった場合、ポリシーが想定どおり一致しないことがあります。この場合は、まず明確なドメインサフィックスでテストし、その後にルールデータの取得元と更新日時を確認してください。

fallbackとフィルター条件は慎重に扱う

古い設定では、fallbackと地理IP判定を組み合わせて解決結果を選ぶことがよくあります。設定を誤ると通常の上流と予備の上流へ同時に問い合わせるため、検出ページに複数のDNSサービスが表示されます。これは必ずしも迂回ではなく、並列問い合わせの仕組みによる場合があります。mihomoへ移行する場合は、必要に応じてnameserver-policyでドメインを明確に分け、説明しにくい並列結果を減らすとよいでしょう。

OS・ブラウザー・アプリ内DNSを確認する

Clashコアの設定が正しくても、すべてのプログラムがそれを使うとは限りません。DNS問い合わせは、システムリゾルバー、ブラウザーのセキュアDNS、アプリ内蔵DoH、仮想マシン、コンテナ、LAN内の別端末から送信されることがあります。切り分けでは、問い合わせ元を一つずつ確認してください。

システムプロキシはすべてのDNSを引き受けるわけではない

システムプロキシを有効にすると、ブラウザーは通常HTTPまたはHTTPS接続をプロキシへ渡しますが、システムサービスやプロキシ設定に従わないプログラムは直接通信する可能性があります。従来のDNS問い合わせは主にUDPまたはTCPの53番ポートで送信され、自然にHTTPプロキシへ入ることはありません。システムプロキシだけを有効にするクライアントでは、一部のシステムレベルの問い合わせがネットワークアダプターに設定されたDNSを使い続けることを想定してください。

一部のクライアントは、TUNを有効にするとシステムDNSを自動変更したり、ネットワークサービスをインストールしたりします。この状態で複数のネットワークアダプターを手動で異なるDNSに変更すると、競合が起きる可能性があります。まずクライアントのドキュメントと実行ログを確認し、DNS設定をクライアントが管理しているか確かめてから手動調整を行ってください。

ブラウザーのセキュアDNSが独立した経路を作ることがある

最新のブラウザーは、指定したDoHサービスへ直接接続できます。この接続は通常のHTTPS通信として扱われるため、システムリゾルバーを迂回する場合があり、dns-hijack: any:53でも捕捉できません。Clash内蔵DNSをテストするときは、ブラウザーのセキュアDNSを一時的にシステム設定に従うよう変更し、ブラウザーのDNSキャッシュを削除してから再検出してください。

ブラウザーのDoHを維持する必要がある場合は、独立したDNS方式として扱ってください。その場合は、DoHサービスのドメインに対するプロキシルール、接続出口、失敗時のフォールバック動作を確認します。Clashのfake-ip設定がブラウザー内部の問い合わせまで引き受けることを期待してはいけません。

IPv6は個別に確認する

ClashのDNS設定でipv6を無効にしても、通常はアプリへAAAAレコードを返さなくなるだけで、OSのIPv6ネットワーク自体が無効になるわけではありません。アプリがキャッシュ済みのIPv6アドレスを使ったり、独自のリゾルバーでAAAAレコードを取得したりする可能性もあります。IPv6環境でだけ異常が起きる場合は、OSのIPv6、コアのIPv6対応、プロキシノードの能力、ルール内のIPv6経路を個別に確認してください。

検出ページの表示を1つに揃えるためだけに、システム全体のIPv6を恒久的に無効にすることはおすすめしません。まず管理された条件でテストし、問題が本当にIPv6に起因するか確認してから、ノードとネットワークの対応状況に応じて調整するほうが確実です。

LANやコンテナはホストのリゾルバーを使わないことがある

仮想マシン、Dockerコンテナ、Androidエミュレーター、LAN内の端末は、独自のDNS設定を持つことがよくあります。ホスト側のClashが正しく問い合わせを引き受けていても、これらの環境がルーターや外部サーバーへ直接問い合わせる場合があります。他の端末からClash DNSを利用するには、待ち受けアドレス、ファイアウォール、LANアクセス権限も確認してください。ループバックアドレスだけにバインドした状態で、他の端末が接続できると期待してはいけません。

TUNモードでDNSハイジャックとルーティング順序を確認する

TUNモードはシステムプロキシに従わない通信も受け取れるため、システムレベルのDNS迂回に対処する一般的な方法です。mihomoの設定では、dns-hijackを使って従来の53番ポートへの問い合わせを捕捉し、内蔵DNSモジュールへ渡せます。実際に利用できるフィールドは、クライアントが生成する設定や実行権限にも左右されます。

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

auto-routeはルートを自動設定し、auto-detect-interfaceは現在の出口となるネットワークアダプターの選択をコアに任せます。有線・無線ネットワーク、別のVPN、仮想アダプターを同時に使用している端末では、自動検出が意図しないインターフェースを選ぶことがあります。DNSタイムアウトや、TUN有効化後に完全に通信できなくなった場合は、nameserverだけでなくデフォルトルートとインターフェースの変化を確認してください。

any:53が主に処理するのは従来のDNSです。外部DoHを復号することはできず、QUIC、プライベートDNS、アプリが独自に構築したトンネルが内蔵リゾルバーへ入ることも保証しません。これらのプロトコルについては、アプリ側でDNSの動作を統一するか、ドメインとネットワークのポリシーで該当する接続を制御してください。

TUNを有効にした後は、Clash自身が上流DNSへ接続する通信が誤ってTUNへ戻され、ループしていないことも確認します。成熟したクライアントでは通常、コアプロセス、ルーティングマーク、または送信インターフェースを適切に処理します。同じDNS問い合わせがログに繰り返し現れて最終的にタイムアウトする場合は、クライアントのサービスモード、コアの権限、除外ルールを確認してください。

検出結果に応じてルールと設定を修正する

検出結果にローカル通信事業者のDNSが表示される場合、最初に何を変更すべきか？

まずコアのログにテストドメインが現れているか確認します。記録がない場合は、ブラウザーのセキュアDNS、システムDNS、TUNハイジャックを優先して確認します。記録があるのに上流接続がDIRECTなら、nameserver、ルール追従設定、現在のポリシーを確認してください。最初から複数の予備DNSを追加すると、結果の変数が増えるため避けましょう。

fake-ipを使っても複数のDNSが表示されるのはなぜ？

fake-ipが管理するのはアプリへ返すアドレスのマッピングであり、コアが1つの上流サーバーにしかアクセスできないよう制限するものではありません。nameserver、fallback、nameserver-policy、ブラウザーのDoH、他のアプリが問い合わせを発生させる可能性があります。まず上流を1つだけ残し、ブラウザー独自のDoHを無効にしてから、設定を一つずつ戻してください。

TUNを有効にするとDNS検出は正常だが、一部のサイトが開けない場合は？

fake-ip-filter、ドメインルール、IPv6、ノードへの到達性を確認します。サイトがLAN内の解決や実IPを必要とする場合は、必要なドメインを正確なフィルターリストへ追加できます。接続記録で誤ったポリシーに一致していないかも確認してください。名前解決に成功したからといって、実際の通信も必ず成功するとは限りません。

DoHの上流接続は必ずプロキシを通すべき？

必ずしもそうではありません。重要なのは経路が目的に合っており、上流サーバーへ安定して到達できることです。DoHを直接接続すれば、ローカル経路上のDNS内容を保護できますが、出口は現在のネットワークのままです。プロキシ経由でDoHへ接続すれば、DNSの出口をプロキシ経路に合わせられますが、コアによるルール処理への対応が必要で、ノードのドメイン解決が循環しないよう注意する必要があります。

サブスクリプション更新後にDNS設定が元へ戻った場合は？

サブスクリプションファイルは通常、リモート側で生成されるため、直接編集すると更新時に上書きされる可能性があります。クライアントが提供するオーバーライド、マージ、設定パッチ機能を使い、変更が必要なDNSフィールドだけを管理してください。更新後はパッチファイルだけでなく、最終的に合成された設定を確認します。

最終確認チェックリスト

  • 現在有効なProfileと、編集しているファイルが一致している。
  • コアの種類とバージョンが、使用しているDNSフィールドに対応している。
  • テストドメインをコアのログで確認できる。
  • システムプロキシとTUNの適用範囲を区別できている。
  • ブラウザーとアプリ内蔵DoHの状態を確認している。
  • nameserver、fallback、ポリシールールが目的なく重複問い合わせを行っていない。
  • ノードのドメインに、独立して到達可能な起動時の解決経路がある。
  • 設定変更後にコアを再起動し、関連キャッシュを削除している。
  • IPv4、IPv6、LAN機器で個別にテストを完了している。

DNS保護の目的は、すべての検出ページに同じ固定名を表示させることではありません。問い合わせ経路を説明・制御できる状態にし、プロキシルールと整合させることが重要です。まず問い合わせがClashへ入っているかを確認し、次にコアがどの上流を選んだか、最後に上流接続と実際の通信の出口ポリシーを確認します。この順序で進めれば、複数のDNSフィールドを何度も試す手間を減らせます。

Clashをダウンロード