故障排查 約 9 分鐘閱讀

Clash DNS 洩漏檢測方法與 fake-ip 防洩漏配置實操

代理連通不代表 DNS 沒洩漏。本文提供線上檢測與本機封包擷取兩套驗證手段,逐行講解 enhanced-mode: fake-ip、nameserver 分組與 fallback-filter 的防洩漏寫法。

DNS 洩漏是什麼,為什麼代理通了也可能漏

能打開網頁、能測速、延遲看起來正常,不代表這次連線完全經過了代理。DNS 洩漏指的是網域解析請求繞開了代理隧道,直接發到本機系統設定的 DNS 伺服器(通常是電信商 DNS 或路由器分配的 DNS)。結果就是:網頁資料走了代理,但「你要存取哪個網域」這條資訊暴露給了本地網路的 DNS 伺服器,對外部觀察者而言,存取紀錄仍能被拼出大致輪廓。

這個問題在純規則模式(系統代理 + 應用層分流)下尤其常見。多數客戶端把系統代理設為 HTTP/SOCKS5,但作業系統本身發起的 DNS 查詢(UDP 53 埠)預設不會走這條代理鏈路,而是走網卡本身的 DNS 設定。有些應用程式還會用自己的 DNS 解析邏輯(例如瀏覽器的 DoH),更不受系統代理約束。這就是為什麼「連線正常」和「DNS 乾淨」是兩件要分開驗證的事。

另一種常見誘因是策略組切換。如果代理規則裡的網域分流寫得不完整,某些網域比對到 DIRECT(直連)策略,那這些網域對應的 DNS 查詢大概率也會走本機預設解析路徑,同樣構成洩漏,只是範圍更窄、更隱蔽,平時很難發現。

兩套檢測手段:線上檢測與本機封包擷取

驗證 DNS 是否洩漏,建議線上工具和本機封包擷取搭配使用,前者能快速給出結論,後者能定位到底是哪條查詢漏出去的。

線上檢測:看 DNS 伺服器歸屬

打開任意一個支援 DNS 洩漏檢測的網站,在開啟 Clash 且代理生效的狀態下執行檢測,頁面會列出實際處理你 DNS 查詢的伺服器 IP 與所屬地。正常情況下,這些伺服器應該屬於代理節點所在的機房,或是你在設定裡指定的公共 DNS(如 Cloudflare、Google Public DNS 的 IP 段),而不是你所在地區電信商的 DNS 網段。如果檢測結果裡出現了本地電信商的 DNS,就代表確實有洩漏。

執行這類檢測時要注意兩點:一是切換節點之後等幾秒再測,給策略組和 DNS 快取一點生效時間;二是多測幾次、多換幾個檢測站點交叉驗證,單次結果可能受快取影響出現假陰性。

本機封包擷取:定位具體洩漏的網域

線上檢測只能告訴你「有沒有洩漏」,要知道「哪些網域洩漏」就得靠封包擷取。Windows 上可以用 Wireshark 擷取本機網卡流量,過濾條件寫 udp.port == 53 || tcp.port == 853,分別對應一般 DNS 和 DNS over TLS。正常運作時,幾乎不應該看到發往電信商 DNS 或路由器閘道位址的 53 埠流量;如果看到了,展開該封包查看 Query 欄位,就能知道具體是哪個網域走漏了。

macOS 和 Linux 也可以直接用命令列工具:

sudo tcpdump -i any port 53 -n

執行後正常瀏覽幾個網站,觀察輸出裡的目的位址是不是全部指向你在 Clash 設定裡指定的 DNS(例如 fake-ip 模式下,系統層面看到的應該是內網虛擬 DNS 流量,而不是直連外部 53 埠)。如果抓到大量直連外部 DNS 伺服器的封包,基本上可以確定設定存在漏洞。

注意 檢測前確認系統代理或 TUN 模式確實處於開啟狀態,規則模式下也要確認對應應用程式沒有被單獨排除在代理之外,否則得到的「洩漏」結論可能只是設定未生效,而不是防洩漏機制本身有問題。

enhanced-mode: fake-ip 原理與設定寫法

Clash(及 Meta 核心 mihomo)提供的 DNS 增強解析是解決洩漏問題最直接的手段,核心設定項是 dns.enhanced-mode,常用取值是 fake-ip。它的運作原理是:客戶端接管系統 DNS 請求入口,當應用程式發起網域解析時,不把真實公網 IP 返回給系統,而是從一段私有位址池裡分配一個「假 IP」作為解析結果。應用程式拿到這個假 IP 後正常發起連線,Clash 核心在流量經過代理鏈路時,再依這個假 IP 反查出真實網域,交給對應的策略組和真實伺服器位址處理。

這樣一來,系統和應用層面完全看不到真實的網域解析請求發往了外部 DNS 伺服器,DNS 查詢這一步被完整收進了 Clash 自身的處理鏈路,從根源上避免走漏。一段典型設定如下:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - localhost.ptlogin2.qq.com
    - +.market.xiaomi.com

逐項說明:enable 打開內建 DNS 伺服器;listen 指定內建 DNS 監聽的本機埠,系統或 TUN 網卡會把解析請求轉發到這裡;enhanced-mode 選 fake-ip 即啟用假位址對應;fake-ip-range 指定假位址池的網段,通常用保留位址段避免和真實區域網路衝突;fake-ip-filter 是白名單,列在裡面的網域(常見於區域網路裝置探索、部分銀行 App 的憑證綁定檢測)會回傳真實 IP 而不走假位址,避免功能異常。

需要強調的是,fake-ip 只有在系統實際把 DNS 查詢交給 Clash 內建伺服器時才生效。TUN 模式下網卡層面接管全部流量,DNS 請求自然會被劫持進來,防洩漏效果最徹底;純系統代理模式下則依賴客戶端把系統 DNS 設定指向自身監聽埠,如果這一步沒有正確寫入系統網路設定,fake-ip 設定再對也不會起作用,這也是很多人設定正確但依然測出洩漏的常見原因。

nameserver 分組與 fallback-filter 的防洩漏細節

假位址解決的是「應用端看到什麼」,真正把網域解析成真實 IP 的工作,還是要靠 nameserver 設定項指定的上游 DNS 伺服器完成,這一步同樣有洩漏風險:如果上游 DNS 本身是不可信的電信商伺服器,或查詢過程沒有加密,依然可能被中間網路裝置記錄。建議按境內外分流的思路設定兩組 DNS,並用 fallback-filter 做兜底判斷:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.facebook.com

nameserver 是預設優先使用的解析伺服器,通常填寫中國大陸公共 DNS,保證中國大陸站點解析速度;fallback 是備用伺服器,建議使用支援 DNS over TLS 的位址(如範例中 tls:// 前綴寫法),讓解析請求本身也走加密通道,防止被鏈路中間節點窺探或竄改;fallback-filter 則決定什麼時候啟用 fallback——geoip-code: CN 表示如果 nameserver 解析出的結果落在中國大陸 IP 段內就採信,否則認為結果可能被污染,轉而採用 fallback 裡的加密 DNS 重新解析,domain 清單裡的網域則強制直接走 fallback,不再信任中國大陸解析結果。

這套雙組設定本質上是「就近解析 + 污染兜底」,既保證中國大陸站點不必繞遠路查詢境外 DNS 拖慢速度,又保證需要走代理的網域不會被中國大陸解析結果污染導向錯誤(甚至是被監控的)位址。設定完成後可以用前文提到的封包擷取方法驗證:境外網域對應的解析流量應該走向 fallback 裡設定的加密 DNS,而不是明文的 53 埠。

常見排查清單

  • 檢查客戶端是否真的啟用了增強 DNS,部分客戶端把 DNS 模組預設關閉,需要在設定裡手動打開。
  • TUN 模式下確認虛擬網卡已成功接管路由,系統網路設定裡的 DNS 條目應該指向 Clash 內建監聽位址或已被虛擬網卡覆蓋。
  • 瀏覽器若單獨啟用了 DoH(DNS over HTTPS)硬編碼解析伺服器,可能繞開系統 DNS 設定,需要在瀏覽器設定裡關閉該功能或改用系統 DNS。
  • 路由器或某些安全軟體強制指定 DNS 伺服器時,可能覆蓋 Clash 的 DNS 劫持,需要在系統或路由器層面放行 Clash 監聽埠的轉發。
  • 規則集裡存在遺漏,導致部分網域走了 DIRECT 策略,建議定期檢查分流規則,配合日誌確認命中的策略組是否符合預期。
建議 優先使用 TUN 模式並開啟 fake-ip,再配合雙組 nameserver + fallback-filter,基本上可以涵蓋絕大多數場景下的 DNS 洩漏問題;設定變更後務必重新做一次線上檢測加封包擷取複核。
下載Clash