DNSはあらゆるネットワークリクエストの最初のステップであり、プロキシ設定で最も問題が起きやすい部分でもあります。Clashには完全機能のDNS処理エンジンが内蔵されています。「プロキシは動いているのに一部のサイトが遅い」「DNSリークが起きている」「ノードのpingは通るのに接続がタイムアウトする」といった問題を診断するには、DNSの仕組みを理解することが不可欠です。この記事では2つのDNSモード（redir-hostとfake-ip）を比較し、本番環境に対応した設定テンプレートを提供します。

プロキシ環境でDNSが難しい理由

通常のブラウジングではシンプルです：DNSルックアップ → 実際のIPを取得 → TCP接続を確立。しかしプロキシが介在すると複雑になります。DNSクエリがプロキシを通さずにローカルリゾルバーへ送られると、プロキシ経由でアクセスしたいドメインのIPが不正確になる可能性があります。一方、すべてをプロキシ経由で解決するとレイテンシが増加し、直接接続すべきトラフィックにとっては不必要です。

Clashは実際のIPアドレスが分かる前に、トラフィックをプロキシ経由にするか直接接続にするかを決定しなければなりません。このジレンマがDNSモード設計の背景にあります。

redir-hostモード：実IPを先に解決

redir-hostはClashの元々のDNSモードです。動作の仕組みは以下のとおりです：

  1. アプリがDNSクエリを発行（例：openai.comの解決）
  2. Clashが複数のアップストリームDNSサーバーに並列でクエリし、最速の結果を返す
  3. 実際のIPがアプリに返される
  4. アプリがそのIPで接続を試みる。ClashはIP-CIDRやGEOIPルールを適用してルーティングを決定

redir-hostの欠点は、ルールマッチングが実際のIPに依存していること。しかしそのIPの取得自体がDNSハイジャックや汚染の影響を受ける可能性があり、トラフィックが誤ったルートを取ることがあります。また、接続ごとに完全なDNSラウンドトリップが必要なため、初回接続のレイテンシが増加します。

fake-ipモード：仮IPを即座に割り当て

fake-ipはMihomo（旧Clash.Meta）が推奨するモダンなアプローチで、TUNモードとの組み合わせに最適です。核心となるアイデア：実際のIPを待たず、すぐに仮のプライベートIPを返し、実際のDNS解決をプロキシ側に委ねます。

  1. アプリがDNSクエリを発行
  2. Clashは即座にfake-ip-rangeプール（デフォルト：198.18.0.0/15）から仮IPを割り当てて返し、内部で「仮IP ↔ ドメイン」のマッピングを保持
  3. アプリが仮IPで接続を試みる
  4. Clashが接続を傍受し、マッピングから元のドメインを復元してドメインベースのルールでプロキシ/直接を決定
  5. プロキシ経由の場合はプロキシサーバー側でDNS解決。直接の場合はClashが実際のDNSクエリを発行して転送
fake-ipが優れている理由：ルールはIPではなくドメイン名でマッチングするため、DNSハイジャックを完全に回避できます。実際のDNS応答を待つ必要がないため初回接続のレイテンシも低くなります。プロキシ対象のドメインはプロキシサーバー側でのみ解決されるため、DNSリークのリスクも最小化されます。

fake-ip-filter：実IPが必要なドメイン

すべてのアプリが仮IPで正常に動作するわけではありません。デスクトップゲーム、VoIPクライアント、P2Pソフトウェアなどは、サービスディスカバリや直接接続のために実際のIPが必要なものがあり、仮IPを返すと動作しなくなります。fake-ip-filterフィールドでそれらのドメインを除外することで、通常のDNS解決で実際のIPを受け取れるようにします。

推奨 fake-ip 設定テンプレート
dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  # 仮IPから除外するドメイン（実IPが割り当てられます）
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - +.stun.*.*
    - +.stun.*.*.*
    - +.xbox.*.microsoft.com
    - *.msftncsi.com

  nameserver:
    - 1.1.1.1           # Cloudflare — プライマリリゾルバー
    - 8.8.8.8           # Google DNS

  fallback:
    - tls://1.1.1.1:853  # Cloudflare DNS over TLS
    - tls://8.8.8.8:853  # Google DNS over TLS

  fallback-filter:
    geoip: true
    geoip-code: JP      # お住まいの国コードに変更してください
    ipcidr:
      - 240.0.0.0/4

nameserverとfallbackの連携

nameserverはすべてのクエリに使用されるプライマリDNSリゾルバーです。fallbackはセカンダリリゾルバーセットで、fallback-filterの条件が満たされた場合（例：解決されたIPがGEOIP範囲外の場合）、nameserverの結果をfallbackの結果で置き換えます。この設計により、直接接続したいトラフィックは高速なローカルリゾルバーを使用し、プロキシしたいトラフィックは傍受や改ざんを防ぐために暗号化DNSで解決されます。

fallbackを設定しない場合、すべてのDNSクエリがnameserverを通ります。リゾルバーによっては、GEOIPの分類が不正確になり、プロキシ経由でも一部のサイトにアクセスできなくなる可能性があります。

DNSリークの確認方法

dnsleaktest.comにアクセスして拡張テストを実行してください。知らないDNSサーバーが表示された場合（例：CloudflareやGoogle DNSではなく、ISPのリゾルバーが表示される）、DNSリークが発生しています。fake-ipとfallbackを正しく設定した後は、プロキシサーバーのDNSまたは設定した暗号化リゾルバーのみが表示されるはずです。

別の確認方法：Clashの設定でlog-level: debugを有効にして再起動します。プロキシ経由でアクセスするサイトへの接続時、デバッグログにそのドメインのDNSクエリがfallbackリゾルバーへ送られていることが確認できます。