「ルールの記述は正しいはずなのに、サイトが開かない」という問題を調査していくと、最終的に原因がDNSにあったというケースは少なくありません。ルールがどれだけ正確でも、ドメインの解決先IPそのものが間違っていれば、その後の振り分けロジックはそもそも成立しません。本記事ではDNS汚染とDNSリークがそれぞれどのような問題なのか、そしてClash側での対応方法を解説します。
01DNS汚染とは
DNS汚染とは、あるドメインのIPアドレスを問い合わせた際に、経路上の中間装置が「先回りして」誤った、あるいはブロックされたIPを返してしまい、そのドメインが実際に指しているサーバーのアドレスが得られない現象です。結果として、プロキシルールの判定自体は正しくても、取得したIPそのものが誤っているため、接続が失敗するか、意図しないページにリダイレクトされてしまいます。
解決方法：信頼できる上流DNSを使用する
config.yaml で暗号化されたDNSサーバー（DoH/DoT）を設定することで、通常のUDP DNS問い合わせに対する中間装置の干渉を回避できます：
dns:
enable: true
nameserver:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-query02DNSリークとは
DNSリークとは、通信自体はプロキシノードを経由しているのに、DNSの問い合わせだけはプロキシを迂回して直接ローカルのネットワーク環境で行われてしまう現象です。この場合、あなたが実際にどのドメインへアクセスしたかは通信事業者から見えてしまいます。プロキシが保護しているのはその後のデータ通信だけで、「何にアクセスしたか」という情報自体は保護されていません。
解決方法：fake-ipモードを有効にする
fake-ipモードはClashコアがDNS解析プロセス全体を引き継ぐ仕組みです。アプリがドメインを問い合わせると、Clashはまず架空のローカルIPを返し、実際に接続が発生する段になってからルールに基づいて本当の解析方法と出口を決定します。これによりDNS問い合わせ自体もClashの統一処理フローに組み込まれ、プロキシを迂回してローカルネットワークに直接漏れることがなくなります。
dns:
enable: true
mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"03nameserver-policy：ドメインごとにDNS問い合わせを振り分ける
特定のドメインを特定のDNSサーバーで解決させたい場合（例えば中国本土向けドメインは中国本土のDNSでより速いCDNノードを得る、それ以外のドメインは海外のDNSで汚染を避ける、など）、nameserver-policy を使ってドメインルールごとに指定できます：
dns:
enable: true
nameserver-policy:
"geosite:cn": ["223.5.5.5", "119.29.29.29"]
nameserver:
- https://1.1.1.1/dns-query上記の例では、geosite:cn（中国本土のドメイン分類ルール）にマッチした問い合わせは中国本土のDNSで解決され、それ以外はデフォルトの nameserver リストを使用します。
04よく使うフィールド一覧
| フィールド | 役割 |
|---|---|
| enable | Clash内蔵のDNSサーバーが解析プロセスを引き継ぐかどうか。通常はtrueに設定します。 |
| mode | 解析モード：fake-ip（推奨、リーク防止）または redir-host（互換性は高いがリーク防止効果は弱め）。 |
| nameserver | デフォルトで使用する上流DNSサーバーのリスト。DoH/DoTなど暗号化された問い合わせを推奨。 |
| nameserver-policy | ドメインルールごとに専用のDNSサーバーを指定。デフォルトのnameserverより優先される。 |
| fake-ip-filter | 架空のIPでの解析に適さないドメインのリスト。 |
05DNS設定が正しく機能しているか確認する方法
設定変更後は感覚で判断せず、いくつかの簡単な方法で実際に期待通り動作しているか確認しましょう：
- クライアントの接続ログを見る：多くのクライアントは「ログ」や「接続」パネルで各リクエストが実際に解決されたアドレスを表示します。fake-ipを有効にしている場合、ドメインが 198.18.x.x 帯の架空アドレスに解決されていれば、fake-ipが正しく機能しています。
- オンラインツールでDNSリークを検査する：プロキシを有効にした状態でDNSリーク検査サイトにアクセスし、表示されるDNSサーバーの所属地域が実際の居住地域や通信事業者と一致していれば、問い合わせがプロキシを経由していない、つまりリークが発生している可能性があります。fake-ip や nameserver-policy の設定を再確認してください。
- 異なる地域のドメインの解決結果を比較する：直接接続すべきサイトとプロキシ経由にすべきサイトのそれぞれにアクセスし、実際の出口ノードが想定通りかを確認します。想定と異なる場合、多くは nameserver-policy のドメイン分類ルールがそのドメインをカバーしていないことが原因なので、対応する geosite ルールを追加する必要があります。
多くのサブスクリプションには、そのまま使えるDNS設定が既に含まれているため、一般ユーザーがゼロから手書きする必要はありません。ただ、「ルールは正しいのに接続できない」「DNSの層でプライバシーが漏れていないか心配」といった状況に遭遇した場合、この部分の設定を見直すことで原因を特定できることが多いです。