この記事は Clash 公式サイト が編集・監修しました。Clash と Mihomo のルールベース振り分けシステムにおいて、DNS はもっとも見落とされやすく、かつ「一部のサイトが開かない」「名前解決が遅い」「ルールが適用されない」といった問題を引き起こしやすいコンポーネントです。ノードやポリシーグループをいくら丁寧に整えても、DNS が誤った IP を返したり不適切な解決経路を通ったりすると、振り分けルールが正しく機能しません。本記事では原理から実践まで、Clash DNS モジュールの設定方法を体系的に解説し、安定・高速・スプーフィング耐性のある名前解決チェーンの構築をサポートします。
Clash に独自の DNS 設定が必要な理由
OS のデフォルト DNS はルーターやプロバイダーから配布されることが多く、解決結果がハイジャック・キャッシュ汚染・クロスボーダー遅延の影響を受けることがあります。Clash はローカルプロキシコアとして、トラフィックがルールマッチングに入る前に、対象ドメインに対応する実 IP または仮想 IP を把握しておく必要があります。これにより DOMAIN や GEOSITE などのルールが正確に機能します。
DNS とプロキシチェーンが切り離されると、ローカルサイトが誤ってプロキシ経由になる、リモートサイトへの直接接続が失敗する、TLS ハンドシェイクエラーが発生する、ブラウザが「名前解決中」のまま長時間止まるといった症状がよく見られます。そのため、高度な設定では DNS モジュールを独立して計画することが、全体的な体験を安定させる重要なステップとなります。
DNS モジュールは振り分けルールの「上流インテリジェンスシステム」と考えると分かりやすいでしょう。情報が間違えば、どれだけ優れたポリシーグループも機能しません。
fake-ip と redir-host：2 つのコアモード
Mihomo / Clash Meta コアは 2 種類の拡張 DNS モードをサポートしています。両者の違いを理解することが正確な設定の前提です。
fake-ip モード
各ドメインに仮想 IP（通常は 198.18.0.0/15 の範囲）を割り当て、アプリがその IP へ接続しようとするとコアがドメイン情報からリアルターゲットを復元してルールを適用します。DNS リークを防止し、名前解決の待機時間を短縮し、TUN モードの互換性を高めるというメリットがあります。一方、実際の IP に依存するアプリ（LAN デバイスの検出、一部のゲームなど）で問題が生じる場合があります。
redir-host モード
DNS クエリが実 IP を返し、コアがその IP をもとに GEOIP などのルールと照合します。従来のプロキシに近い動作で互換性は高いものの、上流 DNS が DNS スプーフィングを受けると誤った IP を取得してルールの適用が期待どおりにならない場合があります。安定動作には信頼できるリモート DNS と dns-hijack の併用が推奨されます。
| 比較項目 | fake-ip | redir-host |
|---|---|---|
| 返却アドレス | 仮想 IP | 実 IP |
| DNS リーク防止 | 比較的強い | 追加設定が必要 |
| TUN 互換性 | 優秀 | 良好 |
| 特殊アプリ互換 | まれに問題あり | 通常は良好 |
DNS 振り分け：ローカルとリモートで異なる解決経路を使う
効率的な設定では、ローカルドメインとリモートドメインを異なる DNS サーバーで処理します。ローカルドメインには信頼できるパブリック DNS（例：223.5.5.5。Cloudflare の 1.1.1.1 や Google の 8.8.8.8 も利用可能）を使用して近くで正確な解決を行います。リモートドメインはプロキシトンネル経由でリモート DNS（例：tls://8.8.8.8:853 やプロキシサービスが提供する DNS）に問い合わせ、DNS スプーフィングを回避してより適切なルーティングを確保します。
設定ファイルでは nameserver-policy を使って特定ドメインや後缀に対して解決サーバーを指定できます。例えば geosite:cn をローカル DNS に向け、geosite:geolocation-!cn をプロキシ DNS に向けます。fallback と fallback-filter を組み合わせることで、メイン DNS がスプーフィングされた疑いのある IP を返したときに自動でバックアップ解決に切り替えるスプーフィング対策が実現します。
推奨設定方針
- TUN ユーザーは
enhanced-mode: fake-ipを優先し、用途に応じて redir-host を選択してください。 nameserverには信頼できる DNS を、fallbackにはプロキシ経由で到達するリモート DNS を指定します。nameserver-policyで振り分けを細分化し、すべてのクエリがリモート DNS 経由になることによるローカルアクセス低下を防ぎます。fake-ip-filterに LAN ドメイン・NTP・一部のローカルサービスドメインを追加して、仮想 IP がローカル業務を妨げないようにします。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://223.5.5.5/dns-query
fallback:
- tls://8.8.8.8:853
nameserver-policy:
"geosite:cn": [https://223.5.5.5/dns-query]
"geosite:geolocation-!cn": [tls://8.8.8.8:853]よくある問題とトラブルシューティング
プロキシを有効にするとローカルサイトが遅くなる：すべての DNS クエリが fallback を経由していないか確認してください。nameserver-policy でローカルドメインをローカル DNS に向けるべきです。
一部のアプリが接続できない：関連ドメインを fake-ip-filter に追加するか、redir-host に切り替えてテストしてみてください。
DOMAIN ルールを書いたのに適用されない：DNS モジュールが有効になっていること、名前解決フェーズで誤った IP による干渉がないことを確認し、ログで実際にマッチした対象アドレスを確認してください。
解決タイムアウト：リモート DNS にプロキシ経由の出口が必要かどうか確認してください。対応する DNS クエリトラフィックがプロキシノードに到達できるようにし、https または tls タイプの DNS に切り替えることで安定性が向上します。
まとめ
Clash DNS の設定は一度作ったテンプレートをそのまま使い回すものではなく、クライアントモード（システムプロキシ / TUN）、プロキシサービスの回線品質、よく使うアプリケーションに合わせて調整することが重要です。fake-ip は効率と DNS リーク防止を重視するユーザーに、redir-host は最大互換性が必要な環境に適しています。どちらのモードを選んでも、ローカル・リモートの DNS 振り分け＋信頼できる fallback は安定した振り分けシステムを構築するための基盤です。
クライアントとコアプログラムの入手は公式ダウンロードページをご覧ください。初回設定はサブスクリプションのインポートとルールモードの設定のためにセットアップガイドも合わせてご参照ください。
関連記事