為什麼「代理開了」仍要單獨談 DNS？

許多使用者看到瀏覽器顯示的出口 IP 已變，就以為「全程都走代理」。實務上，網域解析（DNS）與實際 TCP／UDP 連線可以是兩條路：若應用程式或系統仍把查詢送到電信商、路由器或你不信任的伺服器，測速頁面可能顯示 DNS 位於本地或第三地，體感則像「網站偶爾解析到錯誤 CDN」「規則明明寫了 DOMAIN，卻因為先拿到另一組 IP 而匹配錯規則」。這也是為什麼在 TUN、規則分流之外，仍值得用一篇專文把 Clash Fake-IP 與 DNS 設定講清楚。

本文假設你已能正常匯入訂閱並啟用用戶端；若尚未完成基礎步驟，可先參考站內的訂閱匯入教學，或先瀏覽說明文件總覽整理名詞，再回來調整 DNS。接下來我們先區分兩種常見的增強解析模式，再談設定檔裡各欄位怎麼協同運作。

Fake-IP 與 redir-host：先選對 enhanced-mode

在 Clash Meta／Mihomo 系設定中，dns.enhanced-mode 常見有 fake-ip 與 redir-host（名稱依核心版本可能略有差異，請以你使用的核心文件為準）。兩者都想解決同一件事：讓「網域規則」與「實際連線」盡量對齊，但手段不同。

fake-ip 模式的核心直覺是：對大多數查詢先回一個私有範圍內的「假 IP」（常見為 198.18.0.0/16 類似區段），讓後續連線先進入 Clash，再由核心在內部完成真實解析與策略選擇。好處是規則匹配較一致、較容易做到「網域級」分流；要注意的是，少數依賴本機 DNS 結果的應用程式、或需要真實 IP 的場景，可能要搭配 fake-ip-filter（或同等機制）把特定網域排除在假位址之外。

redir-host 模式則較接近「照常向 DNS 要真實 IP」，再由 Clash 依規則處理連線。相對直覺，但在某些網路環境下，若上游 DNS 回傳結果與你預期的路由不一致，仍可能出現「規則看起來對、連線卻像走另一條路」的感受。兩種模式沒有絕對優劣，重點是你是否理解其取捨，並願意在改動後用下一節的步驟驗證。

ℹ️
用語提醒：本文的「DNS 外洩」採寬鬆的工程語意：泛指「解析路徑未依你預期經過 Clash 或指定上游」，包含測速站顯示的 DNS 供應商、或本機／路由器仍對外發出可追蹤的查詢。實際威脅模型因人而異，請依你的環境解讀測試結果。

dns 區塊：nameserver、fallback 與 proxy-server

多數設定檔會把 DNS 相關內容放在 dns: 底下。你可以用「分工」來記：nameserver 通常是第一線、用於一般查詢的清單；當你啟用諸如「fallback 觸發條件」這類機制時，fallback 會在判定需要時接手，改用另一組你較信任的伺服器，以降低被劫持或污染時拿到錯誤結果的機率。不同核心版本的鍵名與預設行為可能略有出入，請以版本文件為準，但概念上大致如此。

proxy-server／「透過代理查 DNS」類選項則處理另一件事：當查詢必須經過節點才能連到遠端 DoH／DoT 時，避免「為了查 DNS 反而先直連失敗」。若你發現只有在開啟 TUN 或特定策略後，DoH 才穩定，就要把這條路徑一併納入排查。相對地，過度依賴遠端 DNS 也可能增加延遲，因此常會看到使用者為「國內網域」與「海外網域」分別指定不同上游，或在 nameserver-policy（或同等欄位）裡依網域後綴分流。

下面是一段示意用的 YAML 結構，僅協助對齊欄位位置；實際鍵名、是否支援 DoT／DoH、以及預設值請務必對照你的核心版本與訂閱模板，切勿未理解就整段覆蓋。

dns:
  enable: true
  # enhanced-mode: fake-ip | redir-host — check your core docs
  enhanced-mode: fake-ip
  # fake-ip-range: optional private range used for synthetic answers
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - tls://1.1.1.1
  fallback:
    - tls://8.8.8.8
  # nameserver-policy: per-suffix or geosite overrides (if supported)
  # proxy-server: send DNS via proxy when needed (name varies by core)

若你同時使用規則分流，請記得 DNS 決策與 rules 的優先順序是一整套系統：可延伸閱讀規則分流教學，避免只改 DNS、卻被某條寬鬆規則提早匹配。

常見「以為沒洩漏」其實有落差的場景

第一種情況是系統 DNS 與 Clash DNS 各走各的：例如 Windows 仍指向路由器，瀏覽器卻透過擴充功能或內建安全 DNS 繞過系統設定；或 Android 啟用「私人 DNS」與 VPN 類服務並存時，實際生效順序不如預期。第二種是只開系統代理、未開 TUN：部分程式不讀系統代理，解析與連線可能分離；此時可參考TUN 模式詳解評估是否要把更多流量納入同一決策點。

第三種是IPv6：若 IPv6 仍走原 ISP 出口，而你的規則主要掛在 IPv4 思維上，測試工具可能呈現「DNS 或連線來自不同網路」。排查時可暫時在系統層關閉 IPv6 做對照（僅作測試手段），確認後再決定長期策略。第四種則是快取：作業系統、瀏覽器與 Clash 本身都可能快取舊結果；改設定後若沒有等待快取過期或重啟相關元件，容易以為設定沒生效。

實測步驟（建議照順序做）

以下流程目標是「可重現」：你照做一次，就能得到一組可比對的觀察，而不是只看單一數值。

步驟一：確認 Clash 已啟用內建 DNS 並載入預期設定

在用戶端中打開設定檔或圖形介面中的 DNS 相關區塊，確認 dns.enable 為真、enhanced-mode 與你理解的一致，且沒有被另一份本機覆寫檔意外改掉。若你使用訂閱合併，注意合併順序是否讓某段 dns: 被後面的空值蓋掉。

步驟二：用瀏覽器測 DNS／洩漏（至少兩個來源交叉）

選擇你信任的線上測試頁（例如常見的 DNS leak 或瀏覽器安全測試頁），在只開 Clash、其餘 VPN 關閉的前提下跑兩次：一次使用預設瀏覽器設定，一次在無痕視窗並暫停可能改 DNS 的擴充功能。比對「列出的 DNS 伺服器是否落在你的預期（例如代管商、DoH 供應商）」以及「是否出現本地 ISP 名稱」。若出現後者，回到系統 DNS 與 TUN／系統代理設定交叉檢查。

步驟三：用終端機對照「解析結果」與「連線出口」

在桌面系統可挑一個測試用網域，分別觀察解析與實際連線 traceroute／curl 的 IP；重點不是背指令，而是建立「我改的 DNS／fake-ip 設定，是否真的改變了應用程式看到的解析路徑」。若終端機顯示的行為與瀏覽器不同，通常代表仍有程式繞過 Clash。

步驟四：改動後等待與還原

每次只改一個變因：例如先只動 fallback，或先只切換 fake-ip／redir-host，觀察差異後再疊加下一項。完成測試後，把不需要的實驗性路由或過度寬鬆的規則還原，避免長期留下難以除錯的狀態。

⚠️
風險提示：請勿盲目套用網路上「防洩漏大全」而關閉必要回退機制，否則可能換成「整台無法解析網域」。遇到異常時，優先關閉 TUN、暫停自訂 DNS，回到可用狀態再逐步啟用。

與 TUN、系統代理搭配時的檢查清單

若你已依TUN 教學開啟虛擬網卡，請額外確認：系統預設 DNS 是否被導向 Clash 監聽的位址、以及路由是否可能把 DNS 查詢送到非預期介面。若你維持「僅系統代理」，則要把測試重心放在「會讀系統代理的程式」與「不讀代理的程式」是否呈現不同 DNS 行為，並決定要不要升級到 TUN 或為特定程式單獨設定環境變數。

無論哪一種模式，都建議保留一鍵還原：知道如何關閉用戶端、如何清除錯誤的路由或 DNS 覆寫，比在論壇來回發問更快回到可用狀態。

結語：把「設定檔看得懂」變成「測得出來」

Fake-IP 與 DNS 設定不是口號，而是一組可驗證的行為：你選擇 enhanced-mode、指定 nameserver／fallback，最後都要能在瀏覽器與系統層得到一致的解釋。相較於抄一段不明來源的 YAML，更重要的是建立屬於自己的測試順序，並在每次升級核心或用戶端後重跑一次關鍵檢查。

若你希望長期維護成本更低，建議挑選介面清楚、能呈現目前 DNS 工作狀態與設定檔差異的 Clash Meta 用戶端，並固定從可信來源取得安裝包。→ 立即免費下載 Clash，開啟流暢上網新體驗