1 よくある症状（検索に至る体感）
Clash のログでは対象ドメインがプロキシグループに載っているのに、ブラウザやアプリの挙動だけが直結しているような見え方になる。VPN（TUN）をオンにしているはずなのに、名前解決だけがコアの DNS モジュールを通っていないような impression を持つ。FakeIP を有効にしている設定なのに、接続先 IP の見え方がルール評価と一致しない——これらは、OS が握っている DNS の入口がクライアントの設計と噛み合っていないときに起きやすいパターンです。Wi-Fi とモバイルデータで片方だけ変なときは、APN やキャリアの IPv6／464XLAT など別要因もありますが、まずプライベート DNS の状態を確認するコストは低く、再現性の切り分けにも向きます。
ここでいう「分流が効かない」は、必ずしも rules の行順ミスだけではありません。名前解決の帰結が FakeIP の連鎖と揃っていないと、実トラフィックの出口や証明書検証の見え方がずれ、二次的にタイムアウトや「一部サイトだけ開かない」といった症状へつながります。
2 Android の「プライベート DNS」とは何か
Android では、ネットワーク設定にプライベート DNSという項目があり、ざっくり次のようなモードがあります。オフ、自動（キャリア／ISP の既定 DNS に従う）、以及びプライベート DNS プロバイダのホスト名を指定して DNS-over-TLS（DoT）で問い合わせるモードです。メーカーや OS バージョンにより文言や並びは異なりますが、「システム全体で暗号化 DNS を強制的に使う」という性格は共通しています。
ホスト名を指定している場合、そのプロバイダはクラウド由来のパブリック DNS（例：Google・Cloudflare・NextDNS など）になることが多く、ローカルのスタブや VPN が期待する解決チェーンの外側へ問い合わせが出ます。アプリごとの設定ではなくOS レベルなので、ブラウザに限らず多くのソケット API が影響を受けます。これがデスクトップの Chrome「セキュア DNS」との決定的な入口の違いでもあります（後述）。
3 なぜ Clash・FakeIP と衝突しやすいか
Mihomo（Clash Meta）では、dns.enable と listen アドレスを設定し、Android 側の「プライベート DNS」をオフまたは自動にすることで、OS が返すスタブ（例：172.19.0.2 や端末実装依存のアドレス）へ問い合わせが集約されやすくなります。一方、プライベート DNS でホスト名が固定されていると、ドメイン問い合わせがコアの DNS スタックを迂回し、FakeIP（仮想アドレスを返す設計）との連鎖が成立しません。結果としてルールは「合っているはず」なのに、実 IP ベースの経路や証明書検証だけが期待とズレる、という見かけの不整合が生じます。
VPN アプリが「常時オン」やセキュリティ DNS を強制する機能を持っている場合も加わり、設定画面が二重三重になりがちです。Clash 系クライアントの FlClash を Android で使う場合の全体像とあわせて、どのレイヤが名前解決を握っているかを意識すると迷いにくくなります。
4 Chrome／Edge（デスクトップ）のセキュア DNS 記事との棲み分け
当ブログのChrome／Edge のセキュア DNS と Clash の記事は、Chromium ブラウザがアプリ内で DoH を握る問題が主題です。設定はブラウザのプライバシー画面にあり、プロファイル単位で独立します。一方、本稿のAndroid プライベート DNSはOS のネットワーク設定にあり、アプリ横断で効きます。症状が「ブラウザだけ」なら前者、「システム全体で変」なら後者を優先して疑ってください。両方オンになっているケースもあり、その場合はどちらもオフまたは自動へ戻し、コア側の DNS 設計に一本化するのが再現性を取り戻す近道です。
コア内部の dns ブロック、fake-ip、fallback-filter の細部はMeta カーネル DNS の実務記事に譲ります。OS のプライベート DNS を切ったうえでまだ噛み合わない場合は、TUN／システムプロキシ、バッテリー最適化、省電力による VPN 切断なども別記事で扱っているレイヤです。
5 設定をオフまたは「自動」へ戻す（一般的な導線）
機種や Android の世代により文言は異なりますが、おおむね設定アプリ → ネットワークとインターネット（または接続）→ プライベート DNSの順です。オフにするか、少なくとも自動（ISP／キャリア既定）を選び、ホスト名による第三者 DNS への固定をやめます。変更後は、可能なら端末を一度スリープから復帰させるか、対象アプリを強制終了してから再度試し、DNS キャッシュの影響を減らしてください。
「セキュリティのためにプライベート DNS を入れた」という場合でも、Clash 側で DoH／DoT とフィルタリングを設計する運用なら、OS とコアで別々のリゾルバへ逃がさないことが安定の鍵です。上位 DNS をMihomo の設定だけで統制するか、OS は自動に任せるか、どちらかに寄せると二重管理が減ります。
ADB や開発者向けの話題について
開発者オプションや企業ポリシー、カスタム ROM では追加の DNS 制約がある場合があります。一般ユーザー向けの本文では深追いしませんが、職場端末で UI がロックされているときは管理者ポリシーが優先されます。無断で回避手段を試さないでください。
6 VPN・ワークプロファイル・常時接続との関係
Android の「常時オン VPN」やワークプロファイル経由の接続では、DNS の扱いが VPN アプリ実装に依存します。プライベート DNS をオフにしてもVPN アプリ側が別の DNS を注入しているケースがあり、その場合は VPN の設定画面と Clash／Mihomo の TUN・DNS 設定を対で確認します。Termux 上で Mihomo を動かすような構成では、さらに名前空間やルーティングが分岐するため、Termux 関連の記事のレイヤとも混同しやすい点です。
省電力設定で VPN がバックグラウンドで落ち、結果としてフォールバックの経路だけ名前解決が変わる、という見せかけもあります。長時間の安定運用では、バッテリー最適化の除外と、プライベート DNS を自動側に寄せる組み合わせが再現性を高めることが多いです。
localhost、プリンタ、NAS、mDNS など、LAN 内ホスト名はグローバル DNS に存在しません。上位 DNS だけに依存する設定にすると名前解決が失敗することがあります。クライアントの DNS の fake-ip 範囲や fallback の設計とあわせて、ローカル宛トラフィックは DIRECT 側に残す定石を確認してください。
7 変更後の確認と、それでも直らないとき
プライベート DNS をオフまたは自動にしたあと、問題のサイトやアプリを開き直して挙動を比較します。Clash／Mihomo の接続ログと DNS ログで、問い合わせがローカルリスナに届いているかを見ると確度が上がります。信頼できる「現在の DNS／出口」を表示する検査サイトは実装依存なので、一つの結果だけで断定せず、ログと往復させてください。
まだ分流が期待と違う場合のチェックリスト例です。① ほかのセキュリティアプリや広告ブロックがローカル VPN で DNS を握っていないか。② ブラウザアプリ単体にセキュア DNS が残っていないか（デスクトップ記事を参照）。③ TUN／権限・バッテリー最適化。④ YAML の dns.enable、listen、アドレス、fallback-filter——①②はアプリ層、③④は OS／コア層に分けると切り分けが進みやすいです。
8 まとめ
Android のプライベート DNS（ホスト名指定の DoT をシステム全体に効かせるモード）が有効だと、Clash／Mihomo が用意するスタブリゾルバや FakeIP の連鎖を迂回し、ルールベースの分流が効いていないように見えることがあります。コアの YAML をいじる前に、OS 設定でオフまたは自動へ戻し、名前解決をコアの設計に寄せられるかを確認するのは費用対効果が高いです。デスクトップの Chromium はブラウザ設定、Android はシステム設定——入口が違うことを押さえると、検索意図も記事選びもブレません。
ルールと DNS を同一クライアントで扱える構成に寄せておくと、長期的には「どこで解決しているか分からない」状態を減らせます。スマートフォン特有の省電力や VPN アプリとの相互作用も忘れず、ログベースで一段ずつ潰していくのが安全です。
