DNS漏えい防止：MetaのDoHとFakeIP実践設定

1 DNS 漏洩が起きるしくみ

多くのユーザーは「ブラウザのプロキシをオンにしたから安全」と考えがちですが、実際にはアプリケーションが独自のリゾルバを使ったり、OS が DHCP で受け取った DNS を優先したりするため、TCP セッションはトンネル内でも名前解決だけがプロバイダー向けの 53/UDP に流れる、というパターンが珍しくありません。結果として「どのドメインを見に行こうとしたか」というメタデータが、暗号化された HTTPS ペイロードより先に露出します。

対策の第一歩は、クライアント側で「すべての名前解決を意図した経路に集約する」ことです。Clash 系クライアントの中でも、Mihomo／Clash Meta コアは dns セクションとルールエンジンを同一プロセスで扱えるため、プロキシ判定と解決ポリシーを一貫して記述しやすいのが強みです。以降ではその Meta カーネル上で、DoH（DNS over HTTPS）による暗号化と fake-ip モードによる早期ルーティングをどう両立させるかに焦点を当てます。

2 脅威モデルと目標

ここでいう「漏洩」とは、利用者が意図しない第三者（多くはアクセス回線事業者や社内ゲートウェイ）に、問い合わせドメインや解決結果が観測可能になる状態を指します。完全な匿名性や法的手続きへの耐性まで求める場合は、Tor や厳格な端末ハードニングなど別レイヤの設計が必要ですが、一般的なプロキシ利用では、少なくとも「平文 DNS を回線事業者に垂れ流さない」「ルールと一致する解決経路を選ぶ」ことが現実的なゴールになります。

Meta カーネルでは、nameserver に HTTPS エンドポイントを列挙することで DoH を選択でき、fallback と fallback-filter を併用すると、特定地域向けの「汚染された応答」を検知したうえで信頼できる上流へ切り替える、といった運用が宣言的に書けます。あわせて FakeIP は、アプリケーションが接続を開始する前にダミー IP を返すことで、コア側が最終的な実 IP をプロキシ経路に合わせて選べるようにする仕組みです。

3 DoH と FakeIP の役割分担

DoH は「クライアントからリゾルバまでの区間を TLS で包む」技術であり、Wi‑Fi や ISP の途中経路に平文のクエリが載らないようにするのに有効です。一方で、DoH の出口（パブリックリゾルバ運用者）には依然としてクエリ内容が見えるため、プライバシー要求が高い場合は自前リゾルバや VPN 内 DNS など別の選択肢と比較検討してください。

FakeIP（enhanced-mode: fake-ip）は、ドメインごとにプールされた仮想アドレスを返し、実際の接続フェーズでコアが本物の A/AAAA を取得してアウトバウンドへ載せ替えます。これにより「アプリが勝手にシステムリゾルバへフォールバックしてしまう」ケースを減らしやすく、ルールベースのプロキシと相性が良いです。ただし、P2P や STUN、一部の証明書ピンニング実装では想定外の挙動になり得るため、fake-ip-filter で除外リストを保守する必要があります。

default-nameserver の意味： nameserver 自体が HTTPS 形式のとき、ブートストラップ用にプレーンな再帰（UDP/TCP）を default-nameserver に置くパターンが一般的です。社内ポリシーや地域事情に合わせて、信頼できるローカルまたはキャリア中立の値に差し替えてください。

4 推奨 YAML テンプレート

以下は本番に近い形の出発点です。listen を 1053 にしているのは、Linux で systemd-resolved が 53 を占有している場合に衝突しにくいためです。デスクトップ GUI クライアントでは「システムプロキシと DNS をコアに向ける」設定を併用してください。サーバーで headless 運用する場合は、Linux Mihomo ＋ systemd の記事で述べたディレクトリ構成と組み合わせると再現性が高まります。

nameserver の URL は利用規約とレイテンシを踏まえて選びます。中国本土向けドメインだけ国内 DoH に振り分けたい場合は nameserver-policy やルール連動の DNS 設定を追加するのが定番ですが、本テンプレートではまず「暗号化されたグローバル上流＋フォールバック判定」に絞っています。

YAML (dns ブロック抜粋)

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.*'
    - '+.msftconnecttest.com'
    - '+.msftncsi.com'
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.google/dns-query
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - tls://dns.google:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 0.0.0.0/32
    domain:
      - '+.google.com'
      - '+.facebook.com'
      - '+.youtube.com'

アウトバウンド経由でしか届かないリゾルバを使いたい場合は、https://example.com/dns-query#Proxy のようにグループ名サフィックスを付け、実際に存在する proxy-groups 名と一致させます。社内イントラやイントラネット専用ゾーンは nameserver-policy や fake-ip-filter で明示的に直結／除外しないと、意図せず海外 DoH に流れる点に注意してください。

5 TUN／システム DNS との連携

mixed ポートだけを使う構成では、OS の「DNS サーバー」設定が依然としてルーターから配られた値のままだと、一部アプリがそちらを直接叩きます。TUN モードを有効にして透過的にトラフィックを捕捉するか、OS のネットワーク設定で DNS を 127.0.0.1（コアの listen ポートに合わせて調整）へ固定するのが確実です。Windows や macOS では GUI クライアントの「システムプロキシ」「TUN」スイッチがこれを代行することが多いです。

TUN の概念とアプリ横断のルーティングについては、Clash Verge Rev の TUN モード解説が参考になります。DNS と TUN は独立したトピックに見えますが、実務上は「どのプロセスがどのインターフェースからクエリを出すか」まで含めて一つの設計にまとめる必要があります。

IPv6 について： サンプルでは ipv6: false としていますが、環境によっては IPv6 が優先され、意図せず迂回経路が変わることがあります。IPv6 を完全に扱うなら、ルーター側の設定と ipv6: true、および AAAA のフォールバック挙動までセットで検証してください。

6 検証とモニタリング

設定後は、ブラウザだけでなく別ブラウザプロファイルやネイティブアプリでも DNS テストサイトを開き、表示されるリゾルバが期待どおりか確認します。コアのログレベルを一時的に上げ、dns 関連の問い合わせがローカルリスナを経由しているかを追うのも有効です。継続運用では、購読ルールや fallback-filter の条件が変わるたびに再チェックを挟むと、静かな設定ドリフトによる漏洩を防げます。

また、Split DNS を使う企業 VPN と併用する場合は、社内サフィックスだけをローカルリゾルバへ、それ以外を Meta コアへ、とポリシーを分割しないと、機密ドメインが誤ってパブリック DoH に送られるリスクがあります。インフラチームのドキュメントと齟齬がないかを事前にすり合わせてください。

7 よくある落とし穴

ルーター DHCP の DNS が上書きする： 端末側で固定しても、再接続で元に戻ることがあります。可能ならルーター管理画面で DNS をローカルホストに向けるか、静的に割り当てます。
ブラウザ独自の Secure DNS： Chrome の「使用する DNS」の設定が OS より優先され、意図しないリゾルバに行く場合があります。検証時は一時的に無効化して挙動を切り分けます。
FakeIP と証明書エラー： フィルタ漏れで仮想 IP のまま接続しようとすると TLS エラーになることがあります。fake-ip-filter に該当ドメインやサフィックスを追加します。
過度に狭い上流： 単一の DoH に依存すると、その事業者の障害で名前解決全体が止まります。地理的・論理的に独立した複数上流を並べておくのが無難です。

8 まとめ

Meta カーネルの DNS スタックは、暗号化された上流、FakeIP、フォールバック判定を一つの YAML にまとめられるため、「プロキシは通っているのに名前だけ素通し」という状態をかなり減らせます。鍵は、OS・ブラウザ・ルーターの三層すべてでクエリの出口を意識し、例外ドメインを fake-ip-filter とポリシーで保守し続けることです。

手書き YAML の運用が負担になったときは、検証済みのビルドと GUI を備えたクライアントに寄せると、購読更新や TUN の切り替えを日常作業に組み込みやすくなります。単体ツールをいくつも足すより、ルールと DNS を同じコアで扱える環境の方が、長期的には設定のブレが少なく済みがちです。

→ 無料で Clash をダウンロードし、DNS まで含めた体験の違いを確かめる

DNS 漏洩を実務レベルで防ぐ：
Meta カーネル（Mihomo）の DoH と FakeIP ベストプラクティス