Clash DNS 洩漏檢測:確認是否洩漏與防洩漏設定實作

什麼是 DNS 洩漏

代理已經開啟、網頁也能正常存取,但本機仍透過系統 DNS 直接向電信商伺服器查詢網域——查詢並未經過代理通道,存取過的每個網域都以明文形式留在電信商或閘道器的紀錄中,這就是 DNS 洩漏。

洩漏會帶來兩類後果。第一是隱私:誰負責解析,誰就掌握你完整的存取清單,代理建立的加密通道無法掩蓋這一環節。第二是可用性:明文的 53 埠查詢容易遭中間設備劫持,回傳被污染或錯誤的位址,典型表現就是節點狀態正常,但目標網站卻打不開,或被導向不相關的頁面。

一個常見誤解是「打開系統代理就萬事大吉」。系統代理只會修改應用程式的 HTTP 代理設定,並不會接管 DNS 查詢;不少應用程式會繞過系統代理自行解析,瀏覽器也可能啟用內建的加密 DNS 單獨連線。DNS 查詢本身就是流量,必須和網頁流量一樣被完整接管,才算真正堵住洩漏。

檢測步驟:先確認是否洩漏

檢測前先關閉其他代理與 VPN 工具,讓 Clash 保持開啟並處於需要驗證的代理模式,避免多個工具疊加干擾判斷。

1. 打開任意 IP 查詢頁面,確認目前的出口位址已經是節點位址,先證明代理通道本身運作正常。
2. 打開一個 DNS 洩漏檢測頁面並執行完整測試,記錄結果中列出的 DNS 伺服器位址、所屬電信商與所在地區。
3. 打開終端機執行 nslookup example.com,記下回傳資訊中的伺服器位址;macOS 與 Linux 可再用 dig example.com 對照。
4. 在 Clash 中把記錄層級調整為 debug,再執行一次 nslookup,觀察記錄中是否出現這筆 DNS 查詢紀錄。
5. 查看系統目前生效的 DNS:Windows 執行 ipconfig /all,macOS 執行 scutil --dns,Linux 執行 resolvectl status 或直接查看 /etc/resolv.conf。

把以上幾項結果放在一起對照,判定標準如下:

洩漏來源:五個高頻原因

確認洩漏之後,按出現頻率從高到低排查以下五個來源。

1. 只開啟系統代理模式——系統代理只會接管遵循系統代理設定的應用程式,UDP 53 上的 DNS 查詢不在接管範圍內,大量桌面應用程式仍會直連系統 DNS。
2. 瀏覽器開啟了「安全 DNS」——瀏覽器內建的 DoH 會繞過系統代理進行解析,把網域直接送往瀏覽器指定的 DoH 伺服器,系統層面完全看不到這筆查詢。
3. IPv6 未被接管——只接管 IPv4 時,AAAA 查詢與 IPv6 流量會從本機直連漏出,雙堆疊網路環境下尤其常見。
4. 規則放行了 DNS——設定中存在 DST-PORT,53 直連之類的規則,或把需要代理的網域誤劃進 DIRECT 策略。
5. 電信商或閘道器劫持 53 埠——即使手動指定了公共 DNS,明文查詢也可能被中途改道,最終表現與洩漏完全一致。

防洩漏設定:讓解析全部經過 Clash

防洩漏的核心原則只有一條:讓所有 DNS 查詢先進入 Clash 的 DNS 模組,再由 Clash 決定要在本機解析還是隨代理連線。落實分兩步:開啟 TUN 接管整台裝置的流量,然後正確設定 dns 段落。

第一步:開啟 TUN 模式

TUN 透過虛擬網卡接管整台裝置的流量,包括 UDP 53,任何應用程式的 DNS 查詢都會先落到 Clash,這是堵住洩漏最徹底的方式。Windows 需要安裝服務模式並以系統管理員權限執行,macOS 需要授權安裝輔助程式,Linux 需要 root 或相應的 capabilities。以下是 mihomo 核心的設定範例:

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

其中 dns-hijack 的 any:53 表示把發往任意目標的 53 埠查詢劫持進 Clash 的 DNS 模組,這是防洩漏的關鍵一行。

第二步:設定 dns 段落

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://192.0.2.53/dns-query
  proxy-server-nameserver:
    - https://192.0.2.53/dns-query

• enable 與 listen:Clash 在 53 埠提供 DNS 服務,配合 TUN 的 dns-hijack 接管所有查詢。
• enhanced-mode 設為 fake-ip:對需要代理的網域直接回傳 198.18.0.0/16 段的假位址,應用程式拿著假位址發起連線,Clash 依網域還原後交給代理,目標網域全程不在本機解析,這是防洩漏強度最高的一檔;redir-host 會先在本機做一次真實解析,存在明文查詢的時間窗。
• ipv6 設為 false:不回應 AAAA 查詢,避免 IPv6 旁路;確實需要 IPv6 時,必須同時確認 TUN 已接管 IPv6 流量。
• default-nameserver:引導 DNS,僅用於解析 nameserver 中 DoH/DoT 伺服器本身的位址,必須填寫純 IP。
• nameserver:常規解析上游,建議使用 DoH 或 DoT 加密形式,讓查詢經加密通道連線,本機網路只會看到一條連往 DoH 伺服器的加密連線。
• proxy-server-nameserver:專門用於解析節點網域,避免節點位址解析落到不可信的本機 DNS 上。

如果暫時無法開啟 TUN,退而求其次的做法是:保持系統代理開啟,把系統 DNS 指向 127.0.0.1,讓 Clash 的 dns 模組監聽 53 埠接管系統解析。這種方式能覆蓋遵循系統 DNS 的應用程式,但管不住自行指定 DNS 的應用程式,防護強度明顯低於 TUN 方案。

驗證生效:改完再測一輪

設定修改後重啟 Clash 或重新載入設定,然後按前面的檢測步驟完整重跑一遍,逐項核對:

• 執行 nslookup example.com,伺服器位址應顯示為 127.0.0.1 或本機位址,證明查詢已被 Clash 接管。
• 對一個走代理的網域執行 nslookup,回傳 198.18.x.x 段的位址,證明 fake-ip 生效。
• debug 記錄中能看到剛才的查詢紀錄,並標註了命中的上游與策略。
• 重跑 DNS 洩漏檢測頁,結果中不再出現本地電信商或閘道器的 DNS,只剩代理出口地區的解析紀錄。
• 連續存取幾個台灣本地與海外站點,確認直連站點解析正常、代理站點也能正常打開,沒有因設定變更而引入新的問題。

常見問題