Clash DNS 洩漏怎麼檢測:fake-ip 模式與防洩漏配置實操

▶DNS 洩漏是什麼,為什麼會發生

代理軟體的核心工作分成兩部分:先把域名解析成 IP,再把連接這個 IP 的流量送進隧道。規則分流(比如按域名比對台灣本地直連、境外走代理)依賴的前提是 Clash 自己完成解析並按結果路由。如果 DNS 查詢沒有經過 Clash,而是直接從系統網卡發往本地電信商 DNS 或某個未經代理的解析器,監聽方就能拿到完整的域名訪問記錄——這就是 DNS 洩漏。它不影響網頁能不能打開,所以很容易被忽略,但對隱私和分流準確性都是硬傷。

常見的洩漏成因並不神秘,基本集中在下面幾類:

• 瀏覽器開啟了內建的安全 DNS(DoH),繞開系統解析器直連指定的加密 DNS 服務商,完全脫離 Clash 的接管範圍。
• 虛擬機器、容器或某些沙盒環境使用獨立的網路堆疊和 resolv.conf,不走主機的代理配置。
• TUN 模式開啟但 DNS 劫持沒配置到位,53 埠的 UDP 請求繞過虛擬網卡直接出網。
• 系統同時保留了 IPv6 網路出口,而 Clash 的 dns 段只處理了 IPv4 查詢,IPv6 解析走了原生通道。
• 規則集裡給某些域名打了 no-resolve,本意是跳過解析只比對 IP 段,但配置順序不對導致該域名的解析請求提前從系統發出。

▶檢測 DNS 洩漏的可複現步驟

檢測不需要額外軟體,分成四步,任何平台都能照做:

1. 先記錄一次「乾淨」結果。 完全關閉代理和 VPN,用命令列工具解析一個域名,記下返回的解析伺服器地址,這是你的電信商原生 DNS 出口。
2. 開啟 Clash 後重複同一次查詢。 命令列下用 nslookup 或 dig 解析同一個域名,如果第二次返回的解析伺服器地址和第一步完全一致,說明這次查詢壓根沒經過 Clash,直接走了系統原生路徑。
3. 用抓包工具確認埠去向。 用 tcpdump 或 Wireshark 抓 53 埠(以及 853 埠,DoT 走這個口)的流量,觀察這些封包是從哪個網卡發出去的。走 TUN 網卡或本地環回口(Clash 監聽地址)才算安全,走實體網卡直連外部 DNS IP 就是洩漏。
4. 查看 Clash 自身的 DNS 日誌。 把日誌級別調到 debug 或直接看控制面板的連接記錄,確認目標域名的解析請求確實出現在 Clash 的日誌裡。沒出現,就說明這條查詢沒被接管。

瀏覽器層面還有一個更直觀的驗證方法:打開一個支援多節點檢測的線上 DNS 洩漏測試頁面,對比開啟代理前後返回的解析節點歸屬地。如果開啟代理後歸屬地仍顯示為你的本地電信商所在城市,基本可以確認存在洩漏。

▶fake-ip 與 redir-host:兩種增強模式的本質差別

Clash 的 dns 段裡,enhanced-mode 決定了域名解析結果如何配合規則路由,這是防洩漏配置裡最關鍵的一個欄位。

fake-ip 模式

Clash 收到應用程式的域名解析請求後,不去做真實的公網查詢,而是從一個預留的虛擬位址池(通常是 198.18.0.0/16 這類不會在真實網路裡出現的段)裡分配一個「假 IP」返回給應用。應用拿著這個假 IP 發起連接時,Clash 在建立隧道的瞬間才根據假 IP 反查出對應域名,再按規則決定走直連還是走代理節點,並且這時才做真實解析。整個過程裡,系統層面能觀察到的解析結果永遠是虛擬位址,不會暴露真實的目標域名對應的公網 IP,也不需要依賴系統 DNS 出口,天然貼合 TUN 模式的透明代理場景。

redir-host 模式

Clash 直接向上游 DNS 伺服器發起真實解析,拿到真實 IP 後返回給應用,同時把這次查詢記錄下來,後續這個 IP 對應的連接按規則表轉發。這種模式的問題在於兩點:一是真實解析結果一旦被應用快取或被系統層面的其他行程截獲,理論上仍有資訊暴露的可能;二是遇到大量使用 CDN、一個域名對應多個動態 IP 的網站時,規則按 IP 段比對容易判斷錯誤,分流不準。redir-host 更適合舊版本用戶端或者不支援虛擬網卡的部署場景,新配置一般不建議作為首選。

結論很直接:能用 TUN 模式的場景,統一選 fake-ip,防洩漏和分流準確性都更有保障;只有明確需要相容舊規則集或者除錯解析結果時,才臨時切到 redir-host。

▶dns 段配置逐項調整,把洩漏路徑堵上

確認了模式選擇之後,下面這份 dns 段是一份可以直接對照檢查的清單,每一項都對應一個具體的洩漏風險點:

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"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - tls://dns.rubyfish.cn:853
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  ipv6: false

• enable / listen——先確認 DNS 服務確實被開啟並監聽在指定埠,如果用戶端圖形介面裡沒手動打開這一開關,配置檔案寫了也不會生效。
• enhanced-mode: fake-ip——按上一節的結論固定選擇,配合 fake-ip-range 使用一個不會與真實公網位址衝突的私有段。
• fake-ip-filter——區域網路裝置、內網服務這類域名要排除在假 IP 分配之外,否則區域網路內直連會失敗,這裡的排除不會造成洩漏,因為本身就是內網訪問。
• default-nameserver——專門用來解析下面 nameserver 和 fallback 裡那些 DoH/DoT 域名本身,必須填寫裸 IP,否則會出現「解析加密 DNS 域名卻又需要 DNS」的死鎖。
• nameserver——上游解析用加密協議(DoH 或 DoT),避免這一跳本身在網路中間被明文記錄,同時這些查詢預設會經過 Clash 處理而不是直接走系統網路。
• nameserver-policy——針對特定域名分組指定專用上游,常見做法是境內域名走本地解析加速,境外域名走加密上游,兼顧速度與隱私。
• fallback / fallback-filter——當預設上游返回的結果被判定為汙染或不可信時,自動切換到備用解析器,geoip-code: CN 用來判斷返回結果是否落在預期地區。
• ipv6——如果系統或路由器仍保留 IPv6 出口,而這裡沒有對應處理,IPv6 域名解析會繞過 fake-ip 直接走原生通道,是最容易被忽略的洩漏點。沒有針對性配置 IPv6 規則前,建議直接關閉。

▶系統層與瀏覽器層的補充檢查

配置檔案調好之後,還有幾個不在 dns 段內、但同樣會導致洩漏的系統級設定值得逐一確認:

1. 瀏覽器安全 DNS 開關統一設為「跟隨系統」,不要單獨指定固定的 DoH 服務商,否則瀏覽器流量會繞過 Clash 的 DNS 接管邏輯。
2. 作業系統的網路介面卡 DNS 設定盡量清空或保持自動,不要手動填入電信商 DNS 位址作為「備用」,備用位址在某些系統策略下會被優先採用。
3. 路由器或家用閘道如果開啟了 DNS 劫持功能,可能會在裝置發出加密 DNS 請求前就被攔截替換,這種情況需要在用戶端側確認加密協議(DoH/DoT)確實建立成功而不是被降級成明文查詢。
4. 多使用者或多網路設定檔切換時,重新走一遍第二節的檢測步驟,不要假設一份配置在所有網路環境下表現一致——公共 Wi-Fi、企業網路、行動數據網路的 DNS 劫持策略可能完全不同。

把以上檢查項走完一遍,基本可以確認 DNS 請求的完整鏈路都被收進了代理隧道。防洩漏配置不是一次性工作,換裝置、換網路、升級用戶端版本之後都值得用第二節的四個步驟複測一次,成本很低,能提前發現規則分流「看起來生效但實際漏風」的情況。