Clash DNS設定ガイド：仕組み・DNSリーク防止・ベストプラクティス

DNSがなぜ重要なのか

DNS（Domain Name System、ドメインネームシステム）はインターネットの「電話帳」とも言われ、example.com のような読みやすいドメイン名を、機械が識別できるIPアドレスに変換する役割を担っています。ブラウザでURLを入力したりアプリを開いたりする際、最初に行われるのはDNSクエリです。正しいIPアドレスを取得して初めて、TCPコネクションやHTTPSハンドシェイクが進められます。

Clashのようなプロキシツールでは、DNSは単なる「名前解決」に留まらず、ルーティング（分流）の判断に直接関わります。Clashのルールはドメイン名で照合（DOMAIN）、IPレンジで照合（IP-CIDR）、GeoIPで所属地域を判断（GEOIP）するものがあります。DNSが誤った結果を返すと、ルーティングチェーン全体が狂ってしまいます。

設定ミスは主に2つの問題を引き起こします：

• DNSリーク：本来プロキシ経由で解決すべきドメインが、ローカルやISPのDNSで解決されてしまい、アクセス意図の露出や、DNS汚染による不正なIPの取得、プロキシのバイパスにつながります。
• ルーティングエラー：IPベースのルール（GEOIP,PRIVATE,DIRECTなど）は正確な解決結果に依存します。プロキシが必要なドメインがローカルCDNノードに解決されると誤って直接接続になり、逆にローカルドメインが別のIPに解決されると無駄なプロキシ流量を消費します。

したがって、DNS設定はClashの高度な調整において避けて通れない要素です。その原理を理解すれば、「なぜあのサイトが突然直接接続になったのか」「なぜストリーミングが開けないのか」といった現象を説明できるようになります。以下では、汚染の原因・解決モード・実践設定まで、ClashのDNS活用法を体系的に解説します。

DNS汚染と暗号化DNS

暗号化されていないUDP/TCP DNSクエリでは、リクエストが平文で送信されるため、途中のネットワーク機器が返答を改ざんできます。これがいわゆるDNS汚染です。汚染されたドメインは誤ったIP（よく見られるのは0.0.0.0や特定のプレースホルダーアドレス）を返し、サイトへのアクセス失敗や誤ったサーバーへの接続を引き起こします。

汚染に対抗するため、ClashはDoH（DNS over HTTPS）やDoT（DNS over TLS）などの暗号化DNSプロトコルをサポートしています。暗号化によりクエリ内容の改ざんが困難になり、解決結果の信頼性が高まります。Clashのnameserverとfallbackの仕組みは、「プライマリDNSで高速解決 + 暗号化フォールバックで信頼性向上」という考え方で設計されています。

default-nameserverは、nameserverやfallbackで指定されたDoHドメイン自身を解決するために使われます（例：dns.googleのIPを解決するなど）。信頼できるUDP DNSを指定し、「卵が先か鶏が先か」問題を回避します。

Clashの2つの解決モード

redir-host

redir-hostモードでは、ClashはDNSサーバーに実際の名前解決を依頼し、本物のIPを取得した後にルールに基づいてプロキシ経由か直接接続かを決定します。ロジックは直感的でわかりやすく、GeoIPの判断に実際のIPが必要なシーンにも対応できます。

ただし欠点も明確です：プロキシ対象ドメインの解決時に汚染を受けやすく、誤ったIPを取得することがあります。また接続ごとにDNSの応答を待つ必要があるため、初回パケットの遅延が増加します。一部のアプリがDNS結果をキャッシュすることで、Clashのルーティング戦略と衝突する場合もあります。

fake-ip（推奨）

fake-ipモードでは、Clashは解決対象のドメインごとに予約アドレス範囲内の「偽のIP」を割り当てます（デフォルトは198.18.0.0/16。これはIANA予約アドレスで、公共インターネットの実IPとは衝突しません）。アプリがfake-ipで接続を確立しようとすると、Clashがローカルでその接続をインターセプトし、ドメインマッピングテーブルに基づいてプロキシ経由か直接接続かを決め、実際の接続を確立します。

メリットは：実際のDNS応答を待たずにアプリへの応答が速くなること、ドメイン情報がClash内部に保持されるためルーティングがより精確であること、ストリーミングやルール分流との互換性が高いこと、そして現在コミュニティで最も主流の選択肢であることです。

推奨設定テンプレート

以下は多くのユーザーに検証されたDNS設定テンプレートです。お使いのClash設定ファイルにそのまま追加できます（上流DNSはネットワーク環境に合わせて微調整してください）：

各フィールドの説明：

• nameserver：メインDNS。お住まいの地域に近い暗号化DNSサーバーを選ぶことで低遅延の解決が得られます。
• fallback：nameserverの結果が「信頼できない」と判断された場合（GeoIPが設定した地域と一致しないなど）に、fallbackで再解決します。暗号化DNSを使って信頼性を高めます。
• fallback-filter.geoip：GeoIPフィルタリングを有効にします。nameserverが返したIPの所在地がgeoip-code（あなたの国コードに変更してください。例：JP）と一致しない場合にfallbackをトリガーします。
• fake-ip-filter：fake-ipを使わないドメインを除外します。LAN向けの*.lanや、実IPが必要な一部のローカルサービスなどです。

よくある問題とトラブルシューティング

よく使うサイトが遅い、または開けない

fallbackが誤ってトリガーされ、ローカルドメインが別のDNSで解決されている可能性があります。fallback-filterの設定が正しいか確認するか、ローカルドメインのルールの前に直接接続のDOMAINルールを追加してください。またnameserver-policyで特定ドメインに専用DNSを指定することもできます。

ストリーミングで地域制限エラーが出る

一部のストリーミングサービスはDNSとIPの整合性を確認します。ストリーミング関連のドメインがプロキシ経由で処理され、DNS解決もプロキシ側で行われているか確認してください。必要に応じてNetflix、Disney+などのドメインを個別にルール設定してください。

LAN機器が相互アクセスできない

fake-ipはmDNSやBonjourなどのLAN検出プロトコルに影響することがあります。*.localや*.lanをfake-ip-filterに追加するか、該当ネットワークセグメントにredir-hostを使用してください。Chromecast、AirPlayなどのデバイスがある場合も、関連ドメインをフィルターに追加し、キャストや検出機能が正常に動作するようにすることをお勧めします。

IPv6についての注意

ネットワーク環境でIPv6が不要な場合は、ipv6: falseを維持することをお勧めします。一部のアプリがIPv6を優先することでルーティングに異常が生じることを防げます。IPv6を完全に有効化している場合は、trueに設定し、nameserver-policyでIPv6ドメイン専用の解決パスを設定して、v4/v6トラフィックが正しくルーティングされるようにしてください。

設定の動作を確認する

設定完了後、以下の手順で確認することをお勧めします：

1. DNSリーク検出サイト（dnsleaktest.comなど）にアクセスし、解決の出口が期待通りか確認します。プロキシ有効時にローカルISPのDNSが露出していないことを確かめてください。
2. よく使うサイトとプロキシ経由でアクセスするサイトをそれぞれテストし、前者が直接接続、後者がプロキシ経由で速度が正常であることを確認します。
3. Clashのダッシュボードまたはログで接続記録を確認し、ドメインとルールのマッチングが期待通りであることを確かめます。
4. プロキシをオフ・オンし、アプリが引き続き正常に名前解決できるか確認して、DNSキャッシュによる異常を排除します。

まとめ

適切なDNS設定は安定したプロキシ体験の基盤です。fake-ipモードと「プライマリ地域DNS + 暗号化フォールバック + GeoIPフィルタリング」の組み合わせを推奨します。これによりDNSリークと汚染を防ぎながら、良好なアクセス速度も維持できます。LAN機器や特殊なアプリに問題が発生した場合は、fake-ip-filterとnameserver-policyを活用して細かく調整してください。設定後は必ず実際にテストして確認し、実際のネットワーク環境に合わせて継続的に最適化してください。DNS設定を習得すれば、名前解決に関連する接続の問題のほとんどを独自に解決できるようになり、その後のルールベースルーティングやプロキシグループの調整の土台が固まります。