名前解決の「一本化」だけでは足りない場面
いきなり nameserver-policy に飛ぶ前に、なぜトラフィックのルール分岐だけでは済まないのか整理します。ルールは接続処理のときに評価される一方で、名前解決の段階ですでにA/AAAA レコードが選ばれたあと、アプリ側はその IP とポートでソケットを開きます。グローバル CDN が地域ごとに最適なエッジへ誘導する仕組みを考えると、どの上流を通じて質問されたかによって返るアドレスの集合自体が異なることが普通にあります。さらに、企業・学校・個人ともにスプリット DNS（内側と外向きで答えが違うゾーン）を持っていると、上流を誤って選ぶだけで証明書名と実際の宛先がずれる、ログインだけ失敗する、といったログに出ない不具合に化けます。
そこで Mihomo の DNS モデルでは、上流の並びを複数レイヤへ分けられるようになっており、そのなかでも nameserver-policy が「どの質問へどのリストを適用するか」をドメインベースで明示する鍵になります。単一グローバル DoHに寄せ切る構成はシンプルで管理も楽ですが、国内向けコンテンツを国内の視点へ、海外メール・ストレージ・AI API を国外の上流へというニーズとは相性が悪く、そこまで行かなくともCNAME チェーンによって不要なレイテンシが積み上がるだけでも体感速度に効いてきます。必要になったときにだけ名前解決側へルールブックを増やしていくほうが、後からの読み書きとも折り合いが付きやすいでしょう。
「DNS クエリだけが迂回できていない」のか「そもそも Core に届いていない」のかといったレイヤ問題は、アプリ/OS/TUN と絡んで判別が難しいですが、上流の種類を増やしたあとでも最終アウトバウンドはルール側で統制できます。名前解決の出口を増やしたからといって、必ず送信元ポートやプロセス名のルートまで自動で整うとは限らないので、本稿での前提は上流を分ければ望む名前の答えだけが読みやすくなることに置きます。パケット側の総点検はそれぞれの OS 別稿や TUN ガイドと合わせてください。
用語："DNS 分流「」と日本語資料で呼ぶパターンは、英語資料ではresolver policy やconditional forwarding に近い概念です。この記事でも「ドメインマッチだけ別上流」を指して使います。
dns名前空間の土台：nameserver と fallback
Clash Meta 系設定ではdnsオブジェクト直下に並ぶキーたちが名前解決機構の各部品です。読み込み順と実装の細部はリリースで微調整されるため、細かな挙動差はソースとリリースノートへ当たる必要がありますが、実務での設計順は共通しています。enable: trueを忘れず、IPv6 と IPv4 をどちらを優先するかはprefer-h3まで含め環境側の事情が強く出ます。ここでの要点はnameserver列が基本の並びで参照される上流、fallback列がfallback-filterで定義される条件に応じて投入される保険用の上流であることです。この二つが読み書きできる状態になってからnameserver-policyを足していくほうが、トラブル時のログの読みやすさが段違いになります。
nameserver配列へ書く項目は単なる IP だけでなく、明示スキーマ付き URIが基本です。udp://形式で IP を渡す運用や、上流プロバイダが配布しているFQDN ベース DoH の URLまで含められるのが Mihomo の長所であり、リストの並び順はフェイルオーバーとタイムアウトの体感に効きます。ここでのコツはDoH と DoT を混ぜる場合でも必ず並びを短文コメントとして残しておくことで、数日後に見返したときの判断が楽になる点です。また、リストに書いた上流がすべて同じ国境・同じ運用者にぶら下がっていると、上流障害やフィルタの瞬断に弱い構成になるので複数レイヤだけでなく多様な経路カテゴリを意識するのが妥当です。
nameserver-policy は何を上書きするのか
nameserver-policy は、マッチした質問だけに対して適用される上流の並びを差し込むディスパッチャーです。YAML 構造としてはオブジェクトであり、キーがドメインマッチのいずれか、値が上流のリストという形になります。マッチしない名前は、このブロックによる干渉を受けず、先に述べたnameserver/fallbackの世界へ進み続けます。つまり「全体の並び」を壊さずにホットスポットの名前だけ差し替えられるので、リストが肥大化しないというメリットがあります。
キー側には完全一致のドメイン、+. 接頭辞付きサフィックス、正規表現、geosite カテゴリ等の種類があります。名前空間だけで済ますなら単純なサフィックスで足りますが、ドメインパターンで押さえられないときはrule-setと連鎖させる構成を検討したくなります。そちらまで踏むと DNS の宣言とルールセットの運用まで横断になるため、本章ではFQDN ベースだけで済む構成を主に説明しています。複数ポリシーが同じ名前へ当たるとどれが優先されるかについては環境側の並び評価に依存するので、競合しないよう広いサフィックスと狭い名前の関係には注意してください。
1最小の並び：nameserver-policyが無い状態も描く
# Minimal dns skeleton before nameserver-policy
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.google/dns-query#🌐G
- tls://1.1.1.1#☁️CF-TLS
fallback:
- https://dns.alidns.com/dns-query#🇨🇳AliDNS
fallback-filter:
geoip: false
ipcidr:
- 240.0.0.0/4上記は議論がすぐ済むように極めて短くしただけの骨格であり、環境にある既存リストはそのまま残してください。# のあとにあるラベルは Mihomo がログへ出してくれる表示名になり、確認に便利です。この段階でクエリログに実際どの上流が選ばれているかだけでも押さえると、nameserver-policy を足したときの変化が分かりやすくなります。
2nameserver-policyに DoH（と必要なら DoT）を束ねる
dns:
# ...existing keys unchanged...
nameserver-policy:
"+.youtube.com":
- https://dns.google/dns-query#🎬YT-G
"geosite:cn,tld-cn":
- tls://dns.alidns.com#阿里云DoT
"*.some-corp-example.internal":
- udp://192.168.50.210#corp-recursor
Google 系コンテンツの名前だけ広い上流へ寄せつつ、国別カテゴリには国内向け上流を割り当てる、という典型的な並びです。geosite:プレフィクスはルールセットの更新サイクルに追随するため、リストの増減に伴い思わぬマッチ増加にもなりえます。そのため運用フェーズへ入ったらログを定期的に確認し、「意図せず増えていたらサフィックスを狭める」のループへ回したいところです。
DoH は必ずブラウザの開発者コンソールで見慣れた URL と同様にクエリパスまで含んだ完全形で書いてください。h3やh2の自動交渉差は環境側の問題でもあるので、アップデートのたびに一度だけチェックリストへ「TLS レイヤ問題が再発していないか」を足しておくのがおすすめです。UDP/TCP で社内向けリゾルバへ転送するときにはVPN または企業経路側で該当 IP ヘに到達できるかを別途確認し、名前は解決できていても接続がタイムアウトする状態を事前に排除します。
FakeIP と併用するとき読み替えるポイント
Fake IPモードでは、多くのアプリケーションは名前を一度解決するときにフェイクレンジへ誘導され、実際のアドレス選択はステートフル側で行われます。DNS クエリだけを眺めていたときの「返ってきた A だけがすべて」とは限らないので、上流を差し替えた効果検証にはTCP の接続先やルール側の処理ログも添える必要があります。また、フェイク返却自体を避けたい名前はfake-ip-filterへ寄せていく構成が一般的で、上流を国内・国外へ分けつつ名前は実 IPv4/IPv6 へ戻したいケースとの組み合わせは説明だけが長くなる典型的な問題ですので、両キーをセットで並べているサンプルを眺めやすく保存しておいてください。
上流が意図通りかログで順に確かめる方法
実装が上手く進んでいれば、上流の並びだけを増やせば自動的にもっとも早い上流が選ばれますが、そのあと問題が続くときは順に潰してください。ひとつ目は設定が重複適用されていないことで、CLI と GUI とサブスク生成物から三つの異なるYAMLが競合しないかをチェックします。二つ目はdigやアプリ側の開発者コンソールを使って、クライアントが握っている質問タイプごとA と AAAA両方のアドレス族を読むことです。三つ目は Core の名前解決ログで#ラベルごとのヒット統計があるかを読み、一定時間アクセスしない+.example.comだけが異常値を叩いている等の癖を確認します。この三手が通れば、上流の増減を伴う設定変更にも耐えられるようになります。
もう一段踏み込むなら、アプリ側のブラウザ内 DoH（Secure DNS）を直接有効にしたままでも Core の DNS と二重質問しないかを見ていきます。OS 機能とブラウザ機能とセキュリティ製品機能が競合すると、上流をどれだけ整えても見かけだけ正常という落とし穴が残るので、検証コンソールのDNSタブだけは外さない運用へ寄せているチームも多いですね。
失敗パターン短いリスト
・+.演算子の付け忘れ：サフィックスのままでもうまく行くときと行かないときがあり、クエリ側に付くワイルドカードの粒度をログで読みましたか？ と後から自分に質問すると早いです。・YAMLのインデント崩れでブロックだけ丸ごと無効：マージツールでの連結順が悪く、リストの頭にコメントのみが並んでいる事故は珍しくありません。ファイルを一本にエクスポートしてから機械チェックしましょう。・ポリシーとルールセットの両方へ同義のドメイン列挙で二重運用しメンテ不能化：どちらかに寄せ、更新するタイミングを一本化しないと運用側が疲弊します。
読者からよく出る質問（本文の補助）
「国内ゾーン全部をリストで列挙しきれません」という相談は多く、この場合でもgeosite:側へ寄せられるなら運用規模との折り合いが付きます。しかしリストの自動更新にも依存するので、逆に許容できないときはFQDN と短いDOMAIN-SUFFIXの両方へ分割し、増殖しそうな部分だけをセット化するしかありません。セキュリティポリシーで上流を固定しないとダメなドメインだけを名前にしておけば、リストは肥えにくくなります。
「社内だけ独自 DoH を持っている」構成では証明書の検証チェーンが特殊なので、上流 URL をそのまま流用しないでください。mTLS やピンニング要件が絡んだとき Mihomo が素直には通ず、結局ブラウザ専用の設定と二重になることもあります。そんなときは DNS クエリ転送だけを Mihomo で持ち、アプリ側の実装問題はインフラ観点で話を分離したほうが前に進むことがあります。
法令と規約：居住地域や契約環境でのネットワーク利用ルールは各自で順守してください。本稿は技術的一般論であり、特定サービスの利用条件を迂回する作法を促すものではありません。
総括：nameserver-policyは出口の整理から始める
上流を増やせば増やすほど設定は読みづらくなるので増やした理由ごと段落を短文でYAMLコメントにも残しておく運用があると親切です。また、リストを眺めれば将来の自分が「なぜここだけCloudflare」のように迷わなくなり、レビューアとの会話にも耐えられるようになります。DNS の全体構造まで含めてのリーク耐性は依然として広いので、並行して DNS の総覧ガイド と往復読みしていただけると構成の穴が見つかりやすくなります。
ところで、こうした上流の切り替えを手入力 YAML だけで保守するのが骨が折れることもあります。GUI 側でリストを増やしていくとき、バリデーションとログへのラベルの付け外しだけでも手間が省ければ体感速度への投資にもっと時間を寄せられるはずです。一方で汎用的なパケットブラウザ系ツールは DNS のみを細かく切っても、アプリ側のセキュアDNSやプラットフォーム差を吸収しきらず、ログの粒度も一定ではありません。ルールセットとセットで見やすく保てる構成を探しているなら名前解決の宣言と転送処理を同じクライアントで完結させる価値は依然として捨てがたく、上流の増減を家族やチームにも説明できる形で残していけると安心ですね。
まずは自分の環境でよく名前解決に失敗していたドメインを三つだけ挙げ、上流を二系統に増やしたうえでログを並べて比較してみてください。差が体感レベルで出た瞬間、残りはコメント管理とセット更新の問題に移れます。その後の自動化まで含めワークフロー全体を視野にいれたクライアントをお探しなら、視覚的にポリシーと並びを往復確認できるほうが作業時間を短縮できるでしょう。まだ試していない方は、この機会にClash を無料ダウンロードし、自分の上流リストをゆっくり育てていただければ嬉しいです。購読更新と競合しない「追記専用のローカル断片」をどこに置くかもセットで決めておけば、nameserver-policy が急に消失する事故にも強くなります。