Clash DNS が遅い・汚染？nameserver／fallback を YAML で整備

一、症状の整理：DNS だけがボトルネックか

まず「本当に DNS が原因か」を短時間で切り分けます。IP アドレスを直打ちしたブラウザでは速いのにホスト名だけ遅い、モバイル回線に切り替えるとだけ遅い、VPN やプロキシをオフにすると直るなどは DNS またはその経路を疑う目安です。逆に、どちらでも同程度にタイムアウトするなら、上流のノード品質やルール命中の方が先です（TLS や接続ログは別稿の切り分けと併用してください）。

「DNS 汚染」やキャリア・学内 LAN でのフィルタは、見かけ上はブラウザ全体が不安定に見えますが、原因層を追うと 最初の名前解決が嘘の A レコードを返しているケースが混じります。Clash では 主 DNS とフォールバックを分け、条件付きで予備に回す設計が基本です。この記事は、その分岐条件（fallback-filter）とドメイン別上流（nameserver-policy）まで含めて一連の流れとして扱います。

仮想 IP まわりで「一部サイトだけ」壊れる層とは別物ですが、設定を同時に触ることは多いです。fake-ip・fake-ip-filter・DNS 切り分けの専門記事と役割分担してください。本稿は nameserver／fallback の配線にフォーカスします。

二、nameserver と fallback の役割分担

nameserver は、ざっくり言えば普段まず問い合わせる上流 DNS のリストです。ここに載せるサーバは、利用環境から最も遅延が小さく、到達しやすいものを選ぶのが無難です。企業ネットや公共 Wi-Fi では DoH／DoT のホスト名自体が遮断されることもあるため、「コピペしたテンプレのまま」だと突然遅くなることがあります。

fallback は主系の結果が信頼できないときに追加で問い合わせる側です。典型例は、ローカル DNS が意図的に改ざんされた応答を返す状況で、別経路のクリーンなリゾルバへ切り替えたい場合です。重要なのは、「fallback を厚くすればよい」わけではなく、fallback-filter の条件が合致したときにだけ予備が併用される、という考え方だという点です。条件が厳しすぎると予備が死蔵し、緩すぎると常に二重問い合わせになり遅延だけが増えます。

nameserver-policy は、サフィックスごとに「このドメインはこの上流へ」と決めるための設定です。例えば一定の国内向け TLD や社内ドメインだけ、ISP の DNS や社内リゾルバへ向ける、といった用途で、単一の nameserver リストに全部載せるより破綻しにくいことがあります。海外向けサービスは別の DoH に回す、など地理・契約・コンプライアンスに合わせて使い分けるイメージです。

フィールド	ざっくりした役割
`nameserver`	通常時の主たる上流。遅延・到達性を優先して選ぶ
`fallback`	主系が疑わしいときに併用／切替する予備側
`fallback-filter`	いつ予備を使うか（geoip など）の条件
`nameserver-policy`	ドメイン別に上流を上書きする

ヒント：利用中のコア（Mihomo / Clash Meta 等）の公式ドキュメントでキー名と既定挙動を一度確認してから貼り付けてください。メジャーバージョンで細部が異なる場合があります。

三、YAML を段階的に書き換える手順

大きく一気に変えるとログが追いづらいので、次の順がおすすめです。(1) dns.enable と listen 系を確実に有効化し、OS やブラウザが本当に Clash のリゾルバを見ているか確認する。(2) nameserver を「今の回線で一番安定する」ものに絞る——遠隔地の DoH だけにしてラウンドトリップを延ばさない。(3) fallback を追加し、fallback-filter をテンプレより一段シンプルから始めて挙動を見る。(4) なお国内外で解決結果が食い違うなら nameserver-policy でサフィックス分割する、の四段階です。

記述例（構造イメージ／キーは利用コアのドキュメント優先）

dns:
  enable: true
  # listen / ipv6 accept: follow upstream core docs
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - https://dns.google/dns-query
  fallback:
    - https://dns.cloudflare.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    "+.corp.example.com": "10.0.0.1"
    "geosite:cn":
      - 223.5.5.5

上の例の数値・ホストは机上のサンプルです。自環境では、到達できる・規約上許容されるリゾルバに差し替えてください。nameserver-policy に geosite やルールセット名をそのまま書けるかはコアとプロファイルの版に依存します。無い場合は +.example.com のように列挙で始め、後からルールセットへ寄せます。

注意：購読のリモート設定とローカル dns: をマージするとき、同名キーの意外な上書きによくハマります。GUI で「DNS が書き換わらない」ときは、マージ結果の一本化された YAML をエクスポートして確認してください。

四、fake-ip・redir-host と DNS チェーン

enhanced-mode: fake-ip のとき、多くのドメインはクライアントへ仮想 IPv4が返り、実際の接続先決定はコア内部で遅延します。だからといって DNS セクションが不要になるわけではなく、上流との通信そのものや fake-ip-filter に載ったホストでは、従来どおりリゾルバへ問い合わせが発生します。つまり nameserver／fallback の不調は「fake-ip だから隠れる」わけではない層が残ります。

redir-host に切り替えると挙動は変わり、トラブルが消えることもありますが、それは仮想 IP をやめて実アドレスを先に返す方向への変更であり、長所短所が入れ替わります。対照実験として一時切替は有効ですが、運用方針は fake-ip 専用の切り分け記事の手順とセットで決めると安全です。

診断サイトで「プロキシバレ」や実 IP が話題になる場合、DNS 以外に WebRTC など別レイヤーがあります。WebRTC と DNS の切り分け記事と混同しないよう、現象を分類しておくと再発時に早いです。

五、DIRECT と PROXY と「どの DNS が使われるか」

初学者がつまずきやすいのは、「プロキシ経由で開くサイトだから、DNS も自動的に海外のリゾルバを使うはず」という期待です。Clash 系では dns セクションで定義した解決経路と、ルールによる接続出口（DIRECT / PROXY）は関連しますが、常に同一のホップに束ねられるわけではありません。例えばローカルで名前を解き、その結果の IP へ代理で張るのか、どこか別の経路で解くのか——実装とモード（TUN、システムプロキシ、redir 等）で細部が変わります。

実務的には、ログで問い合わせたクエリとヒットしたルールを見ながら、「このホストは DIRECT 想定なのに海外 DNS の結果を信じている」などの矛盾を潰します。GEOIP で国内を DIRECT に寄せる記事の方針と、本章の nameserver-policy は表裏一体です。国内ドメインは国内リゾルバ＋ DIRECT、海外は別——と解決と出口のセットで考えると設定がブレません。

Windows と WSL の併用では、どのスタックがどの DNS を参照しているかがさらに複雑になります。WSL2 と Windows の Clash DNS 記事で層を分けたうえで、本稿の YAML を当てはめると理解が揃います。

六、反映と検証のしかた

設定を保存したら、コアの再読み込みまたは再起動、利用 GUI があれば 「設定の適用」ボタンまで含めて反映を確認します。つづいて、(1) 問題の FQDN を 1〜2 個に絞る、(2) そのドメインについて 複数の外部リゾルバ（可能なら計測ツールや dig 系）で応答を比較する、(3) Clash のログで 該当クエリがどの nameserver／fallback に流れたかを追う、の三段を踏みます。Wi-Fi とモバイルの双方で再現するかも記録しておくと、ISP 側の差分の切り分けに効きます。

遅延が主訴のときは、RTT が大きい遠隔 DoH を主 nameserver に置いていないかを最初に疑ってください。フォールバックが頻発して二重クエリになっているときも、体感は真っ先に悪化します。ログ上でフォールバックの発火頻度が高いなら、fallback-filter の条件と主系の選定を見直します。

最終的なキー名・項目の網羅は、利用中バージョンのリファレンスに従ってください。本サイトのドキュメント索引から、自環境に合った章へ進むと抜け漏れが減ります。

七、まとめ

Clash DNS の遅さや一部ドメインの異常は、ノード以前に nameserver と fallback の役割逆転、過剰な fallback-filter、国内外の分割不足として現れることが多いです。YAML では 主系を遅延の観点で整え、予備は条件付きで、なお食い違うドメインは nameserver-policy で上流を分ける——この三段を軸にすると、fake-ip や DIRECT／PROXY のルールとも矛盾しにくくなります。

同じテーマでも、層の違う記事として fake-ip 特化・WebRTC・WSL などが既にあります。自分の症状がどの層に近いか一度分類してから触ると、設定の行き来が格段に減ります。クライアントの導入や基本画面はドキュメントから辿れます。

総合的にログが読みやすく、DNS とルールをセットで持ち替えやすいクライアントだと運用負担は下がります。仕組みを踏まえて手を入れるほど、長期利用での再現性も上がります。

→ Clash を無料ダウンロードし、DNS セクションを段階的に試す