Clash DNS 設定詳解:汚染と漏洩を解決する
fake-ip と redir-host にはどんな違いがある?nameserver をどう設定すれば DNS 汚染を防ぎ、DNS 漏洩を避けられる?本記事では DNS モジュールの原理と実践的な設定を一気に解説します。
DNS 設定がなぜそれほど重要なのか
多くの人は Clash をインストールしてサブスクリプションをインポートすれば万事解決したと思ってしまいますが、実際には一部のサイトが開けない、プロキシを通しているはずなのに国内 IP だと認識される、逆に国内サイトが海外にルーティングされてしまう、といった問題に遭遇します。これらの問題の大半はDNS の段階で発生しており、プロキシノード自体の問題ではありません。
ブラウザがある URL にアクセスする前には、まずドメイン名を IP アドレスに解決する必要があり、このプロセスが DNS クエリです。このステップで通信事業者に「手を加えられて」しまうと、後段のプロキシをどう設定しても意味がありません——デバイスは最初から間違った IP を受け取ってしまうからです。よくある「手を加える」方法は次の2つです:
-
DNS 汚染通信事業者や中間機器が DNS レスポンスを偽造し、間違った IP へ誘導します(例えばアクセスできないアドレスを返したり、広告ページへリダイレクトしたりします)。
-
DNS 漏洩通信がプロキシを通っていても、DNS クエリ自体は依然として現地の通信事業者へ直接送信され、どのサイトにアクセスしたかが完全に記録されてしまい、プロキシが無意味になります。
判定方法は簡単です。dnsleaktest.com を開いてテストし、表示される DNS サーバーの帰属地がノードの所在地ではなく現地の通信事業者になっていれば、DNS 漏洩が発生しています。
3種類の DNS 解決モードを比較
Clash の DNS モジュールはいくつかの異なる動作モードに対応しており、それぞれの違いを理解することが DNS を適切に設定する鍵となります。
最も初期のモードです。Clash は上流の DNS サーバーに直接実際の IP を問い合わせ、その後ルールに基づいてプロキシか直接接続かを決定します。メリットはシンプルで直感的なことですが、デメリットはドメインベースのルーティングが失敗する可能性があることです——実際の IP を取得した後、その IP 帯がどのルールにもマッチしない場合、直接接続に失敗する可能性があり、また IP 帯ルール(GEOIP など)への対応精度も十分ではありません。
Clash は実際の IP を直接返すのではなく、まず仮想のプライベート IP(例:198.18.0.1)をクライアントに割り当てます。実際に接続を確立する際に、Clash はドメイン名でルールマッチングを行い、プロキシか直接接続かを決定し、その時点で初めて本当の上流に IP を問い合わせます。この「先にルーティング、後で解決」という方式によりドメインベースのルールが常に確実に優先して適用されるため、現在最も推奨されているモードです。
fake-ip モードでは、ドメインルール(DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD)が100%マッチします。これはルーティングの判定が実際の IP が現れる前に行われるためです。これが多くのサブスクリプションでこのモードがデフォルトで使われている理由でもあります。
一部のアプリケーション(LAN デバイスの検出機能や社内システムの一部など)は仮想 IP を使用できず、実際の IP を取得しないと正常に動作しません。この場合は fake-ip-filter を使ってこれらのドメインを仮想 IP 割り当ての対象外にし、常に実際の解決を行わせることができます。
# DNS モジュールの中核設定 dns: enable: true ipv6: false enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 fake-ip-filter: - '*.lan' - '*.local' - '+.market.xiaomi.com' nameserver: - 223.5.5.5 # Alibaba DNS、国内ドメイン用 - 119.29.29.29 # Tencent DNS、同上 fallback: - tls://8.8.4.4:853 # DoT、海外ドメイン用 - tls://1.1.1.1:853 fallback-filter: geoip: true geoip-code: CN
nameserver と fallback はどう選ぶべきか
ここは初心者が最もつまずきやすいポイントです。nameserver と fallback はどちらも「上流 DNS サーバーのリスト」ですが、役割は全く異なります:
- nameserver:デフォルトで優先的に使用されるサーバーで、一般的には国内の通信事業者から正常にアクセスできる高速な DNS(Alibaba の 223.5.5.5、Tencent の 119.29.29.29、114 DNS など)を指定します。
- fallback:
fallback-filterがあるクエリ結果を「国内アドレスらしくない」と判定した場合、こちらのサーバーに切り替えて再クエリを行います。一般的には汚染を避けるために DoH/DoT による暗号化 DNS(Google、Cloudflare など)を指定します。
fallback-filter.geoip: true と組み合わせることで、Clash はまず nameserver で問い合わせを行い、解決された IP が geoip-code で指定された国・地域(例えば CN)に含まれていない場合、自動的に fallback に切り替えて再度問い合わせを行います。これにより「国内ドメインは国内 DNS、海外ドメインは暗号化 DNS」という自動ルーティングが実現でき、ドメインリストを手動でメンテナンスする必要がありません。
お使いのマシンにそもそも海外への直接接続能力がない場合(例えば社内ネットワークが強制的にプロキシゲートウェイを経由する場合)、fallback 内の DoT/DoH リクエストも Clash 自身のプロキシで転送できるようにする必要があります。そうしないとクエリがタイムアウトします。多くのクライアントではデフォルトでこの点は処理済みですが、解決異常が発生した場合はクライアント設定内で「DNS もプロキシを経由する」オプションが有効になっているか確認してください。
検証とよくある問題のトラブルシューティング
-
nslookup / dig テストターミナルで
nslookup google.comを実行し、返ってきたアドレスが198.18.x.x帯であれば fake-ip が有効になっていることを示します(これは正常な現象で、故障ではありません)。 -
DNS 漏洩テストdnsleaktest.com にアクセスして拡張テストを行い、表示される DNS サーバーのアドレスがプロキシノードの所在地と一致していることを確認します(現地の通信事業者ではないこと)。
-
コントロールパネルのログコントロールパネルの「ログ」ページでレベルを debug に切り替えると、サイトに正常にアクセスした際の DNS クエリとルールマッチングの詳細なプロセスが確認でき、どのルールがマッチしたかを特定しやすくなります。
nslookup で調べた IP が 198.18 から始まっているのに、なぜウェブページは正常に開けるのですか?
これはまさに fake-ip モードの動作方式です——198.18.0.0/16 は専用に予約された仮想アドレス帯で、Clash 内部でドメイン名を識別するためだけに使用されます。実際のネットワークリクエストは接続確立時に Clash によって捕捉され、本当のノードへ転送されるため、通常のアクセスには影響しません。
一部の内部デバイス/LAN の NAS に突然接続できなくなりましたが、DNS の問題でしょうか?
仮想 IP 帯が内部デバイスの検出機構と衝突している可能性が高いです。対象のドメイン(*.lan やルーター管理用ドメインなど)を fake-ip-filter に追加し、実際の解決を行わせれば解決します。
DNS 設定を変更したらクライアントを再起動する必要がありますか?
多くのクライアントは設定のホットリロードに対応しています(「設定を再読み込み」をクリックするだけです)。ケースによっては、キャッシュされた DNS レコードがまだ期限切れになっておらず、反映に一時的な遅延が生じる場合があります。その場合はクライアントを再起動するか、システムの DNS キャッシュをクリアすれば完全に更新されます。
さらに詳しく
学び終えたら、Clash をインストールして試してみましょう
全プラットフォームのインストーラーを1か所で入手できます。おすすめタグに沿って選べば間違いなく、数分で使い始められます。