1 よくある症状（検索に至る前の体感）
クライアントの接続ログやダッシュボードでは、対象ドメインが期待どおりプロキシグループに載っているのに、ブラウザの表示 IP や到達性だけが「国内直結のような挙動」になる。別のブラウザ（Firefox や Safari）や curl では期待どおり出口が変わるのに、Chrome／Edge 系だけズレる。VPN や TUN を切り替えても、ページリロード後も名前解決だけがコアを通らないように感じる——これらはすべて、アプリ層で DNS が別経路に逃げている典型パターンです。
ここでいう「分流が効かない」は、必ずしも YAML の rules 行順の誤りだけを意味しません。名前解決の帰結がコアの設計と一致していないと、接続先 IP がルール評価時点の想定と異なり、結果として意図したアウトバウンドに載らない、あるいは証明書エラーやタイムアウトが断続する、といった二次症状が出ます。まずブラウザのセキュア DNS を疑うのはコストが低く、再現性の切り分けにも向いています。
2 なぜブラウザのセキュア DNS が Clash と衝突するか
Chromium 系は、プライバシーと改ざん耐性を理由に、HTTPS（TLS）越しの DNS 問い合わせをブラウザプロセス内で完結させるモードを持ちます。設定が「オン」のとき、OS が 127.0.0.1 のスタブリゾルバ（多くの GUI クライアントが Clash／Mihomo の DNS リスナへ向ける先）を返していても、ブラウザはそこを経由せず、指定されたプロバイダ（例：Google Public DNS、Cloudflare、NextDNS など）へ直接 DoH を送ることがあります。
一方、FakeIP（enhanced-mode: fake-ip）は、コアがドメインに対して仮想アドレスレンジを返し、実接続フェーズで本物の A/AAAA を組み立てる設計です。解決がブラウザ内で完結し、コアの DNS モジュールを迂回すると、この連鎖が成立しません。結果として「ルールは合っているはずなのに実トラフィックだけ別ルート」という見かけ上の不整合が生じます。システムプロキシや TUN を正しく設定していても、DNS だけがアプリ固有という最後の抜け穴が残る、という整理です。
nameserver に書く DoH とは別レイヤです。ブラウザが勝手に使う DoH を切ることと、Mihomo で DoH を使うことは矛盾しませんが、二重に別々のリゾルバへ逃がさないことが重要です。
3 Meta カーネルの DNS 記事（#3）との棲み分け
当ブログのMeta カーネル DNS 実務記事は、Mihomo（Clash Meta）コア内部の dns ブロック、fake-ip、fallback-filter、TUN／OS DNS との連携といったシステム寄りの設計が主題です。本稿はそこから一段下のChromium アプリ設定に焦点を当て、同じ「DoH」という語でもブラウザが握っているスイッチをどう切るかを補います。
つまり、YAML と OS を整えたあとも症状が残る場合は「コアの設定ミス」だけでなく、Chrome／Edge のセキュア DNS がまだオンという可能性を列挙に入れてください。逆に、ブラウザをオフにしても直らない場合は、TUN モードや Windows の UWP ループバック、別アプリの独自リゾルバなど、他層の切り分けに進むのが順当です。
4 Google Chrome でセキュア DNSを無効化する
手順はバージョンにより文言が多少変わりますが、2026 年時点の一般的な導線は次のとおりです。設定を開き、「プライバシーとセキュリティ」→「セキュリティ」を開き、画面下部付近の「セキュア DNS を使用する」（英語 UI では “Use secure DNS” 相当）をオフにします。カスタムプロバイダを列挙するモードになっている場合も、まずはオフに戻して挙動を比較してください。
複数のプロファイル（仕事用と個人用など）を使い分けている場合、プロファイルごとに設定が独立します。症状が出るプロファイルだけオンになっている、というケースは珍しくありません。chrome://policy で組織ポリシーが入っていないかも併せて確認すると、個人端末と職場端末で結果が分かれる理由が説明できることがあります。
上級者向け：内部ページでの確認
切り分けの補助として、chrome://net-internals/#dns 周辺の画面や、DNS 関連のイベントログを一時的に観察する方法もあります。ただし内部 URL はバージョンで削除・変更されるため、最終的には設定 UI でオフにしたうえで再試行を正とし、内部ページは補助に留めるのが無難です。
5 Microsoft Edge でセキュア DNSを無効化する
Edge も Chromium ベースのため構造は似ています。「設定」→「プライバシー、検索、サービス」→「セキュリティ」付近に、「セキュア DNS を使用する」に相当する項目があります。ここをオフにするか、少なくとも「サービス プロバイダーを選択する」ではなくシステム既定に従う状態へ戻し、ブラウザ独自の DoH が動いていないことを確認します。
Windows では、OS 側の「暗号化された DNS」設定とブラウザ側のセキュア DNS が別ダイアログで管理される点に注意してください。OS を Clash のスタブに向けていても、Edge がブラウザ設定で別プロバイダを選んでいれば、やはり衝突し得ます。設定変更後は、可能なら Edge をいったん終了してから起動し直し、プライベートウィンドウと通常ウィンドウで挙動を比較すると、キャッシュや拡張機能の影響を減らせます。
6 無効化の確認と、それでも直らないときの追加切り分け
まず、セキュア DNS をオフにした状態で、問題のサイトを再読み込みします。併せて、信頼できる「現在の出口 IP を表示する」系の Web ページや、DNS リーク検査ツールで、リゾルバの名前が自宅回線の ISP 直ではなく、想定どおりコア経由の経路になっているかを見ます。ツールの表示は実装依存なので、一つのサイトだけで断定せず、コアのログ（問い合わせがローカルリスナに来ているか）と往復させると確度が上がります。
ブラウザを直しても残る場合のチェックリスト例です。① 他の Chromium 派生（Brave、Vivaldi など）でも同様の「セキュア DNS」項目がオンになっていないか。② 拡張機能が VPN／DNS を上書きしていないか。③ DoH ではなく DoT や別アプリのフィルタがシステムワイドで効いていないか。④ コアの dns.enable や listen アドレス、ファイアウォール例外が期待どおりか——①②はアプリ層、③④は OS／コア層に分けて疑うと迷子になりにくいです。
7 プロファイル分離と「一部サイトだけおかしい」現象
同一マシンでも、Chrome のプロファイル A では再現せずプロファイル B だけ再現する、という報告はよくあります。セキュア DNS のほか、同期された設定、実験フラグ（chrome://flags）、拡張機能の有効／無効の差が原因になることがあります。再現プロファイルを一時的に新規作成し、拡張機能なしのクリーン状態で同じ URL を開いて比較すると、原因が「ブラウザ設定」か「環境汚染」かを切り分けやすくなります。
また、HSTS やキャッシュされた証明書エラーが二次的に絡むと、「DNS を直したのにまだ開けない」ように見えることがあります。セキュア DNS をオフにしたあとでも問題が続く場合は、別要因の可能性を切り分けるため、時間をおいて試す、サイトデータだけ削除する、など通常のブラウザトラブルシュートも並行してください。
8 まとめ
Chrome や Edge のセキュア DNS（ブラウザ内 DoH）が有効なままだと、OS や Mihomo が提供する名前解決チェーンをすり抜け、FakeIP とルールベース分流が期待どおりに見えなくなることがあります。コア側の YAML を疑う前に、ブラウザ設定で一度オフにし、症状が消えるかを確認するのは費用対効果の高い手順です。システム全体の DNS 設計は引き続きMeta カーネル向けの解説を参照し、アプリ層の抜け穴を本稿で塞ぐ、という二段構えがわかりやすいです。
ルールと DNS を同じクライアントで扱える環境に寄せておくと、長期的には設定のブレや「どこで解決しているか分からない」状態を減らせます。単体のブラウザ設定一つでも、分流の見え方は大きく変わる——その点を押さえておくだけで、夜間のトラブルシュート時間を短くできるはずです。
