DNSリークとは何か（プロキシ文脈での意味）
ここでいうDNSリークは、利用者の意図に反してドメイン名の問い合わせが、プロキシのトンネルの外側のリゾルバへ向かう状態を指します。ブラウザの表示は問題なくても、アプリがOSに登録されたDNS（ISPのサーバーやルーター配布のDNS）へ直接UDP/TCPで質問していると、どのサイトにアクセスしようとしているかのメタデータが別経路に残る可能性があります。またClashの文脈では、名前解決の結果（IP）と、実際に張るTCP/UDP接続の経路が一致しないこと自体がトラブルの種になり、ルールがヒットしない・遅い・片方だけ失敗する、といった症状に見えます。
Metaコアはdns.enable: trueとenhanced-modeを組み合わせることで、クライアント側で解決戦略を一元化しやすくなっています。ただしOSのDNS設定・ブラウザのセキュアDNS・VPN他製品のフィルタが同時に働くと、想定外の優先順位で上書きされることがあります。まず「誰が53番やDoHの443番を握っているか」を意識することが第一歩です。
MetaコアのDNSパイプラインの俯瞰
Mihomo系では、ざっくり①クライアント内DNSモジュールと②ルールエンジンと③実際のoutbound接続が連動します。enhanced-mode: fake-ipのとき、多くのドメインはまず仮想IP（FakeIPレンジ）へマッピングされ、その後の接続フェーズでスニファーや再解決と組み合わせて実ホストへ向けます。redir-host系の挙動とは設計思想が異なるため、購読YAMLやテンプレートがどちらを前提に書かれているかを確認してください。
nameserverは通常、最初に試す上流です。fallbackは、応答が汚染されている・タイムアウトした・特定条件に合致したときに使われるバックアップ列です。nameserver-policyやproxy-server-nameserverなど、環境によって追加キーが現れる場合がありますが、骨格は「信頼できる上流を複数段に分け、異常時だけ別経路へ逃がす」という発想です。詳細キーは利用中のコア版のドキュメントと照合してください。
実務のコツ：購読プロファイルに既にdnsブロックが入っている場合、GUIで別途DNSを指定すると二重定義になりがちです。最終的に有効なYAMLを一つに収束させ、どのファイルが勝つかをクライアントのマージ規則に沿って確認してください。
FakeIPモード：役割・利点・注意点
FakeIPは、LAN内のクライアントに対して一時的な仮想IPv4（既定では198.18.0.0/15付近）を返し、実際の接続時にプロキシ側で目的ホストへ誘導する方式です。メリットは、ドメイン単位のルールマッチが安定しやすいこと、複数CDN名が同一IPに潰れてルールが誤爆しにくいこと、などです。一方で、ローカル名・社内ドメイン・一部のキャプティブポータルでは想定外の挙動になりやすいので、fake-ip-filterで除外する運用が一般的です。
store-fake-ipを有効にするとFakeIPの対応表を保持し、再接続時の挙動が変わります。端末のメモリとトレードオフなので、モバイルや低スペック機では様子を見ながらにしてください。また、TUNモードと併用する場合は、TUNとdns-hijackの設定を同じプロファイル内で整合させる必要があります。トンネルは張れているのにDNSだけ古いOS設定を見ている、というパターンがよく起きます。
redir-hostとの違い（ざっくりの選び方）
redir-hostは、より素直に「上流DNSの結果のIP」を見てルーティングするイメージに近く、環境によっては設定が単純に感じられます。反面、DNS汚染やCDNの複数名の影響を受けやすい場面もあります。FakeIPはルール設計と相性が良い一方、テンプレートやドキュメントがfake-ip前提かどうかを確認しないと、説明と挙動が噛み合わないことがあります。どちらが「正解」ではなく、使うルールセット・クライアントのGUI・検証手順をセットで決めるのが安全です。
DoHとDoT：上流DNSの暗号化
DoH（DNS over HTTPS）はHTTPS上でDNSを運び、多くの場合https://...形式で指定します。DoT（DNS over TLS）は853/TCPをTLSで包み、tls://...やtls://address:853のように書くのが一般的です。Metaコアではこれらをnameserverやfallbackの要素として列挙できます。ポイントは、暗号化は「ISPの目から隠す」助けにはなるが、プロキシのルール整合を自動では保証しないということです。あくまで上流の信頼性・レイテンシ・ブロックされにくさを選び、FakeIPやtun.dns-hijackと組み合わせて全体を設計します。
パブリックDNSをそのままnameserverに並べる例：
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- tls://8.8.8.8
- tls://1.1.1.1
fallback:
- https://dns.google/dns-query
- https://cloudflare-dns.com/dns-query
fallback-filter:
geoip: true
geoip-code: CN
上記はサンプルです。自宅回線・規制環境・社内プロキシの有無で到達できる上流は変わるため、そのままコピーせず、遅延と到達性を確認しながら置き換えてください。fallback-filterの条件も、利用中のコア版の推奨に合わせるのが安全です。
TUNとdns-hijackを同じ頭で考える
TUNを有効にすると、OSから見たデフォルトルートやDNSの向き先が変わります。ここでtun.dns-hijackにany:53のような指定を入れておくと、アプリが古いDNSへUDPで撃とうとしてもClash側のDNS処理に寄せやすくなります。逆に言えば、TUNを切った瞬間に挙動が変わるのは正常で、「TUNあり／なしで同一のYAMLを前提にできるか」をテストしておくと運用が楽です。手順の全体像はClash Verge RevのTUNガイドと併読すると理解しやすいです。
動作確認の観点
まずクライアントの接続ログで、対象ドメインがどのルールにマッチし、どのDNS経路を想定しているかを確認します。外部サイトの「DNSリークテスト」は参考になりますが、ブラウザだけを見て成功と断定すると、アプリ別の漏れを取りこぼしがちです。可能なら、問題のアプリを起動した状態でもう一度観測してください。CLIツールでcurlやdigを使う場合、OSのリゾルバではなく明示的に指定したサーバを叩いていないかにも注意が必要です。
クライアント本体の入手と更新は、ダウンロードページから行うと、配布物の出所を揃えやすくなります。設定の用語索引としてはドキュメントも併用してください。
よくあるつまずき
一部ドメインだけ遅い・タイムアウトする：上流DNSのレイテンシや、fallback条件の誤設定で、意図せず遠いサーバへ振れている可能性があります。FakeIPフィルタ不足でローカル解決すべき名前まで仮想IPに載っているケースもあります。
ブラウザは速いがアプリだけ失敗する：アプリが独自のDNS（DoH固定）を埋め込んでいると、OSやClashの設定をすり抜けます。その場合はアプリ側の設定、もしくはOSの「暗号化DNS」設定を見直す必要があります。
IPv6だけ別ルートを行く：IPv4だけトンネルに載せてIPv6は直出し、という環境では、見かけ上「リーク」に近い挙動になります。ルーター側のIPv6設定や、クライアントのIPv6処理方針もセットで確認してください。
法令と規約：ネットワーク設定の変更は、居住地域の法律および契約、利用中のサービス規約に従ってください。本稿は技術的一般論であり、特定の制限回避を推奨するものではありません。
上流実装・ソースコードについて
Mihomo（Clash Meta）の挙動差分や最新キー名は、公開されているソースとリリースノートを参照するのが確実です。クライアントのインストールパッケージは、本サイトのダウンロード導線を主にし、リポジトリは仕様確認・Issue報告用として切り分けると混乱が減ります。
まとめ
DNSリーク対策の中心は、名前解決の責務をどこに置くかを決め、FakeIPまたはredir-hostのどちらの物語でルールを書くかを揃えることです。その上でDoH/DoTで上流を暗号化し、fallbackで異常時の経路を用意し、TUNを使うならdns-hijackまで含めて一本のプロファイルとして検証する、という順が実務では扱いやすいです。細部は回線と端末ごとに最適解が変わるため、ログを見ながら少しずつ詰めるのが近道です。
同種のGUIクライアントの中でも、Clash Verge RevはMetaコアの設定を画面から追いやすく、トンネルとDNSを同じ作業フローで試せます。ゼロから入れる公式パッケージはサイト側に揃えておくと、アップデートや再インストール時も手戻りが少ないでしょう。