Clash Meta（mihomo）裡 DNS over HTTPS（DoH）怎麼設？與 fake-ip 對齊的 Windows／macOS 指南（2026）

1. fake-ip＋DoH：你要對齊的是哪三段接力

在多數圖形客戶端的日常模型裡，fake-ip並不是「騙過全世界」，而是一個為了把資料連線拉回可被規則理解的主機名而存在的中繼：應用程式先拿到一個198.18.0.0/15（或你自己改寫的）虛構位址，再在本機發起資料連線；代理核心才在對應的 TLS／HTTP／QUIC／Sniffer 脈絡下去判斷要命中誰。DoH只是把「對外查紀錄」改成走 HTTPS／HTTP2／HTTP3 上的解析 API，對責任邊界而言，它比傳統 UDP/TCP53更不透明一些：許多問題會先在上游出口與對端供應商路由那裡顯現，而不是一眼就看出來。

因此你要對齊的其實是三段：A. 桌面應用程式到底把問題丟到哪裡——系統resolv.conf視角、Wi‑Fi 介面順序或瀏覽器級安全 DNS；（B. 本機 Clash／mihomo 監聽與dns區塊是否真的啟動、對外是否有策略一致的出口可走 DoH）；以及C. 規則與 sniffing 發生的時間點是否在過寬的MATCH／GEOIP之後才把流量送走。本篇把（B）寫成可貼的 YAML 骨幹，把（A）拆成 Windows／macOS 兩條照表操課路徑，把（C）回指到你在 sniffer 與優先序上已經付出的心力。

2. YAML：啟用 dns、寫進 DoH upstream

以下片段示範結構與常見欄位，請依你的訂閱模板、核心版本與機場慣例微調；重點是：nameserver裡出現https://或tls://（DoT）時，要同時檢查該上游是否能在你當前出口下成功握手，否則 fake-ip 再漂亮也只是一層糖衣。

dns:
  enable: true
  # listen address; match your GUI / stack
  listen: '0.0.0.0:1053'
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true

  # Primary resolvers (DoH examples)
  nameserver:
    - https://1.1.1.1/dns-query#🇭🇰-Group
    - https://dns.google/dns-query#🇭🇰-Group

  # Resolvers used when proxy path is required / isolated
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

  # Plain UDP/TCP as emergency fallback (optional)
  fallback:
    - tls://1.1.1.1:853
    - 8.8.8.8
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

上面#🇭🇰-Group只是示意「把 DoH 查詢出口綁在特定策略組」這件事在社群模板裡常出現；實際命名請替換成你檔案裡真的存在的proxy-groups條目。proxy-server-nameserver則用在「需要讓解析走代理管道」或 GUI 幫你隔離的場景，兩者混用時務必以日誌確認不是重複查詢或互相打架。

若訂閱作者已提供proxy-groups與完整的rules，切勿把我們的片段整段覆蓋掉；比較穩健的做法是「只合併你要的dns:鍵值」並用本地覆寫檔維護，以免更新訂閱時被沖掉。需要重新理解策略組語意時，可回到你慣用的 GUI（例如 FlClash、Clash Verge Rev、Mihomo Party）閱讀實際生效檔，而不是只看遠端下載下來的原始文字。

3. fake-ip-filter 與 nameserver-policy（避免誤分流）

fake-ip-filter處理的是「這些名稱我希望保留真實 IP」：常見包含區網主機、某些STUN／VoIP、或機場入口本身；漏列時並不一定會立即爆炸，但會在跨網段印表機、區網影音裝置這類題目上以「莫名其妙的逾時」出現。nameserver-policy則是讓「這家網域的紀錄交給哪一套 upstream」可被明講——對跨國／多出口的訂閱尤其關鍵，因為EDNS Client Subnet視角會影響你拿到的CDN Anycast結果，而 CDN 結果又會回頭影響你以為「節點壞掉」的那些表面現象。

dns:
  # ...same as previous block...
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'time.*.com'
    - 'time.*.gov'
    - 'time.*.apple.com'
  nameserver-policy:
    'geosite:cn':
      - https://doh.pub/dns-query
      - https://dns.alidns.com/dns-query
    '+.google.com':
      - https://dns.google/dns-query#🇭🇰-Group

實務上geosite／geolocation 類資料集是否齊備，取決於你訂閱是否附上對應的RULE-SET來源路徑；若缺資料卻硬寫，核心會在日誌裡提醒你載入不到規則。遇到這種情境寧可退一步，先用字面DOMAIN-SUFFIX把真的會用到的主機名列清，再等你有餘裕整理規則集。

4. Windows：介面順序／127.0.0.1 與安全 DNS

在 Windows 11／10，路徑用語會隨版本微調，但骨架不變：開啟設定 → 網路和網際網路，進入你正在使用的介面（Wi‑Fi 或乙太網路），展開DNS 伺服器指派為手動，優先填入Clash 核心的 DNS 監聽位址（常見寫法為127.0.0.1；埠號若由系統轉送或由客戶端另行橋接，請以 GUI 顯示為準）。若你有多張虛擬介面（公司 VPN、Hyper‑V 預設交換器、額外防火牆產品），請在「介面優先順序」層級確認目前工作階段真的會先問到本機，而不是被某張卡搶走。

接著處理瀏覽器：Microsoft Edge與Google Chrome的「使用安全 DNS」若指向 Cloudflare／Google／自訂供應商，會繞過你剛寫進系統的127.0.0.1，表現為「只有瀏覽器怪怪的」這種難題。對照細節可延伸閱讀本站Windows／Chrome／Edge／系統 Proxy 對照篇；在調校 DoH／fake-ip 這條鏈路的黃金實驗窗裡，我會建議先手動改成關閉供應商模式或使用目前服務提供者，把變數壓到我們能解釋的集合，確認沒問題再決定是否恢復瀏覽器級強化。

對PowerShell／WSL／容器工具鏈而言，請記得它不是「自動繼承你在 GUI 打勾的全部設定」：WSL有自己的resolv.conf視角與發行版預設；建置環境請交叉閱讀你正在用的開發環境部落格或直接以Resolve-DnsName／nslookup驗證該行程實際把查詢送到哪裡。這也是為何很多「規則我寫了但套件管理員仍像直連 ISP」的情境，並不是YAML沒套用，而是該工具的 DNS 視角壓根不是 Windows 桌面上你看到的那張介面。

5. macOS：服務順序、Profiles、本機監聽

在macOS桌面，許多進階使用者會直接用系統設定 → 網路 → 詳細資訊 → DNS加入127.0.0.1，或在企業環境交由 MDM下發的描述檔處理。無論來源為何，重點仍是「系統對一般應用程式的預設查詢會不會先落到本機」。若你同時啟用iCloud Private Relay、第三方防火牆、或公司 VPN 自帶的 DNS 覆寫，請注意它們可能在不同服務順序下各自插入自己的解析器；症狀常常不是完全失敗，而是間歇性切換到另一個上游，讓你以為節點品質在「跳動」。

另外一個在 Mac 上很常遇到的題目是HTTP3／QUIC與嗅探的互動：瀏覽器嘗試走更快的傳輸路徑時，有些規則還在舊的客戶端假設上，於是出現「看影片延遲但下載小檔案沒事」這種切片化症狀。把Sniffer與規則優先序調整到合理範圍通常比全面關閉新協定更現實；細節仍建議回到Sniffer 專文對照你核心版本支援的欄位。

若你平常用Surge／Little Snitch類工具觀察連線，請把它們視為「第二個真相來源」而不是互斥：它們能幫你看出某個行程是否直接連到443上的公共 DoH，但是否要攔截涉及個人風險與公司政策範圍，請自行衡量。本文只強調：任何落在「Clash／系統對齊路徑之外」的 DoH，都可能讓 fake-ip 的診斷變得難以重現。

6. 驗證與對照：用什麼證據判斷接好了

把 DoH 與 fake-ip 當成「工程變更」而不是「改改感覺變快」會省很多時間：① 在客戶端打開DNS 日誌或 debug 級輸出，確認查詢確實命中你寫的 upstream，而不是靜默 fallback 到某個你沒察覺的備援。② 以終端機工具對同一主機名跑兩輪解析，對照是否穩定回到 fake-ip 範圍內的位址／或 filter 規則內的真實位址——兩種答案都要能解釋。③ 在連線紀錄裡找對應時間戳是否出現一致的 SNI／DOMAIN 命中，並檢查是否被過寬的GEOIP提前接管。

④ 對照訂閱更新本身：若你在拉遠端設定檔時就出現 TLS 握手卡住，問題多半不是「fake-ip 哲學有錯」，而是更新這條鏈路的出口與時間窗；可先暫換網路，或保守調整proxy-groups，避免也把訂閱更新丟進你正在實驗、命中率還不穩的策略組。⑤ 準備最小重現資料：主機名、發生時間、客戶端版本，以及對應的日誌片段——當你要在論壇或社群發問時，這會明顯降低被泛泛猜題的比例。

7. 常見問題

我需要為了 DoH 額外開 TUN 嗎？不一定。TUN處理的是「哪些行程會被整張介面級路由覆蓋」，而DoH upstream處理的是「查紀錄走哪一個 HTTPS 終端」。兩者有交集，但不必然要綁在一起：若你已能確定問題行程會對127.0.0.1上的監聽發查詢，先把上游與 filter 對齊通常就很有感；若症狀集中在「這個程式不吃系統 DNS／Proxy」，再評估TUN 或程式自建代理連接埠。

fallback 為什麼會讓人覺得「外洩」或「規則亂跳」？通常來自過濾條件跟你實際網路拓樸不一致：例如誤判「污染」「假應答」而把查詢丟進另一條路徑，或上游太慢觸發連鎖 fallback。解法不是盲目刪掉 fallback，而是請日誌明確交代是哪個判定觸發了切換。

我可以同時保留瀏覽器 DoH，又讓系統指向 Clash 嗎？技術上可以並存，但不利於除錯：觀察窗會被切成兩套解析路徑，因而很難判讀規則命中究竟從何而來。學習與對齊階段我會建議先手動關閉瀏覽器級 DoH，把變數壓縮到你能在日誌裡解釋的範圍。