DNS 設定 読了時間：約12分

ClashのDNS漏れを確認する方法｜fake-ipでDNS漏れを防ぐ設定

DNS漏れテストで名前解決の経路を確認し、enhanced-mode・nameserver・fallbackの設定例と、TUNでDNSを処理する方法を解説します。

まずDNS漏れの判断基準を確認

DNS漏れとは、名前解決の問い合わせが想定外の経路に流れることです。たとえば、Webサイトへのアクセスとドメインの名前解決をどちらもプロキシ経由にしたいのに、テストで名前解決が現地のインターネットサービスプロバイダー（ISP）によって行われていると分かるケースです。ページが開けても、DNSの経路が適切とは限りません。fake-ipを有効にしただけで、DNS漏れが起きないと判断することもできません。

切り分けでは、次の3段階を分けて確認します。アプリがどこに問い合わせるか、Clashのコアが問い合わせをどう処理するか、コアがどの接続経由で上流DNSにアクセスするかです。fake-ipが主に変えるのは2段階目で、アプリにはまず対応するIPアドレスを返し、コアが接続情報からドメインを特定してルールに従って振り分けます。これは暗号化プロトコルではなく、すべてのアプリの通信を自動で引き受ける機能でもありません。

  • システムプロキシ：主にシステムプロキシ設定に従うアプリに影響します。システム上のすべてのDNS問い合わせを処理するものではありません。
  • TUNモード：より多くのネットワーク通信を取り込めますが、ルーティング、DNS hijack、IPv6、ほかのVPNの影響も確認が必要です。
  • DoH：DNSの通信をHTTPSで送信し、経路上で内容が平文のまま見えるリスクを抑えます。ただし、DoHへの直接接続とプロキシ経由の接続は別の経路です。

この記事の設定例はClash Meta、つまりmihomoコアを対象としています。旧版Clashやクライアントによっては、同じ項目や設定の上書き方法に対応していない場合があります。設定を変更する前に、クライアントの「バージョン情報」やコア情報の画面でコア名を確認してください。

確認手順：基準値を記録してからプロキシ接続時と比較

1回目：ローカルネットワークのDNSリゾルバーを記録

  1. 信頼できる自宅などのネットワークでテストし、複数のVPNの設定が重ならないよう、ほかのVPNを終了しておきます。
  2. ClashのシステムプロキシとTUNを無効にします。DNSLeakTestなどのDNS漏れテストサイトを開き、まずStandard testを実行して、リゾルバーのIPアドレス、事業者、時刻を記録します。
  3. 普段プロキシ経由で接続していて、プロキシを切るとテストページを開けない場合は、この確認を省略してください。基準値を得るためにルーターの設定を変更する必要はありません。

2回目：プロキシを有効にして再テスト

現在の設定で起動し、プロキシのポリシーグループで利用可能なノードが選択されていることを確認します。同じテストをもう一度実行し、続けてExtended testも行って、1回目に見つかった現地ISPのリゾルバーが表示されるか確認します。別のWebページも開いて出口IPを調べ、「Web通信の出口」と「DNSリゾルバー」を別々に記録してください。2つをひとつの指標として扱わないようにします。

テストで確認したこと考えられる原因次に確認すること
Web通信はプロキシ経由だが、リゾルバーは現地ISPのままシステムDNSが取り込まれていない、またはDNS問い合わせが直接接続するルールがあるTUN、53番ポートのDNS hijack、実際に適用中の設定を確認
パブリックDNS事業者が表示されるコアの上流DNSか、ブラウザーのセキュアDNSの可能性上流DNSの設定を照合し、ブラウザーのセキュアDNSを一時的に無効にして再テスト
リゾルバーの所在地がノードの所在地と異なるパブリックDNSがエニーキャストを使用している、または出口が異なる国名表示だけで判断せず、事業者と接続ログも確認
テストがタイムアウトするが、キャッシュ済みのページは開ける新しいドメインの名前解決に失敗している一方、既存の接続は利用できるDoHへの接続と、プロキシノードのドメイン解決を確認

テストページで確認できるのは、そのページのテスト用ドメインを再帰問い合わせしたリゾルバーです。すべてのアプリが同じ経路を使うことを単独で証明するものではありません。ブラウザーを変えたり、ネットワークを切り替えたり、別のVPNを有効にしたりすると結果も変わる場合があります。1回のテストで緑色の表示が出ただけで、確認を終えないでください。

fake-ipの設定：ポリシーグループを確認してからDNS設定を統合

以下は既存のmihomo設定に統合するDNS設定例であり、サブスクリプションファイル全体ではありません。既存設定にPROXYという名前のプロキシポリシーグループがあり、そのグループでDIRECTではなく利用可能なプロキシノードが選択されていることが前提です。実際のグループ名が「ノード選択」の場合は、2か所の#PROXYを#ノード選択に置き換えてください。このサフィックスは、上流DNSへの接続に使う出力ポリシーを明示するものです。

まず元の設定をバックアップし、既存のトップレベルdns:セクションを置き換えてください。同じ名前のセクションを追加で作らないようにします。クライアントの上書き機能やマージ機能を使って変更を保存し、サブスクリプション更新で上書きされないようにしてください。保存後は、実行中の設定に反映された内容も確認します。

既存設定の dns セクション
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#PROXY"
  fallback:
    - "https://9.9.9.9/dns-query#PROXY"
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/8
      - 127.0.0.0/8

この例では、通常の通信で使うドメインの上流問い合わせを明示的にPROXY経由にしつつ、起動時の名前解決とノードのドメイン解決は直接接続のままにしています。したがって、「すべてのDNSがプロキシ経由になる」ことを保証する設定ではありません。ローカルネットワークから平文DNSを完全に見えなくしたい場合は、起動時の名前解決経路を別途設計し、コールドスタート時にもノードへ接続できることを検証してください。

enable、listen、enhanced-mode

enable: trueでコアのDNS機能を有効にします。listen: 127.0.0.1:1053はローカルのループバックアドレスの1053番ポートだけで待ち受け、LANに誤ってDNSサービスを公開するのを防ぎます。このアドレスを設定しただけでは、システムDNSの接続先は自動で変更されません。多くのOSのDNS設定ではサーバーアドレスしか指定できず、ポート番号1053を同時に指定できません。

enhanced-mode: fake-ipでIPアドレスのマッピング方式を有効にします。例で使うアドレスプールは198.18.0.0/16で、ベンチマーク用に予約されたアドレス空間です。実際のWebサイトのグローバルIPアドレスではありません。通常のドメイン問い合わせで198.18.0.2のような結果が返るのは正常な場合があります。このアドレスはあくまで例で、実際の割り当て値は固定ではありません。

nameserverとノードのドメイン解決

nameserverは通常の問い合わせに使う上流DNSです。この例では、上流アドレス自体の名前解決が不要なIPアドレス形式のDoHを使用し、#PROXYでプロキシポリシーを指定しています。特殊文字を含む内容がYAMLで誤って解釈されないよう、引用符はそのまま残してください。

proxy-server-nameserverは、プロキシノードのサーバードメイン名を解決するための設定です。ノードへの接続が確立する前に、そのノード自身にドメイン解決を依存させると循環依存になります。この例ではこの処理に直接接続のDoHを使います。default-nameserverは、DNSサービスのドメイン名を解決するための初期問い合わせに使います。通常のWebサイトのドメイン問い合わせとは見える範囲が異なるため、個別に評価してください。

fallbackは単なるタイムアウト時の予備ではない

fallbackとfallback-filterは、どの結果を採用するかに関わる設定です。「プライマリDNSがタイムアウトしてから初めて問い合わせる」という意味ではありません。コアの処理経路によっては、両方の上流DNSに並行して問い合わせることがあります。この例では、予期しない直接接続の経路ができないよう、両方の上流DNSにPROXYを指定しています。

ここではGeoIPによる絞り込みを無効にし、指定した異常アドレス範囲だけを結果の選別に使います。これにより、デフォルトの地理判定が想定と異なる結果を招くのを防ぎます。ただし、この短いリストだけで汚染を完全に検出できるわけではありません。fake-ipがマッピングアドレスを返しても、問い合わせのたびにすべての実IPアドレス解決が直ちに発生するとは限りません。信頼できる上流DNSを1つだけ使う場合は、fallbackとfallback-filterを削除して、まず経路をシンプルにしてください。

TUNとDNS hijack：システムの問い合わせをコアに取り込む

DNSセクションを用意したら、次に確認するのは「問い合わせがコアに届いているか」です。システムの通常DNSを取り込みたいデスクトップ環境では、対応するmihomoクライアントでTUNを有効にできます。以下の設定は既存のトップレベルtun:に統合してください。クライアントの画面からTUNを管理する場合は、画面が生成した最終設定を優先します。

TUN 設定例
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • auto-routeを有効にすると、通信を取り込むためのルートがコアによって設定されます。通常は管理者権限またはクライアントのシステムサービスが必要です。
  • dns-hijackは、TUNに入った通常のUDP・TCP 53番ポートへの問い合わせを内部DNSに渡します。あらゆるDNSプロトコルを対象とした汎用インターセプターではありません。
  • strict-routeは一部の迂回経路を制限できますが、OSによって効果が異なります。LANへのアクセスに影響したり、ほかのVPNとの互換性に問題が出たりする場合もあります。
  • ブラウザーのDoHはHTTPSを使い、DoTは通常853番ポートを使います。どちらも通常の53番ポートへの問い合わせとは別の経路なので、それぞれの接続ルートを確認してください。

複数のネットワークアダプター、仮想マシン、社内VPN、ルーター経由の通信を使う環境では、自動ルートの設定例をそのまま適用しないでください。まずデフォルトの出口アダプターを確認し、ログにルーティングループが出ていないか確認します。有効化後にネットワーク全体が切断された場合は、まずTUNを無効にして接続を復旧し、DNS・ルート・ノードを一度に変更せず、項目ごとに確認してください。

設定の検証：ポート、マッピング、実際の出口を個別に確認

まずコアの1053番ポートに直接問い合わせる

digをインストール済みのmacOSまたはLinuxのターミナルで、次のコマンドを実行します。システムDNSの現在の接続先に依存せず、ローカルのコアを直接指定できます。Windowsでは、対話型のnslookupでポートを設定してテストすることもできます。

macOS / Linux
dig @127.0.0.1 -p 1053 example.com A
Windows：順に入力
nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

フィルターに一致しない通常のドメインでは、通常アドレスプール内のAレコードが返ります。タイムアウトする場合は、コアが正常に読み込まれているか、1053番ポートが使用中でないか、ログに未知のフィールドに関する警告がないかを確認してください。直接問い合わせが正常でもシステムアプリがコアを迂回する場合、問題はDNSの上流ではなく、通信を取り込む経路にあります。

キャッシュを消去して接続を確認

  1. Windowsではipconfig /flushdnsを実行すると、システムのDNSキャッシュを消去できます。ブラウザー独自のキャッシュや接続が残る場合もあるため、再テスト前にブラウザーを完全に終了してから開き直してください。
  2. Chromeの「設定」→「プライバシーとセキュリティ」→「セキュリティ」で、「セキュア DNS を使用する」を確認します。原因を切り分けるために一時的に無効にし、テスト後は自分の運用方針に合わせて設定を戻してください。
  3. クライアントの接続パネルで、1.1.1.1:443や9.9.9.9:443への上流接続に、想定したプロキシが選択されているか確認します。ログの表示方法はクライアントによって異なります。問い合わせのたびに新しい接続が1件ずつ表示される必要はありません。
  4. DNS漏れテストをもう一度実行します。リゾルバーの事業者を比較し、出口とログも合わせて判断してください。地図上の位置だけで決めないようにします。

システムやブラウザーの設定が組織のポリシーで管理されている場合があります。業務用デバイスでは、まず管理上の要件を確認してください。テストのためにセキュリティポリシーを無理に無効にしないでください。通常のDNSテストはWebRTCの検査とは異なります。WebページからローカルIPアドレスやグローバルIPアドレスが見える問題は、別途確認が必要です。

よくある問題：IPv6、LAN、サブスクリプションの上書き

ipv6: falseに設定してもIPv6通信が発生するのはなぜ？

DNSセクションのipv6: falseは、主にコアによるAAAA問い合わせの処理に影響します。OSのIPv6を完全に無効にする設定ではありません。アプリのキャッシュ、IPv6アドレスの直接指定、ブラウザー独自の名前解決、取り込まれていないネットワークインターフェースから、IPv6接続が発生することがあります。IPv6を使う場合は、通信を取り込む設定を整えてテストしてください。一時的に使わない場合も、DNSの項目だけでなくシステムとクライアントの設定を併せて確認します。

プリンター、NAS、LAN内のドメインに接続できない場合は？

まず名前解決の問題か、ルーティングの問題かを切り分けます。fake-ip-filterは、一致したドメインにマッピングアドレスを返さないようにするだけで、ルーターのDNSに自動で問い合わせる設定ではありません。LAN内の実際のDNSサーバーが192.168.1.1の場合は、実際のサブネットを確認したうえで、内部ドメインにnameserver-policyを設定できます。以下は既存設定にフィールドを統合する例です。トップレベルのDNSセクションをもう一度作らないでください。

既存の dns セクションに追加
  nameserver-policy:
    "+.lan":
      - 192.168.1.1

ここでのLAN内DNS問い合わせは、意図して残すローカルの名前解決です。パブリックなWebサイトの予期しないDNS漏れと混同しないでください。.localはmDNSで使われることが多く、ルーターの通常DNSが応答するとは限りません。NASのLAN内IPアドレスを直接指定しても接続できない場合は、まずTUNのルートとファイアウォールを確認してください。

サブスクリプション更新後に結果が変わるのはなぜ？

クライアントが設定を再生成したり、サブスクリプションにnameserver-policy、追加の上流DNS、別のルール設定が含まれていたりする場合があります。エディターでファイルを変更しても、実行中のコアに反映されたとは限りません。更新後は、実際に適用されている設定のDNS、TUN、ポリシーグループ名を確認し、簡単な再テストを行ってください。DNSの問い合わせをルールに従わせるrespect-rulesを使う場合は、対応するルールとノードの初期名前解決を個別に設計してください。この記事のように出力先を明示する設定と混在させて、感覚だけで判断しないようにします。

確認完了：再現できるテスト記録を残す

最後に、使用したコアと設定、ブラウザーのセキュアDNSの状態、プロキシの出口、検出したリゾルバー事業者の4項目を記録します。適切な結果とは、事前に決めた条件と一致することです。通常の通信で使う問い合わせは指定したプロキシ上流を通り、必要なローカル名前解決には明確な用途があり、ノードの初期接続経路も説明できる状態を目指します。fake-ipがアドレスをマッピングし、TUNが通信を取り込み、上流DNSと出力ポリシーが名前解決の経路を決めます。この3つを組み合わせることで、検証可能な設定になります。

クライアントをダウンロード