上級設定 読了目安 12分

ClashのDNS設定を徹底解説：nameserver・fallback・DNSハイジャックの書き方

dnsセクションのenable、enhanced-mode、nameserver、fallback、fallback-filter、listenを項目別に解説。すぐ使えるYAML例とよくある落とし穴も紹介します。

まずClash DNSの処理経路を整理する

ClashのDNS設定は、システムDNSを別のアドレスに置き換えるだけではありません。内蔵DNSを有効にすると、クライアントはドメイン名の問い合わせを受け取り、nameserver、fallback、ルール、拡張モードに基づいて名前解決を行います。接続時には、Clashがドメイン名、解決結果、プロキシルールを関連付けるため、DNS設定はルールのマッチ、初回表示速度、一部アプリの動作に直接影響します。

一般的な問い合わせは4段階に分けられます。アプリがexample.comを問い合わせる、システムまたはTUNが53番ポートのリクエストをClashへ渡す、Clashが設定した上流サーバーで名前解決する、その後の接続リクエストがドメインルール、IPルール、最終ルールに従って直通またはプロキシに振り分けられる、という流れです。どこか一段でもClashを迂回すると、ドメインルールがマッチしない、解決結果がキャッシュに残る、Webページは開くのにアプリだけ接続できない、といった問題が起こります。

項目 担当すること 担当しないこと
enable Clash内蔵DNSモジュールを有効にする システムのすべてのDNS通信を自動的に引き受けるわけではない
listen DNSサービスの待受アドレスとポートを指定する DNSハイジャックを単独で実行するわけではない
nameserver 主な名前解決結果を提供する プロキシのポリシーグループを自動的に決めるわけではない
fallback 予備の名前解決結果を提供する メインサーバーのタイムアウト後だけ問い合わせる単純なバックアップではない
dns-hijack TUN層で指定された宛先へのDNSリクエストを引き受ける 上流DNSの設定を代替するものではない

enable・listenと基本項目の書き方

enable：内蔵DNSを有効にする

enable: trueはClashのDNSモジュールを有効にします。falseにすると、ほかのdns項目は想定どおり名前解決に使われません。設定の読み込みに成功したからといって、問い合わせがすでにこのモジュールへ届いているとは限りません。システムプロキシ、TUN、クライアントのネットワーク拡張もあわせて確認しましょう。

listen：ローカルDNSの待受ポートを指定する

listen: 127.0.0.1:1053は、ローカルループバックアドレスのUDP/TCP 1053番ポートでDNSサービスを提供します。1053はよく使われる非特権テスト用ポートで、システムが使用する53番ポートとの競合も避けられます。0.0.0.0:1053と記述すると、同じLAN上の端末からこのポートへ接続できる可能性があります。そのため、モバイル端末の日常的な設定では、ループバックアドレスを使うか、クライアントによる待受管理に任せるのが一般的です。

listenは「問い合わせをどこで待ち受けるか」を指定するだけで、「問い合わせを横取りする」設定ではありません。TUNを有効にしたデスクトップ環境では、通常tun.dns-hijackも設定する必要があります。iOSではDNSの引き受けをクライアントのNetwork Extensionが行うことが多く、YAMLのtunセクションを無視してアプリ独自のスイッチを使うクライアントもあります。

出発点にできる設定例

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true

  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  fallback:
    - https://8.8.8.8/dns-query
    - tls://1.0.0.1:853

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.com

この例は、Clash Metaまたはmihomoの構文に対応したクライアントで使える基本テンプレートです。クライアントによってはDoH、DoT、IPv6、TUNの項目を独自に処理するため、インポート後はまず設定の検証結果を確認してください。コアが古い場合は、geoip-code、DoTアドレス、拡張モードの項目を認識できるかどうかも確認しましょう。

nameserver・default-nameserver・fallbackの違い

default-nameserver：暗号化DNSの起動時名前解決に使う

nameserverにhttps://dns.alidns.com/dns-queryのようなドメイン名を含むDoHアドレスを指定すると、Clashはまずdns.alidns.comに対応するIPを知る必要があります。default-nameserverは主にこの起動時の名前解決を担い、bootstrap DNSとも呼ばれます。ここには直接到達できるIPアドレスを優先して指定し、「DoHのドメインを解決するためにDoHが必要になる」という循環を避けましょう。

すべての上流サーバーをドメイン名で指定し、default-nameserverにも到達できない場合、ログにはDNSリクエストのタイムアウト、起動直後にインターネットへ接続できない、上流ドメインの解決失敗が繰り返される、といった症状が現れます。切り分けでは、まず現在のネットワークから到達できるIP直書きのDNSを1つ残し、その後DoHアドレスを検証してください。

nameserver：通常の問い合わせに使う主要な上流サーバー

nameserverは通常の問い合わせで使う主要な上流サーバーです。従来のUDP DNS、TCP DNS、DoT、DoHを指定できます。UDPアドレスは223.5.5.5、DoTはtls://1.1.1.1:853、DoHはhttps://1.1.1.1/dns-queryのように記述します。プロトコルを混在させるとネットワーク制限の切り分けに役立ちますが、上流サーバーは多ければよいわけではありません。安定していて経路が明確な2台のほうが、6〜7個を並べるより障害を特定しやすいことが多いです。

fallback：フィルター条件に応じて予備の結果を選ぶ

fallbackは「nameserverがタイムアウトしたら使う予備DNS」と誤解されがちですが、実際には候補結果を並行して取得し、fallback-filterでどちらの結果を採用するか判断する動作に近いのが一般的です。並行処理、キャッシュ、結果選択の細部はコアのバージョンによって異なるため、従来型の主系・待機系の切り替えと考えないでください。

たとえばgeoip: trueを有効にし、geoip-code: CNを指定すると、主要DNSの結果がフィルター条件に合わない場合に、コアがfallbackの結果を採用できます。domainに明示したドメインも、fallbackの結果を優先する対象にできます。ルールデータのバージョン、GeoIPデータ、上流サーバーが返すCDNアドレスのすべてが判定に影響するため、「IPが現地に見えない」だけで設定ミスと判断するのは避けましょう。

fallback-filterの各条件が適用される仕組み

geoipとgeoip-code

geoip: trueはIPの地理データに基づくフィルタリングを有効にし、geoip-code: CNは判定対象の地域コードを指定します。クライアントに同梱またはダウンロードされたGeoIPデータに依存する仕組みで、リアルタイム検索サービスではありません。データファイルの欠落、古さ、パス設定の誤りによって、想定と異なる結果になることがあります。

ipcidr

ipcidrは、fallbackの候補結果を採用するアドレスをCIDRネットワークで指定します。よくある240.0.0.0/4は予約アドレス範囲をカバーし、明らかに異常な解決結果を除外するために使われます。広いパブリックIP範囲をむやみに追加すると、正常なWebサイトまで継続的にfallbackへ回るため注意してください。

domain

domainは対象ドメインを指定します。mihomoでよく使われる+.example.comは、そのドメインとサブドメインにマッチします。少数のWebサイトだけに専用の上流DNSを割り当てたい場合、比較的新しいmihomo設定ではnameserver-policyも検討できます。特定ドメインを指定DNSへ直接割り当てられるため、広範囲なfallbackフィルタリングより意図が明確です。

dns:
  nameserver:
    - https://dns.alidns.com/dns-query

  nameserver-policy:
    "+.example.net":
      - https://1.1.1.1/dns-query
    "geosite:cn":
      - https://dns.alidns.com/dns-query

nameserver-policyでルールセット形式が使えるかどうかは、使用するコアとクライアントのパッケージ版に依存します。mihomo v1.19系の設定を使う場合は、クライアントに表示されるコアのバージョンと設定検証の結果を基準にしてください。古いClashコアを使っている場合は、未対応のルールセット構文をそのままコピーせず、通常のドメインリストに置き換えると安全です。

fake-ipとredir-hostの選び方

fake-ip：予約アドレスを返し、実際のドメインと関連付ける

enhanced-mode: fake-ipは、指定したアドレスプールからマッピング用のアドレスを返します。よく使われる範囲は198.18.0.1/16です。アプリがそのアドレスへ接続すると、Clashは内部マッピングから元のドメインを復元し、ルールを適用します。特定の状況では余分な名前解決の待ち時間を減らし、ドメインルールの情報も維持しやすくなります。

テスト環境でdig @127.0.0.1 -p 1053 example.com Aを実行し、198.18.x.xが返れば、通常はリクエストがfake-ipの処理に入っています。この結果はWebサイトの実際のパブリックIPではないため、パブリックDNSの結果と一つずつ比較するものではありません。

fake-ip-filter：LANや特殊なドメインには実アドレスを返す

プリンター、ルーター、LAN内の検出機能、実IPに依存する一部サービスはfake-ipに適さない場合があります。fake-ip-filterでローカルドメインを除外できますが、実際に問題が起きたドメインから追加し、出所不明のリストを何百行もそのままコピーするのは避けてください。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "router.asus.com"
    - "time.apple.com"

*.localは、mDNSやLAN内検出に関係することが多いドメインです。iOSでAirPlay、AirPrint、スマートホーム機器の検出に問題がある場合は、まずこれらのドメインがfake-ipの対象になっていないか確認し、クライアントにローカルネットワークへのアクセスを許可しているかも確認してください。iOS 26では、「設定」→「プライバシーとセキュリティ」→「ローカルネットワーク」で権限を確認できます。

redir-host：実際の名前解決結果をそのまま返す

redir-hostは通常、アプリに実IPを返すため、互換性の仕組みを把握しやすい一方、ドメインと接続を関連付ける能力はトラフィックの引き受け方法に左右されます。銀行系アプリ、LAN機器、特殊プロトコルがfake-ipと互換性を持たない場合は、一時的にredir-hostへ切り替えて比較できます。切り替え直後に復旧したなら、ノード、ルール、DNSを同時に変更するのではなく、まずfake-ip-filterを見直しましょう。

DNSハイジャックとTUNモードの設定

ここでいうDNSハイジャックとは、ほかのDNSアドレスへ送られる53番ポートのリクエストをクライアントがClash内蔵DNSへ転送することです。アプリがシステムDNSを迂回し、固定DNSサーバーへ直接アクセスする問題を解決します。listenだけを設定しても、これらのパケットの宛先は変わりません。

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

any:53は一般的なDNSリクエストを引き受け、tcp://any:53はTCP DNSにも対応します。DoHはHTTPSの443番ポート、DoTは通常853番ポートを使うため、通常の53番ポートのハイジャックだけで完全に識別することはできません。アプリ内蔵のDoHについては、ドメインルール、接続ポリシー、またはアプリ自体の設定で対処する必要があります。

iPhoneやiPadでは、クライアントが通常iOS Network Extensionを通じてVPN構成を作成します。YAMLのtun項目が有効になるかはクライアントの実装次第です。システムとアプリの状態が一致しない場合は、「設定」→「一般」→「VPNとデバイス管理」→「VPN」で現在の接続を確認し、その後クライアントのログにDNS timeout、no such host、上流接続失敗が出ていないか確認してください。

設定後の確認手順

  1. まず構文を検証します。 YAMLのインデントにはスペースを使い、Tabを混在させないでください。dnsとtunが正しい階層にあり、リスト項目の前にハイフンがあることを確認します。
  2. 待受状態を確認します。 デスクトップ版では、コアが1053番ポートを待ち受けているか確認できます。ほかのプログラムが使用中なら、1054番ポートへ変更し、テストコマンドも合わせて修正してください。
  3. キャッシュされていないドメインを問い合わせます。 コマンドラインを使える端末でdig @127.0.0.1 -p 1053 example.com Aを実行します。fake-ipモードでは198.18.0.0/16の範囲内のアドレス、redir-hostモードではパブリックIPが返るはずです。
  4. 初回と2回目の問い合わせを比較します。 同じテスト環境で、初回が1800ミリ秒、2回目が20ミリ秒なら、通常はキャッシュは正常ですが上流接続の確立に時間がかかっています。毎回2000ミリ秒を超えてタイムアウトする場合は、DoHの経路とdefault-nameserverを確認してください。
  5. ルールのマッチを確認します。 明確なドメインルールがあるWebサイトを開き、クライアントの接続ログで、意図せずIP-CIDRやMATCHにフォールバックしていないことを確認します。
  6. 古いキャッシュを削除して再テストします。 拡張モードを変更した後は、コアを再起動するか、クライアントのDNSキャッシュ更新機能を使ってください。Webページを再読み込みするだけでは、アプリ、システム、ブラウザに保存された古い結果が使われることがあります。
症状 優先して確認する項目 対処方法
すべてのドメインでタイムアウトする enable、上流サーバーへの到達性、default-nameserver 一時的にIP直書きのUDP DNSへ変更し、基本経路を確認する
IPには接続できるが、ドメインには接続できない DNSの引き受けと待受ポート TUN、Network Extension、dns-hijackを確認する
LAN機器だけ使えない fake-ip-filter、ローカルネットワークの権限 .local、.lan、機器で実際に使われるドメインを除外する
一部のWebサイトが異なる地域へ解決される fallback-filter、GeoIPデータ データファイルを更新し、domainとipcidrの範囲を絞る
サブスクリプション更新後に設定が消える 設定の保存先 DNSセクションを上書き設定またはマージ設定へ移す

よくある誤解と推奨する調整順

上流サーバーを増やせば安定すると考える

上流サーバーを増やすほど、経路の違い、並行結果、ログのノイズも増えます。切り分け中はUDP DNSを1つ、DoHを1つだけ使い、それぞれに到達できることを確認してから追加を検討してください。モバイル回線、職場のWi-Fi、家庭のブロードバンドでは53、853、443番ポートへの制限が異なる場合があるため、安定性は現在のネットワークで実測して判断します。

fallback、policy、大量のフィルターを同時に有効にする

fallback-filter、nameserver-policy、プロキシルールは、1回のアクセスに共同で影響します。最初から条件を大量に追加すると、最終的にどの設定が決め手になったのか分かりにくくなります。推奨順序は、まずnameserverを正常に動かし、次にfake-ipまたはredir-hostを選び、その後少数のpolicyを追加し、最後にfallbackフィルタリングを導入することです。

DNSの問題をノードの問題と決めつける

DNS問い合わせは、ノードへの接続前または接続と並行して行われます。プロキシノードを変更して一時的に復旧しても、キャッシュが更新された、または上流接続が再確立された可能性があります。判断するときはログを確認してください。解決段階でcontext deadline exceededやno such hostが出るなら、まずDNSを調べます。対象IPの取得後にプロキシのハンドシェイクがタイムアウトする場合に、ノードや経路を確認しましょう。

IPv6設定の前後で食い違う点を見落とす

ipv6: falseは通常、DNSモジュールがAAAAレコードを返さないことを意味しますが、システム、TUN、プロキシノードにはそれぞれ独自のIPv6設定が残る場合があります。IPv6経路が不安定なネットワークでは、まずDNSのIPv6を無効にして比較してください。IPv6専用サービスへの接続が必要なら、ローカルネットワーク、ノード、ルールのすべてがIPv6に対応していることを確認する必要があり、この項目だけをtrueに変更しても解決しません。

安定した設定の要点は、経路を明確にすることです。default-nameserverで起動時の名前解決を行い、少数のnameserverで通常の問い合わせを処理し、地域による選別が必要な場合だけfallbackを追加します。fake-ipまたはredir-hostでドメインと接続の関係を保ち、最後にTUNまたはiOSのネットワーク拡張で実際の通信を引き受けます。この順序で調整すれば、DNSタイムアウト、ルールの不一致、LANの異常を段階的に切り分けやすくなります。

Clashをダウンロード 各プラットフォームのクライアントを見る