ClashのDNSリーク検出と防止設定：Fake-IPとnameserverの設定方法

まずDNSリークの定義を確認する

ブラウザーでドメインにアクセスする前に、ドメイン名をIPアドレスへ解決する必要があります。Clashを有効にするとWeb接続はプロキシ経由でも、DNSクエリだけがルーター、中国の通信事業者のDNS、システム指定のパブリックDNS、あるいはブラウザーが独自に有効化した暗号化DNSへ直接送信されることがあります。この場合、プロキシの出口とDNSリクエストの出口は同じ経路上にありません。

確認のポイントは、単純に「検出ページに表示されたDNSアドレスがプロキシノードのIPと一致するか」を比べることではありません。パブリックDoHサービスは通常、独立したサーバーが応答し、Anycastによって近隣のデータセンターへ振り分けられることもあるため、両者が異なるのは珍しくありません。本当に確認すべきなのは、検出結果に日本国内の通信事業者、社内ネットワーク、学校のネットワーク、家庭用ルーターが提供するDNSサービスが現れていないか、またクエリが想定したプロキシとルールの経路を迂回していないかです。

よくある4つのDNS経路

リクエスト元	想定される経路	確認ポイント
システムの通常DNS	UDPまたはTCPの53番ポート	TUNが53番ポートを引き受けているか、システムプロキシで対象アプリをカバーできるか
ブラウザーのセキュアDNS	ブラウザーが選択したDoHアドレス	ブラウザーの設定がシステムDNSを上書きしていないか、検出時も同じ設定か
Clash内蔵DNS	nameserver、fallback、またはポリシーで指定したサーバー	上流アドレス、プロキシ経路、ルールが正しいか
アプリ内蔵の名前解決	ハードコードされたDNS、DoH、DoT	TUNのルートが対象アプリをカバーしているか、アプリがシステムプロキシを迂回していないか

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

1回の検出結果は、キャッシュ、ブラウザーの接続再利用、上流サーバーのAnycast振り分けの影響を受けやすいものです。確実に調べるには、まず基準値を記録し、キャッシュを削除したうえで、直接接続とプロキシ接続の両方で繰り返しテストします。ブラウザー、ネットワーク、設定は同じままにし、複数の条件を同時に変更しないでください。

手順1：Clashを有効にしていない状態の基準値を記録する

Clashクライアントを完全に終了し、システムプロキシとTUNの両方が無効になっていることを確認します。
dnsleaktest.comまたはbrowserleaks.com/dnsを開き、標準テストと拡張テストを1回ずつ実行します。
検出されたDNSプロバイダー、国または地域、サーバー数を記録します。家庭用ブロードバンドでは、1～4個のリゾルバーアドレスが表示されることが一般的です。
続いてOSのネットワーク詳細を開き、現在のネットワークアダプターが取得しているDNSアドレスを記録します。ルーターのアドレスである192.168.1.1や、ネットワークから割り当てられたパブリックアドレスが表示される場合があります。

この結果からローカルのリゾルバーを特定できます。後でClashを有効にした際に同じプロバイダーやアドレスが再び現れれば、クエリがローカルネットワークから送信され続けているか判断できます。

手順2：キャッシュを削除してプロキシを有効にする

Windowsでは、まずターミナルでipconfig /flushdnsを実行します。macOSではsudo dscacheutil -flushcacheを実行し、続けてsudo killall -HUP mDNSResponderを実行します。Linuxのキャッシュ削除方法は名前解決サービスによって異なります。systemd-resolvedを使用している場合はresolvectl flush-cachesを実行できます。

続いてクライアントを起動し、対象の設定をインポートしてプロキシを有効にします。すべてのアプリのDNSを確認する場合は、「設定」→「ネットワーク」→「TUNモード」でTUNを有効にします。ブラウザーのシステムプロキシだけをテストする場合はTUNを無効のままにし、今回の結果がそのブラウザーの通信経路だけを示すことを明確にしておきます。

手順3：2回に分けて検出する

1回目は通常ウィンドウで行い、普段のブラウジング環境における実際の結果を確認します。
2回目は新しいプライベートウィンドウで行い、ページキャッシュ、Service Worker、古い接続の影響を抑えます。
各回で少なくとも1回は拡張テストを実行します。拡張テストでは通常、ランダムなサブドメインへのクエリが多く発生するため、混在した名前解決経路を見つけやすくなります。
1回目に指定したDoHリゾルバーが2つ表示され、2回目にローカル通信事業者のリゾルバーが3つ突然追加された場合は、断続的なリークとして扱ってください。都合のよい1回の結果だけを採用してはいけません。

Fake-IPモードでドメイン解決を引き受ける仕組み

mihomoカーネルでは、enhanced-mode: fake-ipを使うと通常のドメインに予約済みアドレスを返し、カーネル内で「ドメイン―Fake-IP」の対応関係を管理します。アプリがこの予約アドレスへ接続すると、カーネルは元のドメインを復元し、ドメインルール、プロキシグループの選択、実際の宛先解決を続けて実行できます。一般的なデフォルトのアドレスプールは198.18.0.1/16で、ネットワークベンチマーク用の予約範囲に由来するため、パブリックな宛先として使用してはいけません。

Fake-IPの利点は、接続段階までドメイン情報を保持できることです。アプリへ実IPを直接返す方法に比べ、DOMAIN、DOMAIN-SUFFIX、GeoSiteなどのルールを安定してマッチさせやすく、アプリが先に実アドレスを取得してから接続することで生じるルール判定のずれも抑えられます。

出発点として使えるDNS設定

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  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://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

例では待ち受けポートに1053を指定し、システムで一般的な53番ポートの直接使用を避けています。システムDNSを実際に引き受ける場合は、通常TUNのdns-hijackによって53番ポートへのクエリをカーネルへ転送します。一般ユーザーのプロセスが特権ポートを直接待ち受ける必要はありません。

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

default-nameserverは主に、DoHやDoTなど上流サーバー自身のドメインを解決するために使います。たとえばnameserverにhttps://dns.alidns.com/dns-queryと記述した場合、HTTPS接続を確立するにはまずdns.alidns.comのIPが必要です。ここには直接到達できるIPアドレスを優先して指定し、「DNSサーバーを解決するために先にDNSへ問い合わせる」という循環依存を避けます。

これはすべての業務ドメインに対する主要な名前解決リストではなく、ネットワークアダプターのDNS設定と同じものでもありません。default-nameserverに十数個のアドレスを詰め込んでも信頼性が自動的に高まるわけではなく、検証すべき変数が増えるだけです。通常は、経路が安定していて直接到達できるアドレスを2つ残せば十分です。

nameserverが主要なドメインクエリを処理する

nameserverは通常のクエリに使う主要な上流サーバーです。UDP DNSのほか、DoHやDoTも利用できます。ローカルネットワークから平文の53番ポート通信を覗かれる可能性を減らすため、https://1.1.1.1/dns-queryのようなDoHアドレスを選ぶ方法が一般的です。ただし、暗号化されるのはクライアントとDNSサービス間の通信だけであり、すべてのドメインを同じ上流へ渡すべきという意味でも、リクエストが必ずプロキシ経由になるという意味でもありません。

DNS接続をルールに従わせる必要がある場合は、対応するmihomoバージョンでrespect-rules: trueを使用できます。その際はproxy-server-nameserverも設定し、プロキシノードサーバーのドメインを解決します。設定しないと、ノードのドメイン自体が循環解決に陥る可能性があります。

nameserver-policyで細かく振り分ける

ドメインごとにリゾルバーを指定する必要がある場合は、nameserver-policyを使用できます。内部ドメイン、LAN上のサービス、特定の解決結果が必要な地域向けサイトに適しており、すべてのリクエストを複数の上流へ並列で送るより検証しやすくなります。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.1.1

最後の設定は、実在する内部ドメインの用途に限って使用してください。192.168.1.1が家庭用ルーターであれば、そこへ問い合わせる対象のリクエストはローカルネットワークを通ります。これは明確に選択したポリシーであり、意図しないリークと混同してはいけません。

fake-ip-filterで除外すべきドメイン

すべてのドメインがFake-IPに適しているわけではありません。LAN内のデバイス検出、画面キャスト、一部のSTUN検出、OSの接続チェック、実アドレスに依存する一部のプログラムでは例外が必要になることがあります。fake-ip-filterは一致した項目に実際の解決結果を返すためのもので、Fake-IPモード全体を無効にする設定ではありません。

最小限の例外から始める

*.lan、*.local：ローカルデバイスやLAN内サービスでよく使われます。
ルーターの管理用ドメイン：実際に使用するときだけ追加し、この端末と無関係なメーカーのドメインをコピーしないでください。
音声、動画、オンライン接続に異常が出た場合に限り、ログに記録されたSTUNドメインへルールを追加します。
特定のアプリがフィルター追加後にだけ動作する場合は、トップレベルドメイン全体ではなく、具体的なドメインを記録してください。

フィルターの範囲が広すぎると、Fake-IPのドメインマッピング機能が弱まります。たとえば*.comを直接追加すると、多数のサイトが実IPを返すようになり、ドメインルールのマッチ過程も追跡しにくくなります。項目を追加するたびに、障害の症状、ログ上のドメイン、再テスト結果を残しておくと、不要になった例外を後で削除しやすくなります。

TUNモードとDNSハイジャックの重要設定

システムプロキシが主に影響するのは、HTTPまたはSOCKSプロキシ設定に従うプログラムです。多くのゲーム、コマンドラインツール、バックグラウンドサービス、独自のネットワークスタックを持つアプリはシステムプロキシを読み取らないため、システムプロキシを有効にするだけではDNSがClashへ入る保証はありません。TUNモードは仮想ネットワークアダプターでIPトラフィックを引き受けるため、端末全体のDNS経路を確認するのに適しています。

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

any:53は通常の53番ポートへのDNSクエリを引き受け、追加のtcp://any:53はTCP DNSをカバーします。auto-routeはルートを自動追加し、auto-detect-interfaceはデフォルトの出口を識別します。strict-routeはクエリがTUNを迂回する可能性を抑えますが、仮想マシン、企業VPN、LAN共有、複数のネットワークアダプター環境では既存のルーティングに影響する場合があるため、項目ごとに確認してください。

クライアントで確認する順番

「設定ファイル」ページを開き、現在の設定が正常に読み込まれ、画面にYAML解析エラーがないことを確認します。
「設定」→「ネットワーク」→「TUNモード」を開き、TUNを有効にして、システムの指示に従いネットワークまたは管理者権限を許可します。
「設定」→「パラメーター設定」を開き、以前キャッシュされた設定のコピーではなく、対象のカーネルと対象設定が使われていることを確認します。
「ログ」を開き、レベルを一時的にDebugへ変更して、dns、fake-ip、またはテストドメインを検索します。
テストが終わったらログレベルをInfoに戻し、大量のデバッグ情報を長期間記録しないようにします。

クライアントのバージョンによってメニュー名は多少異なりますが、確認すべき対象は同じです。現在の設定、カーネルDNS、TUNスイッチ、ルートの引き受け、ログ記録が同じ実行インスタンスに対応していなければなりません。システムトレイに別のClashクライアントが残っている場合、2つのプロセスが同時にプロキシ、ポート、ルートを変更する可能性があります。

よくあるリーク原因と対処法

システムプロキシだけを有効にし、TUNを有効にしていない

Webページの接続はプロキシ経由でも、システムの名前解決はネットワークアダプターのDNSへ送信されることがあります。TUNとDNSハイジャックを有効にするか、システムDNSをクライアントの待ち受けアドレスへ明示的に向けてください。端末全体を引き受ける場合は、前者のほうが一元管理しやすいことが一般的です。

ブラウザーが独自にDoHを有効にしている

ブラウザーが選択したDoHサービスへ直接接続し、Clashのドメイン振り分けを迂回する場合があります。まずブラウザーのセキュアDNSを無効にして比較し、無効化後に検出結果が正常へ戻るなら、ブラウザーをシステム設定に従わせるか、ルールでそのDoH接続を明示的に引き受けるかを決めます。1つのブラウザーの結果だけで、すべてのアプリを推測しないでください。

nameserverが平文UDPで直接接続されている

nameserverに8.8.8.8や1.1.1.1のようなIPだけを指定すると、クエリは通常UDP 53番ポートから送信されます。TUNのルートで処理される可能性はありますが、通信自体は暗号化DNSではありません。ローカルネットワークからの監視を減らしたい場合は、対応するDoHアドレスへ変更し、HTTPS接続が実際にどのポリシーで処理されたかをログで確認します。

ノードのドメインで名前解決が循環する

プロキシノードのアドレスがドメイン名の場合、プロキシを確立する前にカーネルがノードを解決する必要があります。しかし、その解決自体がまだ確立していないプロキシ経由になるようルールで指定されていると、循環が発生します。設定の読み込みは成功しているのに、ノードがすべてタイムアウトするのが典型的な症状です。ノードのドメイン専用にproxy-server-nameserverを設定し、プロキシ確立前にこれらのリゾルバーへ到達できることを確認してください。

IPv6のクエリまたは接続が別の経路を通っている

設定のipv6: falseは、カーネルDNSがAAAAレコードを返すかどうかに影響するだけで、OS全体のIPv6通信を必ず無効にするわけではありません。ローカルネットワークがIPv6を提供しているのにTUNのルートがIPv4しかカバーしていない場合、アプリがIPv6へ切り替えることがあります。テストではIPv4、IPv6のアドレスとDNS結果を同時に確認してください。一時的にシステムのネットワークアダプターでIPv6を無効にする方法は比較に使えますが、最終的にはTUNとルートのカバー範囲を修正する必要があります。

古いキャッシュによる見かけ上の結果

システム、ブラウザー、アプリ、mihomoカーネルはいずれも解決結果をキャッシュすることがあります。設定変更直後に同じページを再読み込みしても、新しいクエリが発生しない場合があります。システムキャッシュを削除し、ブラウザーを再起動したうえで、ランダムなサブドメインや検出サイトの拡張モードを使って、名前解決を再実行してください。

修正後の完全な確認リスト

確認段階では、Webページが開くかどうかだけを見ないでください。接続に成功しても、少なくとも1つの経路が利用できることしか示さず、すべてのDNSが想定どおり流れている証明にはなりません。次の順番で実行し、各手順の結果を記録することをおすすめします。

設定の読み込みを確認：ログにyaml、parse、dns configに関するエラーがない。
待ち受けポートを確認：例の1053、または実際の設定ポートを現在のカーネルが待ち受け、別のプロセスに占有されていないことを確認する。
Fake-IPを確認：通常のドメインを問い合わせたとき、198.18.0.0/16範囲の値が返ることを確認する。フィルターリストのドメインには実アドレスが返る。
ルールのマッチを確認：接続画面またはログ画面で、テストドメインに適用されたルールとプロキシグループを確認し、意図せずDIRECTになっていないことを確認する。
拡張テストを実行：2回連続で実行し、結果に基準値の段階で記録したローカル通信事業者のリゾルバーが表示されないことを確認する。
ブラウザー設定を切り替えて再テスト：セキュアDNSを有効にした状態とシステム設定に従う状態でそれぞれテストし、差異の原因を明確にする。
ブラウザー以外のアプリをテスト：コマンドラインツールまたは別のアプリで接続し、TUNの引き受けがブラウザーだけに有効なのではないことを確認する。
再起動後に再テスト：クライアントとシステムを再起動し、TUN、DNS、設定の選択が想定どおり復元されることを確認する。

nslookup example.com 127.0.0.1
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

コマンド内のアドレスとポートは、実際の待ち受け値に合わせて変更してください。クライアントが127.0.0.1:1053だけで待ち受けている場合、-p 1053を省略できません。Fake-IPモードでAレコードに198.18.x.xが返るのは通常の動作です。これは対象サイトの実際のパブリックIPアドレスではありません。

より安定した調整手順

実際のトラブル対応では、「基準値を確認—経路を統一—例外を絞る—ログを検証」の順に進めるのがおすすめです。まず明確なnameserverを2つ残し、Fake-IPとTUNのDNSハイジャックを有効にして基本経路を安定させます。その後でnameserver-policy、LAN向けの名前解決、アプリ互換用の項目を追加します。

最初から大規模なDNS設定を丸ごとコピーしないでください。フィールドが増えるほど、名前解決の経路は説明しにくくなります。多くの個人端末では、各上流の用途、各例外の出所、各クエリがプロキシを通ったかを説明できることのほうが、大量のリゾルバーを積み重ねるより重要です。変更後は同じ検出サイト、同じブラウザー状態、同じネットワークで繰り返しテストして、リークが本当に修正されたか判断してください。