Clash DNS 設定詳解:nameserver・fallback・DNSハイジャック項目の書き方

Clashが独自のDNS機能を持つ理由

ClashやClash Meta(mihomo)の設定ファイルを開くと、dnsで始まる項目のまとまりが必ず存在します。これは装飾ではなく、上級者だけが触れる部分でもありません。

システムプロキシモードでは、ブラウザはドメイン名をそのままプロキシに渡し、リモートサーバー側で解決するため、端末側のDNSは無関係に思えます。しかしプロキシを経由せずOSのDNS(UDP 53)へ直接問い合わせるアプリが1つでもあれば、汚染や漏洩の問題が再び発生します。改ざんされた偽のIPアドレスを取得したり、問い合わせの履歴がローカルのネットワーク側にそのまま残ったりするのです。

TUNモードでは端末上の全通信が仮想ネットワークアダプタを通過するため、ドメイン名の解決先を先に決めておく必要があります。ClashのDNSモジュールはこれを一手に担い、53番ポートへの問い合わせを一括して受け取り、設定に従ってどのサーバーに問い合わせ、どの結果を信頼するかを決めます。

つまりdns項目の設定が正しいかどうかで、次の3点が決まります。ウェブページの表示速度、汚染されたアドレスを取得するリスクの有無、問い合わせ履歴がどこに残るか、です。

dns項目を1つずつ確認する

基本の3スイッチ:enable / listen / ipv6

enable:全体のオン/オフです。falseにすると項目全体が無効になり、Clashは解決を一切引き受けません。他の項目を書いても意味がなくなります。
listen:内蔵DNSサーバーの待ち受けアドレスで、よく使われる書き方は0.0.0.0:53です。TUNによるハイジャックの終着点であり、LAN内の機器がClashをDNSサーバーとして使う場合の入口でもあります。自分の端末でのみ使い、TUNによるハイジャックを利用する場合はデフォルトのままで問題ありません。
ipv6:falseにするとAAAAレコードの応答を破棄します。回線がIPv6に対応していない場合はオフにしておくのがおすすめで、アプリがIPv6アドレスを取得した結果、存在しない、または遅い経路に接続してしまう事態を避けられます。

enhanced-modeとfake-ip-filter

redir-host:従来型の方式で、すべてのドメイン名を実際に解決します。互換性が最も高い一方、DNSの往復が1回増えます。
fake-ip:プロキシルールに一致するドメイン名には198.18.0.x帯の仮想アドレスをその場で返し、実際の解決を省略します。接続の確立が速くなるだけでなく、アプリが自前でDNSに問い合わせる際に発生する汚染も回避できます。
fake-ip-filter:例外リストです。ここに記載したドメイン名は必ず実際のIPアドレスを取得します。代表的な例は*.lanなどのLAN用ドメイン、時刻同期サーバー、STUNサーバー、一部メーカーのログイン用ドメインなどです。fake-ipモードで動作がおかしいアプリがあれば、まずそのドメイン名をこのリストに追加してみてください。

default-nameserver:ブートストラップDNS

この項目の役割は1つだけです。設定内にドメイン名形式で書かれたDNSサーバー(例:dns.alidns.com)をIPアドレスに解決すること。また、proxy-server-nameserverを別途設定していない場合は、プロキシノードのドメイン名の解決も担います。

ここには必ず純粋なIPアドレスによるUDP DNS(例:223.5.5.5、119.29.29.29)を指定してください。DoHのアドレスを書くと「解決するにはまず解決が必要」という循環に陥り、dns項目全体が機能しなくなります。

nameserver:メインの解決先リスト

標準の名前解決サーバーで、複数台に同時問い合わせを行い、最も速い応答を採用します。書き方は4種類あります。純粋なIPアドレスならUDP 53、tls://で始まればDoT、https://で始まればDoH、systemと書けばシステムのDNSを利用します。

日本国内での利用であれば、国内の主要DoHを指定するのが基本です。例:https://public.dns.iij.jp/dns-query、https://dns.google/dns-query。遅延が低く、CDNの振り分け結果も現地環境に適したものになります。

fallbackとfallback-filter

fallbackはnameserverと同時に問い合わせを行い、「汚染の可能性がある、またはもともとプロキシ経由にすべき」ドメイン名の解決を担います。一般的には海外の信頼できるDNSを指定します。例:https://dns.cloudflare.com/dns-query、tls://8.8.4.4:853。

fallback-filterはどちらの結果を信頼するかを決める設定で、4つの子項目がそれぞれ役割を持ちます。

geoipとgeoip-code:nameserverが返したIPアドレスが指定した地域(例:JP)に属していない場合、汚染と判断してfallbackの応答を採用します。
geosite:ドメイン名がgfwなどの分類に一致した場合、fallbackの結果をそのまま採用します。
ipcidr:返されたIPアドレスが240.0.0.0/4のような予約アドレス帯に含まれる場合、汚染と判断します。
domain:リストに含まれるドメイン名は無条件でfallback側を使用します。

補足しておくと、mihomoの新しいバージョンではnameserver-policyによる振り分け方式が推奨されていますが、fallbackも引き続き利用できるため、既存の設定を急いで変更する必要はありません。

nameserver-policy:ドメイン単位での振り分け指定(応用)

ドメイン名や分類ごとに専用の解決先サーバーを指定でき、nameserverやfallbackよりも優先度が高くなります。よくある書き方として、'geosite:cn'を中国国内向けDoHに、'+.internal.example.com'を社内DNSに割り当てるといった例があります。fallback-filterより細かい単位で振り分けができるため、解決先を明確に指定したい場合に向いています。

「DNSハイジャック」が実際に指すもの

設定内でのハイジャックとは、Clashが端末から発行される53番ポートへの問い合わせを能動的に受け取り、内蔵DNSが上記のルールに従って応答することを指します。他人の通信を傍受するわけではありません。

TUNモードでtun.enableとdns-hijackを設定すると、仮想ネットワークアダプタを通過するDNS要求はすべて処理対象になります。これが最も網羅的な方式で、どのアプリも回避できません。

システムプロキシモードではDNSはハイジャックされません。ブラウザがドメイン名をリモート側のプロキシに渡して解決させる分には問題ありませんが、プロキシを経由せず直接通信するアプリはシステムのDNSを使い続けます。この抜け道を塞ぐには、TUNを有効にするか、システムのDNS設定をlistenで指定したアドレスに手動で変更する必要があります。

注意

listenは端末内またはLAN内からのみアクセス可能な状態に保ち、内蔵DNSを公開ネットワークに晒さないようにしてください。オープンな再帰DNSはスキャナーに発見され、増幅攻撃に利用される恐れがあります。

そのまま使える設定例2パターン

パターン1:家庭用標準設定

fake-ipで速度を高めつつ、国内向けドメインは主要な国内DoHで解決し、gfw分類に一致したドメインや中国国内以外のIPが返ったドメインは自動的にfallbackへ切り替える構成です。ほとんどの家庭用回線に適しており、ページの表示が速く、国内CDNへのアクセスも遠回りになりません。

dns:
  enable: true
  listen: 0.0.0.0:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.msftconnecttest.com"
    - "time.*.com"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://dns.cloudflare.com/dns-query
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw
    ipcidr:
      - 240.0.0.0/4

パターン2:漏洩防止を重視した厳格設定

respect-rules: trueを指定すると、nameserverへの問い合わせ自体もルールに従ってプロキシを経由するようになり、問い合わせ内容がローカルのプロバイダ側に残らなくなります。direct-nameserverは直接接続用ドメイン、proxy-server-nameserverはプロキシノード用ドメインの解決を担当し、役割が明確に分かれます。

dns:
  enable: true
  listen: 0.0.0.0:53
  ipv6: false
  respect-rules: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  nameserver:
    - https://dns.cloudflare.com/dns-query
    - https://dns.google/dns-query

さらにTUNを組み合わせて端末上の53番ポートをすべて処理対象にすれば、抜け道を残しません。

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

トレードオフも明確にしておきます。海外DoHへの問い合わせはプロキシ経由になるため初回の解決がやや遅くなり、プロキシが利用できない状態になると名前解決自体が全面的に失敗します。この依存関係は受け入れる必要があります。

設定変更後は3ステップで確認

ログを見る:クライアントのログにある[DNS]の行には、各ドメイン名がどのサーバーで解決され、どのルールに一致したかが記録されます。まずここで振り分けが想定どおりか確認してください。
検証ページを開く:ブラウザでDNS漏洩チェックサイトにアクセスし、表示される解決サーバーが設定したDoHの提供元やプロキシの出口であること(現地のプロバイダではないこと)を確認します。
コマンドで個別確認:nslookup example.com 127.0.0.1を実行して内蔵DNSに直接問い合わせます。fake-ipモードではプロキシ対象のドメインに対して198.18.x.xが返るのが正常な動作であり、故障ではありません。

ヒント

YAMLのインデントミスは、dns項目が反映されない原因として最も多いものです。各項目の前は半角スペース2つで統一し、変更後は設定を再読み込みするかコアを再起動してから確認してください。

よくある3つの質問

国内サイトの表示が遅い:fallbackに海外DNSを指定しているのにgeositeによる振り分けを設定しておらず、国内ドメインが海外サーバーで解決されてCDNの振り分けがずれている状態です。
特定のアプリが正常に通信できない:多くの場合実際のIPアドレスが必要なので、そのアプリのドメイン名をfake-ip-filterに追加してください。
設定が反映されていないように見える:enable: trueになっているか、インデントが正しいかを確認し、使用しているクライアントがGUI側でdns項目を上書きしていないかもチェックしてください。