ClashのTUNモードでDNS漏れを防ぐ設定方法と原因の調べ方

TUNモードでもDNS漏洩が起きる理由

ClashのTUNモードは、仮想ネットワークインターフェースを使って端末のIP通信を取り込み、Mihomoのルールに従って転送する仕組みです。ただし、TUNを有効にしただけで、端末上のあらゆる名前解決が必ずClash経由になるわけではありません。DNS問い合わせの通り道は、OS、アプリ、ブラウザー、ルーターの設定によって複数に分かれるためです。

一般的なDNSはUDPまたはTCPの53番ポートを使います。TUN側でDNS通信を取り込んでいない、またはネットワーク経路が正しく設定されていない場合、問い合わせがOSに設定されたDNSサーバーや家庭用ルーターへ直接送られることがあります。プロキシ接続自体は正常でも、名前解決だけがISPのDNSに届く状態が、ここでいうDNS漏洩の典型例です。

もう一つ見落としやすいのが、暗号化DNSです。ブラウザーの「セキュアDNS」やアプリ内蔵のDNS over HTTPS（DoH）は、通常の53番ポートではなくHTTPS通信として送信されます。そのため、TUNでUDP/TCPの53番を捕捉していても、ブラウザーのDoH設定が有効なら別経路で名前解決される可能性があります。DNS over TLS（DoT）も同様に、通常は853番ポートを使います。

TUNの取り込み設定：仮想インターフェースやルート設定が無効だと、一部の通信がClashを通りません。
DNSの捕捉設定：53番ポートをClashのDNS処理へ渡さないと、OSやルーターのDNSが使われる場合があります。
アプリ独自の名前解決：ブラウザーのDoH、VPNアプリ、セキュリティソフトなどがClashのDNS設定を迂回することがあります。
IPv6の経路：IPv4だけをTUNへ流し、IPv6を別経路に残すと、DNSや接続先の一部が直接通信になることがあります。

つまり、確認すべきなのは「TUNがオンか」だけではありません。DNS問い合わせがMihomoに届き、選択したDNSサーバーへ意図した経路で送られ、アプリ側の独自DNSにも迂回されていないかを順番に見ます。なお、fake-ipはドメインと接続を対応付けるための方式であり、DNS通信そのものを暗号化する機能ではありません。

MihomoでDNS漏洩を抑える基本設定

設定例を変更する前に、使用中のクライアントがどのMihomo設定を読み込んでいるか確認してください。Clash VergeやClash Verge Revでは、プロファイルの編集・マージ設定・GUI上のTUN設定が同じ項目を上書きする場合があります。設定ファイルをバックアップし、編集後はクライアントの構文チェックや再読み込みを行うと、誤設定による通信断を避けやすくなります。

以下は、一般的なデスクトップ環境でTUNとMihomo内蔵DNSを併用する場合の例です。利用中のコアのバージョンやOSによって対応項目、インターフェース名、GUIでの表示は異なるため、現在のMihomoが各項目を受け付けることを確認してから適用してください。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
  respect-rules: true

dns-hijackはTUNを通る通常のDNS通信をMihomo側へ渡すための設定です。環境によってはUDPだけでなくTCPの53番も必要になります。listenはDNSリスナーの待ち受け先で、ここではローカル端末からの問い合わせに限定しています。LAN内の別端末からこのリスナーを利用させたい場合は、待ち受け先やファイアウォールの設計を別途検討してください。不要に全インターフェースへ公開すると、意図しない端末から利用されるおそれがあります。

nameserverはMihomoが通常の名前解決に使う上流DNSです。ここではDoHの例を示していますが、接続先や証明書の検証、ネットワーク上の到達性を確認して選んでください。proxy-server-nameserverは、プロキシノードのサーバー名を解決するときに使うDNSです。プロキシ接続の確立に必要な名前解決がプロキシ自身を必要とする、といった循環を避けるため、到達可能な値を指定します。

respect-rules: trueは、DNSサーバーへの通信にもルールを適用するための設定です。コアのバージョンやプロファイル構成によって挙動が異なるため、設定を有効にした後は、ログでDNS通信の出口を確認してください。ルールに該当するDNS通信が誤ってDIRECTになっていないか、またDNSサーバー名を解決するための起動時通信が滞っていないかも確認が必要です。

注意：サンプルをそのまま貼り付けても、すべてのネットワークで漏洩が防げるとは限りません。上流DNSへの通信がブロックされる環境では名前解決に失敗することがあります。接続不能になった場合は、直前の設定へ戻せるようバックアップを残し、項目を一つずつ変更してください。

nameserver-policyとIPv6を環境に合わせて調整する

すべてのドメインを同じDNSへ送る必要がない場合は、nameserver-policyでドメインごとの名前解決先を指定できます。たとえば、社内ドメインや家庭内の機器名を社内DNSで解決し、それ以外の問い合わせは通常の上流DNSへ送る構成です。

dns:
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    '+.internal.example':
      - 192.168.1.1
    'geosite:private':
      - 192.168.1.1

この例では、internal.example配下のドメインとプライベート用のドメイン分類に対し、ルーターのDNSを指定しています。社内DNSが必要ない環境では、このような例外をむやみに追加しないでください。ローカルDNSはLAN内の機器名を解決できる一方、問い合わせ内容がルーターや社内ネットワークへ渡るため、プライバシー要件に合うか確認する必要があります。また、ルール名やドメインパターンの書式は、使用するMihomoのバージョンと設定内容に合わせて検証してください。

IPv6はDNS漏洩の原因と決めつけるのではなく、端末・TUN・上流ネットワークの対応を揃えて判断します。IPv6を使う予定がない場合は、OSやクライアントのIPv6経路を含めて一貫して無効化する方法があります。反対にIPv6を使うなら、TUNがIPv6を処理できる状態か、IPv6のDNS問い合わせと通信が意図した経路を通るかを確認します。DNS設定だけでIPv6を無効にしても、OS側に別のIPv6経路が残っていれば、すべての通信を遮断できるとは限りません。

構成	向いている状況	確認するポイント
`fake-ip`	ドメイン情報を使ったルール適用を行いたい	LAN機器、ゲーム、古いアプリで互換性の問題がないか
`redir-host`	実際の解決先IPを使う必要がある	ドメイン情報の取得やルール判定が期待どおりか
IPv6を無効化	ネットワーク全体でIPv6を利用しない	OS、TUN、DNS、ルーターの設定が揃っているか
IPv6を利用	IPv6接続が必要でTUNも対応している	IPv6ルートとDNSがClashを迂回していないか

fake-ipで特定アプリだけ接続できない場合は、DNS漏洩と決めつけず、キャッシュやアプリ互換性も調べましょう。設定を保存したうえで一時的にredir-hostへ切り替え、同じドメインの症状が変わるか比較すると切り分けに役立ちます。モードを変更した後は、クライアントのDNSキャッシュやOSのキャッシュを消去し、古い結果を使ったテストにならないようにしてください。

設定後にDNS経路を確認する手順

設定を反映したら、ブラウザーの表示だけで判断せず、TUNの通信、Mihomoのログ、DNSの結果を組み合わせて確認します。作業中は一度に複数の項目を変えず、変更前後の状態を記録してください。何が改善または悪化したかを追いやすくなります。

確認の手順

ClashクライアントでTUNとMihomo DNSが有効か確認し、プロファイルを再読み込みします。TUNの仮想インターフェースがOSに作成され、期待するネットワーク経路が設定されているかも確認してください。
接続ログを表示し、テスト対象ドメインへアクセスします。DNS関連のエラー、上流DNSへの接続失敗、想定外のDIRECT判定がないかを確認します。ログに問い合わせが表示されない場合は、キャッシュやアプリ独自DNSの影響も考えます。
端末のコマンドラインから複数のドメインを名前解決します。Windowsではnslookup example.com、macOSやLinuxではdig example.comなどを利用できます。返されたDNSサーバー名やアドレスだけで経路を断定せず、Mihomo側のログと照合してください。
ブラウザーのセキュアDNS設定を確認します。テスト時は一時的にDoHを無効にして通常のDNSと比較し、結果が変わるならブラウザー内の設定やポリシーが独立した経路を作っている可能性があります。
IPv4とIPv6の両方で接続を確認します。IPv6を利用しない設計なら、OSにIPv6のDNSやデフォルトルートが残っていないか確認します。利用する設計なら、IPv6通信もClashのルールと出口を通るか調べます。
必要に応じてDNSキャッシュを消去し、Clash、ブラウザー、OSの順に再起動して再テストします。キャッシュが残っていると、設定変更前の解決結果を見て誤判定することがあります。

DNSリークテストサイトは参考になりますが、単独の判定を絶対視しないでください。サイトのテストは限られたドメインと時点の観測であり、ブラウザーのDoH設定、OSキャッシュ、IPv6、他のアプリの挙動まで常に網羅するわけではありません。別のテストサイトやコマンドラインでも結果を比べ、Mihomoのログと矛盾がないか確認するのが確実です。

切り分けのヒント：特定のブラウザーだけで漏洩判定が出るなら、まずそのブラウザーのセキュアDNSを確認します。全アプリで名前解決が失敗するなら、上流DNSへの到達性、リスナーの待ち受け、TUNのルート、設定の構文を先に調べてください。

よくある質問

TUNを有効にすればDNS漏洩は防げますか？

いいえ。TUNは通信を取り込む仕組みですが、DNSの捕捉設定やMihomoのDNS機能が適切でなければ、問い合わせがOSやルーターへ送られることがあります。さらにブラウザーのDoHやアプリ独自DNSは、通常の53番ポートとは異なる経路を使う場合があります。TUN、DNSリスナー、ルール、アプリ側の設定をまとめて確認してください。

fake-ipにするとDNS通信が暗号化されますか？

いいえ。fake-ipは、ドメインに対応する仮想IPを返し、通信時に元のドメイン情報と関連付けるためのDNSモードです。上流DNSとの通信を暗号化するかどうかは、nameserverに指定したDNS方式などで決まります。DoHを使う場合でも、接続先への経路やクライアントの設定が適切か確認が必要です。

DNS設定でIPv6を無効にすれば十分ですか？

必ずしも十分ではありません。DNSのIPv6応答を無効にしても、OSやネットワークアダプターにIPv6の経路が残ることがあります。IPv6を使わないなら端末、TUN、ルーターを含めた構成を揃え、使うならIPv6のDNS問い合わせと接続先が意図した経路を通ることを確認してください。

テストサイトで漏洩なしと表示されれば問題ありませんか？

それだけでは断定できません。テストサイトは限られた条件で観測するため、別のアプリが異なるDNSを使うケースや、IPv6だけが別経路になるケースを見逃す可能性があります。複数の確認方法を組み合わせ、実際の利用アプリでも再現テストを行うのがおすすめです。

DNS経路の確認では、設定が多いだけのクライアントや、DNS項目を個別に管理できないツールだと、原因の切り分けに手間がかかることがあります。ClashはMihomoのTUN、DNSモード、ポリシー、ログをまとめて扱えるため、問題の場所を段階的に調べやすいのが利点です。自分の環境で設定を検証してみたい場合は、ダウンロードから対応クライアントを確認してください。