Clash DNS 設定解説:nameserverとfallback、DNSハイジャック対策パラメータの設定方法

なぜClashが独自にDNSを処理する必要があるのか

通常のネット接続では、デバイスがドメイン名の問い合わせを行い、まずシステムやルーターに設定されたDNSサーバーがIPを解決し、そのIPを使って目的のサーバーに接続します。このDNS要求自体がプロキシを通っていない場合、通信事業者や経路上のネットワーク機器がどのドメインを問い合わせているかを把握できてしまい、場合によっては誤った解決結果を返すこともあります。これがいわゆるDNS汚染・DNSハイジャックです。ルールに基づく振り分けも正確なドメイン情報に依存しており、クライアントが受け取ったドメインに対応するIPが信頼できないと、DOMAIN-SUFFIX や GEOIP などのルール判定も不正確になります。

Clash と Clash Meta(mihomo カーネル)は、設定ファイルの中に独立したDNSモジュールを内蔵しており、ドメイン解決の段階もプロキシ体系の中で統一管理でき、解決をすべてシステムのネットワーク設定に委ねる必要がありません。このモジュールは dns フィールド全体で制御され、nameserver、fallback、enhanced-mode が最も重要な3つの設定項目です。これらを適切に組み合わせることで、解決速度を確保しつつ汚染やハイジャックも回避できます。

nameserverとfallback:2つのDNSサーバー群の役割

Clash のDNSセクションには通常、nameserver と fallback フィールドの下に2組のサーバーアドレスが記述されます。これは単純な主・副の関係ではなく、それぞれ異なる役割を担う2つの解決経路です。

nameserver:デフォルトの解決経路

nameserver は日常的な解決で最初に使われる経路で、ここに設定したサーバーアドレスは大半のドメイン要求の解決に使われ、ルール判定自体もここで返された結果を利用します。日本国内の環境であれば通常、通信事業者のDNSや公共DNS(例:1.1.1.1、8.8.8.8 など)を設定し、国内サイトへのアクセス時に十分な解決速度を確保し、あえてプロキシを経由して戻ってくるような無駄な迂回を避けます。

fallback:バックアップと海外ドメイン用の解決経路

fallback はバックアップ用の経路で、fallback-filter と組み合わせて使うのが一般的です。よくある使い方は、まず nameserver でドメインを解決し、返ってきたIPが fallback-filter.geoip-code で指定した国コード(たとえば CN)の範囲内にあるかを確認します。国内IP帯に含まれていなければ、そのドメインはプロキシを経由すべき海外サイトである可能性が高いと判断し、fallback に設定した海外向けDNS(例:1.1.1.1、8.8.8.8)で再解決します。これにより、国内のDNSで海外ドメインを解決した際に生じる応答遅延や不正確な解決結果を回避できます。

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

このうち default-nameserver はさらに基礎的な経路で、nameserver や fallback フィールドにドメイン名の形式で書かれたDNSサーバーアドレス(たとえばドメイン形式で書かれたDoHアドレスなど)を解決する専用の経路です。まだ確立されていない解決チェーンに依存して自分自身を解決することはできないため、ここには純粋なIPアドレスのみを設定します。

fake-ipとredir-host:2つの解決モードをどう選ぶか

enhanced-mode は、Clash が解決したドメイン情報を後続のプロキシやルールモジュールにどのように渡すかを決めるフィールドで、よく使われる値は fake-ip と redir-host です。両者の動作方式や適用場面はかなり異なります。

fake-ip モード

fake-ip モードでは、Clash はドメイン解決で得た実際のIPをアプリケーションにそのまま渡しません。まずプライベートアドレス帯に属する仮のIP(フェイクIP)を返します。アプリケーションはこの仮のIPで接続を開始し、そのトラフィックはまずClashに流れ込み、Clashが内部で仮IPを元のドメインにマッピングし直してから、ルールに基づいて実際の出口と接続先を決定します。このモードのメリットは解決速度が速いこと、TUN モードと組み合わせてグローバルな透過プロキシを実現できることで、現在のデスクトップクライアントやルーター環境ではほぼデフォルトの選択肢になっています。デメリットは、IPへの依存度が高い一部のアプリケーション(直接接続先のIPを検証する必要があるサービスや、LAN内デバイス探索など)で異常が起きる可能性があることです。この場合は該当するドメインやIP帯に個別で直接接続ルールを設定するか、それらのドメインを fake-ip-filter の除外リストに追加し、仮IP処理をスキップさせる必要があります。

redir-host モード

redir-host モードは従来型の方式です。Clash はドメインを実際のIPに解決してそのままアプリケーションに返し、プロキシの判定はアプリケーションが接続時に送る Host ヘッダーやSNI情報に依存します。このモードは互換性が高く、仮IPによる互換性の問題が起きにくい一方、解決と転送の効率は fake-ip に劣り、明確なドメイン情報を伴わないプロトコル(たとえば純粋なIP通信ベースの一部のアプリケーション)では振り分けの精度が下がります。現在主流のClash Meta / mihomo カーネルクライアントでは fake-ip が推奨設定となっており、redir-host はどちらかというと過去の設定や特殊な互換用途での代替案という位置づけです。

DNSハイジャック対策パラメータの理解と設定

nameserver と fallback の基本的な役割分担以外に、Clash のDNSセクションにはDNSハイジャックへの対策や解決の安全性を高めるための専用パラメータがいくつか用意されています。これらの働きを理解しておくと「ページが開けないのにプロキシは明らかに動いている」といった問題の切り分けに役立ちます。

暗号化されたDNSプロトコルを使う

通常の udp:// による平文DNS要求では、経路上のネットワーク機器に改ざんされたり遮断されたりするリスクが依然として残ります。nameserver や fallback のアドレスを tls://(DNS over TLS)や https://(DNS over HTTPS)接頭辞に変更すると、DNS要求そのものを暗号化経路で送ることができ、ハイジャックや改ざんのリスクを減らせます。たとえば https://1.1.1.1/dns-query や tls://8.8.8.8:853 はよく使われる書き方で、大半のmihomo カーネルクライアントはこの2種類の接頭辞をネイティブでサポートしています。

listen とLAN内DNS要求のハイジャック

dns.listen フィールドは、Clash 内蔵のDNSサービスがリスンするローカルポート(例:0.0.0.0:1053)を指定します。システムプロキシまたはTUNモードのDNSハイジャックスイッチと組み合わせることで、デバイス自身が発するDNS要求を強制的に横取りしてClashに処理させ、Clashを迂回してシステム設定のDNSサーバーへ直接送られることを防げます。一部のアプリケーションのドメイン要求がまったくルール判定を通っていない場合、多くはこのハイジャック処理が効いておらず、アプリケーションがハードコードされたDNSアドレスを使ってシステムの解決入口を回避していることが原因です。

nameserver-policy によるきめ細かな振り分け

特定のドメインだけ特別なDNSサーバーで解決する必要がある場合(たとえば社内ドメインは社内DNSでしか解決できず、公共DNSで解決すると誤った結果になるケース)には、nameserver-policy を使って特定のドメインやサフィックスごとに解決サーバーを個別指定でき、グローバルな nameserver 設定より優先されます。

dns:
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
    "+.corp.internal":
      - 10.0.0.53

このような設定は、社内ネットワークと外部ネットワークが混在するリモートワーク環境などで多く使われ、社内サービスが誤った経路で解決されてアクセスできなくなるのを防ぎます。

DNS設定が実際に効いているかを確認する

設定を書き終えた後は「ページが開ける」といった曖昧な判断だけで済ませず、以下の手順で1つずつ確認することをおすすめします。

1. クライアントの接続ログやDNSクエリ記録を確認する:多くのGUIクライアント(Clash Verge Rev など)は「接続」や「ログ」パネルでリアルタイムのドメイン解決要求を確認でき、対象ドメインが実際にClashを経由しているか、迂回していないかを確認できます。
2. コマンドラインツールで解決結果を照合する:ターミナルで nslookup 対象ドメイン名 127.0.0.1 -port=1053 を実行し(ポートは実際の dns.listen 設定に置き換えてください)、返ってくるのが仮IPか実IPかを確認し、想定している enhanced-mode と一致していればOKです。
3. 国内・海外サイトの振り分けが想定どおりか検証する:明確に国内のサイトと海外のサイトをそれぞれアクセスし、ルールログと合わせて前者が直接接続、後者がプロキシノードを経由しているか、両方が同じ経路を通っていないかを確認します。
4. 解決の漏洩がないかチェックする:一部のアプリケーションは独自のDNS処理を内蔵し、システム設定を回避することがあります。あるアプリケーションが実際の解決要求を漏洩させていると疑う場合は、一時的にそのアプリケーションのネットワーク権限を無効にするか、ファイアウォールルールで個別にDNSトラフィックを観察し、実際にClashへハイジャックされているかを確認してください。

よくある誤解と切り分けの考え方

実際の設定過程では、いくつかの誤解が繰り返し起こりやすく、事前に知っておくと切り分けの時間を大幅に節約できます。

• fallbackをメインのDNSとして使ってしまう:fallback-filter の設定が不適切、または欠けていると、すべての要求がfallback経由と判定されてしまい、国内サイトの解決速度がむしろ遅くなることがあります。この場合は geoip-code が正しく設定されているか確認してください。
• 暗号化と非暗号化のDNSを混在させながらタイムアウト戦略を統一していない:暗号化DNS要求は平文要求よりわずかに時間がかかるのが普通です。クライアントのタイムアウト設定が短すぎると解決が間欠的に失敗することがあり、この場合はクライアントのDNSタイムアウトパラメータを適宜調整するか、fallbackリストのサーバー数を減らすとよいでしょう。
• IPv6が解決結果に与える影響を無視する:一部のネットワーク環境ではIPv6が有効になっており、ClashのIPv6フィールドが実際のネットワーク状況と一致していないと、解決されたIPの種類と実際に使える接続方式が合わないことがあります。自分のネットワーク環境に合わせて ipv6: true または false を明示的に設定し、空欄のままにしないことをおすすめします。
• ルールでIP帯による判定を使っているのに解決モードがfake-ipになっている:fake-ip モードではアプリケーションが受け取るのは仮IPです。ルールが実際のIP帯(GEOIP など)に強く依存している場合、クライアントのカーネルがルール判定時に仮IPを実IPに戻してから判定しているかどうかを確認する必要があります。実装によって処理順序が異なることがあるため、判定に異常が出た場合は一度 redir-host モードに切り替えて比較検証すると原因がわかりやすくなります。

DNSセクションの設定は一度で完璧に仕上げる必要はありません。まず基本の nameserver + fallback + fake-ip の組み合わせで動かし始め、実際に使う中で出てきた具体的な問題(あるアプリがつながらない、ある社内サービスの解決が間違っているなど)に応じて1つずつパラメータを追加・修正していくほうが、最初からすべての項目を盛り込むよりも保守しやすくなります。