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

DNS名前解決・プロキシルール・接続経路を切り分ける

Clash設定のDNSモジュールは、ドメイン名をアドレスに解決し、特定の拡張モードではドメインと接続の対応関係を保持します。プロキシルールは、リクエストをDIRECT、REJECT、特定のプロキシノード、またはポリシーグループのどれに振り分けるかを判断し、実際の接続は選択された経路から確立されます。これら3つは相互に影響しますが、同じものではありません。

たとえば、ブラウザーでドメインにアクセスすると、システムがまずローカルDNSへ問い合わせることがあります。Clashがその問い合わせを受け取ると、設定に応じて上流のリゾルバーを選び、実際のアドレスまたはFake IPをブラウザーへ返します。その後ブラウザーが接続を開始すると、Clashはドメイン名、宛先アドレス、ルールの順序、現在のモードを組み合わせて経路を決定します。設定にDNSサーバーを1つ追加しただけで、すべての接続がプロキシを通るわけではありません。同様に、特定のドメインルールをプロキシに指定しても、アプリが必ずClashのDNSモジュールを使うとは限りません。

名前解決の問題を調べる際は、まず3点を確認します。DNSリクエストが本当にClashへ届いているか、Clashがどの上流を選んだか、解決結果が後続のルールマッチングにどう使われたかです。「Webページが開かない」だけを見ていると、名前解決の失敗、ルールの誤判定、ノードの障害、システムプロキシの未適用を混同しやすくなります。

通常の名前解決と拡張モードの違い

一般的な実装では、enhanced-modeにfake-ipまたはredir-hostを指定できます。Fake IPモードでは、アプリに予約済みアドレス範囲の合成アドレスを返し、カーネル内にそのアドレスと元のドメイン名の対応関係を保存します。アプリがこの合成アドレスへ接続すると、Clashはドメイン名を復元してから、ドメインルールや後続の名前解決を実行できます。これによりドメイン情報を維持しやすくなり、アプリがClashの外部で独自に名前解決することによるルール判定のずれも抑えられる場合があります。

Redir-hostモードは通常、実際に解決されたアドレスをアプリへ返します。従来のDNS動作に近い一方、後続の接続で完全なドメイン情報を保持できるかは、トラフィックの入口、スニッフィング機能、アプリのプロトコル、カーネルの実装に左右されます。どちらのモードが常に優れているわけではありません。LAN機器、ゲーム、プリンターサービス、実アドレスを必要とするプログラム、一部の接続チェック機能ではFake IPフィルターが必要になることがあります。ドメインルールを安定して適用したい場合は、まずFake IPを試すとよいでしょう。

nameserverとdefault-nameserverの役割

nameserverは、ClashのDNSモジュールが通常のドメイン問い合わせを処理する際に使う主要な上流サーバーです。従来のUDP/TCP DNSに加え、カーネルが対応していればDoHやDoTのアドレスも指定できます。複数の上流を設定した場合の並列処理、キャッシュ、結果の選択方法はカーネルのバージョンによって異なるため、リストを単純な上から順番の再試行として考えることはできません。

default-nameserverは主に、DNSサーバー自身のドメイン名を解決するための導入用リゾルバーです。たとえばnameserverにhttps://dns.example.net/dns-queryを指定すると、ClashはDoH接続を確立する前にdns.example.netのアドレスを取得しなければなりません。導入用の名前解決まで、まだ接続できていないDoHサーバーに依存すると、依存ループが発生します。これを避けるため、デフォルトのリゾルバーには通常、直接アクセスできるIP形式のDNSアドレスを指定します。

この2つは「優先DNS」と「代替DNS」の関係ではありません。通常の問い合わせは主にnameserverが担当し、default-nameserverは基礎となる導入処理を担います。主要な上流が223.5.5.5のようなIPアドレスだけなら導入処理は目立ちませんが、ホスト名を含むDoHやDoTのエンドポイントを使う場合は、デフォルトリゾルバーの重要性が高まります。

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

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

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

この例ではAAAAレコードの処理を無効にしていますが、OSのIPv6機能を無効にすることや、すべてのアプリがAAAA問い合わせを停止することを意味しません。この設定では、ClashのDNSモジュールが呼び出し元へIPv6の名前解決結果を返さないという意味です。IPv6の接続経路が安定し、ルールとプロキシノードもIPv6に完全対応している場合は、直結経路とプロキシ経路を個別に検証したうえで有効化してください。

nameserver-policyの適用範囲

Mihomoなどの比較的新しいカーネルでは、nameserver-policyを使って、ドメイン名、ルールセット、Geosite分類ごとにリゾルバーを指定できます。ローカルドメインはLANのDNSへ、特定のサービスドメインは指定したDoHへ送るなど、ドメインごとに異なる名前解決経路が必要な場合に適しています。ポリシーに一致すると、指定されたリゾルバーが通常のnameserverより優先されます。

この項目はカーネルの対応状況とルールデータに依存するため、設定を移行する際はクライアントが実際に使用するカーネルのバージョンを確認してください。ルールセットが読み込まれていない、分類名に対応していない、または別系統の構文を使っている場合、ポリシーが想定どおり適用されないことがあります。基本設定を検証する前に、ドメインごとのDNS振り分けを一度に増やしすぎるのは避けましょう。

プロキシノードのドメイン名も解決が必要

プロキシサーバーのアドレスにドメイン名を指定した場合、カーネルはノードへの接続を確立する前にそのドメイン名を解決する必要があります。Mihomo設定のproxy-server-nameserverを使えば、この問い合わせ専用のリゾルバーを指定でき、ノードの名前解決が通常の通信経路に依存するのを避けられます。ノードのドメイン名を解決する際に、そのノード経由でリモートDNSへアクセスしようとすると、起動時に依存ループが発生する可能性があります。

同様に、direct-nameserverに対応したカーネルでは、直結トラフィック用のリゾルバーを指定できます。これらの拡張項目が必要かどうかは、設定の規模とネットワーク環境次第です。多くの基本設定では、まずdefault-nameserverとnameserverが正常に動作することを確認し、その後でノード用と直結用の名前解決を分けるほうが、問題を特定しやすくなります。

fallbackは単純な障害時の予備ではない

fallbackは、「nameserverがタイムアウトした後にだけ使う予備サーバー」と誤解されがちです。従来のClash DNS設計では、主要リゾルバーとfallbackリゾルバーに並列で問い合わせ、fallback-filterによってfallbackの結果を採用するか判断できます。そのためfallbackは、ネットワーク機器のように順番に切り替える予備DNSというより、別系統の候補となる名前解決経路に近いものです。

よく使われる判定条件には、GeoIP、指定したアドレス範囲、ドメインリストがあります。geoip: trueを有効にし、geoip-code: CNを設定すると、カーネルは主要リゾルバーの結果が属する地域に基づいてfallback候補を使うか判断できます。domainにはfallbackで常に判定したいドメインを指定でき、ipcidrでは特定のアドレス範囲を結果切り替えの条件として扱えます。

dns:
  enable: true
  enhanced-mode: fake-ip

  default-nameserver:
    - 223.5.5.5

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

  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853

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

この例は結果を絞り込む考え方を示したもので、すべてのネットワークにそのまま適用できるわけではありません。リモートDoHやDoTのエンドポイントに接続できるかは、ルーティング、プロキシ経路、証明書検証、システム時刻、カーネルのプロトコル対応状況にも左右されます。fallbackサーバー自体にアクセスできなければ、フィルターを増やしても利用可能な結果は得られません。

GeoIPフィルターの限界

GeoIPの判定はデータベースの内容に依存し、大規模サイトではCDN、Anycast、地域別の振り分けが頻繁に使われます。同じドメインでも地域によって異なるアドレスが返ることがあり、1つのアドレスに付いた地理情報だけでは現在のネットワークに適しているかを完全には判断できません。GeoIPは選別の目安として使い、可用性を絶対的に判定する仕組みとは考えないでください。

目的が明確な場合は、広範なGeoIP切り替えに頼るより、ドメインごとに名前解決ポリシーを設定したほうが説明しやすくなります。たとえばLAN内ドメインはルーターのDNSへ、社内ドメインは企業DNSへ、特定の公開サービスは指定したDoHへ送ります。この場合は、すべての問い合わせを2つのリゾルバーへ同時に送り、結果の地域で判断するより、まずnameserver-policyを検討してください。

TUNモードにおけるDNSハイジャックの役割

ここでいう「DNSハイジャック」は、ローカルのプロキシカーネルがTUNインターフェースへ入ってくるDNSリクエストを能動的に受け取ることを指し、パブリックDNSのレコードを書き換えるものではありません。TUNを有効にすると、アプリのトラフィックは仮想ネットワークインターフェースを通過します。dns-hijackを設定すると、指定したアドレスとポート宛ての従来型DNSリクエストをClash内蔵DNSモジュールへ転送できます。これにより、システムがDNSリクエストをルーターなど別のアドレスへ送っていても、カーネル側でFake IP、キャッシュ、上流の選択を一元管理できる可能性があります。

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

any:53は通常、任意のアドレスに対するポート53のDNSトラフィックを受け取る指定を表します。UDP、TCP、具体的な記法への対応は、OS、カーネルのバージョン、TUNスタックによって異なるため、クライアントが生成した有効な設定と起動ログを基準にしてください。TUNを有効にしただけでDNSリクエストを内蔵リゾルバーへ送らなければ、システムは従来のDNS経路を使い続ける可能性があり、Fake IPやドメインルールの動作も想定からずれることがあります。

DNSハイジャックですべての暗号化DNSを受け取れるわけではない

ブラウザーやアプリがDoHを内蔵し、HTTPSの443番ポートから独自の名前解決サービスへ直接接続することがあります。この通信はネットワーク上では通常のHTTPS接続に見えるため、ポート53のハイジャックだけでClashのDNS問い合わせへ自動的に変換されることはありません。DoTは通常853番ポートを使い、一般的な53番ポートの受け取り範囲にも含まれません。特定のブラウザーだけシステムと異なる名前解決結果になる場合は、アプリで独自のセキュアDNS機能が有効になっていないか確認してください。

アプリ内蔵のDoHトラフィックをプロキシルールで転送できたとしても、ドメインの名前解決はClash設定のnameserverではなく、アプリが選んだDoHサービスによって行われます。その結果、アプリが実IPを取得してから接続する、またはルールが宛先IPに対してしか適用できない、といった動作になることがあります。DNS経路を統一したい場合は、アプリの設定、システムDNS、TUNの受け取り範囲をまとめて確認してください。

LANと特殊なドメインはフィルタリングが必要

Fake IPモードでは、一部のローカルドメイン、デバイス検出用ドメイン、NTPサービス、ゲームプラットフォームの接続、実アドレスに依存するプログラムをfake-ip-filterに追加する必要がある場合があります。フィルター対象のドメインには通常、実際の名前解決結果が返され、Fake IPは割り当てられません。実際に問題が起きた項目を1つずつ追加し、多数のトップレベルドメインをまとめて除外するのは避けてください。Fake IPモードでドメインの対応関係を保持する利点が薄れてしまいます。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"
    - "ntp.*.com"

.localはmDNSによるデバイス検出に使われることが多く、実際の問い合わせが通常のユニキャストDNSを通らない場合があります。フィルターリストに追加してもFake IPの割り当てを防げるだけで、LANのマルチキャスト転送、システムファイアウォール、デバイス検出サービスの代わりにはなりません。LAN機器にアクセスできない場合は、TUNルート、除外するアドレス範囲、ローカルインターフェースの選択も確認してください。

DNSの結果がプロキシルールのマッチングに与える影響

Clashは通常、ルールを上から順番に評価します。DOMAIN、DOMAIN-SUFFIX、RULE-SET内のドメインルールはリクエストのドメイン名を直接利用できますが、IP-CIDRやGEOIPなどのルールには宛先アドレスが必要です。接続の入口がIPアドレスしか提供しない場合にカーネルがドメイン名を復元できるかは、Fake IPのマッピング、プロトコルのスニッフィング、接続方式によって決まります。DNS設定の役割の1つは、接続時にもドメイン情報をできるだけルールで利用できる状態に保つことです。

ルールのno-resolveパラメーターは、そのIP系ルールを評価する際に、アドレスを得るための追加DNS問い合わせを発生させないことを示します。不要な問い合わせを減らし、特定のループを避けられる一方、現在の接続に宛先IPがなければ、想定した判定を完了できない場合があります。使用時は、その前にドメインルールが存在するか、接続の入口から実際の宛先アドレスが提供されているかを確認してください。

DNSサーバーへの接続経路を決めるルールも重要です。DoHサーバーはHTTPSの宛先であり、それ自体がClashのルール評価対象になります。特定のDoHをプロキシ経由で利用したい場合は、プロキシノードに接続できることを確認し、ノードのドメイン名解決がまだ確立していないDoH経路に依存しないようにします。ローカルDNSを直結したい場合は、対象アドレスが広範なプロキシルールによって誤ってプロキシグループへ送られないことを確認してください。

キャッシュによって変更が反映されていないように見える

DNSの結果は、ブラウザー、OS、Clashカーネル、上流リゾルバーのキャッシュに同時に保存されることがあります。nameserverを変更した直後に再アクセスして古いアドレスが表示されても、設定が読み込まれていないとは限りません。まずクライアントの設定リロードが完了したことを確認し、対象アプリの既存接続を閉じ、必要に応じてシステムDNSキャッシュを消去してください。さらに、上流レコードのTTLが切り替わるまで待つ必要があります。

HTTP/2、HTTP/3、コネクションプールは、すでに確立された接続を再利用することもあります。新しいDNS問い合わせで別のアドレスが返っても、ブラウザーが古い接続を使い続ける場合があります。調査時は、シークレットウィンドウ、アプリの完全終了、Clashの接続一覧、ログのタイムスタンプを組み合わせ、新しい問い合わせの問題か既存セッションの問題かを切り分けてください。

処理経路に沿って名前解決の異常を調べる

DNS障害は、入口から出口まで層ごとに確認するのが適しています。一度に変更する項目を1つに絞ることで、複数の設定問題が重なるのを防げます。以下の手順は、「ドメインは開けないがIPには接続できる」「システムプロキシは正常だがTUNに問題がある」「Fake IPを有効にすると一部のアプリが動かない」といった典型的なケースに使えます。

設定がカーネルに受け入れられているか確認する。
まずClash Vergeの設定チェック結果と起動ログを確認します。YAMLのインデントエラー、項目名の誤記、現在のカーネルが対応していないオプションがあると、DNSモジュールが想定どおり起動しないことがあります。リッスンアドレス、拡張モード、上流サーバーが読み込まれているかを重点的に確認してください。
問い合わせがClashへ届いているか確認する。
システムプロキシが引き継ぐのは、プロキシ設定に対応したアプリの通信だけであり、OS全体のDNSリクエストを自動的に処理するわけではありません。DNSハイジャックを利用する場合は、TUNが有効になっていること、自動ルートが機能していること、リクエストが仮想インターフェースを通過していることを確認してください。Clashのnameserverだけを変更しても、アプリが引き続きシステムDNSへ直接問い合わせている場合、両者の結果は異なったままです。
上流サーバーへの接続を確立できるか確認する。
従来のDNSでは、53番ポートのUDPまたはTCP接続の可否を確認します。DoHではHTTPS接続、証明書、システム時刻を確認し、DoTでは853番ポートとTLSハンドシェイクを確認します。ホスト名で指定した上流サーバーについては、default-nameserverでブートストラップ解決を完了できるかどうかも検証してください。
結果の種類を確認する。
Fake IPモードで198.18.0.0/16のような予約済みアドレスが表示されるのは、通常想定される動作です。これだけで名前解決エラーと判断しないでください。本当に確認すべきなのは、後続の接続がClashへ入っているか、カーネルがFake IPから元のドメイン名を復元できるかです。
ルールとDNSの接続経路を確認する。
リゾルバーのドメイン名やIPアドレスが、最終的にDIRECTへ送られたのか、プロキシのポリシーグループへ送られたのかを確認します。リモートDoHが利用できないノードに割り当てられていると問い合わせはタイムアウトします。内部DNSが公開プロキシへ送られても、LAN内ドメインを解決できないことがあります。
設定を縮小してから項目ごとに戻す。
一時的に利用可能なnameserverを1組だけ残し、複雑なfallbackフィルターとドメイン別ポリシーを無効にして、基本的な名前解決を確認します。その後、fallback、nameserver-policy、プロキシノード専用DNS、Fake IPフィルターの順に戻し、変更するたびにログと問い合わせ結果を確認してください。

設定方法を選ぶ際の簡単な原則

通常の名前解決を一元化したいだけなら、まず信頼できるdefault-nameserverとnameserverを設定します。
ドメインとFake IPの対応を保持し、TUNと組み合わせる場合は、fake-ipとDNSハイジャックをテストしてから、特殊なドメインをフィルターに追加します。
2組の候補結果を絞り込みたい場合に、fallbackとfallback-filterを使用します。
業務や用途ごとにドメイン別のリゾルバーを指定したい場合は、カーネルが対応するnameserver-policyを優先的に検討します。
プロキシノードのアドレスがドメイン名で、起動時の名前解決が複雑になる場合は、ノード専用の名前解決経路を設定します。

安定したClash DNS設定は、項目数が多ければよいのではなく、それぞれの名前解決経路について、出所、接続経路、利用条件を説明できることが重要です。まず動作する基本経路を構築し、LAN、IPv6、TUN、特定アプリの要件に応じて拡張すれば、異常発生時にも問題がシステムDNS、Clashカーネル、上流リゾルバー、プロキシルールのどこにあるかを素早く判断できます。

Clash Verge ダウンロードを続ける

ダウンロードページでOSとアーキテクチャを選ぶか、先に詳しいインストール手順を確認してください。

ダウンロードページへインストール手順を見る