Clash DNS 設定完全ガイド:nameserver・fallback・ドメインハイジャック対策

ドメイン解決は Clash のルール振り分けの前提工程だ。ドメイン一致のルールも IP 帰属判定のルールも、いずれもクリーンで制御可能な解決結果に依存している。本稿は設定項目を軸に Clash 内蔵 DNS の動作原理を分解し、nameserver と fallback の役割分担、クエリ1回の全経路、そして DNS リーク・53番ポートハイジャック・応答汚染という3種の典型的な不具合の見つけ方と対処法を解説する。

53 番がデフォルトの待ち受けポート·fake-ip 拡張モード·198.18.0.0/16 仮想アドレス帯·DoH / DoT 暗号化アップストリーム

なぜ DNS が振り分けの基盤なのか

Clash のルールの大半はドメインを一致対象にしている。DOMAIN、DOMAIN-SUFFIX、GEOSITE はドメインを直接見るが、GEOIP や IP-CIDR のようなルールはドメインを IP に解決してから判定する必要がある。つまり、1本の接続を直結にするか代理経由にするかの答えの半分は、DNS の応答に隠れている。

解決処理をシステム標準の DNS に任せてしまい、そのルートが通信事業者にハイジャックされたり応答を改ざんされたりすると、Clash が受け取るのは誤った答えになる。中国本土のサイトが海外アドレスに解決されて誤って代理経由になったり、逆のケースも起こる。さらに厄介なのは、クエリが海外向けの平文 UDP で送られ、途中で横取り応答を受け取ってしまい、返ってきた結果がクエリ対象と無関係になるケースだ。この状態では振り分け自体が成立しない。

そのため Clash は DNS サーバーを内蔵している。有効化すると、システムまたは TUN インターフェースからのドメインクエリはすべて Clash に集約され、設定されたアップストリーム・ポリシー・キャッシュに従って一括応答される。拡張モード(enhanced-mode)は応答方式をさらに決定する。redir-host は実際の解決結果を返し、fake-ip はまず仮のアドレスを返してから、接続が実際に発生した時点でドメインを逆引きしてルール判定を行う。

fake-ipfake-ip mode

拡張モードの一つ。クエリに即座に 198.18.0.0/16 帯の仮アドレスを返しマッピングを記録し、接続発生時にドメインを逆引きしてルールに一致させる。代理経由のドメインは実解決が不要になる。

redir-hostredir-host mode

拡張モードの一つ。先にアップストリームで実際の解決を行ってから応答する。すべてのドメインが完全なクエリを経る必要があり、結果の品質はアップストリーム経路の状態に左右される。

ドメインハイジャックDNS hijacking

経路上の中間機器が応答を横取り・改ざんし、問い合わせ元が実際の記録と異なる IP を受け取る現象。平文 UDP 53 番のクエリで最も多く発生する。

設定の骨格:enable・listen・enhanced-mode

DNS モジュールの入口は設定ファイル内の dns セクションだ。最小構成の骨格は以下の通り:

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"
    - "*.localhost"
    - time.*.com
    - ntp.*.com
    - localhost.ptlogin2.qq.com

各項目を順に解説する:

  • enable:全体の有効/無効スイッチ。false の場合 Clash は DNS を待ち受けず、ドメイン解決はシステムに戻る。ルール内の IP 判定はシステムの解決結果に依存するしかなくなる。
  • listen:待ち受けアドレスとポート。0.0.0.0:53 は本機の全ネットワークインターフェースの 53 番ポートを占有する設定で、相応の権限が必要。GUI クライアントは通常、権限付与とシステム DNS の向き先変更を自動で行う。
  • ipv6:AAAA クエリに応答するかどうか。IPv6 の出口を持たないネットワークでは false のままにしておくと、アプリが到達不能な v6 アドレスを優先的に試すのを防げる。
  • enhanced-mode:拡張モード。fake-ip または redir-host を指定する。意味は上記の用語カードを参照。
  • fake-ip-range:仮アドレスプール。デフォルトは 198.18.0.1/16。この帯域はベンチマーク用の予約アドレスで、通常のネットワークに実機が存在することはない。社内ネットワークで既にこの帯を使用している場合は別の帯域を選ぶ必要がある。
  • fake-ip-filter:仮アドレスの除外リスト。リストに載ったドメインは仮アドレスで応答せず、実際の解決結果を直接返す。ローカルネットワークのドメイン、NTP 時刻同期、STUN に依存する一部の音声・ゲームサービスは基本的に登録が必要になる。
補足

53 番ポートの占有は DNS モジュールが起動に失敗する最も多い原因だ。Linux デスクトップの systemd-resolved や Windows のインターネット接続共有はいずれも 53 番を占有する。listen を 0.0.0.0:1053 に変更して TUN モードで引き受けるか、占有元のサービスを停止する方法がある。

nameserver と fallback:2系統のアップストリームの役割分担

nameserver はデフォルトのアップストリームリストだ。実際の解決処理が発生すると、Clash はリスト内の全アップストリームに並行してクエリを送り、最初に返ってきた応答を採用する。大半のドメインの解決を担い、特に低遅延で本地の通信事業者による最適化結果を必要とする中国本土向けドメインでは、通常は中国本土の公共 DNS の DoH アドレスを設定する。アップストリームアドレスは4種類の書式に対応する:平文 IP(平文 UDP)、tls:// + ドメイン(DoT)、https:// + パス(DoH)、dhcp:// + ネットワークインターフェース名(システムの割り当てに追従)。

fallback は元祖 Clash における比較検証用のアップストリーム機構だ。nameserver と同時にクエリされるが、その結果はデフォルトでは採用されない。nameserver の応答が fallback-filter の検証を通過しなかった場合にのみ、Clash は fallback の結果に切り替える。設計意図はこうだ:中国本土のアップストリームは速いが改ざんされる可能性があり、海外のアップストリームは遅いが信頼できる。フィルタで両者から良い方を選ぶ仕組みだ。fallback-filter は3種類の判定基準を提供する:

  • geoip と geoip-code:nameserver の応答 IP の帰属国コードが設定値(デフォルト CN)と一致しない場合、結果が疑わしいと判定し fallback を採用する。
  • ipcidr:応答 IP が指定ネットワーク帯(予約帯の 240.0.0.0/4 など)に含まれる場合、汚染と判定する。
  • domain:リストに載ったドメインは無条件で fallback の応答を使用する。
項目nameserverfallback
役割デフォルトのアップストリーム。大半の解決処理を担う信頼できる比較検証用アップストリーム。結果はデフォルトで未採用
代表的な選択中国本土の公共 DNS の DoH アドレス海外の公共 DNS の DoH / DoT アドレス
クエリのタイミング実際の解決処理ごとに並行してクエリnameserver と同時に並行してクエリ
結果採用の条件応答が fallback-filter の検証を通過nameserver の応答が検証を通過しなかった場合
mihomo での現状維持されており、nameserver-policy と併用非推奨としてマーク済み。新規設定での使用は非推奨

特に注意すべき点が2つある。1つ目は、fallback のアップストリームには DoH や DoT のような暗号化チャネルを必ず使うこと。fallback 自体が平文 UDP であれば、そのクエリも同様にハイジャックされ、比較検証の仕組みが無意味になってしまう。2つ目は、mihomo(Meta カーネル)は fallback と fallback-filter を非推奨としてマークしており、公式は nameserver-policy に切り替えてドメイン集合単位で明示的に振り分けることを推奨している。意味がより直接的になる点は後述する。

ドメインクエリ1回の完全な経路

  1. アプリがクエリを発行

    システムの DNS は Clash の待ち受けアドレスを向いているか、TUN インターフェースがネットワーク層で捕捉することで、クエリが Clash 内蔵 DNS サーバーに入る。

  2. fake-ip の判定

    拡張モードが fake-ip で、かつドメインが除外リストに含まれない場合、即座に 198.18.x.x の仮アドレスを返しマッピングを記録する。リストに含まれるドメインは実際の解決処理に進む。

  3. 接続発生時にドメインを逆引き

    アプリが仮アドレスへの接続を開始すると、Clash は元のドメインを逆引きし、まずドメインでルール一致を完了させて直結か、どの代理ノードに渡すかを決定する。

  4. IP が必要な場合は実際に解決

    GEOIP や IP-CIDR ルールに一致した場合、または対象が直結を必要とする場合、まず nameserver-policy に専用アップストリームがあるか確認し、一致しなければ nameserver で並行クエリを行う。

  5. 汚染検証と応答

    元祖 Clash は fallback-filter で nameserver の結果を検証し、通過しなければ fallback の応答を採用する。最終結果はキャッシュに書き込まれ、以降の同一クエリはキャッシュから直接返される。

nameserver-policy と proxy-server-nameserver

nameserver-policy はドメインまたはドメイン集合単位で専用アップストリームを指定でき、nameserver より優先度が高い。mihomo は geosite: 接頭辞でドメイン集合を参照する機能に対応しており、1行の設定でドメイン群全体を指定アップストリームに振り分けられる。これこそが fallback を置き換える理由だ。振り分けの根拠が明示的に書かれ、事後の結果検証に依存しなくなる。

proxy-server-nameserver はノードサーバーのドメイン解決専用だ。サブスクリプション内のノードアドレスがドメインの場合、代理接続を確立する前に必ず IP へ解決する必要がある。通常のアップストリームを使って代理経由で解決してしまうと循環依存になる。この項目には直結で到達可能なアップストリームを必ず指定する。default-nameserver はブートストラップ用のアップストリームだ。設定内の DoH・DoT アップストリーム自体もドメインであり、これらのドメインを先に解決するための純粋な UDP アップストリームの組が必要になる。

dns:
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
      - https://doh.pub/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query
      - https://dns.google/dns-query
    "+.corp.example.com":
      - 10.0.0.2

この設定例では、中国本土向けドメイン集合はアリババとテンセントの DoH を使用し、海外向け集合は Cloudflare と Google の DoH を使用し、社内ドメインは社内 DNS を指す。nameserver は未一致時のデフォルトの出口として機能する。海外 DoH アップストリームへのクエリ自体が代理経由で送られるため経路は信頼できるものとなり、fallback のような事後比較の仕組みはもはや不要になる。

リーク・ハイジャック・汚染:3種の典型的な不具合への対処

DNS リーク

ブラウザ標準搭載のセキュア DNS(Chrome、Edge はデフォルト有効)はシステム DNS を経由せず直接 DoH クエリを発行するため、Clash はドメインを見ることができず IP でしかルール一致を判定できず、振り分け精度が明らかに落ちる。対処法はブラウザのセキュア DNS 設定を無効化するか、TUN モードを有効にしてネットワーク層で全トラフィックを引き受け、ブラウザがどこにクエリを送っても必ず Clash を経由させることだ。

53番ポートのハイジャック

平文 UDP 53 番のクエリは経路上のどの中間ノードからも横取り応答を受け得る。海外向け UDP アップストリームは中国本土のネットワーク環境ではほぼ確実に横取りされる。設定に書くアップストリームは、海外方向に対しては例外なく DoH または DoT を使うこと。nameserver に海外向けの平文 UDP アドレスを書いてはならない。

結果の汚染

fake-ip モードでは、代理経由のドメインはそもそも実際の解決結果を必要としないため、汚染が判定プロセスに入り込む余地がない。直結が必要なドメインは中国本土の DoH アップストリームに任せれば、汚染される確率は極めて低い。個別のドメインで解決に異常がある場合は、まず fake-ip-filter への追加が必要か確認し、次にクライアントのログでそのドメインが実際にどのアップストリームに当たったかを確認する。

補足

nameserver に 8.8.8.8 のような海外向け平文 UDP が書かれているのは、設定レビューで最も多く見られる誤りだ。より正確な結果が得られるわけではなく、横取りによる汚染と余計なタイムアウト待ちを招くだけだ。

参考設定とチェックリスト

以上を踏まえ、そのまま流用できる mihomo 形式の DNS 設定例は以下の通り:

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"
    - time.*.com
    - ntp.*.com
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  nameserver-policy:
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query
      - https://dns.google/dns-query

有効化する前に一項目ずつ確認する:

  • enable が true になっており、listen のポートが他のサービスに占有されていないこと
  • システム DNS が Clash を向いているか、あるいは TUN モードが有効になっていること
  • nameserver に中国本土の DoH を使用し、海外向けアップストリームはすべて暗号化チャネル経由であること
  • proxy-server-nameserver が設定済みで直結可能であり、ノードのドメインが正常に解決できること
  • fake-ip-filter にローカルネットワークと時刻同期のドメインが含まれていること
  • クライアントのログに継続的な DNS タイムアウトの記録がないこと

DNS 設定が完了して初めて、ルール振り分けは信頼できる基盤を得られる。以降のカスタムルール作成やポリシーグループ設計は、このクリーンな解決結果の上に構築できる。

Clash をダウンロード