応用設定 読了時間：約14分

Clash DNS設定ガイド：nameserver、fallback、fake-ipとDNSハイジャック

ClashのDNS設定を解説。nameserverとfallbackの違い、fallback-filterの判定、fake-ipとredir-hostの比較、TUNでのDNSハイジャック設定を紹介します。

まずカーネルを確認してからDNSを設定

ClashのDNS設定が反映されるかどうかは、現在のカーネルが各フィールドに対応しているか、アプリの名前解決リクエストが実際にカーネルへ届くかで決まります。dns.enableをtrueにしただけで、Windows上のすべてのアプリがこのDNSを使うわけではありません。システムプロキシを有効にしても、システムのUDP 53番ポートへの問い合わせが自動的に処理されるわけではありません。

Clash for Windowsの開発・保守は終了しています。これはクライアントの画面であり、接続を実際に処理するのは使用中のカーネルです。従来のClash、Clash Premium、Clash Meta（現mihomo）では、利用できる機能がそれぞれ異なります。この記事では、まず一般的なDNSフィールドを解説し、その後mihomoのTUN設定例を紹介します。新しいカーネル向けの設定を旧クライアントにそのまま上書きしないでください。

  1. クライアントのGeneral（一般）画面でカーネル情報を確認します。画面に表示されない場合は、Logs（ログ）で起動時の記録を確認してください。
  2. Profiles（プロファイル）で現在選択されている設定を確認し、編集前にコピーを保存します。サブスクリプションの更新によって、直接編集した内容が上書きされることがあります。
  3. Mixinや設定のオーバーライドが有効になっていないか確認します。トラブルシューティングでは、サブスクリプションの元ファイルだけでなく、最終的に適用された設定を確認してください。
  4. 変更するパラメーターは一度に一組にし、再読み込み後にログを確認します。不明なフィールド、起動失敗、リッスン失敗が発生した場合は、まず直前の正常な設定に戻してください。

DNSの基本フィールド：待ち受け・上流サーバー・名前解決のブートストラップ

以下はトラブルシューティング向けのDNS基本設定例です。応答には実際のIPアドレスを返すredir-hostを使用しています。完全なサブスクリプション設定ではないため、既存設定のトップレベルに統合してください。同じファイルにdns:マッピングを複数記述すると、値の上書きや解析エラーにつながるため、1つだけ残します。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
フィールド 設定例 役割と注意点
enable true カーネルのDNS機能を有効にします。これだけですべてのアプリの名前解決経路が変更されるわけではありません。
listen 127.0.0.1:1053 ローカルDNSの待ち受けアドレスです。接続先はローカルマシンに限定されます。この記事ではテスト用に1053番ポートを使用します。
ipv6 false カーネルDNSがAAAAレコードにどう応答するかを制御します。システムのIPv6ネットワークアダプターを無効にする設定ではありません。
default-nameserver 223.5.5.5 主にDNS上流サーバーのホスト名を解決し、暗号化DNSサーバーへの接続に必要なブートストラップを行います。
nameserver 2つのDoHアドレス 通常のドメイン問い合わせに使う主な上流サーバーです。リストの順に必ず再試行されるわけではありません。

1053、53、7890を混同しない

通常のDNS問い合わせには、一般に53番ポートを使います。設定例では既存サービスとの競合を避けるため1053番を使用していますが、WindowsのネットワークアダプターにあるDNSアドレス欄では、通常このようなカスタムポートを指定できません。ポート指定に対応した問い合わせツールでテストするか、TUN経由でDNSリクエストをカーネルに渡してください。7890などのプロキシポートはHTTP/SOCKSなどのプロキシ接続用であり、DNSポートとしては使えません。

DoHは通信を暗号化するが、接続性を保証するものではない

https://dns.alidns.com/dns-queryはDNS over HTTPS（DoH）のアドレスです。カーネルはHTTPS接続を確立する前に、DNSサーバーのホスト名に対応するIPアドレスを知る必要があるため、ブートストラップが必要です。DoHは問い合わせ内容をHTTPSで暗号化しますが、サーバー側には問い合わせ内容が見えます。経路に接続できない、証明書の検証に失敗する、システム時刻が正しくないといった場合は、名前解決に失敗します。

「速くする」ために上流サーバーを一度に十数個も追加するのは避けましょう。まずは現在のネットワークから安定して接続できるDNSサーバーを1～2個に絞り、応答を確認してから他の設定を追加します。ここで示すアドレスは記述例であり、あらゆるプロバイダーのネットワークで利用できることや、低遅延を保証するものではありません。

nameserverとfallback：タイムアウト時の予備だけではなく応答結果を選別

fallbackは「1台目のDNSが応答しなければ2台目に問い合わせる」と誤解されがちですが、Clashではfallback-filterを使って、どちらの応答を採用するかも判定します。上流サーバーを2グループ設定した場合、カーネルは通常、並行して問い合わせます。通常の問い合わせではまずnameserverの応答を考慮し、フィルター条件に基づいてfallbackの応答を採用するか判断します。

以下は従来のGeoIPフィルター設定例です。2つ目のトップレベルdnsを追加するのではなく、前のセクションのdns設定に統合してください。例のGeoIP判定は、カーネルに実際に読み込まれているデータベースに依存します。

  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.example.com'

fallback-filterの判定順序

  • domain：指定したドメイン条件に一致すると、fallbackの名前解決結果が優先されます。ここで使う+.example.comは構文説明用の予約ドメインです。実際の設定では必要なドメインに置き換えるか、この項目を削除してください。
  • ipcidr：nameserverから返されたアドレスが指定したネットワーク範囲に含まれる場合、fallbackに切り替える候補として扱います。240.0.0.0/4はよく使われる設定例であり、異常なアドレスを網羅した一覧ではありません。
  • geoip：有効にすると、geoip-codeを使って主要な応答が想定した地域に属するか判定します。CNを指定した場合、主要な応答がCN以外であればfallbackの結果を採用する処理が行われます。

たとえば、あるドメインに対してnameserverがCNとしてデータベースに認識されるアドレスを返し、ほかのフィルター条件にも一致しなければ、通常はその結果を採用します。CN以外のアドレスが返された場合はfallbackの結果に切り替えます。これは判定の流れを説明する例であり、実測結果ではありません。実際のCDNアドレス、データベース上の地域判定、問い合わせ結果は変わることがあります。

また、DoHサーバーをfallbackに設定しても、必ずプロキシ経由になるとは限りません。DNS上流への接続方法は、カーネルの種類やバージョン、関連設定に左右されます。現在のネットワークから直接接続できないDNSサーバーを使う場合は、まず接続経路を確認してください。「海外のDNSに変更する」だけでは問題解決になりません。明確なフィルタリング要件がなければ、まずnameserverだけを設定すると原因を特定しやすくなります。

fake-ipとredir-host：仮想アドレスと実アドレスの違い

2つのモードの大きな違いは、アプリに返すDNS応答です。redir-hostは通常、上流DNSから返された実際のアドレスを返し、ドメインとアドレスの対応関係を管理します。一方、fake-ipはドメインごとに仮想IPアドレスを割り当てます。そのアドレス宛ての接続をカーネルが受け取ると、対応表からドメインを特定し、ルール判定と通信処理を行います。

比較項目 fake-ip redir-host
アプリに返されるアドレス 通常はカーネルが割り当てた仮想アドレスです。 通常は上流DNSが返した実際のアドレスです。
ドメインの識別 仮想アドレスとの対応表からドメインを特定します。透過的に通信を処理する用途に適しています。 名前解決の記録をもとに対応関係を管理します。共有IPなどでは判定が複雑になることがあります。
互換性に関する注意点 DNS応答を直接使って通信先を調べたり、LAN内の機器を検出したりするアプリでは、例外設定が必要な場合があります。 一般的なDNSの動作に近い一方、早い段階で実際の名前解決結果に依存します。
テスト方法 pingの成否ではなく、接続がカーネルに届いているか、ドメインが対応付けられているかを確認します。 実際の名前解決結果、ルールの適用状況、その後の接続を確認します。

fake-ipの基本設定例

  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'

198.18.0.0/16はベンチマークテスト用に予約されたアドレス範囲であり、接続先サイトの実際のグローバルIPアドレスではありません。問い合わせ結果が198.18.x.xでも、直ちにDNS汚染と判断しないでください。fake-ipモードでは想定どおりの応答である可能性があります。アプリの接続を正常に処理するには、この対応関係を認識できるカーネルを経由する必要があります。

fake-ip-filterに一致したドメインには仮想アドレスを割り当てません。ただし、ドメインに直接接続するルールが自動で作成されるわけではありません。LAN内のドメインをフィルターする場合は、それらを名前解決できる経路も必要です。特に.localはmDNSで使われることが多く、マルチキャストによる機器検出はシステムやLAN環境にも左右されるため、フィルターリストへの追加だけでは解決できません。

fake-ipを使うためにTUNが必須というわけではありません。重要なのは、DNS応答に対応する接続がカーネルに届くことです。逆に、TUNとredir-hostを組み合わせることもできます。モードを切り替えた後は、古い実アドレスや仮想アドレスが使われ続けないよう、システムのDNSキャッシュを消去し、影響を受けるアプリを再起動してください。

TUNでDNSをハイジャック：53番ポートの問い合わせをカーネルに渡す

TUNは仮想ネットワークインターフェースを作成し、ルーティング条件に一致したIP通信をカーネルに取り込みます。dns-hijackはその中のDNSリクエストを識別し、内蔵DNSモジュールに渡します。すべてのDNSパケットを書き換える機能でも、暗号化通信を解読する機能でもありません。リクエストが先にTUNへ入って初めて、ハイジャックのルールが処理できるようになります。

mihomoでUDP・TCPの53番ポートを処理する設定例

以下はmihomoでよく使われるフィールドの組み合わせです。有効なdns設定と併用してください。現在使用しているカーネルが各オプションに対応していることを先に確認してください。旧版のClash for Windowsに付属するカーネルには、そのまま適用できません。Windowsでは通常、インターフェースやルートを作成するためにクライアントのサービス、または十分な権限も必要です。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • stack: mixedは混合プロトコルスタックを選択するカーネル機能の設定です。古いバージョンを含め、どの環境でも使える汎用スイッチではありません。
  • auto-route: trueは関連するルートを自動設定しますが、すべてのアプリ、ネットワークアダプター、ほかのVPNが作成した経路をカバーするとは限りません。
  • auto-detect-interface: trueは送信インターフェースを自動判定します。複数のネットワークアダプターや仮想アダプターを使っている場合は、引き続き設定を確認してください。
  • any:53はUDP 53番ポートへの問い合わせに一致し、tcp://any:53はTCP 53番ポートを追加で処理します。応答サイズが大きい場合や再試行時には、TCPが使われることがあります。

ハイジャックを有効にしても、別のDNS接続が発生する理由

ブラウザーの「セキュアDNS」はDoHサーバーに直接接続する場合があり、Androidの「プライベートDNS」は通常DoTを使用します。いずれも通常のUDP/TCP 53番ポートへの問い合わせではないため、上記の2つのルールでカーネルDNSに転送されるとは限りません。アプリが独自にDoHリクエストを送る場合、通常のHTTPS接続としてプロキシ経由になることはありますが、「通信がプロキシを通ること」と「名前解決がカーネルDNSに委ねられること」は別です。

トラブルシューティングでは、まずブラウザーのセキュアDNSを一時的に無効にし、システムの名前解決経路で比較してから、再び有効にするか判断してください。オンラインのDNSチェックサイトを一度見ただけでDNSリークと判断しないでください。表示されるのは再帰DNSサーバーの出口アドレスであり、端末やプロキシノードのアドレスとは限りません。接続ログ、実際の出口、システム設定、パケットキャプチャを合わせて確認してください。

順番に確認：待ち受け・名前解決・通信の取り込み・ルール

「TUNを有効にしたらWebページが開けない」という場合でも、ノード、DNS、プロトコルスタックを同時に変更しないでください。次の順序で確認すれば、問題のある段階を絞り込めます。名前解決の失敗をノードの障害と誤認することも防げます。

  1. 待ち受けを確認：設定が再読み込みされ、ログにアドレスの競合や権限エラーがないことを確認します。この記事ではテスト用に127.0.0.1:1053を使用します。実際の設定で別のポートを使っている場合は、テストコマンドも同じポートに変更してください。
  2. カーネルDNSへ直接問い合わせ：ローカルサーバーとポートを明示し、システムの既定DNSを使わずにテストします。ここで失敗する場合は、上流サーバーへの接続、ブートストラップ、設定の構文を確認してください。
  3. 既定の経路を確認：TUNを有効にした後、サーバーを指定せずに問い合わせ、カーネルのログと照らし合わせてシステムのリクエストが取り込まれているか判断します。
  4. 実際の接続を確認：クライアントの接続一覧で、接続先ドメイン、適用されたルール、プロキシグループ、送信ノードを確認します。名前解決に成功しても接続がタイムアウトする場合は、ルール、ノード、ネットワーク経路を引き続き調べてください。

Windowsでの問い合わせとキャッシュの削除

コマンドプロンプトでnslookupを実行して対話モードに入り、次の3行を順番に実行します。基本的な問い合わせにはexample.comを使用します。応答値はあらかじめ指定していません。

server 127.0.0.1
set port=1053
example.com

対話モードを終了したら、次のコマンドでWindowsのDNSキャッシュを削除できます。ブラウザーにも別のキャッシュがある場合があるため、必要に応じて完全に終了してから再起動してください。

ipconfig /flushdns

macOS・Linuxでの問い合わせ例

digがインストールされている環境では、UDPとTCPを個別にテストできます。どちらのコマンドもローカルの1053番ポートに直接問い合わせるため、システムの既定DNSが変更されたかどうかの確認には使えません。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp

よくある質問と設定の仕上げ

システムプロキシだけ有効にしたのに、DNSがシステム設定のままなのはなぜ？

システムプロキシの影響を受けるのは、主にプロキシ設定に従うアプリです。システムDNSを一括して処理する機能ではありません。アプリによってはローカルで名前解決したり、プロキシ側に解決を任せたりします。通常のDNSも処理したい場合は、TUNとDNSハイジャックを正しく設定し、ブラウザー内蔵の暗号化DNSも個別に確認してください。

サブスクリプションの更新後、手動で変更したnameserverが消えるのはなぜ？

サブスクリプションの設定ファイルは、新しくダウンロードした内容で置き換えられるのが一般的です。ローカル設定を保持するには、現在のクライアントが対応しているMixinや設定のオーバーライド機能を使い、最終的な統合結果を確認してください。リスト項目を置換するか追加するかはクライアントによって異なります。編集画面で保存できたかどうかだけでは判断できません。

fallbackを設定すれば、異常な名前解決をすべて防げる？

いいえ。選別結果は応答アドレス、ドメイン条件、GeoIPデータベース、上流サーバーへの接続状況に左右されます。誤った応答がフィルター条件に一致しない場合もあれば、正常なCDNアドレスが地域フィルターに一致する場合もあります。fallbackサーバーを際限なく増やすのではなく、対象ドメインの問い合わせ記録を確認して調整してください。

fake-ipでLANプリンターやNASに接続できない場合は？

まず機器の実際のアドレス、LAN内ドメインの名前解決元、直接接続ルールを確認し、互換性の問題が確認できたドメインだけをfake-ip-filterに設定してください。ネットワークでmDNS、ブロードキャストによる機器検出、社内DNSを使っている場合は、それぞれに必要なローカル検出・名前解決経路も維持する必要があります。

最後に確認する点は4つです。DNSの待ち受けに接続できること、上流サーバーに到達できること、アプリの名前解決リクエストが想定した経路に入ること、接続に正しいルールが適用されること。まずこの4点を個別に確認してから、fallbackフィルター、fake-ipの例外、複雑なドメイン別名前解決を追加してください。再現可能な基本設定を保てるうえ、サブスクリプションの更新やクライアントの変更後も設定を戻しやすくなります。

Clashをダウンロード