1 為何仍會發生 DNS 洩漏
DNS 洩漏指的是：您以為流量已走加密隧道，但網域名稱解析卻仍由電信業者、公司內網或作業系統預設的解析器完成。對方雖然未必看得到完整 HTTPS 內容，卻能從查詢紀錄推斷您造訪了哪些站點，在某些網路環境下風險並不低。
常見原因包含：僅開啟「系統代理」而應用程式自行解析、命令列工具忽略代理設定、IPv6 走另一條路由、以及行動裝置的私人 DNS與客戶端內建解析策略互相打架。若規則引擎依賴「目標網域」做分流，但應用程式在握手前拿到的 IP 與規則預期不一致，還會出現「看似連上卻頻繁重試」的假性故障。
Meta 核心（Mihomo／Clash.Meta）內建完整的 dns 模組，可把解析納入與規則、出站、日誌同一套管線。接下來我們會先講管線，再談 FakeIP 與 DoH 如何分工，最後給一段盡量可直接改寫上線的 YAML。若您打算在伺服器上以 systemd 常駐核心，可先對照Linux 安裝 Mihomo 與 systemd 教學把服務跑起來，再把本文的 dns 區塊併入。
2 Meta 核心的解析管線（概念）
啟用 dns.enable 後，核心會在本機監聽一個 DNS 埠（例如 127.0.0.1:1053），並依設定把查詢送往 nameserver、fallback 或 nameserver-policy 指定的上游。與傳統「作業系統直接問 8.8.8.8」不同，您可以把解析決策與出站策略綁在一起思考：哪些網域應快速直連、哪些應走可信的加密 DNS、哪些要在被污染時自動切換備援。
default-nameserver 的角色特別容易被忽略：它是用來解析 DoH／DoT 伺服器主機名稱本身的「引導解析器」，通常會保留為延遲較低、可達性高的傳統 UDP／TCP DNS。若把引導與業務查詢混在同一組加密上游而沒有拆開，可能在網路剛連上、或上游暫時不可達時出現雞生蛋的循環依賴。
log-level 暫調為 debug，觀察單一網域從「收到查詢」到「選擇出站」的完整鏈路，再恢復 info。這比憑感覺改規則更有效率。
3 FakeIP：讓「解析結果」與「規則」對齊
FakeIP（enhanced-mode: fake-ip）的核心想法是：對大多數需要分流的網域名稱，核心先回一個虛構位於 fake-ip 區段內的位址（常見為 198.18.0.1/16），等實際連線發生時再依規則決定真實解析與出站。這樣做的好處是應用程式不會提前拿到「與規則不一致」的真實 IP，較不容易出現繞過或匹配錯亂。
fake-ip-filter 用來列出不應走 FakeIP的網域或後綴，例如區網名稱、部分對本機服務敏感的網域。漏設會導致本該直連的目標被錯誤導向；設太多則削弱 FakeIP 的保護效果。建議至少涵蓋 *.lan、*.local、*.localhost 等常見內網慣例，並依您實際使用的 NAS、印表機或公司內部網域補齊。
若您更在意與舊版行為相容，亦可評估 redir-host 模式；但在多應用、多協定並存時，FakeIP 通常較容易與 Rule 模式協同。選定後請整體測試，不要在同一台機器上混用互相矛盾的系統 DNS 與核心策略。
4 DoH、nameserver 與 fallback-filter
DoH（DNS over HTTPS）把查詢包在 TLS 裡，對中間設備較不友善，可降低被竄改與旁路記錄的機率。nameserver 一般放您主要信任的上游，可依延遲與法遵需求混合國內與國際供應商；fallback 則作為主要上游回傳可疑結果時的備援。
fallback-filter 典型會搭配 geoip: true 與 geoip-code，用來辨識「看起來不合理」的回應（例如應為海外站卻得到特定區域的保留或污染特徵）。再加上 ipcidr 黑名單（如 240.0.0.0/4）可過濾明顯無效位址。參數細節會隨核心版本演進，若升級後行為改變，請以官方 Wiki 與變更日誌為準。
nameserver-policy 可把特定網域／地理分類導向專用上遊（例如將國內常用網域指向延遲較低的 DoH）。撰寫時請注意與 rules 中 GEOSITE、GEOIP 策略一致，避免「解析走 A 路徑、連線却按 B 規則」的撕裂感。
5 生產環境 YAML 範本（DoH + FakeIP）
下列片段假設您已具備可用的 proxies 與 proxy-groups，僅示範 dns 與全域開關的相對完整拼法。請將密碼、埠號、上游 URL 依環境替換；若與訂閱產生的片段衝突，以「單一權威來源」為原則合併，避免重複 dns: 鍵。
# Global flags — align with your full config
mode: rule
ipv6: false
log-level: info
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "*.localhost"
- "+.stun.*"
# Bootstrap resolvers for DoH/DoT hostnames
default-nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
fallback:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
nameserver-policy:
"+.cn":
- https://doh.pub/dns-querydns 區塊。若未合併而是被覆寫，可能一夜之間退回「純系統解析」。建議在面板或模板中固定採用您驗證過的 DNS 策略。
寫入後請執行核心提供的語法檢查（例如 mihomo -t -d /etc/mihomo），確認無 YAML 錯誤再上線。若您的核心版本支援 geosite: 類規則，亦可將 nameserver-policy 的鍵改寫為官方文件建議的形式，以取代範例中的 +.cn 後綴匹配。
6 TUN 與作業系統 DNS 對齊
僅依賴「應用程式讀系統代理」時，最容易漏掉不走代理的程式。開啟 TUN 可把更多底層流量納入核心，但同時也會放大 DNS 設定的影響面：若作業系統仍指向電信自動下發的解析器，部分查詢可能在進隧道前就已送出。
實務上常見作法是：讓系統 DNS 指向核心監聽位址（與 dns.listen 一致），並在用戶端啟用與 TUN 配套的 DNS 劫持／重定向選項（名稱依客戶端而異）。圖形介面使用者可參考Clash Verge Rev TUN 模式完全指南中的整體流程，再把本文的 dns 參數嵌回設定檔。
macOS 與 Windows 對「系統 DNS」的介面不同，行動裝置又有「私人 DNS」與「永遠開啟的 VPN」等特殊行為。對齊的原則只有一句話：確保應用程式認為要問的 DNS，最終會落到核心正在監聽的那個埠，而不是另一套您沒察覺的解析鏈。
7 驗證與常見陷阱
- 線上洩漏檢測：在規則與 TUN 皆穩定後，使用信任的 DNS 洩漏測試頁面觀察列出的解析器是否僅剩預期上游／節點出口。請勿過度解讀單次結果，應多次刷新並切換網路環境比對。
- IPv6：若上游或本機意外啟用 IPv6，而規則未涵蓋，可能出現「繞過隧道」的旁路。若環境不需要 IPv6，可在核心與系統層級同步關閉以降低變數。
- Android 私人 DNS：與 FakeIP、本機監聽埠策略容易衝突。除錯時建議改回自動，確認訂閱與規則無誤後，再依FlClash Android 配置教學逐步收斂。
- 公司根憑證與分離隧道：企業裝置可能攔截 DNS 或強制內網解析，與個人用戶端的「全加密解析」目標衝突。此時應以資安政策為優先，而非硬套同一組 YAML。
nameserver 或 fallback，再查規則匹配與實際出站。順序顛倒容易誤判為「節點壞了」。
8 總結
徹底降低 DNS 洩漏風險，重點不在堆疊更多加密協定名詞，而是讓解析路徑、規則引擎與實際出站彼此一致。FakeIP負責把應用程式看到的位址與分流決策對齊，DoH與fallback-filter則負責在不可信的網路裡挑選較可信的上游，並在異常時自動退避。
若您希望盡量減少手動維護 YAML，可優先選擇內建 Meta 核心、並對 TUN／DNS 有完整開關的用戶端；相較零散組合各種外掛，一體化用戶端在升級與除錯上通常更省事。站上的下載頁整理了跨平台選擇，方便與本文的命令列或伺服器部署方案並用。
