Clash DNS 設定解説:nameserver、fallback と DNS ハイジャックの設定方法

Clash における DNS セクションの位置づけと役割

Clash の設定ファイルにおいて、dns セクションは proxies や rules とは独立したモジュールです。トラフィックがどのプロキシノードを通るかには関与せず、ドメイン名を IP アドレスに変換する処理だけを担います。この処理はルールマッチングより前に行われます——Clash はドメイン名を受け取った後、まずそれに対応する IP を知る必要があり、それから GEOIP や IP-CIDR といったルールに基づいて振り分けを判断します。dns セクションの設定が不適切だと、ルール振り分けの精度に直接影響が出ます。典型的な症状は、直結ルールを設定しているにもかかわらずプロキシ経由になってしまう、あるいはその逆のケースです。

dns セクションの主要フィールドには、enable(Clash 自身の DNS 処理を有効にするか)、listen(リスニングアドレス。通常は TUN モードと併用)、enhanced-mode(fake-ip または redir-host)、nameserver(主に使用する解析サーバーのリスト)、fallback(補助的な解析サーバーのリスト)、fallback-filter(fallback を発動するタイミングを判定するルール)があります。これらが連携し合って、解析処理全体のフローを構成しています。

nameserver と fallback の役割分担

nameserver は主に使用する解析サーバーのリストで、Clash はまずこれらのサーバーでドメイン名を解析します。fallback は補助的な解析サーバーのリストで、特定の条件が発動した場合にのみ採用されます。単純に「nameserver が失敗したら fallback に切り替える」という仕組みではありません。

nameserver の一般的な設定例

通信事業者の解析速度が速く、地理的に近いサーバーを設定するのが推奨されます。日本国内でよく見られる組み合わせは、国内のパブリック DNS とプロバイダー DNS の併用です:

nameserver:
  - 223.5.5.5
  - 119.29.29.29
  - 114.114.114.114

fallback の発動条件

fallback には通常、海外またはネットワークをまたぐ解析サーバー(例:1.1.1.1、8.8.8.8)を設定します。これは無条件のバックアップではなく、fallback-filter と組み合わせて使用されるものです——nameserver で解析された結果が「信頼できない」と判定された場合(例えば geoip 外のアドレス帯に該当する、または特定のルールにマッチする場合)にのみ、Clash は fallback に切り替えて再解析を行います。この仕組みの意味は、国内向けドメインは国内 DNS を使うことで近い CDN ノードにアクセスでき遅延を減らせる一方、汚染されている、あるいはプロキシ経由でのアクセスが必要なドメインについては、クリーンな海外 DNS を使うことで誤った解析結果を避けられる、という点にあります。

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
  domain:
    - +.google.com
    - +.facebook.com

上記の設定の意味は次のとおりです:nameserver で解析された IP が中国本土に属さない場合(geoip-code: CN 以外)、または domain リストに記載されたドメインに一致する場合、その解析結果を信頼できないと判断し、fallback に設定されたサーバーで再度クエリを行います。これにより、汚染されているドメインへのアクセス時には正しい海外の解析結果を得られる一方、国内向けサイトへのアクセスでは最も速いローカル DNS を利用し続けられます。

fake-ip と redir-host:2つの拡張モードの違い

enhanced-mode フィールドは、Clash が DNS 解析結果をどのように処理するかを決定するもので、fake-ip と redir-host のいずれかを選択できます。この2つのモードは設計目標が異なり、適用シーンも異なります。

fake-ip モード

fake-ip モードでは、Clash が DNS クエリリクエストをインターセプトし、ドメイン名に対応する実際の IP を返す代わりに、予約されたアドレス帯(デフォルトは 198.18.0.0/16)内の仮想 IP を返します。アプリケーションはこの仮想 IP を受け取って接続を開始し、Clash はトラフィックが通過する際にこの仮想 IP を実際のドメイン名に変換し、ルールエンジンに振り分け判定を渡した後、最終的に実際の IP を解析して転送を行います。

このモードの利点は解析速度が速いこと(実際の DNS クエリの応答を毎回待つ必要がない)、ルールマッチングをドメイン名で直接行えるため IP に依存せず精度が高いことです。TUN モードと組み合わせて使用する場合、fake-ip はほぼ標準的な選択となります。欠点は、IP アドレスに強く依存する一部のソフトウェア(例えば一部のゲームのオンライン通信、LAN 内での検出プロトコルなど)が、仮想 IP を受け取ることで正常に動作しなくなる場合があり、その場合は fake-ip-filter でこれらのドメインを個別に除外する必要があります。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
    - "time.*.com"

redir-host モード

redir-host モードでは、Clash が nameserver/fallback に直接実際の IP を問い合わせ、アプリケーションにそのまま返します。仮想アドレスへの置き換えは行いません。ルールマッチングの段階では、この実際の IP、またはクエリ時に記録されたドメイン名と IP の対応関係が利用されます。このモードは互換性が高く、アプリケーションが「偽の」アドレスを受け取ることで動作異常を起こすケースはほとんどありませんが、解析のオーバーヘッドが大きく、複雑なシーンではルールマッチングの精度が fake-ip に劣る場合があります。

DNS ハイジャックの判定と対処シーン

DNS ハイジャックとは、解析リクエストが通信経路上の中間ノードによって改ざんされ、誤った IP アドレスが返されることで、広告ページやエラーページへリダイレクトされたり、あるいは接続すらできなくなったりする現象を指します。DNS ハイジャックが発生しているかどうかを判定する一般的な方法は、異なる DNS サーバーで同じドメイン名を解析し、返される結果が一致するかを比較することです——ローカルのプロバイダー DNS が返す IP が、既知のパブリック DNS が返す結果と大きく異なり、かつアクセスに異常がある場合、ハイジャックや汚染が起きている可能性が高いと判断できます。

Clash の仕組みにおいては、fallback-filter 機能自体が DNS ハイジャックへの対処手段の一つです:geoip とドメインリストによって解析結果が信頼できるかを判断し、信頼できない場合は別のサーバー群で再度クエリを行います。それ以外にも、以下の点を検討できます:

• nameserver では DoH(DNS over HTTPS)または DoT(DNS over TLS)対応のサーバーアドレスを優先的に使用し、平文クエリが改ざんされるリスクを減らします。書式は https://dns.server/dns-query または tls://dns.server:853 です。
• 既に汚染が判明しているドメインについては、hosts セクションで正しい IP を直接指定し、DNS クエリの工程を回避できます。
• use-hosts フィールドが有効になっていることを確認し、hosts セクションの静的マッピングが DNS クエリより優先して機能するようにします。

dns:
  enable: true
  use-hosts: true
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN

hosts:
  example.local.test: 127.0.0.1

注意すべき点は、DNS ハイジャックとプロキシルールの振り分けは異なる次元の問題であるということです。プロキシノード自体が正常に使えるにもかかわらず、特定のウェブサイトへのアクセスが常に異常な場合は、まず DNS 解析の段階に問題がないかを確認するべきであり、最初からノードやルール記述の誤りを疑うべきではありません。逆に、複数の DNS サーバーで解析した結果が一貫して正しいにもかかわらずアクセスが失敗する場合は、問題はプロキシノードやルールマッチングにある可能性が高いです。

漏洩防止のポイントと完全な設定例

DNS リークとは、本来プロキシ経由で処理されるべきドメイン名解析リクエストが、実際には Clash を経由せずシステムのデフォルト DNS サーバーへ直接送られてしまい、実際のアクセス意図が漏れてしまう現象を指します。リークを避けるためには、以下の点に注意が必要です:

1. システムレベルのプロキシ設定または TUN モードが正しくトラフィックを引き受けていることを確認してください。一部のアプリケーションのみプロキシを有効にし、システムレベルの DNS クエリ経路を見落とさないようにしましょう。
2. dns セクションの enable フィールドは必ず true にしてください。そうでなければ Clash は解析処理に介入せず、すべてのクエリがシステムのデフォルト経路を通ります。
3. listen フィールドは明示的に指定することを推奨します。例えば 0.0.0.0:1053 のように設定し、OS またはルーターレベルの DNS リクエストがこのリスニングポートに正しく転送されていることを確認してください。システム標準の DNS クライアントを迂回しないようにします。
4. TUN モードを有効にする場合は、dns の fake-ip または redir-host モードと TUN の stack 設定が一致していることを合わせて確認し、2つの解析ロジックが競合して一部のリクエストが逃れてしまうことを避けてください。
5. DoH/DoT 対応の nameserver を使用することで、通信事業者が伝送層でクエリ内容を観察・改ざんする機会を減らせます。

以下に、本記事の要点を統合した完全な dns セクションの設定例を示します。そのまま設定ファイルに適用し、実際のノード状況に応じて nameserver と fallback の具体的なアドレスを調整してください:

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  use-hosts: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.io

この中の default-nameserver フィールドについては個別に説明する価値があります:これは nameserver と fallback の中でドメイン名形式で書かれた DoH サーバーアドレス(上記例の 223.5.5.5/dns-query 自体は IP ですが、これがドメイン名形式の DoH アドレスに置き換わった場合)を解析するために専用で使われます。その場合、default-nameserver がまずこの DoH サーバー自体の IP を解析し、それを使って実際のユーザードメインをクエリする、という流れになります。これは見落とされがちですが、解析フロー全体が正常に機能するかどうかに影響する重要な細部です。