Clash DNS 洩漏檢測與防護設定：fake-ip、nameserver-policy 實作指南

如何判斷 DNS 洩漏

DNS 洩漏是指網域查詢未依預期路徑解析。例如，瀏覽器透過代理出口建立連線，網域查詢卻仍送到本地網路業者的遞迴解析器。網頁能正常開啟、出口 IP 已變更，都不能單獨證明 DNS 查詢也經過代理。

排查時要分別確認三個環節：應用程式將查詢送給誰、Clash 核心選用哪個上游解析器，以及連往上游的流量走哪條路徑。fake-ip 主要改變核心回傳給應用程式的位址；nameserver-policy 用來選擇解析器；respect-rules 則決定連往解析器的連線是否遵循路由規則。三者處理的是不同問題。

檢測流程：系統查詢、核心查詢與瀏覽器查詢

第一步：記錄目前狀態

先記錄目前的網路、客戶端模式、是否啟用系統代理與 TUN，以及瀏覽器是否開啟安全 DNS。測試期間固定使用同一個代理節點，暫時不要讓自動策略組切換，避免兩次測試使用不同出口。測試時也不要同時啟用公司 VPN 或其他代理客戶端。

• Windows：在 PowerShell 執行 Get-DnsClientServerAddress，記下目前使用的網路介面卡與 DNS 位址。
• macOS：執行 scutil --dns，查看預設解析器及依網域設定的解析器；系統可能同時存在多組 resolver。
• 使用 systemd-resolved 的 Linux：執行 resolvectl status，檢查各網路連線使用的 DNS，不要只查看 /etc/resolv.conf。

網路介面卡顯示路由器位址，不一定代表發生洩漏。啟用 TUN 後，送往該位址的 53 埠查詢可能已由核心接管；反過來說，介面卡顯示公共 DNS 位址，也不代表查詢已加密。還需要確認實際連線狀況。

第二步：直接查詢核心監聽埠

以下範例將核心 DNS 監聽位址設為 127.0.0.1:1053。配置載入成功後，執行以下指令。第一個指令適用於提供 nslookup 的系統；第二個則適用於已安裝 dig 的環境。

nslookup -port=1053 example.com 127.0.0.1
dig @127.0.0.1 -p 1053 example.com A

若查詢未命中 Fake-IP 篩選規則，A 紀錄預期會回傳所設定位址池中的映射位址。這是預期結果的判讀方式，並非本文宣稱已完成實測。若查詢逾時，請先確認 DNS 模組已啟用、配置已載入，以及 1053 埠未被其他程式占用。不要一開始就更動所有分流規則。

接著執行 nslookup example.com，比較系統預設查詢與直接查詢核心的結果。只啟用系統代理時，兩者結果不同很常見，因為命令列解析器通常不會使用 HTTP 系統代理。啟用 TUN 後再測一次，才能判斷系統查詢是否已被接管。

第三步：檢查瀏覽器是否自行解析

在 Chrome 中，可前往「設定」→「隱私權和安全性」→「安全性」→「使用安全 DNS」，檢查 DoH 設定。選單名稱可能因版本略有不同。初次排查時，可暫時關閉此功能，讓瀏覽器使用系統解析；完成基準測試後再重新開啟，並另外確認瀏覽器 DoH 連線的路由。

DNS 洩漏測試網站通常會透過隨機子網域觀察遞迴解析器。請比較啟用代理前後顯示的解析服務商，並搭配核心連線紀錄判斷。解析器所在地不必與代理出口相同；公共 DNS 的 Anycast 節點與遞迴解析出口也可能位於不同地點。只看國家或城市很容易判斷錯誤。

Fake-IP 與 DNS 上游設定範例

以下是可合併至 mihomo 配置的 dns 區段。請保留原有節點、訂閱提供者與策略組；若檔案中已有頂層 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"
    - "*.local"
    - "localhost"
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    "+.qq.com":
      - https://dns.alidns.com/dns-query#DIRECT
    "+.weixin.qq.com":
      - https://dns.alidns.com/dns-query#DIRECT

欄位用途與限制

• listen 僅綁定本機迴路位址。此處的 1053 是範例監聽埠，不會自動將作業系統 DNS 改成使用此埠，也不適合直接提供給區域網路裝置使用。
• enhanced-mode: fake-ip 會為網域指派映射位址，讓後續連線保留網域資訊，以便套用規則。這項功能本身不會加密上游查詢。
• fake-ip-filter 中的網域不會以一般 Fake-IP 映射方式回傳結果。篩選項目不是直連路由規則，不能用來取代 rules。
• ipv6: false 是為了縮小這次 DNS 排查的範圍，不代表停用作業系統的 IPv6，也無法阻止應用程式存取已有的 IPv6 位址。
• proxy-server-nameserver 專門用來解析代理節點的網域，避免解析節點位址時又依賴該節點建立連線。節點解析是需要另外檢視的引導解析路徑。

此處保留明確的引導解析路徑，是為了讓初次載入時更容易找出故障原因。若目前網路無法連線至所選的解析服務，請改用實際可連線的上游，並重新確認路由。DoH 只能保護本機到解析服務之間的 DNS 傳輸內容；若 DoH 直接連線，網路仍會看到目標解析器的位址。

搭配使用 nameserver-policy 與 respect-rules

先選擇解析器，再決定連線出口

nameserver-policy 會依查詢網域選擇上游解析器，不會決定網站連線使用哪個節點。範例將 qq.com 及其子網域交由指定的中國大陸解析器處理，並透過 #DIRECT 明確指定解析器連線使用直連。此處的 weixin.qq.com 項目與前者重疊；保留它是為了示範細分網域的寫法，沒有特殊需求時可以刪除。

其他查詢則交由 cloudflare-dns.com 處理。啟用 respect-rules 後，上游 DNS 連線會遵循路由規則，但「遵循規則」不等於「自動使用代理」：若該網域最後命中 DIRECT，DoH 仍會直接連線。

假設目前配置已有名為「代理」的策略組，且該組目前選用了可用的代理節點，可將以下兩條規則放在範圍較廣的直連規則與最後的 MATCH 之前。配置中的策略組名稱必須與實際名稱一致；若現有策略組名為「節點選擇」，請一併修改引用名稱。

rules:
  - DOMAIN,dns.alidns.com,DIRECT
  - DOMAIN,cloudflare-dns.com,代理
  # 後續保留現有分流規則與最後的 MATCH 規則

此段僅示範應合併的位置，並非完整的 rules 替換內容。不要只為了加入兩條規則，就刪除訂閱中的其他規則。如果代理策略組允許選擇 DIRECT，也要確認目前選取的項目；否則規則名稱看似正確，實際出口仍可能是直連。

避免解析依賴循環

常見的循環依賴是：解析 DoH 服務網域需要代理，但代理伺服器網域又必須透過尚未建立的 DoH 連線解析。通常會出現啟動後大量查詢逾時、節點也無法連線的情況。範例將節點網域交給 proxy-server-nameserver，並讓其上游連線採用直連，藉此拆開這兩條依賴路徑。

• 節點使用網域時，請先確認該網域可透過獨立的解析路徑取得位址。
• 節點使用 IP 時，不需要解析節點主機名稱，但 DoH 服務仍可能需要引導解析。
• 不要強制所有引導解析器都透過尚未可用的代理鏈連線，再期待系統自行恢復。
• 每次只調整一種依賴；儲存後先確認配置載入結果，再查看連線日誌。

使用 TUN 模式接管系統 DNS

系統代理主要影響會遵循系統代理設定的應用程式，不會自動接管作業系統送出的 UDP DNS 查詢。若要讓更多應用程式的一般 DNS 查詢進入核心，可啟用客戶端的 TUN 功能。桌面作業系統通常需要相應權限、服務或虛擬網路介面卡支援；建議優先使用客戶端提供的選項，避免介面設定與檔案配置互相覆蓋。

以下是 mihomo 的 TUN 合併範例。若客戶端已產生 tun 區段，請先查看最終生效的配置，再決定是否修改。

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

any:53 用於接管進入 TUN 的 UDP 53 埠查詢，第二個項目則涵蓋 TCP 53 埠。關鍵限制在於「進入 TUN」：路由排除、其他 VPN、虛擬機器網路與平台限制，都可能讓部分流量繞過這條路徑。對於區域網路 DNS 位址，尤其要透過實際查詢確認接管狀況。

DoH 通常使用 HTTPS 的 443 埠，DoT 通常使用 853 埠；設定 53 埠劫持不會讓它們自動進入核心 DNS 模組。TUN 可依路由接管這些網路連線，但只設定 53 埠無法取代其內部查詢。Android 的「私人 DNS」與瀏覽器的安全 DNS 也應分別檢查。

修改後驗收與故障還原

在相同條件下重新測試

1. 確認配置已成功載入。若出現未知欄位或找不到策略組的提示，請先修正配置，不要繼續測試瀏覽器。
2. 固定使用同一個節點，直接查詢 127.0.0.1:1053，確認 DNS 模組有回應。
3. 啟用 TUN 後查詢系統預設 DNS，同時查看核心 DNS 日誌與連線紀錄。
4. 造訪新的網域，確認 cloudflare-dns.com 的上游連線命中預期的代理組，而不只是檢查網頁連線。
5. 重新執行瀏覽器 DNS 測試，最後還原安全 DNS 等原有設定，再測試一次並記錄差異。

Windows 可執行 ipconfig /flushdns 清除系統 DNS 快取；使用 systemd-resolved 的 Linux 則可執行 resolvectl flush-caches。瀏覽器與核心可能也有各自的快取，必要時請重新啟動瀏覽器並重新載入配置。Fake-IP 映射可能會保留；看到舊位址，不能單獨作為配置未生效的證據。

還原時，先恢復已另存的 DNS 與規則配置，再關閉這次新增的 TUN 設定，最後確認作業系統代理與網路介面卡 DNS 是否仍留有測試值。不要直接刪除整個客戶端資料目錄；這會同時移除訂閱、自訂規則與日誌，反而減少排查時可用的資訊。

常見問題

啟用 Fake-IP 後，為什麼測試頁仍顯示網路業者的 DNS？

可能是瀏覽器使用了獨立解析器，也可能是核心上游仍依直連規則送出查詢。Fake-IP 只能證明某次解析使用了位址映射機制，無法證明所有 DNS 流量都經過代理。請分別檢查瀏覽器設定、上游連線與引導解析。

把 nameserver 全部改成 DoH 就夠了嗎？

不夠。DoH 解決的是查詢傳輸加密，代理出口則由路由決定；系統或應用程式也可能完全繞過核心。還需要同時確認查詢是否被接管、上游解析器選擇、路由規則與節點解析依賴。

保留中國大陸網域的直連解析，一定算 DNS 洩漏嗎？

應依事先訂定的目標判斷。若策略明確允許這些網域透過指定的直連解析器查詢，這就是刻意分流；若目標是讓所有查詢都經過代理，這種配置便不符合目標。先明確列出允許的例外，再以日誌確認，比追求測試頁只顯示一個位址更可靠。

訂閱更新後設定消失，該修改哪裡？

不要長期直接編輯會被遠端訂閱覆蓋的原始檔案。請使用客戶端支援的本機覆寫、合併配置或指令碼機制，實際操作入口會因客戶端版本而異。更新訂閱後，請檢查最終生效的 DNS、TUN 與規則順序，而不只是確認覆寫檔案已儲存。