ClashのDNS設定に初めて触れると、少し混乱する人が多いです。内核には独自のDNSモジュールがあり、クライアント側でも「システムプロキシ」や「TUN」を選べる——結局どうやってドメインが解決されているのでしょうか。この記事は原理から説明し、dns セクションの設定を本当に理解できるようにします。
プロキシツールがDNSまで管理する理由
ドメイン解決がローカルのISPのDNSを経由すると、通信自体が最終的にはノードを経由して転送されても、解析結果がすでに汚染されていたり、不正確なIPが返されていたりする可能性があり、ルールの振り分けが誤った地域判定（例えば GEOIP,JP の誤判定）を引き起こすことがあります。そのためClashはDNSモジュールを内蔵し、解析処理を自ら制御下に置いて、「解析」と「転送」の両方を自分の管理範囲内に収めています。
2つの解決モード：redir-hostとfake-ip
DNSを設定する前に理解しておくべき重要な概念です。両者の核心的な違いは「クライアントが受け取るIPが本物かどうか」にあります。
| モード | 解決結果 | 適した場面 |
|---|---|---|
| redir-host | 実際のパブリックIP | 互換性が最も高く、一部アプリが実IPで検証する場面に対応 |
| fake-ip | 仮想のプライベートレンジIP | 解決が速く、DNSリークを回避できる現在の主流設定 |
fake-ip-filter に追加して除外してみてください。
DoH／DoTを導入してアップストリームの汚染を防ぐ
nameserver が平文のUDP DNS（8.8.8.8 など）のみを設定している場合、リクエスト自体が経路上で改ざんされたり、乗っ取られたりする可能性があります。暗号化DNS（DoH/DoT）はクエリをHTTPS/TLSでラップすることで、汚染される確率を大幅に下げます。
nameserver はデフォルトの解決グループで、fallback はデフォルトの解決結果が指定した地域外（fallback-filter で判定）にある場合にのみ使われる予備の解決グループで、通常は速度が速く汚染耐性の高い海外のDNSに設定します。
nameserver-policy：ドメインごとにDNSを指定
特定のドメインだけ特定のDNSを使わせたい場合（内部ドメインはローカルDNS、それ以外は暗号化DNSなど）は、nameserver-policy で個別に指定できます。
IPv4/IPv6デュアルスタック環境で気をつけること
ローカルネットワークがIPv4とIPv6を両方持っていて、ISPのIPv6出口品質があまり良くない場合、むしろ速度が落ちることがあります。ブラウザはHappy Eyeballs機構により両方のプロトコルを同時に試しますが、ClashはデフォルトではIPv6解決を特別扱いしないことがあります。ipv6 フィールドで、IPv6結果を解決・使用するかどうかを明示的に制御できます。
IPv6の出口品質が良好であれば、有効にしたまま fake-ip にIPv4/IPv6両方の結果をカバーさせてもかまいません。実際の速度テストを比較したうえで判断することをお勧めします。どこかの「万能設定」をそのままコピーするのは避けましょう。
DNSとローカルhostsの優先順位
自作サービスのテストや特定ドメインの一時的なブロックなど、システムのhostsファイルを直接編集したい場面もあるでしょう。注意すべきは、Clashがいったんdnsを制御下に置くと（dns.enable: true）、システムhostsのマッピングは内核に認識されない場合があることです。解決リクエストがシステムのresolverを経由しないことがあるためです。このような場合は、Clashの設定に hosts フィールドを直接追加するほうが、効果は同等でも適用範囲がより明確になります。
hosts は、通常の解決プロセスより優先度が高くなります。ローカル開発環境のドメインマッピングに向いており、システムレベルのhostsファイルを書き換える必要はありません。
クライアントごとのDNS設定画面の違い
GUIクライアントの多くは dns の設定を「基本」「詳細」の2段階に分けて表示します。基本モードでは「拡張モード」（enhanced-mode に対応）のドロップダウンのみが表示され、詳細モードで nameserver や fallback などの具体的なフィールドが表示されます。UI上で該当フィールドが見つからない場合でも、設定ファイルを直接編集（あるいは「設定」内の生YAML編集欄）すれば追加できます。クライアントはUIに表示していない項目も、読み込み時には無視しません。
名前解決異常のトラブルシューティング
- まずDNSモジュールが有効か確認：
dns.enableがfalseの場合、Clashは解決を制御せず、システムに任せます。 - 誤ったルールにマッチしていないか確認：一部のドメインルールが
DIRECTより前に書かれていて、本来プロキシ経由にすべきドメインが直接解決されてしまうケースがあります。 - fake-ipの衝突を疑う：内部機器、LANプリンター、ゲーム機の検出異常が出た場合は、該当ドメインを
fake-ip-filterに追加してみましょう。 - 外部ツールで相互検証する：プロキシのオン・オフそれぞれの状態で
nslookupやオンラインのDNS検査ツールを実行し、解決結果の差異を比較します。
モバイル端末だけ個別に調整が必要か
スマートフォンはWiFiとモバイル通信を頻繁に切り替えるため、DNSキャッシュの挙動がデスクトップよりも「敏感」になりがちです。ネットワークを切り替えた後にあるサイトが切り替え前の結果のまま解決される場合、多くは設定の問題ではなく、システムやクライアント自体が前回の解決結果をキャッシュしているだけです。キャッシュが期限切れになるか、プロキシサービスを手動で再起動すれば解決します。モバイルアプリの一部は省電力のためバックグラウンドの再接続頻度を制限しているので、長時間サスペンド後に解決異常が出た場合は、クライアントを完全に終了して再起動するのも試してみましょう。
TUNモードでのDNSの挙動の違い
TUNモードを有効にすると、システムレベルのすべての通信（DNSクエリも含む）が仮想ネットワークアダプタを経由するようになり、理論上は従来のシステムプロキシ方式よりも広い範囲をカバーできます。システムプロキシ設定に従わないアプリ（独自のDNS解決ライブラリを使っているものなど）も捕捉できます。ただしこれは、DNS設定を誤った場合の影響範囲も大きくなることを意味します。そのため、まずシステムプロキシモードで dns の設定を安定させてから、TUNモードに切り替えて効果を確認することをお勧めします。最初からTUNモードで試行錯誤するのは避けましょう。
まとめ
通常使用では fake-ip ＋暗号化DNSアップストリームだけでほとんどの場面をカバーできます。内部ネットワークの発見や特定プロトコルの異常に遭遇したときだけ、fake-ip-filter や nameserver-policy を細かく調整すれば十分です。この仕組みを理解しておけば、「速度テストは通るのにページが開かない」といった問題も、自分で切り分けて解決できるようになります。