1. ホーム
  2. ブログ
  3. Clash DNS設定を項目別に解説
読了目安:9分

Clash DNS設定を項目別に解説:nameserver・fallback・DNS改ざん対策パラメータの書き方

DNSセクションは、Clash/Clash Metaの設定ファイルの中で最もコピペされがちなのに、実はきちんと理解されていない部分です。本記事では enhanced-mode の2つの動作方式から解説を始め、nameserverfallback それぞれの役割、fallback-filter がどのようにドメインの改ざんを判定するのかを分解し、最後に行ごとの注釈付きでそのまま使えるテンプレートを紹介します。

DNSセクションが解決する課題

プロキシソフト自体はドメインを解決しません。転送するのはトラフィックですが、そのトラフィックがプロキシに入る前に、OSやアプリがまずドメインをIPに解決する必要があります。この段階でローカルの通信事業者のDNSを使うと、典型的に2つの問題が発生します。1つは解決結果が改ざん・ハイジャックされ、誤ったIPが返されること。もう1つは、解決動作そのものがアクセス意図を露呈してしまうことです。トラフィック自体は後でプロキシを経由しても、DNSリクエストは平文のUDP 53番ポートを使うことがあり、中間の機器に記録されたり遮断されたりする可能性があります。Clashの dns 設定セクションは、この解決プロセスそのものを引き受け、ドメイン解決とトラフィック転送を同じルール体系のもとで完結させるためのものです。

このモジュールは2つの部分から構成されています。enhanced-mode はドメインからIPへの変換方式を決定し、nameserver/fallback 系のパラメータは実際に解決リクエストを発行する際、どのアップストリームサーバーをどの順序で試すかを決定します。両者が組み合わさることで、ルールによる振り分けの精度を保ちつつ、解決結果の改ざんも避けられます。

enhanced-mode:fake-ipとredir-hostの選び方

enhanced-mode には2つの値しかありませんが、動作は大きく異なります。

  • fake-ip:ClashはDNSクエリを捕捉した後、すぐに実際のIPを問い合わせるのではなく、専用のアドレス帯(デフォルトは 198.18.0.0/16)から偽のIPを割り当ててアプリに返します。アプリがその偽IPで接続を開始すると、Clashが接続確立の瞬間に実際のドメインを逆引きし、ルールに基づいてどのプロキシグループを使うか判断します。この方式はルール判定の精度が最も高く、振り分けの基準が常にドメイン(変化しうるIPではない)になるためです。現在主流のクライアント(mihomoカーネル系)のデフォルト値であり、公式が推奨する設定でもあります。
  • redir-host:アップストリームサーバーに直接実際のIPを問い合わせ、そのまま返します。互換性は高く、特に実際のIPで地理位置判定を行う一部のアプリ(動画・地図系アプリなど)は偽IP帯を受け取ると誤動作するため、その場合にのみredir-hostへ切り替える必要があります。代償として、ルール判定がIP帯単位に退化し、ドメインベースの細かい振り分けの精度は落ちます。

特別な互換性の問題がない限り、統一して fake-ip を使用し、fake-ip-filter でLANアドレス・内部サービス・実際のIPを積極的に使うドメイン(一部の銀行、LAN機器発見プロトコルなど)を偽IP割り当てから除外し、それらのドメインは実際の解決を続けさせます。

nameserverとfallbackの役割分担

多くの人が nameserverfallback の両方にDNSサーバーのアドレスを並べて書いてしまいますが、Clashが具体的にどう使うのかを理解していないケースが多いです。実際のロジックはこうです。

  1. nameserverでまず解決

    すべてのドメインはデフォルトで nameserver に記載されたサーバーで解決されます。ここには通常、日本国内の信頼できるパブリックDNSを設定します(平文UDPではなくDoH/DoTの利用が推奨され、通信事業者が伝送層でクエリ内容を見て改ざんすることを避けられます)。

  2. fallback-filterが再検証の必要性を判定

    nameserver から返された結果を受け取った後、fallback-filtergeoip 検出が有効な場合、Clashはそのそのが geoip-code で指定された国・地域(通常はJP)に属するかを判定します。属していればその結果を採用し、属していなければ、そのドメインは海外リソースである可能性が高いにもかかわらず誤った、あるいは異常なIPに解決されていることを意味し、次のステップが発動します。

  3. fallbackによる再検証

    再検証が必要と判定されると、Clashは fallback リストのサーバーで再解決を行います。ここには通常、海外の、あるいは改ざん耐性の強いDoH/DoTサーバーを設定し、得られた結果がそのまま最終的な解決結果として使われます。

言い換えると、nameserver はデフォルトの経路で効率を担い、fallback は検証経路で誤りの補正を担い、fallback-filter はその間の審判役です。3つのうちどれかが欠けると、DNSセクションの改ざん耐性は落ちます。nameserver だけで fallback がなければ、改ざんに遭遇しても訂正できません。fallback だけで nameserver がなければ、すべてのリクエストが海外サーバーを経由し、日本国内サイトの解決遅延が明らかに増加します。

注意

fallback-filtergeoip 判定は、内蔵または追加でダウンロードされたGeoIPデータベースに依存します。初回起動時やデータベースが期限切れの場合、この機能が一時的に無効になることがあり、一部の海外ドメインの解決結果が異常になる場合があります。クライアントのGeoIPデータベースが利用可能な状態であることを確認するのが、DNS関連の問題を調査する最初のステップです。

DNS改ざんの症状とfallback-filter以外の対策手段

一部のネットワーク環境では、通信事業者の機器を経由する平文DNSクエリ(UDP 53番ポート)に対して改ざんやDNSポイズニングが行われることがあります。よくある症状は、海外サイトにアクセスすると無関係なローカルIPに解決されてしまう、あるいは存在しないアドレスが返されて接続がタイムアウトするというものです。この種の改ざんは伝送層で発生するものであり、Clashのルール設定とは関係がありません。有効な対策はDNSクエリ自体を暗号化された経路に乗せることだけです。

  • https:// 接頭辞のDoH(DNS over HTTPS)アドレスを使う。クエリは443番ポートを経由し、通常のHTTPSトラフィックと混ざるため、単独で識別・遮断されにくくなります。
  • tls:// 接頭辞のDoT(DNS over TLS)アドレスを使う。クエリは853番ポートを経由して暗号化され、同様に平文改ざんを回避できますが、853番ポート自体が個別に帯域制限や遮断を受けることがあり、互換性はDoHよりやや劣ります。
  • nameserver/fallback に平文UDPアドレス(8.8.8.8 のようにプロトコル接頭辞のない形式)を混在させないこと。平文アドレスは一部のネットワーク環境では実質的に無防備と同じです。

さらに default-nameserver フィールドにも注意が必要です。これは nameserver/fallback に設定したDoH/DoTサーバー自体のドメイン(例えば doh.pub というドメインがどのIPを指すか)を解決するためだけに使われるものであり、必ず純粋なIPアドレスを設定しなければなりません。ドメイン形式のDoHアドレスを設定すると、循環解決が発生してDNSモジュールが起動できなくなります。

そのまま使えるdns設定テンプレート

以下のテンプレートはmihomoカーネル(Clash Meta系クライアントはすべてこのカーネルをベースにしています)向けで、各フィールドの役割を行ごとに注釈しています。設定ファイルの dns セクションにそのまま丸ごと置き換えて使えます。

dns:
  enable: true                      # DNS処理の引き受けを有効化。無効にするとOS標準の解決に戻る
  ipv6: false                       # IPv6ネットワークを使っていない場合は無効化推奨(無効な問い合わせを削減)
  enhanced-mode: fake-ip            # ルール判定が最も正確なモード。互換性問題があればredir-hostに変更
  fake-ip-range: 198.18.0.1/16      # 偽IPの割り当て帯。ローカルの実ネットワークと重複しなければ問題なし
  fake-ip-filter:                   # 以下のドメインは実際の解決を行い、偽IPを割り当てない
    - "*.lan"
    - "+.local"
    - "time.*.com"
    - "*.market.xiaomi.com"
  default-nameserver:                # 下記DoH/DoTサーバー自体のドメイン解決専用。純粋なIPのみ指定
    - 223.5.5.5
    - 119.29.29.29
  nameserver:                        # デフォルトの解決経路。国内DoHを優先
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:                          # 検証・補正用の経路。海外ドメインの解決異常時に発動
    - https://1.1.1.1/dns-query
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true                      # 位置情報検証を有効化
    geoip-code: CN                   # 解決結果がこの地域に属さない場合、fallbackによる再検証を発動
    ipcidr:                          # 以下のネットワーク帯に該当する結果は異常とみなし、即fallbackを発動
      - 240.0.0.0/4
    domain:                          # 以下のドメインは常にfallbackを使用し、nameserverの判定を経由しない
      - "+.google.com"
      - "+.youtube.com"

使用する際は、fake-ip-filterfallback-filter.domain のサンプル項目を、実際に特別対応が必要なドメインに置き換えるだけで済みます。それ以外のフィールドはほとんどの場合変更不要です。

よくある調査の手順

dns設定を変更したらインターネットに全く接続できなくなった場合は?

まず default-nameserver に純粋なIPを設定しているか(ドメイン形式のDoHアドレスになっていないか)を確認してください。これが最もよくある循環解決の問題です。次にYAMLのインデントが正しいかを確認します。dns セクションは階層に厳しく、スペース1つのずれで設定全体が無視されることがあります。

fake-ipモードで特定のアプリの接続が常に失敗するのはDNSの問題?

そのアプリがサーバーアドレスの検証やIP帯のホワイトリスト判定を内蔵している可能性が高いです。そのドメインを fake-ip-filter に追加して実際の解決を行わせることで解決することが多いです。同様の問題が繰り返し発生する場合は、全体的に redir-host への切り替えを検討してください。

海外サイトへのアクセスが依然として遅いのはfallbackが効いていないから?

まずプロキシルール自体が正しいプロキシグループにヒットしているかを確認してください。DNS解決が正しくても、誤ったポリシーグループを経由していれば同様に遅く感じられます。ルールの問題を除外できたら、fallback サーバーの接続性を確認し、必要に応じて他の利用可能なDoH/DoTアドレスに変更してください。

Clash クライアントをダウンロード