DNS 解決はプロキシ経路における最も問題が発生しやすい箇所です。設定が不適切な場合、2種類のリスクが生じます：DNS ハイジャックによりプロキシ経由のドメインが誤った IP に解決されてアクセス不能になる問題と、DNS リークによって実際のアクセス記録が ISP に露出してしまう問題です。Clash 公式の DNS モジュールには Fake-IP メカニズムが内蔵されており、システムレベルでこれら2つの問題を根本的に解決します。これは Clash が同類ツールと一線を画すコア機能の一つです。
従来のプロキシにおける DNS の課題
従来の HTTP プロキシモードでは、ブラウザが google.com にアクセスする際、まずローカルで DNS 解決を行い、IP アドレスを取得してから接続を確立します。ここに根本的な矛盾があります。DNS 解決をローカル ISP の DNS サーバーで行うと、google.com の解決結果が DNS ハイジャックにより誤った IP を返す可能性があります。一方、プロキシ経由で DNS 解決しようとすると、DNS リクエストを転送するためにまず接続を確立する必要があり、鶏と卵の問題が生じます。
初期の解決策はプロキシサーバー側での DNS 解決（Remote DNS Resolution）でした。クライアントがドメイン名を直接プロキシサーバーに送り、プロキシサーバーがその環境内で解決して結果を返す方式です。これにより DNS ハイジャックの問題は解決されますが、レイテンシが増加し、GEOIP などの Clash の IP ベースのルールとも連携できません。
Fake-IP の動作メカニズム
Fake-IP は Clash が採用したよりエレガントな解決策です。その核心となる考え方は：アプリケーションが DNS リクエストを送信した際、Clash は実際の DNS 解決結果を待たず、あらかじめ予約された IP レンジ（デフォルト 198.18.0.0/16）から「仮想」IPをアプリケーションに即座に返すというものです。アプリケーションはこの仮想 IP を受け取り、すぐに接続リクエストを送信します。Clash がその接続を捕捉し、仮想 IP から対応するドメイン名を検索し、ルールに従って処理方法を決定します。
この方式のメリットは明確です。アプリケーションは DNS 解決の完了を待たずに接続を開始できるため、初回接続のレイテンシが大幅に低減します。実際の DNS 解決はバックグラウンドで非同期に行われ、プロキシ経由で送信されるため、DNS ハイジャックを完全に回避できます。また、すべての DNS リクエストが Clash によって一元管理されるため、ローカル DNS サーバーへのリクエスト漏洩が発生しないことから、DNS リークも防止できます。
DNS 完全設定例
dns:
enable: true
listen: 0.0.0.0:53
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
# Fake-IP を使用しないドメイン（実際の IP を直接返す）
fake-ip-filter:
- "*.lan"
- accounts.google.com
# ローカル DNS：直接接続ドメインの解決に使用。高速
nameserver:
- 1.1.1.1 # Cloudflare
- 8.8.8.8 # Google
# プロキシ経由 DNS：プロキシドメインの解決に使用。ハイジャック対策
fallback:
- https://8.8.8.8/dns-query # Google DoH
- https://1.1.1.1/dns-query # Cloudflare DoH
- tls://8.8.4.4:853 # Google DoT
# fallback を発動させる条件
fallback-filter:
geoip: true
geoip-code: JP
ipcidr:
- 240.0.0.0/4 # 予約アドレス。通常は DNS ハイジャックの結果nameserver と fallback の役割分担
nameserver はメイン DNS サーバーグループで、大部分の DNS リクエストを処理します。通常は高速なローカル DNS（Cloudflare の 1.1.1.1、Google の 8.8.8.8 など）を設定します。fallback はバックアップ DNS サーバーグループで、nameserver が返した結果が fallback-filter のルールによって疑わしいと判定された場合（プロキシ経由の IP が返された場合や予約アドレス範囲に該当する場合など）、Clash は fallback DNS を使って再クエリを実行し、fallback の結果を採用します。
fallback DNS には DoH（DNS over HTTPS）または DoT（DNS over TLS）プロトコルの使用を推奨します。これらのプロトコルは DNS リクエストを暗号化して送信するため、ネットワーク転送中に中間ノードによる改ざんができず、DNS ハイジャックの問題を根本的に解決できます。
fake-ip-filter：Fake-IP を使うべきでないドメイン
すべてのドメインに Fake-IP が適しているわけではありません。以下のカテゴリのドメインは fake-ip-filter の除外リストに追加し、Clash が実際の IP を直接返すようにする必要があります：
- LAN ドメイン：
*.local、*.lanなど。これらはローカルエリアネットワーク内で使用されるアドレスであり、Fake-IP を適用するとLAN デバイスの検出に支障をきたします - ゲームプラットフォーム関連ドメイン：一部のゲームクライアントは DNS 解決結果を検証するため、Fake-IP がアンチチートメカニズムを誤作動させる可能性があります
- NTP 時刻同期サービス：時刻同期は IP の正確性を要求するため、実際の IP を直接返す必要があります
- 特定アプリの認証ドメイン：accounts.google.com などの認証ドメインは Fake-IP を適用するとログインに失敗する場合があります
DNS リークの確認方法
設定完了後、dnsleaktest.com または bash.ws/dnsleak で DNS リーク検査を実施してください。検査結果にプロキシサーバーの所在地の DNS サーバーのみが表示されれば設定は正しく機能しています。ローカル ISP の DNS サーバーが表示された場合は DNS リークが発生しているため、DNS 設定を確認するか、TUN モードの DNS ハイジャック機能と組み合わせて解決してください。
