トラブル対処 約9分で読めます

Clash DNS 漏洩検出方法と fake-ip 漏洩防止設定の実践

プロキシ接続時でもDNSが漏洩する場合があります。オンライン検出とパケットキャプチャによる確認方法を紹介し、fake-ipやnameserverグループ、fallback-filterによる漏洩防止設定を解説します。

DNS 漏洩とは何か、プロキシが通っていても漏れる理由

ウェブページが開けて、速度も測れて、遅延も正常に見える——それは今回の通信がすべてプロキシを経由したことを保証しません。DNS漏洩とは、ドメイン名解決リクエストがプロキシトンネルを回避し、端末のシステムに設定されたDNSサーバー(多くの場合契約プロバイダのDNSやルーターが割り当てるDNS)へ直接送られてしまう現象です。結果として、ウェブページのデータはプロキシを通っているのに、「どのドメインにアクセスしようとしているか」という情報だけがローカルネットワークのDNSサーバーに漏れてしまい、外部から見た場合、アクセス履歴のおおよその輪郭は依然として組み立てられてしまいます。

この問題は、純粋なルールモード(システムプロキシ+アプリ層振り分け)で特に多く発生します。多くのクライアントはシステムプロキシをHTTP/SOCKS5に設定しますが、オペレーティングシステム自体が発行するDNSクエリ(UDP 53番ポート)は、デフォルトではこのプロキシ経路を通らず、ネットワークカード自体のDNS設定を使います。一部のアプリは独自のDNS解決ロジック(ブラウザのDoHなど)を使うため、さらにシステムプロキシの制約を受けません。だからこそ「接続が正常」であることと「DNSがクリーンである」ことは、別々に確認すべき事柄なのです。

もう一つのよくある原因はポリシーグループの切り替えです。プロキシルールにおけるドメイン振り分けの記述が不完全で、一部のドメインがDIRECT(直接接続)ポリシーにマッチしてしまう場合、そのドメインに対応するDNSクエリも高い確率で端末のデフォルト解決パスを通ってしまい、同様に漏洩を構成します。ただし範囲がより狭く目立ちにくいため、普段は発見しづらいという特徴があります。

2つの検出手段:オンライン検出とローカルパケットキャプチャ

DNSが漏洩しているかどうかを確認するには、オンラインツールとローカルパケットキャプチャを併用することを推奨します。前者は迅速に結論を出し、後者は具体的にどのクエリが漏れているかを特定できます。

オンライン検出:DNSサーバーの所属を確認する

DNS漏洩検出に対応した任意のサイトを開き、Clashを起動してプロキシが有効な状態で検出を実行すると、実際にDNSクエリを処理しているサーバーのIPと所属地域がページに表示されます。正常な場合、これらのサーバーはプロキシノードが所在するデータセンター、または設定で指定したパブリックDNS(Cloudflare、Google Public DNSのIP帯など)に属しているはずで、自分が所在する地域の契約プロバイダのDNSセグメントであってはなりません。検出結果に契約プロバイダのDNSが現れた場合、漏洩が確実に発生していることを意味します。

この種の検出を行う際は2点に注意してください。一つはノード切り替え後に数秒待ってから検出すること。ポリシーグループとDNSキャッシュが反映される時間を確保するためです。もう一つは複数回検出し、複数の検出サイトで相互検証すること。1回の結果だけではキャッシュの影響で偽陰性が出る可能性があります。

ローカルパケットキャプチャ:漏洩している具体的なドメインを特定する

オンライン検出は「漏洩しているかどうか」しか教えてくれません。「どのドメインが漏洩しているか」を知るにはパケットキャプチャが必要です。Windowsでは Wireshark を使って端末のネットワークカードのトラフィックをキャプチャし、フィルタ条件に udp.port == 53 || tcp.port == 853 を指定します。それぞれ通常のDNSとDNS over TLSに対応します。正常に動作している場合、契約プロバイダのDNSやルーターのゲートウェイアドレス宛の53番ポートトラフィックはほとんど見えないはずです。見えてしまった場合は、そのパケットを展開してQueryフィールドを確認すれば、具体的にどのドメインが漏れているか分かります。

macOSやLinuxでは、コマンドラインツールを直接使うこともできます:

sudo tcpdump -i any port 53 -n

実行後、いくつかのサイトを通常どおり閲覧し、出力に表示される宛先アドレスがすべてClashの設定で指定したDNS(たとえばfake-ipモードであれば、システム側から見えるのは内部の仮想DNSトラフィックであり、外部の53番ポートへの直接接続ではないはず)を指しているかを確認します。もし外部DNSサーバーへ直接向かうパケットが大量にキャプチャされた場合、設定に漏れがあるとほぼ断定できます。

注意 検出前に、システムプロキシまたはTUNモードが実際に有効な状態になっていることを確認してください。ルールモードの場合は、対象アプリが個別にプロキシ対象外に設定されていないかも確認が必要です。そうでなければ、得られた「漏洩」という結論は防止機構自体の問題ではなく、単に設定が反映されていないだけかもしれません。

enhanced-mode: fake-ip の原理と設定方法

Clash(およびMeta系カーネルmihomo)が提供するDNS拡張解決は、漏洩問題を解決する最も直接的な手段であり、核となる設定項目は dns.enhanced-mode、よく使う値は fake-ip です。その仕組みは次のとおりです:クライアントがシステムのDNSリクエスト入口を引き受け、アプリがドメイン名解決を要求した際に、実際のパブリックIPをシステムに返す代わりに、プライベートアドレスプールから「偽のIP」を割り当てて解決結果とします。アプリはこの偽IPを受け取って通常どおり接続を開始し、Clashカーネルはトラフィックがプロキシ経路を通過する際に、この偽IPから実際のドメイン名を逆引きし、対応するポリシーグループと実サーバーアドレスに処理を渡します。

これにより、システムやアプリ層からは、実際のドメイン名解決リクエストが外部DNSサーバーに送られたようには全く見えなくなり、DNSクエリの工程はClash自身の処理経路に完全に取り込まれ、根本から漏洩を防ぐことができます。典型的な設定例は次のとおりです:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - localhost.ptlogin2.qq.com
    - +.market.xiaomi.com

各項目の説明:enable は内蔵DNSサーバーを有効化します。listen は内蔵DNSがリッスンする端末側のポートを指定し、システムやTUNネットワークカードはここに解決リクエストを転送します。enhanced-mode は fake-ip を選ぶことで偽アドレスマッピングを有効化します。fake-ip-range は偽アドレスプールのネットワーク帯を指定するもので、通常は予約アドレス帯を使い実際のLANと衝突しないようにします。fake-ip-filter はホワイトリストで、ここに列挙されたドメイン(LAN内デバイス探索や一部銀行アプリの証明書バインディング検出でよく見られる)は偽アドレスを経由せず実際のIPを返すことで、機能異常を避けます。

強調しておきたいのは、fake-ipはシステムが実際にDNSクエリをClashの内蔵サーバーに渡している場合にのみ有効になるという点です。TUNモードではネットワークカード層がすべてのトラフィックを引き受けるため、DNSリクエストは自然に横取りされ、漏洩防止効果が最も徹底しています。一方、純粋なシステムプロキシモードでは、クライアントがシステムのDNS設定を自身のリッスンポートに向ける必要があり、この設定がシステムのネットワーク設定に正しく反映されていない場合、fake-ipの設定が正しくても機能しません。これは、設定は正しいはずなのに漏洩が検出される、というよくある原因の一つです。

nameserver グループと fallback-filter の漏洩防止の細部

偽アドレスが解決するのは「アプリ側から何が見えるか」という問題であり、ドメインを実際のIPに解決する本当の作業は、依然として nameserver 設定項目で指定された上流DNSサーバーが担っています。この工程にも同様に漏洩リスクがあります。上流DNS自体が信頼できない契約プロバイダのサーバーであったり、クエリ過程が暗号化されていなかったりすると、経路上の中間ネットワーク機器に記録される可能性があります。地域内向けと地域外向けの振り分けの発想で2組のDNSを設定し、fallback-filter で最終判定を行うことを推奨します:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.facebook.com

nameserver はデフォルトで優先的に使用される解決サーバーで、通常は中国本土向けのパブリックDNSを記入し、中国本土サイトの解決速度を確保します。fallback は代替サーバーで、DNS over TLSに対応したアドレス(例のようなtls://プレフィックスの記法)を使うことを推奨し、解決リクエスト自体も暗号化経路を通ることで、経路上のノードに覗かれたり改ざんされたりするのを防ぎます。fallback-filter はいつfallbackを有効にするかを決定します——geoip-code: CN は、nameserver が解決した結果が中国本土のIP帯に収まっていればそれを採用し、そうでない場合は結果が汚染されている可能性があると判断して fallback の暗号化DNSで再解決を行うという意味です。domainリストに列挙されたドメインは、中国本土の解決結果を信用せず強制的にfallbackを経由させます。

この2組構成は本質的に「近距離解決+汚染時のフォールバック」です。中国本土のサイトが遠回りして海外DNSに問い合わせる必要をなくして速度低下を防ぎつつ、プロキシを経由すべきドメインが中国本土の解決結果によって汚染され誤った(あるいは監視されている)アドレスに誘導されることも防ぎます。設定完了後は、前述のパケットキャプチャの方法で検証できます:海外ドメインに対応する解決トラフィックは、fallback で設定した暗号化DNSに向かうべきで、平文の53番ポートに向かってはいけません。

よくあるチェックリスト

  • クライアントが実際に拡張DNSを有効化しているか確認する。一部のクライアントはDNSモジュールをデフォルトで無効にしているため、設定画面で手動で有効化する必要があります。
  • TUNモードでは、仮想ネットワークカードがルーティングを正しく引き受けているか確認する。システムのネットワーク設定内のDNS項目は、Clashの内蔵リッスンアドレスを指しているか、仮想ネットワークカードによって上書きされているはずです。
  • ブラウザが独自にDoH(DNS over HTTPS)を有効化し、解決サーバーがハードコードされている場合、システムのDNS設定を回避してしまう可能性があります。ブラウザの設定でこの機能を無効化するか、システムDNSを使うように変更する必要があります。
  • ルーターや一部のセキュリティソフトが強制的にDNSサーバーを指定している場合、ClashのDNSハイジャックを上書きしてしまう可能性があります。システムまたはルーターの層でClashのリッスンポートへの転送を許可する必要があります。
  • ルールセットに漏れがあり、一部のドメインがDIRECTポリシーを通ってしまっている場合があります。定期的に振り分けルールを確認し、ログと合わせてマッチしたポリシーグループが想定どおりか確認することを推奨します。
推奨 優先的にTUNモードを使用しfake-ipを有効化し、さらに2組のnameserver+fallback-filterを組み合わせれば、ほとんどのシナリオにおけるDNS漏洩問題を基本的にカバーできます。設定を変更した後は、必ずオンライン検出とパケットキャプチャによる再確認を行ってください。
Clash をダウンロード