DNS 漏洩とは何か

インターネットに接続するとき、ブラウザやアプリはまずドメイン名を IP アドレスへ変換する必要があります。この名前解決の流れが、意図せず契約 ISP や社内 DNS のような「プロキシの外側」のサーバーに届く状態を、広く DNS 漏洩 と呼びます。HTTP や TLS のペイロードはプロキシ経由でも、クエリだけが別経路に出ると、どのホスト名を解決しようとしたかが観測されやすくなります。

Clash 系クライアント（Mihomo／Clash Meta コアを同梱する GUI を含む）は、内蔵 DNS とルールエンジンを組み合わせてこの経路を制御できます。ただし tun.enable の有無、OS の「システム DNS」設定、ブラウザのセキュア DNS 機能などと競合すると、見かけ上はプロキシオンなのに解決だけ別ルート、という状態が起こり得ます。ここからは、よくある落とし穴と、設定でどう塞ぐかを順に整理します。

関連する速度調整の話題は Clash を高速化するテクニック でも触れています。プライバシーとレイテンシはトレードオフになりやすいので、用途に合わせて読み替えてください。

漏洩しやすい典型パターン

実務で多いのは次のようなパターンです。どれにも当てはまるかを頭の中でチェックすると、原因切り分けが速くなります。

  • システムスタック優先：アプリが OS の解決 API を直接使い、Clash の仮想 DNS を素通りする。
  • ブラウザの独自 DNS：Chrome などの「セキュア DNS」が有効で、プロキシと別の DoH エンドポイントへ向く。
  • IPv6 の取りこぼし：IPv4 だけトンネルし、AAAA クエリがローカル DNS に流れる。
  • TUN 未使用のままルールのみ：一部アプリがプロキシ設定を無視し、直接名前解決する。
  • 誤った fallback：フォールバック条件が緩く、常に ISP 側リゾルバが選ばれてしまう。

これらは「悪意」ではなく、OS とアプリの既定動作の組み合わせで起きることがほとんどです。だからこそ、意図した DNS パスを YAML とモードで明示することが重要になります。

enhanced-mode：redir-host と fake-ip

Mihomo では dns.enhanced-mode に redir-host か fake-ip を指定して、ルール評価前の名前解決の扱いを変えられます。

redir-host

実在の IP を返しつつ、トラフィックの振り分けと整合しやすいモードです。一部の古いアプリや、ローカル名前解決に依存するサービスとの相性が比較的よい反面、解決結果がそのまま観測ポイントに触れる設計になりやすいので、上流を暗号化 DNS に寄せることが前提になります。

fake-ip

プライベートレンジの「仮アドレス」を返し、実際の接続時にコア側で再解決する流れになります。ルールと相性がよく、体感速度の面でも好まれることが多いモードですが、fake-ip-filter に載せるドメインを誤ると、意図しない挙動や特定アプリでの不具合の原因になります。LAN、キャプティブポータル、一部のゲームクライアント向けドメインなどはフィルタに入れる例がよく挙げられます。

ヒント：どちらが「絶対に正しい」わけではありません。自宅回線、利用アプリ、購読ルールの前提に合わせて選び、検証サイトと実アプリの両方で確認するのが確実です。

nameserver・fallback・分割の考え方

DNS 設定の骨格は、普段使う上流と、疑わしいときにだけ使う上流を分けることです。nameserver は第一候補、fallback はポリシーに応じて使われるバックアップ、という位置づけです。fallback-filter で GeoIP やドメインサフィックスを条件にすると、「国内向けは速いリゾルバ、それ以外は信頼できる遠方の DoH」といった切り替えが組みやすくなります。

日本のユーザーであっても、利用する購読ルールや参照する geosite カテゴリは多様です。下の例はあくまで構造のサンプルであり、実際の URI は自環境のポリシーと遅延測定に合わせて差し替えてください。

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*"
  nameserver:
    - https://dns.google/dns-query
    - tls://dns.quad9.net:853
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: JP
    geosite:
      - gfw

geoip-code や geosite のリストは、手元の geoip.dat／geosite.dat の世代と整合している必要があります。データが古いと、意図しないフォールバックや逆に漏洩が続く原因になります。コアや GUI を更新するときは、ルールセットとあわせてデータファイルも見直す習慣をつけると安心です。

より細かくドメインごとに上流を変えたい場合は nameserver-policy やドメイン条件付きの指定を検討します。設定の全体像は ドキュメント の DNS 章と併せて読むと理解が早いです。

DoH と DoT を選ぶときの実務ポイント

DNS-over-HTTPS（DoH）と DNS-over-TLS（DoT）は、クエリを暗号化して中間者から読まれにくくします。URI 形式（https://）とホスト＋ポート形式（tls://）の書き方の違いに注意してください。また、企業プロキシやセキュリティ製品が中間者 TLS を行う環境では、ルート証明書の都合で DoH が失敗し、結果として別の経路にフォールバックすることがあります。その場合はエラーログと遅延テストを見ながら、許可されたリゾルバに寄せるか、管理者ポリシーに沿った構成に切り替える必要があります。

利用するプロバイダを選ぶときは、プライバシーポリシー（ログの有無、保持期間、準拠法）もあわせて確認してください。技術的な「漏洩防止」と、契約上の取り扱いは別次元の話です。

TUN モードと dns-hijack

アプリがプロキシを無視しやすい環境では、TUN デバイスでトラフィックをコアに引き込み、DNS クエリを明示的にハイジャックする構成が有効です。Windows では管理者権限、macOS ではシステム拡張やプロファイルの許可など、プラットフォームごとの前提があります。

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

stack を gvisor にすると環境によっては安定性が変わります。接続はできるが名前解決だけ怪しい、というときは TUN の有効／無効と dns-hijack の行き先をログで追うと切り分けがしやすくなります。

注意：TUN は他の VPN クライアントや仮想化ソフトとルートが競合することがあります。併用する場合は、どちらがデフォルトゲートウェイと DNS を握るかを整理してから有効にしてください。

検証のしかた（テストサイトの見方）

設定を変えたあとは、必ず第三者の DNS 漏洩チェッカーで確認してください。表示されるリゾルバの国・ASN が契約 ISP と一致してしまう場合は、まだクエリが外に抜けている可能性が高いです。複数ブラウザ・シークレットウィンドウ・モバイルテザリングなど、普段使う条件を変えて試すと見落としが減ります。

ブラウザの拡張機能や「DNS over HTTPS」設定がオンになっていると、OS 側の Clash 設定と二重にリゾルバが存在します。テスト時は一時的にオフにして挙動を比較するのも有効です。WebRTC 由来の IP 露出は DNS とは別問題ですが、プライバシー検証では同時にチェックリストに入れておくと安心です。

よくあるつまずき

特定ドメインだけ開かない

fake-ip-filter の過不足、または nameserver-policy の優先順位が原因のことがあります。ログで該当クエリがどの上流に送られたかを追い、ルールと DNS の両方から見直してください。

遅延だけが悪化した

遠方の DoH を第一候補にすると RTT が伸びます。nameserver を地理的に近い信頼できるエンドポイントにし、fallback を遠方に置く、といった階層設計が現実的です。

更新後に挙動が変わった

コアのメジャーアップデートで DNS まわりのデフォルトや検証ロジックが変わることがあります。リリースノートを読み、既存 YAML の非推奨フィールドがないか確認してください。

まとめ：設定を終えたらクライアント側も最新に

DNS 漏洩対策は、YAML の数行だけで完結する話ではありません。OS、ブラウザ、TUN、IPv6、購読ルールという複数層の挙動が重なった結果として現れます。そのため、設計 → 実装 → 計測 → 微調整 のループを回せる GUI とコアの組み合わせを揃えておくのが近道です。

コアのソースやライセンスを確認したい場合は GitHub 上の公式リポジトリが参照先になりますが、日々のインストールと更新の導線は、検証済みパッケージがまとまっている公式の入手ページに寄せると手戻りが少なくなります。ルールや DNS の話題は 技術ブログの一覧 にも関連記事があります。→ Clash を無料ダウンロードして、意図した DNS パスでプライバシーを守る構成を試す