Clash DNS 洩漏檢測與防漏設定：Fake-IP、nameserver 設定

判斷 DNS 洩漏：先釐清預期的解析路徑

Clash DNS 洩漏通常是指網域查詢未經過預期的解析路徑。例如，連線已經透過代理，但系統仍將查詢送到路由器或電信業者的 DNS。網頁可能正常開啟，對外 IP 也可能是代理節點的 IP，但網域查詢卻走了另一條路。因此，「網頁能開」和「DNS 已依設定處理」必須分開驗證。

先釐清目標：是要讓所有傳統 DNS 查詢都進入本機核心，還是要求上游解析也透過代理出口？前者著重於流量接管，後者還牽涉 DNS 上游連線的路由策略。使用 DoH 或 DoT 只能表示查詢連線已加密，不能單憑此點證明查詢是從代理節點送出。

用戶端：管理設定、系統代理、服務權限與介面開關。
核心：執行 DNS 解析、Fake-IP 對應、規則比對與連線轉送。
訂閱：提供節點、規則或完整設定；更新時可能覆蓋本機變更。
應用程式：可能使用系統解析器，也可能內建 DoH，繞過系統 DNS 設定。

檢測步驟：分別檢查出口、解析器與本機流量

第一步：建立關閉代理時的基準資料

在允許直接連網的測試環境中，關閉系統代理與 TUN，記錄對外 IP、系統 DNS 位址，以及 DNS 檢測網站列出的解析器資訊。企業網路或受管理裝置不宜擅自停用既定網路政策。基準資料僅供比對，不應直接把檢測網站顯示的國家或城市視為洩漏證據。

Windows 可用 PowerShell 查看各張網路介面卡的 DNS。無線網路、乙太網路、VPN 與虛擬網路介面卡可能同時存在，不能只看目前介面上的第一筆資料。

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
ipconfig /all

第二步：啟用設定後，重複相同的測試

啟用預計使用的系統代理或 TUN，並確認目前套用的設定與所選策略組。
重新檢查對外 IP，並記錄瀏覽器是否啟用了「安全 DNS」。
執行 DNS 檢測，記錄解析器 IP、所屬資訊與測試時間，不要只保存「通過」提示。
在用戶端的連線紀錄或除錯日誌中查找上游 DNS 連線，核對目標位址與實際採用的出站策略。
改用一個尚未快取的網域重新查詢，避免將快取命中誤判為 DNS 未運作。

公共 DNS 可能採用 Anycast 與分散式出口。檢測網站顯示的解析器位置不一定等於連線入口位置，也不必與代理節點所在城市完全一致。若設定原本就要求部分網域使用本地解析器，出現本地解析結果也可能符合預期；關鍵在於結果是否與網域策略及出站紀錄相符。

第三步：透過明確的本機連接埠驗證核心

假設核心監聽 127.0.0.1:1053，可使用支援指定連接埠的 dig 測試解析服務。這裡的 1053 是本文範例連接埠，並非所有用戶端的預設值；若系統未安裝 dig，不必為了測試而勉強更換工具。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

直接查詢本機監聽連接埠成功，只能證明核心 DNS 能回應。還需要測試應用程式的實際請求，才能確認系統 DNS、TUN 劫持與瀏覽器解析行為都符合預期。Windows 的 nslookup 預設使用 53 連接埠，不能因為預設連接埠查詢失敗，就直接認定監聽在 1053 的服務有問題。

Fake-IP：保留網域對應，不等於加密 DNS

enhanced-mode: fake-ip 會讓核心對適用的網域回傳虛擬位址，並維護網域與虛擬位址之間的對應。應用程式接著連線到該位址時，核心可還原網域，進行規則比對或將網域傳給代理出站。實際位址可能要到後續連線階段才需要解析，也可能由遠端代理服務處理，視通訊協定與出站實作而定。

常見的 Fake-IP 位址池為 198.18.0.1/16。此範圍用於虛擬對應，並非節點的公網出口位址。查詢結果落在此範圍通常表示模式運作正常，不應將其填入遠端伺服器位址，或手動加入系統公網 DNS 清單。

設定	直接作用	無法單獨保證
`fake-ip`	回傳虛擬位址並保存網域對應	上游查詢已加密或經由代理出站
`redir-host`	向應用程式回傳實際解析位址	應用程式的 DNS 查詢一定進入核心
`fake-ip-filter`	讓符合條件的網域依過濾規則處理，常用於回傳實際位址	取代代理分流規則

區域網路探索、部分裝置管理頁面或依賴實際位址的應用程式可能需要例外。請先限定具體網域，再考慮擴大範圍。將大量公共網域加入 Fake-IP 過濾清單會改變解析行為，也會讓問題更難判斷。過濾清單控制 DNS 回傳方式，rules 控制連線的出站，兩者不能互相取代。

nameserver 設定：區分一般解析與啟動解析

以下是用來說明欄位的 mihomo DNS 設定範例，並非完整訂閱。請保留現有節點、策略組與規則，將對應欄位合併至實際生效的設定；同一個 YAML 層級只能保留一個 dns 鍵。若用戶端採用覆寫或合併設定，請檢查合併後的結果，而不只是編輯器中的文字。

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"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

listen：綁定迴路位址，避免解析服務直接暴露在區域網路中。若確實需要讓其他裝置使用，還須另外設定存取範圍。
default-nameserver：主要用來解析 DNS 上游本身的網域，解決啟動階段「必須先知道解析器位址」的問題。
nameserver：一般網域解析的上游清單；實際處理方式也會受網域策略等欄位影響。
proxy-server-nameserver：用來解析代理節點網域，避免節點解析依賴尚未建立的代理連線。
ipv6: false：限制此 DNS 模組的 IPv6 解析回應，不代表關閉作業系統的 IPv6，也不代表阻擋所有 IPv6 連線。

不要為了讓 DoH 連線成功而關閉憑證驗證。請優先檢查系統時間、上游位址、網路連線狀況與引導解析。若要求 DNS 上游也遵循分流規則，mihomo 可使用 respect-rules 等設定，但必須同時處理節點網域解析及 DNS 上游的出站依賴。只加入 respect-rules: true 而未核對規則，可能造成解析迴圈，或仍套用直連策略。

fallback 與網域策略：備用解析器不一定等到失敗才啟用

fallback 常被誤以為是「第一個 DNS 逾時後才查詢備用 DNS」。在常見的 fallback 解析流程中，核心可能同時向主要解析器與 fallback 發出查詢，再依據 fallback-filter 選擇結果。因此，將某個公共解析器加入 fallback，不代表它平時不會收到查詢。

fallback-filter 可依地理資訊、位址範圍或網域等條件影響結果選擇。地理資料庫可能已過時，CDN 也可能回傳跨區域位址；不能把某個地區代碼當成通用的污染判斷標準。排查時先使用一組可驗證的上游，再依需求加入 fallback，通常比同時堆疊多個解析器更容易找出問題。

指定網域上游：nameserver-policy

區域網路網域通常需要內網 DNS。以下範例將 +.home.arpa 交由 192.168.1.1 解析；只有該位址確實是目前網路的內網解析器時才適用。這是明確保留的本機查詢路徑，不應再以「所有查詢都從代理節點送出」作為驗收標準。

dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

這段只是欄位片段，應合併至前一段既有的 dns 對應設定中，不可直接在檔案末尾重複附加。需要取得實際內網位址的網域，也要檢查 Fake-IP 過濾策略。網域透過內網解析，不會自動讓業務連線走內網；連線規則仍須允許相應的區域網路存取。

TUN DNS 劫持：接管 53 連接埠不代表接管所有解析

系統代理主要影響遵循代理設定的應用程式，不會統一接管系統 DNS。TUN 透過虛擬網路介面卡與路由接管流量，搭配 dns-hijack 才能將符合條件的傳統 DNS 請求送入核心。以下片段需要用戶端服務權限及相應平台支援，並應與既有 TUN 設定合併。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 用於比對 UDP 53 查詢，tcp://any:53 則補上 TCP 53。實際接管效果仍會受到作業系統路由、TUN 堆疊、排除網段與其他 VPN 影響；尤其是指向區域網路 DNS 的請求，應透過實際封包擷取確認是否進入 TUN。切換網路介面卡後也要重新測試，不能只驗證啟動時使用的單一網路。

需要分開處理的三類流量

瀏覽器 DoH：通常會呈現為 HTTPS 443 連線，不會被 53 連接埠的劫持規則自動改寫。排查時可暫時關閉瀏覽器的安全 DNS，或將其納入明確的加密解析方案。
DoT 與其他加密解析：DoT 通常使用 TCP 853；應用程式內建的加密 DNS，則須依實際通訊協定與出站連線檢查。
IPv6 與多張網路介面卡：IPv4 已接管不代表 IPv6 也已接管。請檢查 IPv6 路由、DNS 位址及用戶端支援情況，不要只依賴 dns.ipv6 開關。

擷取封包時，可使用 udp.port == 53 || tcp.port == 53 作為 Wireshark 顯示篩選器。若實體網路介面卡持續出現送往非預期解析器的明文 DNS，值得進一步追查；迴路或虛擬網路介面卡上出現接管前的查詢，不一定表示已經外洩。篩選器看不到 DoH 的實際查詢內容，也無法證明其他連接埠沒有解析流量。

排查順序與設定驗收

現象	優先檢查項目	驗證方式
本機 1053 連接埠沒有回應	DNS 開關、連接埠衝突、設定載入錯誤	檢查核心啟動日誌與連接埠監聽狀態
本機查詢正常，瀏覽器結果不同	瀏覽器安全 DNS、快取、擴充功能代理	統一解析設定後，使用新網域重新測試
啟用 TUN 後所有網域都逾時	權限、上游連線狀況、解析迴圈	先驗證節點網域與上游啟動解析
公網正常，內網名稱解析失敗	網域上游策略、Fake-IP 過濾、區域網路規則	分別查詢內網 DNS 與核心 DNS
訂閱更新後問題再次出現	覆寫順序與生效設定	比較更新前後的 DNS、TUN 欄位

變更解析模式或上游後，應清除相應快取再重新測試。Windows 可執行 ipconfig /flushdns 清除系統快取；瀏覽器與核心可能也保有各自的快取，須透過各自的清除功能或重新啟動處理。既有連線不一定會重新解析，測試時應建立新連線，避免只重新整理一個長時間維持連線的頁面。

設定有效：核心已成功載入，DNS 監聽位址與連接埠和測試命令一致。
接管有效：實際應用程式的傳統 DNS 依預期進入核心，且例外路徑都有明確用途。
上游有效：能說明業務解析、啟動解析與節點網域解析各自使用哪個上游。
出站有效：需要透過代理的 DNS 上游連線，實際套用了正確策略，而不是只根據 DoH 位址推斷。
重新啟動後仍有效：重新啟動用戶端、更新訂閱及切換網路後再次檢測，確認設定仍然保留。

DNS 防洩漏並非只靠一個開關，而是由應用程式的解析方式、系統路由、核心設定與上游出站共同決定。Fake-IP 處理網域對應，nameserver 決定解析服務，TUN 劫持負責接管符合條件的請求。分別驗證這三者，才能找出異常所在層級。更多概念請參閱Fake-IP 協定參考；設定匯入與覆寫方式請見使用說明。