上級機能 読了目安 9 分

Clash DNS 設定と漏洩防止の実践ガイド

fake-ip モードと redir-host モードの違いと選び方、上流 DNS サーバーの選定基準、そして DNS リクエストがプロキシを迂回して漏洩していないかを検証する実用的な方法を解説します。

プロキシ経路における DNS 解決の位置づけ

プロキシソフト自体は確立済みのネットワーク接続だけを処理しますが、ドメイン名の解決は接続確立より前に発生します。DNS リクエストがシステム標準のリゾルバではなく Clash 内蔵の DNS モジュールを通らない場合、2つの問題が生じます。1つは、端末の DNS リクエストがそのまま通信事業者やローカルネットワークの解決サーバーへ送られ、どのドメインにアクセスしたかが露出してしまう「DNS リーク」です。もう1つは、ルールエンジンの DOMAIN や DOMAIN-SUFFIX といったドメイン系ルールが正しくマッチしなくなる問題です。クライアントが受け取る IP とルールが想定しているドメインの対応関係が一致しないため、振り分けが誤動作します。

Clash と Clash Meta（mihomo コア）はいずれも独立した dns 設定ブロックを提供し、クライアントのドメイン解決フローを乗っ取ることで、システムの hosts やシステムネットワーク設定に登録された DNS への依存をなくします。このモジュールの主要な設定項目は enhanced-mode（解決モード）、nameserver（上流 DNS）、fallback（バックアップ DNS）、そして fake-ip 関連のフィルタルールを有効にするかどうかです。これらの項目の役割を理解することが、振り分け異常や DNS リークの調査の前提になります。

補足：dns.enable が有効で、かつクライアントがシステムプロキシまたは TUN モードで通信を乗っ取っている状態でのみ、DNS モジュールは実際にリクエストを横取りできます。DNS 設定だけを有効にしてシステムプロキシを乗っ取らない場合、効果は限定的です。

fake-ip と redir-host、2つのモードの選び方

Clash の enhanced-mode は2つの値をサポートしており、動作原理と適用場面が大きく異なります。モードの選択を誤ることが、振り分け異常やアクセス失敗の多くの原因になっています。

fake-ip モード

クライアントが特定のドメインを問い合わせると、DNS モジュールは実際にこのドメインを解決するのではなく、あらかじめ確保されたアドレス帯（例：198.18.0.1/16）から仮の IP を割り当ててシステムに返します。アプリケーションはこの仮 IP で接続を開始し、Clash は TCP/UDP 接続確立時にこの仮 IP から元のドメイン名を逆引きし、ルールエンジンに渡してどの経路を使うか判断します。本当のドメイン解決はこの段階で初めて発生します。この方式の利点は、上流 DNS へ実際のアクセス記録を漏らさないことと、ルールエンジンが解決後の IP ではなく元のドメインを受け取るためマッチング精度が高いことです。欠点は仮 IP からドメインへのマッピングテーブルに依存する点で、クライアント IP を厳密に検証する一部のサービス、LAN 内デバイス検出プロトコル、実際の解決結果を必要とする一部の場面（例えばマルチスレッド速度測定を行う一部のダウンロードソフト）で異常が出ることがあります。こうしたドメインは fake-ip-filter で仮 IP の対象から除外し、実際の解決結果を使うようにする必要があります。

redir-host モード

このモードでは、DNS モジュールが設定された上流サーバーを使ってドメインを実際の IP に解決し、そのままシステムに返します。クライアントが受け取るのは実際のアドレスです。歴史的には、初期の透過プロキシ（iptables REDIRECT、TPROXY）と組み合わせて使われてきました。透過プロキシは IP 接続を横取りするだけでドメインを認識できないため、プロキシサーバー側で Host ヘッダーや SNI から対象ドメインを復元してルールにマッチさせる必要があったのです。このモードの限界も明白で、実際の解決結果は Clash に設定した上流 DNS を経由するため、上流の選択が不適切だと解決された IP が実際に近い最適なノードと一致しない場合があり、CDN のマルチルート型サービスには不向きです。また、クライアントが直接実際の IP を受け取るため、IP セグメントに基づく検出手法にプロキシの痕跡を見つけられやすくなります。

総合的に見ると、現在の主流の方法は基本的に fake-ip を優先し、本当に実際の IP が必要な少数の場面だけ fake-ip-filter で局所的に例外扱いにすることです。全体を redir-host に切り替える必要はほとんどありません。redir-host はドメイン嗅知能力を持たない古い透過プロキシ環境向けで、一般利用者が TUN モードやシステムプロキシモードを使う場合はほとんど使う必要がありません。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - 'time.*.com'
    - 'ntp.*.com'

上流 DNS サーバーの選定基準

nameserver フィールドは最終的にどのサーバーでドメインを解決するかを決め、fallback フィールドはバックアップの解決元として、通常 fallback-filter の地理的位置判定と組み合わせて使われます。上流 DNS を選ぶ際は、以下の原則を参考にできます。

  • 暗号化に対応したプロトコルを優先する。平文の UDP 53 番ポートによる問い合わせは中間のネットワーク機器に観察・改ざんされやすいため、条件が許すなら DoH（DNS over HTTPS）や DoT（DNS over TLS）を設定しましょう。形式はそれぞれ https://ドメイン/dns-query と tls://ドメイン:853 です。
  • 日本国内向けと海外向けの解決経路を分ける。日本国内のサイトへのアクセスは国内のパブリック DNS を使うことで解決速度と CDN の最適経路効果を確保し、海外サイトへのアクセスは海外または暗号化 DNS を使い、国内向け DNS の解決結果が不適切なノードを指し示す事態を避けます。この振り分けは通常 nameserver-policy でドメインのサフィックスごとに行うか、fallback-filter.geoip で解決結果が国内 IP セグメントに属するかどうかを判定して採用を決めます。
  • プロキシノードの所在地域と解決サーバーの地域が大きくずれた組み合わせを避ける。すべてのドメインを一律で海外 DNS 解決に流すと、日本国内のサイトが不利なノードに解決されてしまい、アクセスが遅くなったり認証（CAPTCHA）が頻発したりすることがあります。
  • fallback を最低1つ残す。メインの DNS に到達できない、またはタイムアウトした場合でも、fallback があれば解決が途切れません。メインとバックアップは異なる事業者または異なるプロトコルを使うことをおすすめします。同時に機能しなくなることを避けられます。
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query
    - tls://223.5.5.5:853
  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    'geosite:cn': 'https://doh.pub/dns-query'
    'geosite:geolocation-!cn': 'https://1.1.1.1/dns-query'

上記の例の考え方は次の通りです。デフォルトでは国内向け暗号化 DNS を使い、海外ドメイン分類（geosite ルールセット）にマッチした場合は海外 DNS に切り替え、同時に fallback-filter で解決された IP が国内アドレス帯に属するかどうかを判定してフォローします。これにより、ドメイン分類データベースの更新が遅れて誤判定が起きるリスクを抑えられます。この組み合わせなら、国内サイトのアクセス速度と海外サイトの正しい振り分けの両方をおおむね両立できます。

DNS リクエストがプロキシを迂回して漏洩していないかの検証

DNS モジュールを設定した後は、リクエストが実際に Clash を経由しているか、システム標準のリゾルバに流れていないかを実際の手段で確認する必要があります。よく使われる方法は以下の通りです。

方法一：クライアントの接続ログを確認する

ほとんどの Clash 系 GUI クライアント（Clash Verge、Mihomo Party、FlClash など）には接続ログやアクティブ接続パネルが備わっており、正常であればプロキシを経由した各接続に対応するドメイン名が表示され、裸の IP だけが表示されることはありません。IP だけでドメインが表示されない項目が多数見つかった場合、これらのリクエストがプロキシエンジンに到達する前にドメイン情報を失っていることを意味します。通常はシステムプロキシがリクエスト元のアプリをカバーしていない、またはそのアプリがシステムプロキシ設定を無視した直接接続方式を使っていることが原因で、この種のトラフィックは TUN モードに切り替えて一括で乗っ取ることをおすすめします。

方法二：パケットキャプチャで平文 DNS トラフィックの漏洩を確認する

パケットキャプチャツール（Wireshark やコマンドラインの tcpdump など）で UDP 53 番ポートや一般的な DoH ポートをフィルタし、端末のネットワークカード上で Clash に設定していない上流サーバー宛ての問い合わせパケットが存在しないか観察します。プロキシを有効にしているにもかかわらず、システムネットワーク設定に登録された通信事業者の DNS アドレスへの問い合わせが依然として捕捉できる場合、バイパス的な漏洩が存在することを意味します。システムプロキシが UDP トラフィックをカバーしているか、あるいは TUN モードに切り替えてすべてのネットワーク層トラフィックを乗っ取る必要があるかを確認しましょう。

方法三：コマンドラインで解決結果を直接比較する

ターミナル上でシステム標準のリゾルバと、Clash に設定した上流サーバーを個別に指定して同じドメインを解決し、返される IP が一致するか、また応答時間が想定される経路と合致しているかを比較します。

# システム標準のリゾルバを使う
nslookup example.com

# サーバーを直接指定して解決し、結果が一致するか比較する
nslookup example.com 223.5.5.5

fake-ip を有効にした状態でシステム標準のツールを使ってドメインを問い合わせると、実際のグローバル IP ではなく fake-ip-range の範囲内のアドレスが返るはずです。これは正常な動作で、仮 IP の仕組みが効いていることを示しており、解決失敗を意味するものではありません。

方法四：オンラインの DNS リーク検出サイトを利用する

ブラウザで専用の DNS リーク検出サイトにアクセスすると、実際に解決リクエストを行ったサーバー情報が一覧表示されます。正常であれば、設定した上流 DNS または対応する暗号化解決ノードのみが表示されるはずです。一覧にローカルネットワークの通信事業者の解決サーバー情報が現れた場合、一部のトラフィックがプロキシを迂回して直接問い合わせを行っていることを意味します。システムプロキシの適用範囲、TUN モードの有効化状態を確認するか、ブラウザ自体が独立した DoH 設定を有効にしていて Clash の DNS モジュールと競合していないかを確認する必要があります。

よくある誤解：一部のブラウザに内蔵されているセキュア DNS 機能は、システムプロキシを迂回して指定した暗号化 DNS サーバーに直接接続するため、Clash の設定が正しくてもドメイン問い合わせがプロキシを回避してしまうことがあります。漏洩を調査する際は、ブラウザ自身の DNS 設定がオフになっているか、システム設定に追従する設定になっているかも合わせて確認してください。

よくある設定上の問題と調査の考え方

実際の利用で遭遇する DNS 関連の問題は、大きく以下のパターンに集約されます。1つずつ確認すれば早期に原因を特定できます。

  1. ルールによる振り分けの精度が低い。多くの場合、redir-host を使っている、または fake-ip が有効になっていないことが原因で、ルールエンジンが解決後の IP を受け取り、元のドメインを受け取れていないため、ドメイン単位で設定したルールが機能しません。fake-ip に戻すことで通常は解決します。
  2. LAN 内の端末が互いに検出・アクセスできない。これは fake-ip モードの典型的な副作用です。LAN 関連のドメイン（*.lan、ルーターの管理用ドメインなど）を fake-ip-filter に追加し、これらのリクエストを仮 IP ではなく実際の解決に流すようにする必要があります。
  3. 国内サイトへのアクセスが遅くなる、または追加の認証が発生する。通常、国内ドメインが海外 DNS 解決に流れて不適切な IP を得ていることが原因です。nameserver-policy や fallback-filter の地域判定が正しく設定されているか確認してください。
  4. 解決に長時間タイムアウトする。設定した上流 DNS サーバー自体に到達できるか確認します。暗号化プロトコル（DoH/DoT）は一部のネットワーク環境で干渉を受けることがあるため、一度平文の UDP サーバーに切り替えてプロトコル層の問題かどうかを検証し、その上で暗号化設定を維持するかを判断します。
  5. システムプロキシモードで UDP 系アプリ（ゲーム、ビデオ通話）の解決が異常になる。システムプロキシは通常 TCP トラフィックのみを乗っ取り、UDP リクエスト（一部の DNS 問い合わせを含む）は制御下に置かれないことがあります。この場合は TUN モードを直接使用し、ネットワーク層からすべてのプロトコルのトラフィックと解決リクエストを一括で乗っ取ることをおすすめします。

DNS モードを正しく選び、上流サーバーを地域ごとに適切に振り分け、接続ログ・パケットキャプチャ・オンライン検出の3つの手段を組み合わせて検証すれば、解決経路がプロキシを迂回していないこと、そしてルールエンジンが振り分け判断に正確なドメイン情報を得られていることをおおむね確認できます。

DNS 設定が終わったら、クライアント全体の設定も忘れずに確認

対応プラットフォームの最新クライアントをダウンロードするか、インストール・設定の完全ガイドを確認して、プロキシモード・サブスクリプションルール・DNS 設定が連携して機能しているかを確かめましょう。

ダウンロードページへ チュートリアルを見る
クライアントをダウンロード