Clash DNS漏洩チェック:確認方法と漏洩防止設定の実践

DNS漏洩とは

プロキシは有効でウェブサイトも正常に表示されているのに、実は端末が依然としてシステムのDNSを使って通信事業者のサーバーへ直接名前解決の問い合わせを行っている——この問い合わせがプロキシ経由でない場合、アクセスした全てのドメインが平文のまま通信事業者やゲートウェイのログに残ります。これがDNS漏洩です。

漏洩がもたらす影響は2つあります。1つ目はプライバシー面:名前解決を行う側がアクセス履歴を丸ごと把握でき、プロキシの暗号化トンネルではこの部分を隠せません。2つ目は可用性面:平文の53番ポートへの問い合わせは中間の機器に横取りされやすく、汚染されたアドレスや誤ったアドレスが返される場合があります。ノードの状態は正常なのに目的のサイトが開かない、あるいは無関係なページに飛ばされるといった現象が典型例です。

よくある誤解として「システムプロキシをオンにすれば十分」という考え方があります。システムプロキシはアプリのHTTPプロキシ設定を変更するだけで、DNS問い合わせは管理対象外です。多くのアプリはシステムプロキシを迂回して独自に名前解決を行い、ブラウザも内蔵の暗号化DNSを使って単独で通信することがあります。DNS問い合わせもトラフィックの一種であり、ウェブのトラフィックと同様に完全に取り込まなければ、漏洩を防いだとは言えません。

チェック手順:まず漏洩の有無を確認する

チェックの前に他のプロキシやVPNツールを終了し、Clashだけを起動して確認したいプロキシモードにしておきます。複数のツールが同時に動作していると判定が乱れます。

1. 任意のIP確認ページを開き、現在の出口アドレスがノードのアドレスになっていることを確認します。まずプロキシ経路自体が正常に機能していることを証明します。
2. DNS漏洩チェックサイトを開いてフルテストを実行し、結果に表示されるDNSサーバーのアドレス、所属する通信事業者、地域を記録します。
3. ターミナルで nslookup example.com を実行し、返ってきたサーバーアドレスを記録します。macOSとLinuxでは dig example.com でも確認できます。
4. Clashでログレベルをdebugに変更し、再度nslookupを実行して、ログにこの問い合わせが記録されているか確認します。
5. 現在有効になっているシステムのDNSを確認します。Windowsでは ipconfig /all、macOSでは scutil --dns、Linuxでは resolvectl status または /etc/resolv.conf を直接確認します。

これらの結果を照らし合わせて、次の基準で判定します。

漏洩の原因:頻出する5つのケース

漏洩を確認したら、発生頻度が高い順に次の5つの原因を確認します。

1. システムプロキシモードのみを使用——システムプロキシはシステムプロキシ設定に従うアプリしか制御できず、UDP 53番ポートでのDNS問い合わせは対象外です。多くのデスクトップアプリは依然としてシステムDNSに直接問い合わせます。
2. ブラウザの「セキュアDNS」が有効——ブラウザ内蔵のDoHはシステムプロキシを迂回して名前解決を行い、ドメインをブラウザ指定のDoHサーバーへ直接送るため、システム側からはこの問い合わせが全く見えません。
3. IPv6が取り込まれていない——IPv4だけを取り込んでいる場合、AAAA問い合わせやIPv6トラフィックがローカルから直接漏れ出します。デュアルスタック環境で特によく発生します。
4. ルールでDNSが通過してしまう——設定に DST-PORT,53 を直接接続にするルールが存在する、あるいはプロキシが必要なドメインを誤ってDIRECTポリシーに振り分けている場合があります。
5. 通信事業者やゲートウェイによる53番ポートの横取り——公開DNSを手動で指定していても、平文の問い合わせは途中で書き換えられる場合があり、結果として漏洩と全く同じ現象が起きます。

漏洩防止設定:名前解決を全てClash経由にする

漏洩防止の原則はただ一つ:全てのDNS問い合わせをまずClashのDNSモジュールに通し、ローカルで解決するかプロキシ経由で通信するかをClashに判断させることです。実施は2ステップです。TUNで端末全体のトラフィックを取り込み、その上でdnsセクションを正しく設定します。

ステップ1:TUNモードを有効化する

TUNは仮想ネットワークカードを通じて端末全体のトラフィック(UDP 53を含む)を取り込みます。どのアプリのDNS問い合わせも必ずまずClashに届くため、漏洩を防ぐ最も確実な方法です。Windowsではサービスモードをインストールし管理者権限で実行する必要があり、macOSではヘルパープログラムのインストールに許可が必要、Linuxではrootまたは相応のcapabilitiesが必要です。mihomoカーネルの設定例は次のとおりです。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

ここで dns-hijack の any:53 は、任意の宛先への53番ポート問い合わせをClashのDNSモジュールへ横取りすることを意味し、漏洩防止における最重要行です。

ステップ2:dnsセクションを設定する

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://192.0.2.53/dns-query
  proxy-server-nameserver:
    - https://192.0.2.53/dns-query

• enable と listen:Clashが53番ポートでDNSサービスを提供し、TUNのdns-hijackと組み合わせて全問い合わせを取り込みます。
• enhanced-mode を fake-ip に設定:プロキシが必要なドメインに対して198.18.0.0/16の仮アドレスを直接返します。アプリはその仮アドレスで接続を開始し、Clashがドメインを復元してプロキシへ渡すため、対象ドメインはローカルで一度も解決されません。防止強度が最も高い方式です。redir-hostはローカルで一度実際の名前解決を行うため、平文で問い合わせが発生する時間帯が生じます。
• ipv6 を false に設定:AAAA問い合わせに応答しないことでIPv6経由の漏洩を防ぎます。IPv6が必要な場合は、TUNがIPv6トラフィックも取り込んでいることを必ず確認してください。
• default-nameserver:ブートストラップDNSです。nameserverに指定したDoH/DoTサーバー自体のアドレスを解決するためだけに使い、必ずIPアドレスのみを記入します。
• nameserver:通常の名前解決先です。DoHまたはDoTなど暗号化形式の使用を推奨します。問い合わせが暗号化トンネルを経由するため、ローカルのネットワークからはDoHサーバーへの暗号化接続しか見えません。
• proxy-server-nameserver:ノードのドメイン解決専用です。ノードのアドレス解決が信頼できないローカルDNSに流れることを防ぎます。

TUNを有効化できない場合の次善策として、システムプロキシを有効にしたまま、システムのDNSを 127.0.0.1 に指定し、Clashのdnsモジュールが53番ポートでシステムの名前解決を受け持つようにする方法があります。この方式はシステムDNSに従うアプリはカバーできますが、独自にDNSを指定するアプリは制御できず、防止強度はTUN方式より明確に劣ります。

設定の反映確認:変更後に再チェック

設定変更後はClashを再起動または設定を再読み込みし、前述のチェック手順を一通り再実行して、以下の項目を一つずつ確認します。

• nslookup example.com を実行し、サーバーアドレスが127.0.0.1またはローカルアドレスと表示されれば、問い合わせがClashに取り込まれた証拠です。
• プロキシ経由のドメインに対してnslookupを実行し、198.18.x.x帯のアドレスが返れば、fake-ipが機能している証拠です。
• debugログに先ほどの問い合わせが記録され、適用された上流DNSとポリシーが表示されていることを確認します。
• DNS漏洩チェックサイトを再実行し、結果に現地のプロバイダやゲートウェイのDNSが表示されず、プロキシ出口地域の名前解決のみが残っていることを確認します。
• 国内外の複数のサイトに連続してアクセスし、直接接続のサイトが正常に解決され、プロキシ経由のサイトも正常に開けることを確認し、設定変更によって新たな不具合が起きていないかチェックします。

よくある質問