DNS 設定 預計閱讀 12 分鐘

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

了解 DNS 洩漏成因與線上檢測方式，並提供 enhanced-mode、fallback 過濾、nameserver-policy 及 TUN DNS 劫持設定範例。

DNS 路徑與洩漏判定：解析路徑和連線出口

Clash 能開啟網頁，不代表所有 DNS 請求都走預期路徑。瀏覽器可能透過 HTTP 代理傳送連線，也可能預先呼叫系統解析器；背景應用可能不理會系統代理；瀏覽器的安全 DNS 也可能自行建立 HTTPS 解析連線。排查時必須分別記錄兩件事：網域交由哪個服務解析，以及解析請求透過哪條線路送出。

本文所稱的「DNS 洩漏」是指：原本應走指定解析路徑的網域查詢，實際上卻交由本地網路、電信業者或其他非預期的解析服務處理。若刻意為中國大陸直連服務指定本地解析器，不應只因檢測頁顯示中國大陸 IP 就判定為洩漏。判斷依據應是事先設定的分流目標，而非結果中是否出現某個國家或地區名稱。

觀察結果實際意義下一步確認事項
網站出口已變更目前網頁連線使用代理請另外檢查 DNS，不能據此推斷解析出口
偵測到電信業者的解析器測試網域最終由該遞迴解析服務查詢檢查系統 DNS、瀏覽器安全 DNS 與分流策略
偵測到多個解析器可能有並行查詢、轉送或多個出口比對 nameserver、fallback 與測試條件
查詢結果為 198.18 網段的 IP可能已命中 Fake-IP 對應繼續確認流量是否回到同一個核心

檢測前準備：固定用戶端、瀏覽器與網路條件

以下設定以 mihomo 核心為例。Clash Meta 是其舊稱；舊版 Clash 原版與已停止更新的用戶端不一定支援所有欄位。請先到用戶端的「關於」或核心資訊頁記錄核心名稱與版本，再匯出目前設定。用戶端版本與核心版本應分開記錄，不能只寫「Clash 最新版」。

  1. 保留復原方式。匯出訂閱設定與本機覆寫內容，並記下系統代理、TUN、瀏覽器安全 DNS 原本的開關狀態。
  2. 固定測試條件。使用相同網路、節點與瀏覽器進行比較；測試期間暫停其他 VPN 和代理工具。
  3. 先排除瀏覽器自行解析。Chrome 可在「設定」→「隱私權和安全性」→「安全性」中尋找「使用安全 DNS」；Firefox 可在「設定」→「隱私權與安全性」中尋找「透過 HTTPS 的 DNS」。選單名稱可能因版本而異。
  4. 確認設定套用位置。訂閱原始檔可能在更新時遭到取代。請透過用戶端提供的本機覆寫或合併功能保存修改，並檢查最終執行中的設定。

線上 DNS 洩漏檢測：比較測試結果，不只看地理位置

可開啟 DNSLeakTest，先執行 Standard test，再執行 Extended test。檢測網站會透過隨機子網域，觀察遞迴解析器向權威伺服器查詢的情況，因此結果通常反映解析服務的出口，不一定是系統設定中填入的伺服器位址，也不是代理節點位址。

如何記錄三組測試結果

  1. 基準：關閉用戶端代理接管後檢測一次，記錄解析器 IP、服務營運者與目前使用的網路。
  2. 系統代理：啟用用戶端的系統代理，保持 TUN 關閉，再檢測一次。若結果沒有變化，只能表示這條測試路徑可能仍使用原本的解析路徑。
  3. TUN 接管：啟用下方的 DNS 與 TUN 設定後再次檢測，記錄相同欄位，並在用戶端的連線面板確認解析連線。

建議每組測試執行兩次。結果不一致時，先檢查快取、瀏覽器安全 DNS 與多個上游同時查詢的情況，不要立刻更換節點。公用解析服務可能採用任播與分散式出口；檢測頁標示的國家或城市也可能不準確。應優先確認服務營運者是否符合預期，以及停用某條解析路徑後結果是否跟著改變。

線上檢測只涵蓋瀏覽器觸發的測試查詢，無法證明系統中的每個應用程式都已被接管。還需要執行本機查詢，必要時觀察實體網卡流量。請勿將包含訂閱連結、造訪網域或存取權杖的完整記錄直接上傳至公開討論區。

fake-ip 基本設定：讓網域與連線正確對應

Fake-IP 模式會先回傳虛擬位址給應用程式，再由核心根據對應資料還原網域並比對規則。這能減少部分連線建立前對真實 DNS 解析的依賴，但它不是加密協定，也不會自動攔截所有 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"
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.qq.com":
      - https://dns.alidns.com/dns-query

此範例暫時關閉 DNS 的 AAAA 回應，以減少初步排查時的變數；這不等於關閉作業系統的 IPv6，也不會阻止應用程式使用快取中的 IPv6 位址。需要 IPv6 的環境應恢復相關功能，並確認 IPv6 路由、DNS 與代理接管都正常，不能長期依靠單一開關掩蓋路徑問題。

fallback 過濾：選擇回應結果，不是阻止查詢送出

fallback 常被誤解為「主解析器逾時後才查詢備用伺服器」。在常見設定中，主上游與 fallback 可能會同時查詢，再由過濾條件決定採用哪組回應。因此，同一個網域可能被多組服務查詢，不能用它來證明「只允許單一解析服務」。

以下是優先選用中國大陸位址的獨立設定範例。若採用此方案，應將這些欄位合併至同一個 dns: 底下；此方案用途與前述單一上游設定不同，建議先驗證基本方案，再決定是否加入 fallback。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

此範例會依據 GeoIP 條件判斷主要解析結果；不符合 CN 條件或命中列出的位址範圍時，便會改採 fallback 結果。實際行為取決於地理資料與核心實作，不能將 IP 地理分類視為網域可信度判斷。跨國 CDN、企業服務與資料更新延遲，都可能讓選擇結果不如預期。

如果需求只是「幾個明確指定的網域使用特定解析器」，優先採用 nameserver-policy，比擴大 fallback 條件更容易驗證。對已套用專用解析策略的網域，也不要假設它仍會按照預設主上游與 fallback 的組合處理；請查閱目前版本文件並檢視實際查詢記錄。

TUN DNS 劫持：接管系統代理無法涵蓋的查詢

系統代理主要供遵循代理設定的應用程式使用，不等於接管系統 DNS。TUN 會透過虛擬網卡接收流量，再將符合條件的 DNS 請求交給核心解析模組。以下片段可與前面的 DNS 基本設定合併，但能否建立虛擬網卡仍取決於系統權限、用戶端服務與平台支援。

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

any:53 用來比對進入 TUN 的 UDP 53 請求，第二項則補上 TCP 53。這些不是系統防火牆規則：只有實際進入核心接管路徑的流量才有機會被處理。多張網卡、虛擬機器、容器、其他 VPN 與特定系統路由，都可能改變這項前提。

53 連接埠以外的路徑

啟用後若整台裝置無法上網，先關閉 TUN 恢復網路，再檢查管理員權限或服務模式、預設出口網卡與路由衝突。不要同時啟用多個用戶端的 TUN，也不要為了解決連接埠衝突，就直接將 DNS 服務公開監聽於 0.0.0.0；調整監聽位址也涉及區域網路存取控管。

本機驗證與檢查：確認設定生效、流量接管及訂閱更新

先確認 1053 連接埠有監聽，並測試 Fake-IP 回應

在已安裝 dig 的系統上執行以下指令。明確指定連接埠即可直接測試核心 DNS，不必依賴作業系統是否已切換解析器。若未安裝此工具，可使用用戶端的 DNS 診斷功能；一般 nslookup 預設會連線至 53 連接埠。

dig @127.0.0.1 -p 1053 www.wikipedia.org A
dig @127.0.0.1 -p 1053 www.qq.com A
dig @1.1.1.1 www.wikipedia.org A

前兩條指令會直接檢查核心 DNS。在此 Fake-IP 設定範例中，未被過濾的 A 查詢通常會回傳 198.18.0.0/16 範圍內的對應位址；這無法證明實際使用了哪個真實上游。若 TUN 已啟用且 53 劫持生效，第三條指令也可能被核心攔截。此時即使工具顯示伺服器為 1.1.1.1，也不能據此認定請求確實送達該位址。

接著檢查實體網卡與實際連線

需要進一步確認時，可在 Wireshark 中選取實際連線的網卡，並使用 udp.port == 53 || tcp.port == 53 || tcp.port == 853 篩選。觀察測試期間是否有非預期的明文查詢離開實體網卡。此篩選條件不涵蓋 DoH，而且單憑「未看到 53 流量」無法證明所有查詢都經過代理；加密上游的連線出口仍需搭配用戶端記錄與連線面板確認。

  1. 清除舊快取。Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。接著重新啟動測試用瀏覽器，避免舊連線造成干擾。
  2. 重新執行線上測試。保持節點與瀏覽器設定不變，比較解析服務營運者及其與基準結果的差異。
  3. 重新測試實際使用情境。檢查中國大陸網站、海外網站、企業內網與區域網路裝置，確認專用 DNS 策略沒有影響內部網域解析。
  4. 確認設定能持續生效。更新一次訂閱並重新啟動用戶端，確認執行中的設定仍包含 dns、tun 與策略欄位。
下載Clash平台與用戶端選擇