DNS リーク防止と検出

DNS の基礎知識

DNS リークを理解するために、まず DNS の仕組みを簡単に振り返りましょう。DNS（Domain Name System、ドメインネームシステム）はインターネットの「電話帳」です。ブラウザで www.google.com と入力して Enter キーを押すとき、あなたのデバイスはそのドメイン名に対応するサーバーの IP アドレスを直接知りません。そのため、まず DNS サーバーに「www.google.com の IP アドレスは何ですか？」と問い合わせます。DNS サーバーが IP アドレスを返してから、デバイスは実際の接続を開始します。

この DNS クエリは、従来の設定では ISP（インターネットプロバイダー）が指定する DNS サーバーに平文で送信されます。つまり、ISP（そしてあなたのネットワークトラフィックを傍受できる第三者）は、あなたがどのドメイン名を検索したかを完全に記録できます。最終的にプロキシ経由でそれらのサイトにアクセスしても、DNS クエリ自体がアクセスの意図を漏洩しています。

DNS over HTTPS（DoH）と DNS over TLS（DoT）は DNS クエリを暗号化する 2 つの標準的な方法で、転送中に ISP が DNS リクエストを傍受するのを防ぎます。しかし、暗号化 DNS だけでは不十分です。プロキシ環境では、DNS リクエストがプロキシトンネルを経由して送信されることを確認する必要があります。プロキシをバイパスして海外の DNS サーバーに直接送信されないようにすることが重要です。

DNS リークとは

DNS リーク（DNS Leak）とは、プロキシを有効にしてウェブサイトのコンテンツはプロキシトンネル経由で転送されているにもかかわらず、DNS クエリがプロキシを経由せず、ローカル ISP の DNS サーバーやプロキシを経由しない DNS サーバー（例：8.8.8.8）に直接送信されてしまう状態を指します。これにより、ドメイン名のクエリ履歴がプロキシの保護外に露出します。

Clash の従来の動作モード（Redir-Host モード）では、DNS リークは構造的な問題です：

www.google.com にアクセスする際、OS がまずローカル DNS サーバーに実際の IP を問い合わせ、IP を取得した後に Clash がその IP を基に直接接続かプロキシかを判断します。問題は、この DNS クエリが Clash が接続を処理する前に発生し、システムのデフォルト DNS サーバー（通常は ISP のサーバー）を使用するため、クエリ全体がプロキシを完全にバイパスしてしまう点です。最終的にプロキシ経由で Google にアクセスしても、Google にアクセスしたという事実は ISP の DNS サーバーに記録されています。

より深刻な状況は「グローバルプロキシ」設定で発生します。一部のユーザーは海外の DNS（例：8.8.8.8）を設定しながらプロキシ経由でアクセスしていません。この DNS リクエストは平文で送信されるため、公共 Wi-Fi や信頼できないネットワークでは盗聴のリスクがあり、DNS プロバイダー側にも記録が残り、余分な遅延も発生します。デメリットばかりでメリットはありません。

リークの危険性

プライバシーの露出：DNS リークの最も直接的な被害はプライバシーの漏洩です。接続内容が暗号化されていても、DNS クエリ自体がどのウェブサイトにアクセスしたかを第三者に知らせてしまいます。ISP、政府機関、カフェの Wi-Fi 管理者がこれらの情報を記録できます。

精度の低下：DNS クエリがプロキシを経由しない場合、DNS サーバーは実際の接続元（日本）の IP に基づく結果を返します。プロキシ出口の地域向けに最適化された結果ではありません。これにより、ウェブサイトにアクセスする際に地理的に不適切なサーバーに接続され、速度が遅くなる可能性があります。

DNS ハイジャックのリスク：ホテルや空港、カフェなどの公共 Wi-Fi をはじめとする信頼できないネットワークでは、経路上の機器が DNS クエリを改ざんし、偽の IP を返す「DNS ハイジャック」が発生することがあります。悪意のあるサイトへ誘導されたり通信内容を盗聴されたりするリスクがあります。DNS リクエストがプロキシを経由しない場合、プロキシノードが完全に利用可能でも、こうした攻撃に対して無防備な状態になります。

Fake-IP によるリーク防止の仕組み

Clash の Fake-IP モードは DNS リーク問題を根本的に解決する最良の方法であり、Mihomo カーネルで推奨設定として広く使用されています。

Fake-IP の動作方式は従来の DNS モードとは全く異なります。アプリが DNS クエリを発行すると、Clash の内蔵 DNS サーバーは即座に「偽の」内部 IP アドレス（予約アドレス範囲、例：198.18.0.0/15）を返し、外部サーバーへの実際の DNS リクエストは送信しません。アプリはこの偽の IP を使って TCP/UDP 接続を確立し、Clash は接続レベルでこの接続をインターセプトして偽の IP から元のドメイン名を逆引きし、ルールに基づいて次の処理を決定します：

ルールがそのドメイン名にプロキシが必要と判断した場合、Clash は「ドメイン名 + ポート」をプロキシトンネル経由でプロキシサーバーに直接送信し、プロキシサーバー側で実際の DNS 解決を行います。これにより DNS クエリはプロキシサーバー側で処理され、ローカルの ISP や経路上の第三者に記録されることはありません。

ルールがそのドメイン名を直接接続（ローカル向けドメイン）と判断した場合、Clash はそのドメイン名の実際の DNS 解決を行い、設定ファイルに指定されたローカル向けの DNS サーバー（例：1.1.1.1）を使用してクエリします。結果は正確で速度も速いです。

全プロセスを通じて、DNS クエリがシステムのデフォルト DNS サーバーに漏洩することはなく、暗号化されていない海外への DNS リクエストも発生しません。これが Fake-IP の根本的な優位性です。

Mihomo DNS 設定方法

以下はほとんどのシナリオに適した Mihomo DNS 設定です。Fake-IP を有効にし、ローカルと海外向けのトラフィックの振り分けを適切に処理します：

dns:
  enable: true
  listen: 0.0.0.0:53        # ローカルの 53 番ポートでリッスン
  enhanced-mode: fake-ip    # Fake-IP モードを有効化
  fake-ip-range: 198.18.0.1/16

  # Fake-IP フィルターリスト：これらのドメインは Fake-IP を使用せず、実際に解決する
  # NTP、Apple プッシュ通知などのシステムサービスへの影響を防ぐ
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.localhost"
    - "time.*.com"
    - "time.*.gov"
    - "ntp.*.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

  # ローカル向けドメインの解決に使用する nameserver
  # DoH/DoT 暗号化クエリを優先使用
  nameserver:
    - https://1.1.1.1/dns-query          # Cloudflare DoH
    - https://8.8.8.8/dns-query          # Google DoH
    - 1.1.1.1                            # Cloudflare DNS（バックアップ）
    - 8.8.8.8                            # Google DNS（バックアップ）

  # プロキシノードのドメイン解決に使用（プロキシサーバー自身のドメインは直接解決が必要）
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
    - 1.1.1.1

この設定のポイントは、Fake-IP フィルターリストが一般的なシステムサービスドメインの実際の解決を保持し、NTP 時刻同期や mDNS などのローカルサービスが Fake-IP の影響を受けないようにしている点です。ローカル向けの nameserver には DoH 暗号化クエリを使用し、ISP や経路上の第三者による DNS レスポンスの改ざんを防いでいます。プロキシノードのドメインには信頼できる高速な DNS を専用で使用し、プロキシサーバーのアドレスが DNS ハイジャックの影響を受けないようにしています。

リークの確認方法

設定完了後、以下の手順で DNS リークが解消されているか確認してください：

方法 1：オンライン検出ツールを使用する。dnsleaktest.com または ipleak.net にアクセスし、「Extended test（拡張テスト）」をクリックします。テスト完了後、ページにはどのサーバーが DNS クエリを処理したかが表示されます。リストにプロキシノードの地域（例：アメリカ、香港）の DNS サーバーのみが表示されていればリークはありません。日本の ISP（NTT、KDDI（au）、ソフトバンクなど）の DNS サーバーが表示された場合はリークが発生しており、設定を確認する必要があります。

方法 2：コマンドラインで確認する。ターミナルで以下のコマンドを実行し、どのサーバーがクエリに応答しているか確認します：

# 海外ドメインをクエリして SERVER フィールドを確認
nslookup google.com

# または dig を使用（より詳細な結果）
dig google.com

SERVER に 127.0.0.1#53（Clash のローカル DNS）が表示されていれば、システム DNS が Clash を指しており、Fake-IP が正常に動作しています。192.168.x.x（ルーターの DNS）や ISP の IP が表示されている場合は、システム DNS が正しく Clash を指していません。TUN モードが有効かどうか、または DNS リスニングが正常かどうかを確認してください。

よくある誤解

誤解 1：「8.8.8.8 に変えればリークを防げる」。システム DNS を Google の 8.8.8.8 や Cloudflare の 1.1.1.1 に設定しても DNS リークは防げません。むしろ悪化する可能性があります。これらの海外 DNS サーバーへのクエリリクエスト自体が平文で送信されるため、公共 Wi-Fi など信頼できないネットワークでは盗聴されるリスクがあり、遅延も高くなります。リーク防止の鍵は、特定の DNS サーバーを選ぶことではなく、DNS クエリが Clash を経由して処理されるようにすることです。

誤解 2：「プロキシを有効にすれば DNS も自動的にプロキシ経由になる」。従来のシステムプロキシモードでは、DNS クエリはプロキシとは完全に独立しており、自動的にプロキシを経由しません。Clash が DNS リスニング（enable: true）を有効にし、システムの DNS が Clash を指している場合（TUN モードで自動的に設定されるか、システム DNS を手動で 127.0.0.1 に変更する）のみ、DNS が Clash によって一元管理されます。

誤解 3：「Fake-IP モードにするとすべてのサイトがプロキシ経由になる」。Fake-IP は DNS 解決方法の変更にすぎず、トラフィック分岐の判断は引き続きルールセットが行います。GEOIP,JP,DIRECT ルールが設定されていれば、Fake-IP を使用していてもローカル向けトラフィックは直接接続され、ローカルサイトの速度に影響しません。

まとめ：Clash Plus を使用し、TUN モードを有効にして、Fake-IP DNS を設定することが、現時点で最も完全な DNS リーク防護ソリューションです。三つの機能が連携して動作することで、プロキシが真に「シームレス・安全・リークなし」を実現します。