高度な設定 読了目安 14分

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

ClashのDNSリクエスト経路、プライマリ／セカンダリDNSの役割、fallbackのフィルタ条件、よくある異常の確認手順を整理します。

まずDNSリクエストの実際の経路を確認する

Clashのプロキシルールは、接続をダイレクト、プロキシ、拒否のどれで処理するかを決めます。ただし、ルール判定の前には通常、ドメイン名の名前解決があります。ブラウザでドメインにアクセスすると、アプリがOSのリゾルバーを呼び出す場合もあれば、内蔵の暗号化DNSから直接問い合わせる場合もあります。OSのリゾルバーは、ネットワークアダプターに指定されたDNS、ルーター、またはClashのローカル待受ポートへリクエストを渡します。リクエストが実際にClashのDNSモジュールへ入って初めて、設定した nameserver、fallback、fake-ip が有効になります。

一般的なリクエスト経路は、アプリがドメイン名を送信し、OSまたはTUNがDNS問い合わせを引き受け、Clashがポリシーに応じて上流リゾルバーを選び、アドレス取得後にプロキシルールを照合し、最後にダイレクトまたはプロキシ接続を確立するという流れです。アプリがOSのリゾルバーを迂回していたり、LAN上の機器がDNSをルーターへ送信し続けていたりする場合、Clashの設定を変更してもそのリクエストの結果は変わりません。

システムプロキシだけを有効にした場合、HTTPとHTTPSの通信はClashに入っても、DNSまで同じ経路を通るとは限りません。ブラウザ側で名前解決を行う場合もあれば、SOCKSクライアントがドメイン名をプロキシ側で解決できる場合もあります。TUNモードはより広い範囲をカバーし、ルーティングとDNSハイジャックによってシステムプロキシ設定に従わないプログラムも引き受けられます。ただし、ブラウザのセキュアDNS、仮想マシンの独立したネットワーク、LAN上の他の機器などの例外には引き続き対処が必要です。

1回の問い合わせを構成する4つの層

  1. アプリケーション層：ブラウザ、コマンドラインツールなどのソフトウェアが、システムDNS、内蔵DoH、SOCKSプロキシへのドメイン委任のいずれを使うかを決めます。
  2. システム層：OSのキャッシュ、ネットワークアダプターのDNS、VPNインターフェースの優先順位、ローカルのhostsが、Clashより前に結果を返すことがあります。
  3. Clash DNS層：待受ポート、拡張モード、プライマリ／セカンダリリゾルバー、ドメインポリシーによって、問い合わせ方法と返却内容が決まります。
  4. 接続層：Clashはドメイン名、宛先アドレス、ルールセットを使って出力先を選びます。ノードのドメイン名自体にも追加の名前解決が必要になる場合があります。

トラブル対処では、パブリックDNSを何度も入れ替えるより、層ごとに下流へ進めて確認するほうが効果的です。特にキャッシュに注意してください。ブラウザ、OS、Clashはいずれも解決結果を保存する可能性があります。設定変更後すぐに同じドメインをテストすると、古い結果が変更内容を隠すことがあります。まず設定を再読み込みし、関連するキャッシュを削除するか、レコードの期限切れを待ちます。

dns・default-nameserver・nameserverの役割

理解しやすい基本設定の例を示します。利用できる項目は、オリジナル版Clash、Clash Meta（現在はmihomoと呼ばれることが多い）、クライアントの統合バージョンによって異なります。実際の運用では、使用中のカーネルのドキュメントと設定検証結果を優先してください。

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
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query

enable と listen

enable: true はカーネルのDNSモジュールを有効にします。listen はローカルの待受アドレスとポートを指定します。0.0.0.0 で待ち受けると、すべてのネットワークインターフェースからリクエストを受け付けるため、デスクトップ端末ではファイアウォールで外部アクセスも制限してください。本機からの明示的な利用だけが目的なら、ループバックアドレスでの待受を検討できます。TUNのDNSハイジャックをカーネルが転送する場合、具体的な待受方法はクライアントとカーネルの実装によって異なります。

ポート競合は、設定を起動できない代表的な原因です。53番ポートはシステムサービス、コンテナツール、別のDNSプログラムが使用している可能性があるため、デスクトップクライアントでは1053などの非特権ポートを使い、TUNやシステム設定からリクエストを取り込む構成がよく採用されます。使用状況を確認せず、2つのローカルDNSサービスを同時に起動しないでください。

default-nameserver：上流ドメインのブートストラップ解決

nameserver にDoHやDoTのドメイン名を指定する場合、カーネルは暗号化接続を確立する前に、上流ホストのIPアドレスを知る必要があります。default-nameserver はこのブートストラップ解決を主に担い、プロキシノードのドメイン名を初回に解決する際にも使われます。「DNSサーバーを解決するために、同じDNSサーバーへ先にアクセスしなければならない」という循環を避けるため、互換性を重視する設定では、ここに直接到達できるIPアドレスを指定するのが一般的です。

default-nameserver は通常のドメイン問い合わせにおける主な回答元ではありません。このリストに大量のリゾルバーを追加しても、自動的に速度が向上するわけではなく、結果のばらつきや切り分けの難しさが増します。ネットワークから到達でき、応答が安定した少数のリゾルバーを選べば十分です。

nameserver：デフォルトのプライマリリゾルバー

nameserver は通常の問い合わせに使う主な上流リゾルバーです。通常のUDP DNSのほか、カーネルが対応していればDoHやDoTなども利用できます。CDNアドレス、IPv6レコード、DNS汚染がある環境での挙動は、リゾルバーごとに異なる場合があります。同じリストに複数の上流を指定すると、カーネルは並列または内部ポリシーに従って問い合わせることがありますが、固定順で1台ずつ試すフォールバックとは限りません。

リゾルバーを増やしすぎるのは避けてください。上流が多いほど、同じドメインから異なるCDNアドレスが返されたり、障害を再現しにくくなったり、想定した経路を通らないリクエストが発生しやすくなります。初期設定では、プライマリリゾルバー1つと独立したセカンダリリゾルバー1つに絞り、経路が安定してから冗長性を追加するとよいでしょう。

fallbackとfallback-filterの連携方法

fallback は単純に「メインサーバーがタイムアウトしたら予備サーバーへ問い合わせる」という仕組みではありません。従来のClash設定の意味では、プライマリとセカンダリのリゾルバーが同時に問い合わせへ参加し、その後 fallback-filter が対象ドメインやプライマリの解決結果を判定して、セカンダリの回答を採用するかどうかを決める場合があります。そのため、予備アドレスを追加するだけでなく、フィルタ条件を理解することが重要です。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
      - "+.githubusercontent.com"

geoip と geoip-code

geoip を有効にすると、カーネルはプライマリの解決結果に含まれるアドレスの地域情報を基に、fallbackの結果を採用するか判断します。たとえば geoip-code: CN の場合、プライマリの結果が指定地域に該当しなければ、セカンダリの回答へ切り替わることがあります。地域間の名前解決差を扱うのに便利ですが、GeoIPデータベースの精度に依存します。クラウドサービス、Anycast、CDN、新しく割り当てられたアドレスは想定外の地域に分類されることがあるため、地域判定を絶対的な結論として扱わないでください。

geosite と domain

geosite では、ドメインの集合ごとにfallbackの利用傾向を指定できます。利用できる集合は、カーネルとルールデータに依存します。domain は、明確にセカンダリリゾルバーを使いたい少数のドメインを追加するのに適しています。+. を付けた記法は通常、ルートドメインとそのサブドメインへのマッチを表しますが、ドメインマッチ形式の互換範囲はバージョンによって異なるため、設定検証で確認してください。

多数のサイトを domain に1件ずつコピーするのはおすすめしません。リストが長いほど保守負担が増え、nameserver-policy、ルールセット、サブスクリプション設定との競合も起きやすくなります。mihomoを使う場合は、ドメインごとにリゾルバーを指定できるポリシー項目を優先的に検討すると、用途を明確に表現できます。

ipcidr

ipcidr は、特定のアドレス範囲を異常な結果、またはfallbackが必要な結果として扱うために使います。たとえば、予約アドレス帯を通常のパブリックドメインに対する有効な応答とみなしたくない場合に、フィルタ条件へ追加できます。この項目は、実際に確認した問題に対して使い、不明な情報源から大量のネットワーク帯をコピーしないでください。範囲が広すぎると、正常なCDNアドレスまで継続的にセカンダリ経路へ送られ、遅延や結果の変動を招きます。

fallback利用時の判断ポイント

mihomoでリゾルバーを細かく役割分担する

mihomoはClashの設定体系を拡張し、nameserver-policy、proxy-server-nameserver、direct-nameserver などのDNS制御項目を提供しています。これらは「業務ドメイン、プロキシノードのドメイン、ダイレクト接続のドメインを同じ解決経路に通したくない」という問題に適しています。ただし、古いクライアントではすべての項目を認識できるとは限りません。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.example.net":
      - https://cloudflare-dns.com/dns-query

proxy-server-nameserver は主に、プロキシノードのサーバー自身のドメイン名を解決するために使います。ノード接続がまだ確立していない段階で、そのノード経由でしか到達できないDNSに依存すると、起動ループが発生します。ノードのドメイン名には、現在のネットワークから直接到達できる上流を選んでください。

direct-nameserver は、ダイレクト接続の出力に関係するドメイン名の解決に使います。ダイレクト接続のサイトに、ローカルネットワークに近い回答を使わせることができます。有効になる条件、呼び出されるタイミング、ルールマッチとの関係は、カーネルのバージョンとDNS設定に左右されます。設定を移行する際は、YAMLを読み込めるかだけでなく、実行ログも確認してください。

nameserver-policy は、ドメイン名やルール集合ごとに上流を指定します。統一されたプライマリ／セカンダリ構成よりも意図を直接表現できます。たとえば、地域ドメインはローカルリゾルバーへ、特定の業務ドメインは別の暗号化リゾルバー群へ渡せます。ポリシー同士が上書き関係になる場合もあるため、設定前に「どの種類のドメインを、どの上流へ、どの出力先で処理するか」という想定表を作り、項目ごとに検証してください。

fake-ipとredir-hostの選び方

enhanced-mode は、ClashがDNS問い合わせと後続の接続をどのように関連付けるかを決めます。代表的なモードは fake-ip と redir-host です。どちらもカーネルがドメイン情報を保持するために使われますが、仕組みは異なります。

fake-ip：予約アドレスを返してドメインをマッピングする

fake-ipモードでは、Clashが問い合わせごとに予約アドレスを割り当てます。たとえば 198.18.0.0/16 のアドレス帯を使い、そのアドレスと元のドメイン名の対応を記録します。アプリがそのアドレスへ接続すると、通信はClashに引き渡され、カーネルがマッピングからドメイン名を復元してルールを適用します。ドメインルールを適用しやすく、実アドレスを取得してから判定する際の曖昧さも抑えられるため、一般に高い判定精度が期待できます。

fake-ipアドレスは、Clashが通信経路を引き受ける場合にだけ意味を持ちます。通信がClashに入らず、OSや別の機器がこの予約アドレスへ直接接続しようとすると、接続は失敗します。LAN探索、プリンター、ゲーム機、企業認証、時刻同期、実際のDNS応答に依存する一部のプログラムもfake-ipと互換性がない場合があります。

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

fake-ip-filter に登録したドメインはfake-ipで返さず、実アドレスを取得します。フィルタ項目は、実際に発生した障害をもとに少しずつ追加してください。広すぎるワイルドカードをそのまま使うと、fake-ipによるドメインマッピングの利点が損なわれ、接続前にローカル名前解決が行われるリクエストも増える可能性があります。

redir-host：実アドレスを返す

redir-hostモードは通常、クライアントへ実際のIPアドレスを返し、接続時にできるだけドメイン名を関連付けます。実アドレスを必要とする機器やプログラムとの相性は良い一方、複雑な転送、接続の再利用、宛先IPしか残らない状況では、ドメインルールの認識がfake-ipほど安定しないことがあります。具体的な挙動は、sniffing、TUNスタック、カーネルのバージョンにも左右されます。

デスクトップでの日常利用では、まずfake-ipを試してください。LANサービス、企業ネットワーク、特定アプリとの互換性に問題がある場合は、正確なフィルタ項目を優先的に追加します。問題の範囲が広く、安定した除外が難しい場合は、redir-hostを検討します。モードを切り替えた後はDNSキャッシュを消去し、関連アプリを再起動してください。古いfake-ipの記録は、すべてのキャッシュ層からすぐに消えるとは限りません。

TUNモードでのDNSハイジャック対策

ここでいう「DNSハイジャック」は、TUN設定における通信の取り込み機能を指します。指定ポート宛てのDNSリクエストをClashのDNSモジュールへリダイレクトするもので、通信事業者が解決結果を書き換えることを意味しません。アプリがネットワークアダプターのDNSやルーターへ53番ポートの問い合わせを送信し続ける問題を解決します。

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

any:53 は、任意の宛先アドレスに対する53番ポートの従来型DNSリクエストを取り込むことを表します。カーネルのバージョンによっては、ほかの形式にも対応しています。クライアントのGUIがTUN設定を自動生成している場合、複数箇所で同じ設定を重ねて定義しないでください。設定が上書きされたり、起動に失敗したりすることがあります。

従来型のDNSハイジャックで通常カバーできるのは、UDPまたはTCPの53番ポートです。ブラウザが外部のHTTPSアドレスへ直接接続するDoHを自動的に捕捉したり、すべてのDoTリクエストを透過的に書き換えたりすることはできません。ブラウザで独立したセキュアDNSを有効にすると、システムツールとは異なる挙動になる場合があります。切り分けでは、まずブラウザを一時的にシステムリゾルバーへ切り替え、Clashの経路が安定してから、ブラウザ内蔵設定を残すか判断してください。

よくある取り込み失敗のケース

透過ルーター環境では、DHCPで配布されるゲートウェイとDNSも確認してください。DNSアドレスを透過ルーターへ向けただけでは、すべての接続が透過ルーターを経由するとは限りません。ゲートウェイを透過ルーターへ向けても、端末が独自の暗号化DNSを使わない保証はありません。ゲートウェイ、DNS、転送ルール、ファイアウォールを一つの経路として確認してください。

名前解決異常を段階的に切り分ける順序

DNS障害は似た症状に見えても、原因は異なる層にある可能性があります。以下では、設定の読み込み、待受状態、上流へのアクセスから、ルールとキャッシュまで順に確認します。「ウェブページが開かない」「一部のドメインがタイムアウトする」「TUNを有効にすると解決できない」「同じサイトの結果が何度も変わる」といった問題に適しています。

ステップ1：現在のカーネルが設定を受け入れているか確認する

まずクライアントのログと設定状態を確認し、YAMLのインデント、項目の型、プロトコル付きアドレスに誤りがないか調べます。リストのインデント、コロン後のスペース、ドメインルールに含まれる特殊文字、古いカーネルが対応していない新しい項目には特に注意してください。GUIクライアントには、サブスクリプションの元設定、上書き設定、実行時の統合設定が同時に存在する場合があります。最終的に有効な設定を基準にしてください。

ステップ2：ローカルDNSポートが待ち受けているか確認する

設定で指定したアドレスとポートに、待受プロセスが存在するか確認します。ポートが別のプログラムに使われていると、ClashのDNSモジュールだけが起動に失敗し、プロキシコアの他の機能は動作し続けることがあります。その場合、システムプロキシは正常に見えても、名前解決に依存する接続は失敗します。ポートを変更した後は、システムDNSの転送設定やTUNの取り込み設定も合わせて変更してください。

ステップ3：プライマリとセカンダリのリゾルバーを個別にテストする

一時的に nameserver を1つだけ残し、複雑なフィルタポリシーを無効にして、通常のドメインが安定して解決できるか確認します。次にfallbackの上流を単独でテストします。DoHへ接続できない場合は、default-nameserver でホスト名のブートストラップ解決ができるか、現在のネットワークから対象アドレスとポートへアクセスできるかを確認してください。

ステップ4：ノードのドメイン名による起動ループを確認する

プロキシノードがドメイン名で指定され、DNS上流へのアクセスにもそのノードが必要な場合、カーネル起動時にノード名を解決できないことがあります。その結果、プロキシを確立できず、DNS上流にも到達できなくなります。ノードのドメイン名には、現在のネットワークから直接到達できるブートストラップリゾルバーを使ってください。mihomoでは proxy-server-nameserver も確認できます。

ステップ5：fallback-filterの範囲が広すぎないか確認する

一時的に geosite、domain、広範囲の ipcidr を削除し、最小構成だけを残します。問題が解消したら、条件をグループ単位で順に戻してください。特定のドメインが異なる解決結果の間で頻繁に変わる場合は、予備サーバーを増やすのではなく、プライマリとセカンダリがそれぞれ返したアドレスとフィルタ判定を記録します。

ステップ6：fake-ipの通信が実際にClashへ入っているか確認する

198.18.0.0/16 のようなアドレスが返る場合、fake-ipは動作しています。その後の接続失敗は、対象通信がTUN、透過プロキシ、システムプロキシによって正しく取り込まれていないことを示す場合があります。ここではDNSを変更するのではなく、ルーティングとアプリのプロキシ方式を重点的に確認してください。LAN内の一部や認証用ドメインだけに問題がある場合は、対象を正確に fake-ip-filter へ追加できます。

ステップ7：IPv6の不整合に対処する

ipv6: false は通常、Clash DNSがAAAAレコードを返すことを制限しますが、OS、ブラウザ、別のリゾルバーがIPv6アドレスを取得する可能性は残ります。IPv6の接続性が不完全なネットワークでは、アプリがIPv6を優先してタイムアウトすることがあります。OSのIPv6、Clash DNS設定、TUNルーティング、プロキシノードの対応状況が一致しているか確認し、1つのスイッチだけを変更しないでください。

ステップ8：キャッシュを消去し、同じ条件で再確認する

設定を再読み込みしたら、ブラウザとOSのDNSキャッシュを消去し、対象アプリを終了して再起動します。テスト時はネットワーク、ドメイン、動作モード、プロキシグループを固定し、複数の変数を同時に切り替えないでください。まずDNSの返答を確認し、次にClashのログでルールのマッチと出力先を確認し、最後に接続が確立したかを調べます。

長期的に安定する設定は、リゾルバーの数ではなく、役割の境界が明確であることに支えられます。まずは、直接到達できるブートストラップリゾルバー、デフォルトのプライマリリゾルバー、必要に応じたfallbackという最小構成を作り、明確な要件に応じてポリシー分岐やfake-ipフィルタを追加してください。

  1. まず現在のクライアントが使っているカーネル名とバージョンを確認し、対応していない項目をそのまま適用しないでください。
  2. default-nameserver は簡潔に保ち、暗号化DNSとノードのドメイン名をブートストラップ解決する用途に絞ります。
  3. nameserver には、安定して到達できる主要な上流だけを選び、用途の不明なアドレスを混在させないでください。
  4. 名前解決に実際の差異がある場合だけ fallback を有効にし、フィルタ条件を追加した理由を記録してください。
  5. fake-ipを使う場合は、必要最小限で正確なフィルタリストを維持し、不要になった例外を定期的に削除します。
  6. TUN環境では、DNSの取り込み、ルーティング、IPv6、ブラウザ内蔵のセキュアDNSを合わせて確認してください。
  7. 変更は毎回1つの項目グループに限定し、戻せる元設定を保存したうえで、ログから実際の経路を検証します。

サブスクリプションが提供する設定には、すでにDNSセクションが含まれていることがあります。クライアントの上書き機能で同名の項目を追加した場合、最終結果が置換、統合、完全な無視のいずれになるかは、クライアントの実装によって異なります。サブスクリプションを更新する前に、カスタムDNSが独立した上書き設定にあるのか、サブスクリプションのコピーへ直接書き込まれているのかを確認してください。更新後は最終設定を確認し、カスタム内容が上書きされていないか調べます。

多くのデスクトップ環境では、まず「リクエストがClashへ入っているか」と「上流へ到達できるか」の2点を解決してから、fallbackとポリシー分岐を最適化します。透過ルーターや複数端末のネットワークでは、DHCP、デフォルトゲートウェイ、端末独自のDNS、IPv6の出口も追加で確認してください。アプリから上流までの名前解決経路を順序図にすると、設定項目を増やし続けるより、障害箇所を見つけやすくなります。

Clashをダウンロード