為什麼會「DNS 洩漏」？先釐清三條路徑
所謂洩漏，不一定是「別人立刻看到您的身分」，更多時候是解析請求沒有走您預期的隧道，導致本機 ISP、路由器或公司 DNS 仍看見您正在查哪些網域。對使用規則分流的 Clash 類客戶端而言，更棘手的狀況是：規則顯示命中、連線卻走錯策略，因為域名解析結果與實際連線目標不一致，或應用程式繞過了客戶端提供的解析鏈。
實務上可先把路徑想成三條：系統解析器（作業系統或路由器指派的 DNS）、應用程式內建解析（瀏覽器 DoH、某些遊戲或通訊軟體）、以及代理核心內建的 DNS 模組。Meta 核心的價值在於，能把「需要被規則看見的解析」盡量收斂到同一條管線；但若您同時在系統層硬塞另一套 DoH，或在未開 TUN 時讓部分程式仍走系統 DNS，就會出現看似設定正確、體感卻不一致的現象。
若您尚未完成桌面客戶端基礎安裝，建議先依 Clash Verge Rev Windows 完整安裝與設定教學（2026）：從零到系統代理 建立可更新的設定檔與訂閱流程，再回到本文調整 dns 區段，學習成本會低很多。
Meta 核心的 DNS 管線：從查詢到規則命中
在 Meta／Mihomo 中，dns.enable 為 true 時，核心會嘗試介入解析流程，讓後續的 RULE 能以「預期中的域名／IP 資訊」做決策。當 enhanced-mode 設為 fake-ip 時，核心會對符合條件的查詢回傳一段虛擬位址（常見於 198.18.0.0/16 這類私有範圍），真正的解析延後到連線建立階段再處理。這樣做的好處是：規則可以先依域名分流，而不必在第一次 DNS 回應就暴露真實出口解析路徑。
相對地，若使用 redir-host（或舊文檔中的類似概念），核心較傾向讓客戶端看見「較接近真實」的解析結果，對某些應用程式的相容性可能較直覺，但在規則與解析一致性上更需要您自行把關，避免系統層 DNS 搶答。兩種模式沒有絕對優劣，取決於您是否啟用 TUN、是否依賴 Sniffer、以及訂閱規則對域名的依賴程度。
小結：先把「模式（fake-ip／redir-host）」與「上游 DNS 清單」當成兩個旋鈕；只改其中一個卻忽略另一個，最常產生「延遲變高」或「特定網站永遠直連」的錯覺。
Fake-IP：與規則分流如何協作
Fake-IP 的核心意義不是「造假」，而是把域名決策與連線決策綁在同一套狀態機裡。當應用程式拿到 Fake-IP 後，實際連線仍由代理核心接管，核心再依策略組與規則決定要走向哪個節點。對需要命中 DOMAIN／GEOSITE 類規則的情境，Fake-IP 通常能顯著降低「解析先洩漏、規則卻來不及介入」的機率。
使用 Fake-IP 時，請一併留意：fake-ip-filter（或您版本中對應的排除清單）是否需要排除區域網段、本機服務或特定網域；以及 Sniffer 是否在您的場景需要開啟，以彌補少數只使用 IP 連線的應用程式。若您發現「瀏覽器正常、遊戲或桌面程式異常」，往往是這類邊界條件，而不是節點本身故障。
DoH 與 DoT：把上游查詢包在 TLS 裡
DNS over HTTPS（DoH）與 DNS over TLS（DoT）的共通點，是讓客戶端到公共解析器之間的查詢不易被旁路竊聽或篡改。在 Clash Meta 的設定中，通常以 https:// 開頭的 URL 表示 DoH，以 tls:// 表示 DoT。實務上建議準備至少兩組不同路徑的上游（例如不同供應商或不同傳輸型態），避免單點在區域網路或出口被干擾時整體失效。
需要強調的是：DoH／DoT 解決的是您到公共解析器這一段的機密性與完整性；若應用程式仍繞過核心、直接向系統解析器發問，問題會回到「路徑沒進隧道」。因此請把加密 DNS 視為必要但非充分條件，並與 TUN、系統代理模式與應用程式行為一併檢視。
fallback、fallback-filter 與「誰是備援」
當主要 nameserver 無法在合理時間內回應，或回應被判定不可信時，fallback 清單會接手。設定時請避免「主與備完全同一條路由、同一個封鎖點」，否則備援意義不大。fallback-filter 則用來定義哪些情況要切到備援，例如對特定地域或結果型態敏感時。這裡的調整會直接影響首次連線延遲，建議以「能穩定上網」為先，再逐步收緊。
nameserver-policy：分域指定解析器
nameserver-policy（或您版本中對應的政策欄位）適合處理中國大陸與海外網域分流解析這類需求：讓特定 geosite 類別走國內公共 DNS，其餘走海外 DoH。這能減少「海外 DNS 解析國內 CDN 節點不理想」的體感問題，同時維持境外網域走加密解析。實作時請確認與您的 rules、proxy-groups 命名一致，並留意規則優先順序是否會讓某些域名意外落到直連。
若您同時使用大型規則集，建議搭配閱讀 ACL4SSR 與 Loyalsoldier 規則集深度對比，理解規則命中與 Geo 資料更新節奏，避免「DNS 已分域、規則卻仍誤判」的疊加問題。
與 TUN、dns-hijack 一起驗收
在開啟 TUN 模式時，系統內多數程式會把 IP 層流量交給虛擬介面處理；此時若未妥善處理 DNS，仍可能出現繞過核心的查詢。多數教學會提醒將 tun.dns-hijack 指向合理範圍（例如攔截往 53 埠的請求），讓查詢回到 Clash 的 DNS 管線。完整步驟與平台差異請以 Clash Verge Rev TUN 模式完整開啟教程 為準，本文不再重複截圖級操作，只強調DNS 與 TUN 必須同一套邏輯驗收。
YAML 範例方向（請依核心版本微調）
下列片段僅示意思路，實際鍵名與預設值可能隨 Meta 核心版本演進；匯入前請備份原設定，並以客戶端日誌與連線測試交叉驗證。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.google/dns-query
- tls://dns.google
fallback:
- https://dns.cloudflare.com/dns-query
fallback-filter:
geoip: true
geoip-code: CN
nameserver-policy:
"geosite:cn":
- https://dns.alidns.com/dns-query提醒：請勿直接複製網路上的完整設定檔而不理解每一段的用途；尤其 fake-ip-filter、sniffer 與 tun 區塊會互相影響，錯誤組合可能導致區域網路或本機服務無法連線。
如何驗證「真的沒洩漏」？
建議分三層檢查：第一層在客戶端連線／日誌中觀察域名是否依預期走代理或直連；第二層以瀏覽器開啟您信任的 DNS 測試頁（僅作參考），確認可見的解析路徑是否符合預期；第三層針對特定應用程式，分別測試「只開系統代理」與「開 TUN」下的行為差異。若同一網站在兩種模式下結果不同，幾乎可斷定仍有流量或 DNS 未進核心。
測試時請保持單一變因：不要同時更換訂閱、規則集與 DNS 三組參數；先固定兩項、只動一項，較容易回溯。若您需要更完整的文件索引，亦可從 站內說明文件 開始，將 DNS 章節與策略組章節對照閱讀。
常見誤區與排查順序
系統層與核心層「兩套 DNS」打架
Windows、macOS 與部分 Linux 桌面環境都能獨立設定加密 DNS；若與核心內設定並存，可能出現搶答或快取污染。建議先決定誰是唯一權威：以隧道與規則為優先時，通常讓核心主導，並在系統端關閉衝突選項。
規則很多卻「怎麼改都不像生效」
先確認 rules 優先順序與 GEO 資料是否更新；再檢查 DNS 模式是否讓域名資訊在規則評估階段不可得。此時與其繼續堆規則，不如回到本文前段，重畫解析路徑圖。
開源專案與安裝包取得方式
Meta／Mihomo 與周邊圖形客戶端多為開源專案，您可在公開程式庫中查閱授權條款、Issue 與變更紀錄，以評估安全性與相容性。日常取得安裝檔與更新仍建議優先使用 本站 Clash 客戶端下載頁，與「自行從 Release 挑選檔案」分開看待：前者適合一般使用者完成安裝與版本管理，後者較適合開發者或需要核對校驗碼的情境。
結語
DNS 防洩漏的本質，是把解析、路由、規則與應用行為放在同一張圖上檢視，而不是只改一個開關。當 Fake-IP、DoH／DoT、fallback 與 TUN 設定彼此呼應時，Meta 核心能在多數場景下提供清楚可預期的連線路徑；相較於四散的外掛與手動改系統設定，用同一套客戶端維護長期設定，通常更穩定、也更容易在升級後還原。
若您已理解上述管線，下一步便是依自己的網路環境微調上游清單與政策，並用小步實驗驗證；不必一次追求「最嚴格」，而是先追求可解釋、可重現、可回滾。