Clash DNS設定を徹底解説：汚染と漏洩への対策

Clashクライアントを導入したのに、相変わらずページが開かないというケースはよくあります。原因を調べてみると、ノード（サーバー）側ではなくDNSにあることが少なくありません——ドメイン名がそもそも間違ったIPに解決されてしまっていれば、プロキシの設定がどれだけ完璧でも意味がありません。この記事では、ClashクライアントのDNSモジュールをどう設定すればよいかを整理し、「汚染」と「漏洩」という2つの落とし穴を一気に解消します。

なぜDNSに特別な対応が必要なのか

通常のネット接続では、ブラウザはまずDNSサーバーに「このドメイン名のIPは何か」を問い合わせ、そのIPに対して接続を確立します。トラブルが起きやすいのは次の2つの場面です。

DNS汚染：ISPのDNSで一部のドメインを問い合わせた際に、偽のIPアドレスが返されるケースです。接続は当然失敗するか、タイムアウトしてしまいます。
DNS漏洩：通信そのものはプロキシを経由していても、DNSの問い合わせだけはローカルから平文で送られてしまい、どのサイトにアクセスしたかがそのまま外部に漏れてしまう状態です。

そのためClashクライアントにはDNSモジュールが内蔵されています。有効にすると、デバイス上のすべてのDNSクエリはまずClashクライアントを経由し、どのサーバーで解決するか、プロキシ経由で問い合わせるかをClashクライアントが判断します。

fake-ipとredir-hostの違い

enhanced-modeには2つの値があり、システムからのDNSクエリにどう応答するかを決定します。

モード	動作方式	メリット・デメリット
`fake-ip`	予約アドレス帯の偽IP（198.18.x.x）をすぐに返し、実際の解決は接続確立のタイミングまで遅らせる	応答が速く漏洩もない。実IPを検証する一部のアプリ（一部のゲームやネットバンキングなど）では相性が悪い場合がある
`redir-host`	律直に実際のIPを解決してから返す	互換性は最も高いが、解決結果が汚染される可能性があり、ルールマッチのタイミングも遅くなる

結論：通常はfake-ipを優先しましょう。相性が悪いアプリに遭遇したら、fake-ip-filterでそのアプリだけを除外すればよく、全体をredir-hostに戻す必要はありません。

fake-ip-filter の例

dns:
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "+.stun.*.*"
    - "+.battle.net"       # game launchers often need real IP
    - "time.windows.com"

nameserverとfallbackの役割分担

DNS設定全体の中で、最も間違えやすいのがこの部分です。正しい考え方は次のとおりです。

nameserver：メインの解決グループ。応答が速く信頼できる汎用DNS（Cloudflareの1.1.1.1やGoogleの8.8.8.8など）を指定し、通常のドメイン名解決を高速かつ正確に行います。
fallback：バックアップの解決グループ。暗号化DNS（DoH/DoT）を指定し、改ざん・汚染の疑いがあるドメインの解決を専門に担当します。

この2つのグループは同時に問い合わせを行います。解決結果がfallback-filterの条件に合致した場合（たとえば解決されたIPが自国のIP帯に含まれないなど）、Clashクライアントはfallback側の結果を採用し、汚染を回避します。

おすすめの完全なDNS設定

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1                         # Cloudflare
    - 8.8.8.8                         # Google
  fallback:
    - https://dns.quad9.net/dns-query   # Quad9 DoH（プライバシー重視）
    - https://dns.google/dns-query      # Google DoH
  fallback-filter:
    geoip: true
    geoip-code: JP
    ipcidr:
      - 240.0.0.0/4                   # 汚染で返される偽IP帯

この設定の効果は次のとおりです。通常のドメインはCloudflare/GoogleのDNSで即座に解決され、解決結果に疑わしい点があれば自動的に暗号化DNSの結果に切り替わります。汚染を防ぎつつ、クエリが平文で漏れることもありません。

設定が有効になっているかを確認する方法

コントロールパネルの「ログ」ページを開き、レベルをdebugに設定すると、各DNSクエリがどのサーバーで処理されたかを確認できます。
dnsleaktest.comにアクセスして漏洩テストを行います。表示されるDNSサーバーは、fallbackに設定したもの（またはノード側のDNS）であるべきで、ローカルのISPのDNSであってはいけません。
nslookupで汚染されやすいことが知られているドメインを問い合わせ、198.18から始まる偽IPが返ってくれば、fake-ipが正常に機能している証拠です。

よくあるつまずきポイント DNS設定を変更したら、設定の再読み込みとブラウザのDNSキャッシュのクリア（Chromeのアドレスバーで chrome://net-internals/#dns と入力）を忘れずに行いましょう。Android版では、VPN接続を一度再起動しないと設定が完全に反映されないことがあります。

ルーターで全体プロキシを運用する際の注意点

Clashクライアントをルーターやnasで動かし、家中のデバイスをまとめて透過プロキシにする場合、DNS設定の重要性はさらに一段上がります。この構成では「各デバイスが自分で解決する」という逃げ道がなく、すべてのデバイスのドメイン名解決がClashクライアントを経由することになるからです。このようなケースでは、次の2点に注意しましょう。

listenをLAN側のネットワークインターフェースにバインドする：デフォルトでは127.0.0.1のみをリスニングしているため、他のデバイスからのDNSリクエストはそもそも届きません。0.0.0.0:53に変更し、ルーターのDHCP設定でゲートウェイをDNSサーバーとしても指定しましょう。
スマートTVやゲーム機は個別にホワイトリスト登録する：この種のデバイスはネットワーク接続時の検証ロジックが厳格な場合が多く、DNSの結果が想定する地域と食い違うだけで接続できなくなることがあります。そうした場合は家全体のfake-ipを無効にするのではなく、まずfake-ip-filterに該当ドメインを追加してみましょう。

もう一つ触れておくと、手軽さから8.8.8.8だけをメインDNSに設定する人もよく見かけます。しかし、Google DNSへの応答自体が回線状況によって遅延したりタイムアウトしたりすることもあり、メインの解決に使うとむしろ遅くなる場合があります。先ほどの役割分担の原則を思い出しましょう——nameserverには応答が速い汎用DNSを、fallbackには暗号化DNSを使うのが基本です。

よくある2つの誤解

最後に、初心者がよく持ってしまう誤解を2つ整理して、無駄な回り道を防ぎましょう。

「fake-ipを有効にすると本当のIPが二度と見えなくなる」——そうではありません。fake-ipはシステムから見えるIPを仮のアドレスに置き換えているだけで、Clashクライアントは接続確立時に内部で実際の解決を行っています。ログや接続一覧では引き続き実際の宛先IPを確認できるため、トラブルシューティングに影響はありません。
「DNS設定は複雑にするほど安全になる」——実際は逆です。nameserverとfallbackはそれぞれ2〜3個で十分で、サーバーを増やしすぎると初回クエリの応答時間が伸びるだけです（並行問い合わせの結果を待つ必要があるため）。シンプルで明確な設定の方が、盛りすぎた設定よりもずっと実用的です。

このDNS設定をconfig.yamlに反映して再読み込みすれば、汚染と漏洩という2つの厄介な問題とはひとまずお別れできるはずです。

ルール分岐との連携：DNSも判断に関わる

ルールセットでGEOIP判定を使っている場合、DNSの解決結果はルール分岐の精度に直結します。IPの解決を誤れば、GEOIPも当然その国を誤判定してしまい、結果として国内向けのサイトがプロキシ経由になってしまったり、本来プロキシすべきサイトが直接接続になってしまったりします。これが「まずDNSを整えてから、ルールのチューニングに進む」という順序を強調する理由です——土台が整っていなければ、上に載せるルールをどれだけ精密に書いても意味がありません。「あるサイトの振り分け結果が想定と違う」と感じたら、ルールを直す前に、まずDNSの解決自体がずれていないかを疑ってみることをおすすめします。

まとめ

この記事で伝えたいことは実はシンプルです——行くべきドメインを、行くべき経路に通し、DNSに足を引っ張らせないこと。要点をおさらいすると、通常はfake-ipを優先し、相性の悪いアプリはフィルターで除外する（全体を戻すのではない）。nameserverは通常のドメインを、fallbackは汚染の疑いがあるドメインを担当し、両者の役割は明確に分かれていて重複しません。設定を変更したら、キャッシュのクリア・再読み込み・動作確認の3ステップを踏んで、初めて本当に反映されたと言えます。この原則を覚えておけば、デバイスやクライアントを変えても、毎回ゼロから調べ直す必要はなく、すぐに安定したDNS設定を組めるようになります。

Clashクライアントを使い始めたばかりの方は、まずこの記事の完全な設定例をそのまま使ってみて、しばらく問題なく動くことを確認してから、自分のネットワーク環境に合わせてnameserverとfallbackの具体的なサーバーを微調整するのがおすすめです。最初から完璧を求めるより、まず動かしてから最適化していく方が結果的に近道です。