dns モジュールが担うこと

Clash Meta（多くの GUI では Mihomo コアとして表示されます）は、プロキシのルール判定の前段でドメイン名をどう解くかを dns: ブロックに集約できます。ここを整えると、「ログに DNS エラーが出たから直した」という事後対応ではなく、最初から意図したリゾルバへ問い合わせる設計が可能になります。特に enhanced-mode: fake-ip を使う構成では、アプリが受け取る IP と実際の接続経路がコア側で橋渡しされるため、ルール・DNS・TUN の三つを同じ前提で語る必要があります。

用語だけ先にそろえます。nameserver は通常まず使う主系のリゾルバ列です。fallback は、主系の応答が「信頼できない」と判定されたときに試す副系です。その判定条件が fallback-filter です。一方、proxy-groups の type: fallback はノードの主備切替であり、名前は似ていても別物です。混同しやすいので、本稿では DNS 側を dns.fallback と呼び分けます。ノード側の fallback については ポリシーグループの解説 を参照してください。

ℹ 整理：DNS を触る目的は大きく二つあります。（1）意図した出口へ名前が解けるようにする。（2）偽応答や汚染を検知したら別リゾルバへ切り替える。fallback-filter は（2）のためのスイッチです。

enable と enhanced-mode

まず dns.enable: true が前提です。無効のままではコアの DNS フックが働かず、アプリは OS のリゾルバやブラウザの DoH に任せた挙動に戻ります。enhanced-mode には代表的に fake-ip と redir-host（または実装・版により同等の別名）があり、本稿の主眼は利用者の多い fake-ip です。fake-ip では、多くの名前に対して fake-ip-range 内の仮想アドレスが返り、実際の宛先 IP はコアが後段で確定します。これにより「アプリがシステム DNS を勝手に使う」系の取りこぼしを抑えやすい反面、ローカル名や社内サフィックスまで仮想 IP に載せると LAN 到達が壊れます。その対策が fake-ip-filter です。ローカル周りの具体例は Fake-IP と LAN バイパスの記事 とも線でつながります。

モード ざっくりした挙動
fake-ip 多くのドメインに仮想 IP を返し、ルールと接続処理側で実 IP を扱う。アプリの DNS 取りこぼし対策に強い。
redir-host 系 実 IP を返す方向に寄せる。挙動は素直だが、環境によってはアプリがコア外 DNS を使いやすい。

nameserver：主系リゾルバの書き方

nameserver には、素の UDP/TCP の IP 指定、tls://、https://（DoH）など、コアの版が解釈できるスキームを列挙します。複数ある場合は並列問い合わせやフェイルオーバーの優先度が実装依存になるため、公式ドキュメントと GUI の説明をあわせて確認してください。運用上のコツは、応答が速いが汚染されやすい DNS を単独で主系にしないことです。国内キャリア DNS を主系にしつつ、海外 DoH を fallback に置く、あるいはその逆で fallback-filter を厚くする、といったバランスがよく取られます。

DoH／DoT を主系にする場合、リゾルバのホスト名自体を解く必要が出ます。そのための入り口が次節の default-nameserver です。ここを空のまま DoH だけ並べると、「プロキシのドメインが解けない」「ブートストラップでループする」といった二次障害に見えます。症状の読み方は 接続ログの記事 も参考にしてください。

dns: nameserver sketch 
dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - tls://dns.quad9.net:853
    - https://dns.google/dns-query

default-nameserver とブートストラップ

default-nameserver は、他の DNS サーバーのホスト名を解くためだけに使われることが多いです。例えば https://dns.google/dns-query の dns.google を、まず誰に聞くかを決めるプールです。ここに到達しやすい素の UDP リゾルバ（例：ISP 系やパブリック DNS）を置くのが定石です。社内ネットでは、社内が許可するリゾルバだけに絞る必要があります。プロキシのエンドポイント名も同様に、起動直後に解ける必要があるため、proxies のホストが DoH 名だけに依存していると、default-nameserver と proxy-server-nameserver（プロキシ経由で名前を解く指定）の整理が重要になります。

dns: default-nameserver (example) 
dns:
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

fallback と fallback-filter

dns.fallback は、主系 nameserver の応答がフィルタ条件に引っかかったときに試される副系リゾルバ列です。典型的には、特定国の GeoIP に落ちる IP、予約帯やダミー帯の IP、などを「疑わしい」とみなして副系へフォールバックします。条件は fallback-filter にまとめられ、geoip と geoip-code、ipcidr、domain、geosite など、コアの版が解釈するキーを組み合わせます。

よくある誤解は、「fallback に書いた順に常に上から試すのか」という点です。実際には主系の結果がフィルタを通ったかどうかがゲートになり、通らなかった場合に副系が使われます。したがって fallback-filter が広すぎると副系ばかりが動き、狭すぎると汚染を拾い損ねます。運用では、まず 意図しない地理ゾーンの IP が返っていないか、ログとテストドメインで確認すると調整が速いです。

dns: fallback + fallback-filter (example) 
dns:
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
      - "+.facebook.com"
      - "+.youtube.com"
⚠ 注意：上記は教育用の骨格です。geosite: や geoip: の利用可否、キー名の揺れは利用中のコア版と GUI が生成するスキーマに合わせてください。取り込み後は必ず実ネットワークで疎通確認を行ってください。

fake-ip-filter とローカル名

fake-ip-filter に載ったドメイン（やルール）は、fake-ip を返さず通常の名前解決結果を使う方向に寄ります。ここに +.lan、+.local、ルータメーカーの管理 FQDN、社内イントラのサフィックス、stun.* や特定の STUN／ルックアップ系など、環境で観測したホストを足していくのが実務的です。geosite:private のような集合をサポートする版なら、プライベート系をまとめて列挙する負担を減らせます。

fake-ip を使うほど、ルールが DOMAIN ベースで効くかが DNS 側の振る舞いと強く結びつきます。フィルタ漏れでローカル名が仮想 IP になったままだと、LAN や NAS だけが静かに壊れるパターンになります。必要に応じて Sniffer や rules 側のプライベート帯 DIRECT を併用してください（前述の LAN 記事参照）。

dns: fake-ip-filter (example) 
dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.msftconnecttest.com"
    - "router.asus.com"

nameserver-policy でドメイン別に振り分ける

特定ドメインだけ別リゾルバへ送りたいときに使うのが nameserver-policy です。例えば、一部の CDN やメールホストだけ社内 Split DNS に聞かせる、特定サフィックスだけ信頼できる DoH に固定する、といった用途です。キーにはワイルドカード付きのサフィックスや geosite: 名が使える場合があり、GUI によっては別名のマップ UI になっています。nameserver-policy と fake-ip-filter はどちらも「この名前は特別扱い」ですが、前者はどのリゾルバへ聞くか、後者はfake-ip を使うかという軸が異なるので、設定をいじるときは軸を取り違えないようにします。

dns: nameserver-policy (example) 
dns:
  nameserver:
    - 223.5.5.5
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
    "+.corp.example":
      - system

TUN・システム DNS との関係と漏洩

「DNS 漏洩」という言葉は文脈によって意味が広いですが、ここでは次の二層に分けて考えると切り分けが楽です。（1）アプリケーションがコア外のリゾルバへ直接問い合わせる。（2）トンネル外の経路で DNS パケットが観測される。（1）はブラウザの DoH、別 VPN の DNS、モバイルの Private DNS などが典型です。（2）は TUN のルートや除外インターフェース、split tunnel の設定ミスで起きやすいです。TUN の観点は TUN モードの深掘り とセットで読むと、ルーティング層と DNS 層の境界が掴みやすくなります。

Clash 側の dns が完璧でも、アプリが 8.8.8.8 や別 DoH に直行すれば、その問い合わせはポリシーと無関係に流れることがあります。対策は「アプリ設定で DoH を切る」「システムの DNS をコアの listen に向ける」「TUN でキャプチャ範囲を確認する」など環境依存の組み合わせになります。社内ポリシーと法令を踏まえ、許された方法だけを選んでください。

また、dns.listen をローカルポートに開く構成では、他プロセスとポートが衝突しないか、ファイアウォールで意図しない端末から叩かれないかも確認ポイントです。概念の整理には よくある質問の DNS の項 も併読するとよいでしょう。

統合例：よくある構成のひとつ

以下は、主系に国内パブリック DNS、副系に DoT／DoH、fallback-filter で疑わしい応答を弾き、fake-ip-filter でローカル名を守る、という流れを一続きの骨格として示したものです。実際の購読ルールや proxies は省略しています。コアを新しめの版に揃えたい場合は アップグレード手順 も参照してください。ソースや変更履歴を追う用途では GitHub も有用ですが、クライアントの入手はサイトの導線を主にすると、配布物と説明の対応が取りやすいです。

dns: integrated skeleton (merge carefully) 
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:
    - "*.lan"
    - "*.local"
    - "+.msftconnecttest.com"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5
    - tls://dns.quad9.net:853
  fallback:
    - tls://1.1.1.1:853
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  nameserver-policy:
    "+.corp.example":
      - system

よくある落とし穴チェックリスト

  1. dns.enable が false のまま、OS だけいじって挙動が変わらないと嘆いていないか。
  2. DoH／DoT だけ並べて default-nameserver が空で、ブートストラップが不安定になっていないか。
  3. dns.fallback と proxy-groups.fallback を取り違えていないか。
  4. fallback-filter が広すぎて副系ばかり動いていないか、逆に狭すぎて汚染を拾えていないか。
  5. fake-ip-filter 漏れで LAN 名が仮想 IP になっていないか。
  6. TUN とブラウザ DoH が二重に効いて、見かけ上だけ「漏洩している」ように見えていないか。
  7. プロキシのホスト名解決が proxy-server-nameserver やルールと矛盾していないか。

まとめ

Clash Meta／Mihomo の dns は、nameserver で主系を定義し、fallback と fallback-filter で「疑わしい応答」を副系へ逃がし、fake-ip-filter と nameserver-policy でローカル名や社内名を例外扱いする——という役割分担で読むと迷子になりにくいです。TUN やアプリ独自 DoH は、コアの DNS 設定と別レイヤーで漏洩経路になり得るため、「YAML は正しいのにテストサイトでは漏れる」といった現象は、層を分けてログとパケットで確認するのが近道です。

同じ考え方でも GUI のラベルは製品ごとに違いますが、dns ブロックを正面から編集できるクライアントを選ぶと試行錯誤のコストが下がります。一般的な単一トンネル型 VPN に比べ、ルールと DNS を同じプロファイルに持てる点が Clash 系の強みです。

→ 手元で nameserver と fallback を安全に試したい方は、Clash を無料ダウンロードし、DNS と接続ログを同じ操作導線から扱えるクライアントから検証を始めてみてください。