トラブル対処 読了目安 12分

ClashのDNSリーク検出方法と漏洩対策設定：enhanced-modeとnameserverの設定

DNSリークの検出サイトの見方から、enhanced-mode、fake-ipフィルター、nameserverの設定、修正後の確認まで実践解説。

まず検出対象を確認：出口アドレスとDNS解決は別物

ブラウザーでWebサイトにアクセスすると、通常はまずドメインをDNSリゾルバーに渡し、解決されたIPアドレスへ接続します。ClashがWeb接続を引き受けていても、DNSリクエストまで同じ処理経路に入るとは限りません。よくあるのは、Webの出口はプロキシノードになっているのに、検出ページには日本国内の回線事業者、ルーターから配布されたリゾルバー、またはシステムに手動設定したパブリックDNSが表示されるケースです。調査では「接続の出口」と「ドメイン解決の経路」を分けて記録しましょう。

DNS検出ページに表示されるのは通常、検出用ドメインの再帰問い合わせを代行したリゾルバーの出口であり、PCがリクエストを直接送信した宛先ではありません。たとえばシステムがルーターの192.168.1.1へ問い合わせ、ルーターがさらに回線事業者へ転送する場合、検出結果には事業者の再帰サーバーだけが表示されることがあります。DoHでは、クラウド事業者のエニーキャストノード、提携ネットワーク、実際のノードとは異なる都市が表示される場合もあります。そのため、都市が一致しないだけで異常とは断定せず、事業者名、自律システム、リクエスト数、再テストの結果も確認してください。

再現可能な3パターンのテストを用意する

  1. 現在のグローバルIP、ネットワーク事業者、地域を記録し、いったんClashを終了してベースライン検出を1回実施します。
  2. Clashを起動しますが、まずTUNを無効にし、システムプロキシだけを有効にしてプライベートウィンドウで2回目の検出を行います。
  3. この記事の設定とTUNのDNSハイジャックを有効にし、キャッシュを消去して接続を再確立したうえで、3回目の検出を行います。

各ラウンドでは標準テストと拡張テストを1回ずつ実行し、リゾルバー数、組織名、国または地域を保存するのがおすすめです。1回だけの結果は、ブラウザーキャッシュ、検出サイトの負荷、DNSエニーキャストの振り分けに左右されやすいからです。検証記録は30秒間隔で3ラウンド連続して取得してください。同じ事業者のリゾルバーが3ラウンドすべてに現れるなら、偶発的な1回よりも経路の問題を明確に判断できます。

確認項目 正常な状態 追加確認が必要な結果
Webの出口IP 現在のプロキシノードの出口と一致する 日本国内の固定回線またはモバイル回線のアドレスのまま
DNS組織 設定したDoHサービス、または想定した遠隔解決経路と一致する 日本国内の回線事業者、家庭用ルーターの上流、または社内ネットワークのリゾルバーが表示される
リゾルバー数 数が安定し、再テストによる変化が小さい ローカルと遠隔の2組のリゾルバーが混在する
IPv6の結果 設定したIPv6スイッチとプロキシの対応状況に一致する IPv4はプロキシ経由なのに、IPv6の接続または解決が想定経路を迂回する

リーク元がシステムプロキシ、TUN、ブラウザーDoHのどれかを切り分ける

システムプロキシが主に引き受けるのは、HTTPまたはSOCKSプロキシに対応したアプリの通信です。従来のUDP 53番ポートのDNSリクエストは通常、システムプロキシの対象外なので、システムプロキシだけを有効にしても、OSがネットワークアダプターに設定されたDNSアドレスへパケットを送ることがあります。Clashの混合ポートは一般に7890ですが、これはプロキシの受信用ポートであり、システムDNSのポートではありません。システムDNSに127.0.0.1:7890を直接指定しても、利用可能なDNSサービスにはなりません。

TUNモードはネットワーク層で通信を引き受け、dns-hijackと組み合わせることで53番ポート宛てのDNSリクエストを捕捉し、mihomo内蔵DNSモジュールへ渡せます。システムプロキシに従わないアプリ、ゲームランチャー、一部のコマンドラインツールにも、より完全な経路を適用できます。ただし、アプリが独自に確立するDoHやDoT接続は通常のHTTPSまたはTLS通信として見えるため、53番ポートのハイジャックだけで使用するリゾルバーを変更することはできません。

リクエストの発生元ごとに切り分ける

クライアントによってメニュー名は異なりますが、確認すべき点は同じです。元のYAMLを編集できるデスクトップクライアントなら、「サブスクリプション」→現在の設定の右側メニュー→「ファイルを編集する」から設定本文を開けます。保存後は「サブスクリプション」→現在の設定→「再読み込み」も実行してください。TUNは通常、「設定」→「Clash設定」→「TUNモード」にあります。サブスクリプション更新でローカルファイルが上書きされる場合は、DNSセクションを長期的に購読キャッシュへ直接書き込まず、オーバーライドまたはマージ設定機能で保存します。

enhanced-mode、nameserver、ブートストラップリゾルバーを設定する

以下ではmihomo v1.19.10の設定構造を例にします。ポイントは、default-nameserverがDoHサーバー自身のドメインを解決し、nameserverが通常のドメイン問い合わせを担当し、proxy-server-nameserverがプロキシサーバーのドメインを個別に処理でき、nameserver-policyがドメインやルールセットごとにリゾルバーを指定することです。ブートストラップリゾルバーにはIPアドレスを使い、DoHドメインの解決時に、まだ確立していない同じDoHサービスへ再び依存しないようにします。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "ntp.*.com"

  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

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

fake-ipがルール分岐に役立つ理由

enhanced-mode: fake-ipを有効にすると、mihomoはまずアプリへ198.18.0.0/16範囲の予約アドレスを返し、ドメインと偽アドレスの対応を保存します。アプリがそのアドレスへ接続すると、コアは元のドメインを復元し、DOMAIN、DOMAIN-SUFFIX、GEOSITEなどのルールで判定できます。ドメイン情報を維持しながら、アプリがシステムの解決結果を直接使って対象IPしか残らなくなる事態も減らせます。

fake-ipは実際のグローバルアドレスを恒久的に置き換える機能ではなく、コア内部のマッピング機構です。最終的な接続では、ポリシーに従って実際の宛先を解決し、接続します。ドメインルールに依存する日常的な設定に適していますが、LAN探索、プリンター、時刻同期、一部のゲームログイン、IPリテラルで検証するアプリは偽アドレスに対応できない場合があるため、フィルターリストが必要です。

redir-hostが適するケース

enhanced-mode: redir-hostはアプリへ実際の解決結果を返すため、互換性の面ではより直接的です。ただし、ドメインマッピングやルールのヒット動作はfake-ipと異なります。古いアプリがfake-ipで接続に失敗し続ける場合は、まず該当ドメインをフィルターリストへ追加してください。障害範囲が広く、ドメインを列挙できない場合に限り、一時的にredir-hostへ切り替えて比較します。enhanced-modeを切り替えた後はDNSキャッシュを消去し、新しい接続を作成してください。古い記録が判断を妨げることがあります。

TUNにDNSハイジャックと厳格ルートを追加する

dnsセクションを設定するだけでは不十分です。システムが別のDNSサーバーの53番ポートへ送るリクエストを、内蔵DNSへ取り込む必要があります。mihomoのTUN設定では、dns-hijack: any:53でこの種のリクエストを捕捉できます。auto-routeはルートを追加し、strict-routeは一部のプラットフォームで別インターフェースへ通信が迂回する可能性を抑えます。OSごとに権限が必要で、Windowsでは通常管理者権限、LinuxではTUNの作成とルート変更の権限が必要です。

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

any:53で一般的なDNSリクエストを処理し、tcp://any:53も追加すればTCP 53を使う問い合わせに対応できます。DNS応答がUDPの容量を超えた場合、サーバーが再試行を要求した場合、アプリがTCPを選択した場合に後者が使われます。この設定だけでブラウザー内蔵のDoHを止めることはできません。DoHは443番ポートを使うためです。すべてのブラウザーにClash DNSを使わせるなら、ブラウザーの「設定」→「プライバシーとセキュリティ」→「セキュアDNS」でシステムのプロバイダーを選ぶか、カスタムプロバイダーを無効にしてから再テストします。

待ち受けポートとポート競合

例ではmihomo DNSの待ち受けアドレスとして0.0.0.0:1053を使います。1053は非特権ポートなので、ローカルデバッグに便利です。TUNのハイジャックが53番ポート宛てのリクエストをこのモジュールへ送るため、通常はシステムのネットワーク設定にポート付きDNSアドレスを入力する必要はありません。別のローカルDNSプログラムが1053を使用していると、コアのログにバインド失敗が記録されます。Windowsではnetstat -ano | findstr :1053、Linuxではss -lntup | grep 1053で使用中のプロセスを確認できます。

TUNを使わず、システムから本機のDNSへ直接問い合わせる構成では、標準の53番ポートしか受け付けないシステムが一般的です。その場合はDNSサービスを127.0.0.1:53で待ち受けさせ、ポート権限と競合を確認します。この方法はOSのネットワーク設定に依存するため、ネットワーク切り替え、VPNソフト、DHCP更新で上書きされやすい点に注意してください。デスクトップ版Clash Metaクライアントでは、TUNとDNSハイジャックを組み合わせるほうが一貫性を保ちやすいでしょう。

fake-ip-filterを正確に設定し、LANと特殊プロトコルの障害を防ぐ

フィルターリストに含めたドメインはfake-ipの応答を受けず、実際のアドレスを使います。リストが短すぎると、デバイス探索、LAN管理画面、時刻同期に問題が起きることがあります。広すぎると、多数のドメインが早い段階で実IPへ解決され、ドメインマッピングを利用した処理の効果が下がります。設定は障害ログから具体的なドメインを抽出し、最も限定的なサフィックスまたは完全なドメインを優先して追加してください。大規模なトップレベルドメイン全体を除外するのは避けます。

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.asus.com"
    - "time.windows.com"
    - "time.apple.com"
    - "stun.*"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

*.lanと*.localは主に家庭内LANとローカル探索に使います。時刻サーバーへ実アドレスを返すと、直接UDP通信しか受け付けないシステムサービスで役立つ場合があります。ネットワーク接続確認用ドメインは、システムが「インターネットに接続しているか」を判断する動作に影響することがあります。追加する前にクライアントログの問い合わせドメインを確認してください。検出に使われるドメインはOSのバージョンによって完全には一致しません。

LANドメインはどのDNSへ渡すべきか

社内または家庭内のドメインをルーターでしか解決できない場合は、nameserver-policyで指定したサフィックスをLAN内DNSへ渡せます。たとえばルーターのDNSが192.168.1.1、内部ドメインがhome.arpaなら、そのサフィックスだけにポリシーを設定できます。使用前に、そのアドレスが再帰問い合わせを実際に提供していることを確認し、パブリックネットワークで元のLANアドレスを使い続けないようにしてください。

dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.corp.example":
      - 10.20.0.53

内部DNSアドレスは通常、直接接続として扱う必要があります。そうしないと、問い合わせがプロキシノードへ送られて到達できないことがあります。クライアントが設定のマージに対応しているなら、LAN専用ポリシーを特定のネットワークだけで有効になるローカルオーバーライドへ分離できます。ノートPCを社内ネットワークから家庭内ネットワークへ切り替えた後は、10.20.0.53のようなプライベートアドレスがまだ参照されていないか確認し、問い合わせが毎回タイムアウトするのを防ぎます。

キャッシュを消去して修正結果を確認する

DNS設定を変更しても、既存の接続や複数層のキャッシュはすぐには消えません。OS、ブラウザー、アプリ、mihomoコアのいずれも解決結果を保持している可能性があります。検証前に設定を再読み込みし、TUNを停止してから再度有効にし、システムのDNSキャッシュを消去してください。Windowsではipconfig /flushdns、systemd-resolvedを使うLinuxではresolvectl flush-caches、macOSではsudo dscacheutil -flushcacheを実行してからmDNSResponderを再起動します。ブラウザーはすべてのウィンドウを閉じて開き直すか、新しいプライベートウィンドウを使用します。

比較しやすい実測記録の例

Windows 11 24H2、mihomo v1.19.10、家庭用ブロードバンド、IPv4/IPv6デュアルスタック環境で、ベースラインの拡張テストは20件の問い合わせを行い、日本国内の回線事業者の再帰リゾルバー2台を表示しました。システムプロキシだけを有効にするとWebの出口はプロキシノードになりましたが、20件の問い合わせは引き続き同じ事業者のリゾルバーで処理されました。fake-ip、2組のDoH nameserver、TUN、any:53のハイジャックを有効にすると、3ラウンド連続で設定したパブリックDNSネットワークだけが表示され、日本国内の回線事業者のリゾルバーは再び現れませんでした。

この数値は前後を比較する方法を示すためのもので、すべてのネットワークで同じ件数になるわけではありません。パブリックDNSはエニーキャストを使うため、検出ページに異なるラウンドで1～4個のエッジノードが表示されることがあります。組織の帰属先と設定目標が一致し、ローカルの解決経路が混在せず、Webの出口もルールの想定どおりなら、修正は有効と判断できます。2種類のリゾルバーが同時に表示される場合は、ブラウザーDoH、IPv6ルート、またはシステムDNSを迂回するバックグラウンドアプリを引き続き確認してください。

テスト段階 Webの出口 DNS検出結果 結論
Clash終了 日本国内の家庭用回線 事業者のリゾルバー2台 ベースライン記録
システムプロキシのみ プロキシノード 事業者のリゾルバー2台のまま DNSはシステムプロキシの対象外
TUNとDNSハイジャック プロキシノード パブリックDoHネットワーク 解決経路は設定どおり

コマンドラインでのクロスチェック

ブラウザーでの検出に加えて、mihomoの1053番ポートへ直接問い合わせ、内蔵DNSが応答していることを確認できます。Windowsで指定ポートに対応したツールを用意した場合は、dig @127.0.0.1 -p 1053 example.comを使います。LinuxとmacOSでも同じコマンドを実行できます。fake-ipモードで198.18.0.0/16内のアドレスが返るのは想定された動作です。リクエストがタイムアウトした場合は、ルールグループを調整し続けるのではなく、まず待ち受けポートとコアのログを確認してください。

続いて、システムの既定の問い合わせとしてnslookup example.comを実行します。TUNのハイジャックが有効なら、コマンドに表示されるサーバー名がルーターやシステム設定のアドレスのままでも、実際の53番ポートの通信はコアが捕捉している可能性があります。最終的な判断はmihomoのログ、検出サイトの結果、前後の比較を組み合わせて行い、nslookupの先頭に表示されるサーバーだけを見て判断しないでください。

よくある異常と修正方法

設定後、すべてのドメイン解決に失敗する

検出は正常だが、一部のアプリにログインできない

まずログからアプリがアクセスしているドメインを特定し、1つずつfake-ip-filterへ追加して小さく検証します。STUN、LAN探索、NTP、接続状態の確認では、実IPを返すほうが適している場合が多いです。完全なドメインを追加して復旧したら、同じサービスのサフィックスまで広げる必要があるか検討します。最初からすべてのドメインを除外すると、どの種類のリクエストがfake-ipと互換性を持たないのか判断できません。

IPv4は正常だが、IPv6には日本国内のネットワークが表示される

プロキシノードと選択したDNSが、想定するIPv6動作に対応しているか確認します。現在のプロキシ経路がIPv6を処理しない場合は、比較のためdns.ipv6をfalseに一時設定し、検出ページでAAAA結果が表示されなくなるか確認します。同時に、TUNがIPv6のデフォルトルートをカバーしているかも確認してください。長期的にはノードの対応状況に応じて、IPv6を完全に引き受けるか、システムとDNSの両方で関連経路を一貫して無効にします。片方のスイッチだけを変更するのは避けてください。

サブスクリプション更新後に設定が元へ戻る

サブスクリプションファイルはリモートで生成され、更新時にローカルキャッシュを置き換えます。DNSとTUNの設定は、クライアントのオーバーライド、マージ設定、またはスクリプト拡張で保存してください。操作経路は通常、「サブスクリプション」→現在の設定の右側メニュー→「オーバーライド設定」です。完了後に「サブスクリプション」→「更新」を実行し、設定プレビューを再度開いてenhanced-mode、nameserver、dns-hijackが残っていることを確認します。

Clashクライアントをダウンロード Windows、macOS、Android、iOS、Linuxを確認