ClashのDNSリーク検出と対策｜fake-ip・nameserver-policyの設定方法

DNSリークとDNSリゾルバーの地域差を見分ける

Webページがプロキシ経由でも、DNS問い合わせまでプロキシ経由とは限りません。システムプロキシの設定が適用されるのは、通常その設定に従うアプリだけです。システムの名前解決、ブラウザーのセキュアDNS、アプリ独自のDoHは、それぞれ別の経路を使う場合があります。対策には「どこから問い合わせが発生したか」「どのリゾルバーを使ったか」「リゾルバーへの接続にどのルールが適用されたか」の確認が必要です。fake-ipに切り替えるだけでは解決しません。

この記事の設定例はmihomoコアを対象としています。旧バージョンのClashやクライアントごとの実装では、対応する設定項目が異なる場合があります。まずクライアントのコア情報や起動ログで名称を確認してください。設定チェックで不明な項目が検出された場合は、使用中のコアのドキュメントを参照し、名前が同じだからといって同等の機能だと判断しないでください。

• DNSリーク：プロキシ経由にするつもりだったドメインの問い合わせが、ローカルネットワーク経由でISPなど、想定していないリゾルバーに送信されることです。
• リゾルバーの所在地の違い：テストページに表示される国・地域は、多くの場合リゾルバーの出口IPに関するデータベースに基づきます。プロキシノードの実際の所在地を示すものではありません。
• 意図した直接接続：LAN内の名前、直接接続するサイト、プロキシサーバーのドメイン名などは、DNS問い合わせを直接接続にする場合があります。こうした問い合わせを許容するか、まず自分のルーティング方針を明確にしましょう。

検証の基準を作る：ブラウザー・システム・コアを個別に確認

条件をそろえて2回テストする

1. ほかのVPNやプロキシツールを停止し、プロキシノードを1つに固定します。システムプロキシ、TUN、ブラウザーのセキュアDNSが現在有効かどうかを記録してください。
2. DNSLeakTestを開き、Extended testを実行します。表示されたリゾルバーのIPアドレス、運営組織、地域を記録してください。
3. 一度だけ直接接続でテストしても問題ない場合は、プロキシをオフにして再テストし、ローカルネットワークの基準値を記録します。プロキシを再び有効にしたら、もう一度テストしてください。以前開いたタブの結果を新しい結果と混同しないようにしましょう。
4. プロキシを有効にしても基準値と同じISPのリゾルバーが表示される場合は、さらに原因を調べます。想定どおりのパブリックリゾルバーだけが表示された場合も、そのリゾルバーへの接続が直接接続かプロキシ経由かを確認してください。

テストサイトで確認できるのは、主に再帰リゾルバーから権威DNSへのアクセス時の出口です。「PCから再帰リゾルバーまで」の通信経路を単独で証明することはできません。共有リゾルバー、Anycast、キャッシュなども結果に影響します。国名だけで結論を出さず、クライアントの接続ログと合わせて確認してください。

ブラウザーのDNS経路を一時的にそろえる

デスクトップ版Chromeの場合、「設定」→「プライバシーとセキュリティ」→「セキュリティ」→「セキュアDNSを使用する」を開きます。まずシステムからmihomoまでの経路を調べるため、この項目を一時的にオフにし、テスト後に戻すか判断してください。組織のポリシーで管理されているブラウザーでは、設定を変更できない場合があります。

ブラウザー内蔵のDoHはHTTPSを使うため、通常はUDP 53の通信ではありません。TUN経由でプロキシ通信されることはありますが、dns-hijackを設定しても、自動的にmihomoのDNSモジュールへ切り替わるわけではありません。Androidの「プライベートDNS」も個別に記録し、異なるDNS経路の結果を混同しないようにしましょう。

コアのDNSが実際に問い合わせを受け取っているか確認する

以下の例では、コアのDNSをローカルの1053ポートで待ち受けさせます。digをインストール済みのmacOSまたはLinuxでは、ポートを指定して直接テストできます。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

WindowsではPowerShellで次のコマンドを実行し、システムのデフォルトの名前解決経路を確認できます。ただし、ローカルの1053ポートに直接問い合わせる方法とは異なります。TUNを有効にしたら、コアのDNSログにこのリクエストが記録されるかも確認してください。

Resolve-DnsName example.com -Type A
Get-DnsClientServerAddress

fake-ip・nameserver・ブートストラップDNSの役割

fake-ipは通常、アプリにマッピング用アドレスを返し、その後の接続をコアが元のドメインに対応付けます。例にある198.18.0.1/16はベンチマーク用のアドレス範囲であり、実在サイトのグローバルIPではありません。この範囲のアドレスが返っても、サイトの名前解決に問題があるとは限らず、上流への問い合わせがプロキシで保護されている証拠にもなりません。

fake-ip-filterでは、Fake-IPを返さないドメインを指定します。LAN内の一部サービスで実アドレスが必要な場合は、必要に応じて例外を追加してください。互換性の問題を解消するために、すべてのドメインをフィルターに入れるのは避けましょう。フィルターが変えるのは返却アドレスの処理方法であり、上流へのルーティング設定の代わりにはなりません。

上流DNSを設定する：プロキシのルールを明示

以下は名前解決の経路を説明するためのmihomo設定例で、設定ファイル全体ではありません。既存の設定にProxyという名前のポリシーグループがあり、利用可能なノードが含まれている前提です。通常の問い合わせとテスト用のexample.comへの問い合わせをプロキシ経由の上流へ送り、ブートストラップ用の直接接続経路は明示的に残しています。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#Proxy"
  nameserver-policy:
    "+.example.com":
      - "https://8.8.8.8/dns-query#Proxy"

• #Proxyで、このDNS上流に既存の送信ルールを指定します。ポリシーグループ名は大文字・小文字も含めて完全に一致させてください。引用符で囲むことで、アドレス全体をYAML文字列として明確に扱えます。
• +.example.comは、該当ドメインとそのサブドメインに一致します。これは再現可能なテスト用の設定で、実際のサービス向けドメイン一覧ではありません。運用前に必要に応じて置き換えるか削除してください。
• 例のdefault-nameserverは直接接続するブートストラップ用リゾルバーです。proxy-server-nameserverも、意図的に直接接続の経路として残しています。ノードサーバーにドメイン名を使用する場合、このリゾルバーへの問い合わせでノードのドメイン名が開示されます。
• この例ではIPアドレス形式のDoHエンドポイントを使い、上流ホスト名の名前解決への依存を減らしています。ただし、ネットワークから到達できること、証明書が正しく検証されること、プロキシノードが該当する接続に対応していることが必要です。

既存の設定でrespect-rulesを使っている場合

mihomoのrespect-rules: trueを有効にすると、DNS接続にルーティングルールを適用できます。ただし「ルールに従う」ことは「必ずプロキシ経由になる」ことを意味しません。リゾルバーへの接続先がルールでDIRECTに一致すれば、直接接続されます。この方式を使う場合は、適切なproxy-server-nameserverを設定し、上流リゾルバーのアドレスに実際にどのルールが適用されるか確認してください。

まず検証しやすい上流のルーティング方式を1つ選び、段階的に統合してください。fallbackや複数のルールを一度に追加してからテストすると、どの変更が問い合わせの出口を変えたのか特定しにくくなります。また、ファイル末尾にdns:を追加するだけでは不十分です。既存の設定を編集し、キーの重複による設定の上書きや読み込み失敗を防いでください。

TUNでシステムDNSを取り込む：ポート53の通信を処理

システムプロキシだけを有効にしている場合、プロキシ設定を使わないプログラムはシステムDNSへ直接問い合わせることがあります。TUNはより多くのIP通信を取り込み、DNSハイジャックと組み合わせることで、従来型DNSのリクエストをコアへ転送できます。以下は該当するTUN機能に対応したmihomo環境向けの設定例です。クライアントには仮想ネットワークアダプターの作成とルート変更の権限が必要です。

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

any:53はUDP DNSを対象とし、tcp://any:53でTCP DNSも処理します。ここでのハイジャックはTUNの処理経路に入った接続に適用され、LAN全体のDNSを強制的に変更するものではありません。ローカルネットワークのDNS宛てルートを特別に扱うOSもあるため、実際にリクエストがコアへ届いているかログで確認してください。

• DoHとDoT：HTTPSを使うDNSは通常443番ポート、DoTは通常853番ポートを使うため、上記のポート53のハイジャック対象外です。それぞれの送信ルールを確認してください。
• 複数のネットワークアダプター：有線LAN、Wi-Fi、仮想マシンのアダプター、ほかのVPNによってデフォルトの出口が変わることがあります。TUNを有効にした後に通信できなくなった場合は、まず自動選択された出口アダプターを確認してください。
• IPv6：dns.ipv6はDNSのAAAAレコードへの応答を制御する設定であり、システム全体のIPv6を切り替えるものではありません。Aレコードだけをテストしても、IPv6通信が取り込まれているとは判断できません。
• LAN：NAS、プリンター、社内ネットワークのホスト名では専用リゾルバーが必要な場合があります。該当ドメインに個別のルールを設定し、想定される直接接続の問い合わせもテスト記録に含めてください。

TUNを使わない場合でも、OSが対応していればDNSの参照先をコアの待ち受けアドレスにできます。ただし、通常のシステムDNS設定ではポートを指定できないことが多く、例の待ち受けポートは53ではなく1053です。127.0.0.1だけを設定しても自動的には接続できません。待ち受けポートを変更する際は、権限とポートの競合にも注意してください。

保存・キャッシュ削除・再テスト：順番に対策を確認

有効な設定を確認してからキャッシュを調べる

サブスクリプションを管理するクライアントでは、更新時に設定ファイルが再生成されることがあります。DNSの変更はクライアントが対応するオーバーライドやマージ機能で保存し、一時的にダウンロードしたファイルだけでなく、最終的に適用される設定を確認してください。コマンドラインで運用している場合は、まず設定をテストします。実行ファイル名がmihomoの場合、コマンドは次のとおりです。

mihomo -t -f config.yaml

テストに成功してから再読み込みしてください。成功しても、コアが設定を受け付けたことを示すだけで、ノード、リゾルバー、ネットワークへの到達性までは保証されません。GUIクライアントを使う場合は再読み込み後の起動ログを確認し、DNSの待ち受け失敗、権限不足、ポリシーグループの未定義などのエラーがないか調べてください。

WindowsではシステムのDNSキャッシュを消去してから、再度問い合わせます。ブラウザーに独自のキャッシュや既存の接続が残っている場合は、完全に終了してから起動し、テストページを開き直してください。モバイル端末では、現在のネットワークを一度切断して再接続してからテストします。

ipconfig /flushdns
Resolve-DnsName example.com -Type A

3つの証拠を照合する

1. 入口の確認：システムから問い合わせたときに、コアがDNSリクエストを受け取っていることを確認します。1053ポートへの直接問い合わせと、システム経由の問い合わせは分けて検証してください。
2. ルーティングの確認：接続ログで、DoHのテスト用エンドポイント1.1.1.1:443または8.8.8.8:443への接続に想定したプロキシルールが適用されていることを確認します。必要に応じて一時的にlog-level: debugを設定して調査し、終了後は元のログレベルに戻してください。
3. 外部からの確認：テストページを再実行し、リゾルバーの運営組織が想定どおりで、使用する予定のないローカルISPのリゾルバーが表示されないことを確認します。地域が異なるだけでは失敗と判断できません。

デバッグログには、アクセスしたドメイン名、ノードのアドレスなどのネットワーク情報が含まれることがあります。ログを共有する前に、サブスクリプションのURL、認証情報、公開する必要のないドメイン名を削除してください。設定ファイル全体を公開の掲示板に貼り付けないでください。

よくある症状と次の確認項目

最終的な合格基準は、テストページにIPアドレスが1つだけ表示されることではなく、名前解決の経路が決めたルールに沿っていることです。直結での名前解決を許可するドメインを明確にし、システムの入口、コアの上流、プロキシのルーティングを対応させれば、実際のリーク、正常な振り分け、リゾルバー表示の違いを区別できます。各項目の詳細は応用設定を、基本的な設定手順はクライアント設定ガイドを参照してください。

設定の根拠と確認先

• mihomoドキュメント：DNS設定で、上流リゾルバー、ドメインルール、Fake-IP、プロキシサーバーの名前解決に関する項目を確認できます。
• mihomoドキュメント：TUNインバウンドで、DNSハイジャック、自動ルーティング、OSごとの差異を確認できます。
• DNSLeakTestのテストページでは、再帰リゾルバーの出口を確認できます。結果はコアのログと合わせて判断してください。