Clash Meta（mihomo）で DNS over HTTPS（DoH）を設定し、fake-ip と矛盾なく揃える手順：Windows と macOS（2026）

1. なぜ fake-ip と DoH を「別問題」として扱わないのか

DoHは名前解決を HTTPS 上に載せるトランスポートの選択です。一方 fake-ipは dns.enhanced-mode がアプリケーションに返す応答の形と、コア内部でドメインと接続をひも付ける流れを変えるスイッチです。つまり 「DoH にしたから fake-ip が不要になる」わけでも、「fake-ip なら DoH は使えない」わけでもありません。ユーザー体感として問題になりやすいのは、ブラウザや OS がコアより先に自分好みのリゾルバへ問い合わせてしまい、ルール評価まで届く前に IP が決まってしまうパターンです。このとき画面には「つながる／切れる」だけが出て、どの DNS 経路で名前が確定したかが見えにくくなります。

したがって実務では、まず「クエリがコアの DNS リスナーに到達しているか」を確定させ、次に 「上流が DoH で期待どおり応答しているか」を見るのが早道です。購読テンプレートがデフォルトで DoT／DoH 混在になっている場合もあるため、自分が本当に有効化している行をプロファイル全体で確認してください。テンプレの骨格理解は チュートリアル総覧にもまとまっています。

2. mihomo の YAML：DoH を nameserver に載せる書き方

mihomo（Clash Meta）では、HTTPS 形式の URLを dns.nameserver に並べることで DoH へ向けられます。環境やバージョンで細部は異なるので、必ず手元のドキュメントとログで裏取りしてください。以下は説明用の断片であり、既存の proxy-groups や rules とはマージして使います。PoP や規約によりブロックされるエンドポイントもあるため、使う URL は各プロバイダの公式表記に合わせます。

# config.yaml fragment — DNS over HTTPS with fake-ip (adjust to your profile)
dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://9.9.9.9/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

listen はクライアント／OS が実際に向ける口です。TUN モードやシステム設定で 127.0.0.1 に固定したい運用なら、その方針と矛盾しないようにします。fallback と fallback-filter は、メイン DoH が失敗したときの保険です。国内ドメインだけ別 DNS に寄せたい場合は nameserver-policy で束ねると、名前の出どころをルール側と揃えやすくなります。ポリシーを足すほど差分が見えにくくなるので、一度に複数項目をいじらず、ログで効果を一区切りずつ確認するのが安全です。

3. fake-ip との整合：listen・filter・policy

fake-ip を維持したまま DoH を入れるときの要点は、「仮 IP で返してよい名前」と「実解決寄りに残したい名前」の境界です。fake-ip-filter に LAN 名やキャプティブ検出などを入れる典型は、既存テンプレにも載っていることが多いですが、自宅の NAS 名・社内ドメイン・ゲームランチャー特有の名前が抜けていると、仮 IP とアプリ期待がすれ違います。フィルタを広げすぎると fake-ip の利点が薄れるので、ログで「そのドメインはどう解かれたか」を見てから追加するのがよい運用です。

nameserver-policy は「このサフィックスはこのリゾルバ」と決める仕組みです。例えば国内サイトだけ ISP の DNS、海外だけパブリック DoH、といった切り方ができますが、ポリシーどうしの優先順位とルールの DOMAIN 条件が噛み合っていないと、また別の経路で名前が固まってしまいます。HTTPS 接続が IP のまま見えてドメインルールに乗らない場合は、DNS 以前に Sniffer 側の話になるので、症状を混同しないようにしてください。

4. Windows：システム DNS とブラウザのセキュア DNS

Windows では アダプター DNSと Chrome／Edge の「セキュア DNS」が同時に効き、コア外で名前が確定しやすいです。まず GUI クライアントを使っていても、実際に効いているプロファイルが一本か、TUN やシステムプロキシと DNS の組み合わせが想定どおりかを確認してください。ブラウザだけ挙動がおかしいときは、Windows でのセキュア DNS とシステム代理の稿に沿って セキュア DNS をオフにするか、提供元を限定してコアと二重にならないようにするのが現実的です。

アダプター側では、暗号化された DNSの設定が有効になっていると、コアのリスナーに届かないケースがあります。運用ポリシーとして「コアの DNS が正」と決めるなら、OS が先に外向き DoH を握らない状態へ寄せます。変更後はブラウザのシークレットウィンドウだけでなく、別アプリ（CLI など）でも名前解決の経路が一貫しているかを軽く確認すると見落としが減ります。購読更新が DNS で失敗する話題は切り分けの癖が似ているため、購読更新とログの稿も参照ください。

5. macOS：ネットワーク DNS とブラウザの重複を避ける

macOS では システム設定の DNSと、ブラウザ拡張やブラウザ内のセキュア DNS が組み合わさります。Wi‑Fi プロファイルごとに DNS が残っていると、場所を変えた瞬間だけ挙動が変わるので、接続先ごとの DNS 一覧を一度整理しておくと再現性が上がります。iCloud Private Relay や VPN 系と同時に TUN を使う場合は、どちらが名前解決の最終形を握るかが衝突しやすい点にも注意してください。

コア側で listen をローカルに固定し、システムの DNS をそのアドレスへ寄せる運用にするか、クライアントの「システム代理／TUN 連携」に任せるかは、利用中の GUI（Clash Verge Rev など）の設計に依存します。どちらにしても、ブラウザが独自の DoH を有効のままだと 二重解決に戻るので、Windows と同様にブラウザ設定を一段いじることになりがちです。調整のたびに短時間だけ debug を取り、戻すことを忘れないでください。

6. 検証：ログと動作確認の順序

推奨順は次のとおりです。（1）再現手順を1本に絞る。（2）一時的に log-level: debug を入れ、DNS とルールマッチの行が続くか眺める。（3）Windows／macOS のブラウザ・OS 設定を変えた前後でログ差分を見る。（4）問題が消えたらログレベルを通常へ戻す。常時 debug は肥大化と情報漏えいリスクが上がるため、トラブルシュートの窓だけ開ける運用がよいです。

# temporary — revert after checks
log-level: debug

GUI 利用時も、画面上の策略名とログの一致、インポート後に本当に再起動／再読み込みされたかを最初に確認すると、時間の大半の「設定したつもり」事故を防げます。mihomo は表現力が高い反面、差分が増えるほど観測ポイントも増えるので、変更は小さなコミットのように積み上げるのが再現性につながります。

7. 典型トラブルと切り分け

代表的なのは次の三つです。（1）ブラウザ DoH が先に勝ち、コアの fake-ip パイプラインにクエリが来ない。ルールは生きているつもりでも名前確定が別経路だと、期待したアウトバウンドに乗りません。（2）nameserver-policy とルールの DOMAIN 条件が噛み合わず、意図しないリゾルバに流れる。ポリシーは便利ですが、優先順位を説明できない設定は後から壊れます。（3）HTTPS が IP 評価のまま残り、ドメイン系ルールに届かない。これは DNS 以前のレイヤーなので Sniffer 側の切り分けへ進みます。

どのケースでも、まず「その接続で名前がどこで確定したか」をログに残すことが第一歩です。感覚的なルール足しより、観測できる事実を1行ずつ固定したうえで、フィルタ・ポリシー・ブラウザ設定のどれを動かすかを選ぶと、設定理由を将来の自分に説明しやすくなります。

8. よくある質問

Q. DoH のエンドポイントを複数並べれば速くなりますか？
A. 必ずしもそうではありません。並列ではなくフェイルオーバーやフォールバックの意図で並べることが多く、環境によっては最初の1つに偏ります。遅さより応答不全が問題なら fallback の設計を見直すほうが効く場合があります。

Q. redir-host に切り替えたほうが楽でしょうか？
A. ブラウザ DoH との二重解決が主因なら、モード変更よりブラウザと OS を先に揃えるほうが副作用が少ないことが多いです。モード比較の判断軸は 対照稿にまとめています。

Q. VPN と同時に使えますか？
A. 構造的には可能ですが、どちらがルーティングと DNS の最終決定権を持つかが衝突しやすいです。同時利用時は、fake-ip でも DoH でも「観測してから」と心得てください。

9. まとめ

Clash Meta／mihomo で DoH を入れる作業は、URL を1行足すことよりも fake-ip と OS／ブラウザの解決経路を一本化する作業のほうが比重が大きいです。listen・fallback・nameserver-policyを理解したうえで、Windows／macOS それぞれのセキュア DNS を点検すると、分流失効や地域判定のズレが劇的に減ります。変更のたびにログで確認すれば、設定の「なぜ」が残るので運用も楽になります。

一方で、公式クライアントを前提にしない改造版や、ルール編集がGUIから追いにくいフォークでは、DNS と TUN の組み合わせがブラックボックスになりがちです。差分を説明しづらい環境ほど、トラブル時に手戻りが増えます。ルールとログの両方を読みやすい Clash 系のエコシステムは、観測しながら DoH と fake-ip を同時にいじれる意味で、長期運用の再現性が高い部類に入ります。GUI の選択や入手は「雰囲気で入れる」と後から DNS だけ例外だらけになりやすいので、最初から観測可能なクライアントを選ぶ価値があります。

クライアントの入手と環境別の導線は → 無料で Clash をダウンロードし、快適な接続体験を試す からどうぞ。