疑難排解 預計閱讀 12 分鐘

Clash DNS 洩漏檢測方法與防洩漏設定步驟

透過線上檢測網站與本機封包擷取，確認 DNS 是否繞過代理直連，再從 dns 區段的 nameserver、fallback、fake-ip 著手排除洩漏。

先判斷什麼情況才算 DNS 洩漏

瀏覽器存取網域時，必須先將網域解析為 IP 位址。代理連線已經透過 Clash 轉送，不代表 DNS 查詢也一定會進入代理鏈路。如果 Windows 仍將 UDP 53 或 TCP 53 查詢傳送給目前寬頻、公司網路或公共 Wi-Fi 提供的解析器，網路服務提供者仍能看到查詢過的網域，這就是排查時最常見的 DNS 洩漏。

檢測結果出現本地電信業者，不一定代表設定錯誤。規則模式可能刻意讓中國大陸網域使用本地解析器，再將其他地區網域交給另一組解析器；這種分流會讓檢測頁面同時顯示多個 DNS 出口。真正需要注意的是：原本應由代理處理的網域，是否仍透過實體網卡直接查詢，以及切換節點後 DNS 出口是否始終停留在本地網路。

常見洩漏路徑

使用線上檢測網站進行三輪對照測試

線上 DNS 檢測適合快速確認現象，但單次結果不足以下定論。瀏覽器快取、系統 DNS 快取，以及檢測網站的節點歸屬資料庫都可能影響顯示。建議使用同一個瀏覽器與同一個檢測頁面連續測試三輪，並記錄代理出口 IP、DNS 伺服器數量、電信業者名稱與所在區域。

  1. 完全結束 Clash，等待 30 秒後執行一次標準檢測，記錄本地網路的 DNS 基準。
  2. 啟動 Clash，只開啟系統代理，選擇一個與本地網路所在地區不同的節點，再執行一次完整檢測。
  3. 維持同一個節點，開啟 TUN 與 DNS 劫持，清除快取後進行第三次檢測，比較結果變化。

清除 Windows DNS 與瀏覽器快取

以系統管理員身分開啟 PowerShell 或命令提示字元，執行以下命令清除 Windows DNS 快取：

ipconfig /flushdns

Chromium 系瀏覽器也可能保留自己的主機快取與連線池。關閉所有瀏覽器視窗後重新開啟，通常是最直接的做法。測試時不要同時執行其他 VPN、遊戲加速器、虛擬機器網路或公司安全用戶端，否則 DNS 可能被另一層網路元件接管。

測試結果 可能原因 下一步
只顯示本地電信業者 DNS Clash DNS 未接管，或瀏覽器仍使用系統解析 檢查 TUN、dns-hijack 與系統代理狀態
同時顯示本地與遠端 DNS 規則分流、快取或多條解析鏈並存 清除快取後擷取 53 埠流量
切換節點後 DNS 沒有變化 解析器固定直連，或設定刻意使用固定 DoH 確認 DNS 請求是否依規則經過代理
檢測正常但個別應用程式仍洩漏 該應用程式使用獨立 DNS 或繞過系統代理 改用 TUN 並啟用 DNS 劫持

在 Windows 本機確認 DNS 是否直連

Windows 內建的 pktmon 可以快速檢查是否存在明文 53 埠請求。不需要安裝額外工具，適合確認開啟 TUN 前後是否仍有封包從實體網卡送出。請先關閉正在執行的封包擷取工作，再以系統管理員身分開啟 PowerShell。

pktmon stop
pktmon filter remove
pktmon filter add DNS -p 53
pktmon start --etw -m real-time

讓視窗保持執行，開啟幾個先前未造訪過的網站，觀察目標位址與網路介面卡。測試結束後按下 Ctrl+C，再執行：

pktmon stop
pktmon filter remove

如果目標是路由器位址，例如 192.168.1.1:53，或寬頻提供的公共 DNS，而且封包來自 Wi-Fi、乙太網路實體介面卡，表示仍有明文查詢未被 Clash 接管。若只在 Clash 啟動瞬間看到少量請求，可能是加密 DNS 網域的引導解析；如果瀏覽網頁時持續出現，則應繼續調整設定。

檢查系統目前使用的解析器

以下 PowerShell 命令會列出所有網卡的 DNS 位址。重點查看目前連線中的 Wi-Fi 或乙太網路，以及 Clash、Wintun、Mihomo 等虛擬介面卡：

Get-DnsClientServerAddress |
  Where-Object {$_.ServerAddresses.Count -gt 0} |
  Format-Table InterfaceAlias, AddressFamily, ServerAddresses -AutoSize

nslookup 更適合確認系統 DNS 基準，不適合單獨證明瀏覽器是否洩漏。它通常會直接呼叫系統設定的解析器，可能無法重現瀏覽器透過 SOCKS、HTTP 代理或獨立 DoH 發出的請求。排查時應將 nslookup 結果與 pktmon、Clash 記錄一併查看。

調整 nameserver、fallback 與 fake-ip

DNS 設定的目標不是單純堆疊伺服器位址，而是釐清三件事：Clash 使用哪個解析器處理一般網域、由誰完成加密 DNS 位址的首次解析，以及解析結果如何交給規則系統。以下是適合檢查結構的基礎範例，使用 YAML 時必須維持縮排一致。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

default-nameserver：只負責引導解析

default-nameserver 通常填寫可直接存取的 IP 位址，用來解析 DoH 伺服器本身的網域。例如系統必須先知道 dns.alidns.com 的 IP，才能建立 HTTPS 連線。這裡不宜填寫網域形式，也不應塞入大量位址。兩個穩定的 IP 解析器已足以提供容錯。

nameserver 與 fallback：釐清分流目的

nameserver 是主要解析器，fallback 是傳統 Clash 設定中的備用解析器。搭配 fallback-filter 後，核心會根據 GeoIP、回傳位址範圍等條件決定採用哪一組結果。不同 Clash Meta 或 mihomo 版本對 DNS 策略的擴充能力不同，使用訂閱覆寫設定時，也要確認用戶端是否保留本地 DNS 區段。

DoH 只負責加密 DNS 內容，不會自動確保連線經過代理。如果希望遠端解析器依代理規則建立連線，應使用支援 respect-rules、proxy-server-nameserver 與 nameserver-policy 的較新 mihomo 核心，並先為代理伺服器網域準備獨立解析器，避免「解析代理伺服器必須先連線代理」的循環依賴。

fake-ip：讓網域先進入規則系統

fake-ip 模式會先向應用程式回傳 198.18.0.0/16 範圍內的映射位址，等應用程式建立連線時再還原原始網域並比對規則。這能減少應用程式自行解析後只提交目標 IP 的情況，讓規則分流與 DNS 接管更加穩定。此位址區段用於基準測試網路，不應與家庭或公司實際網段衝突。

區域網路裝置探索、印表機、遊戲平台連線、STUN 與部分登入網域可能不適合 fake-ip，應加入 fake-ip-filter。過濾清單不應直接複製數百條未經確認的規則；每增加一項，就代表該網域改用真實 IP 解析。遇到找不到區域網路裝置或應用程式登入循環時，再依記錄補充特定網域會更容易維護。

使用 TUN 與 DNS 劫持涵蓋非代理應用程式

系統代理只會影響遵循 Windows 代理設定的程式。命令列工具、遊戲、商店應用程式與部分啟動器可能直接建立連線，因此僅靠 System Proxy 很難完整接管 DNS。TUN 模式會建立虛擬網卡，在 IP 層處理流量，再搭配 dns-hijack 擷取應用程式發出的 53 埠查詢。

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

在 Clash for Windows 0.20.39 中，可先進入「General」→「Service Mode」安裝服務模式，再開啟「General」→「TUN Mode」。設定檔本身可在「Profiles」中找到目前設定，透過右鍵選單的「Edit」檢查 DNS 區段。不同的 mihomo 圖形用戶端選單名稱可能有所差異，但需要同時確認核心權限、TUN 開關與 DNS 劫持三項。

strict-route: true 在 Windows 上有助於限制多重主機 DNS 等旁路路徑，但公司 VPN、Hyper-V、WSL、虛擬機器橋接與區域網路分享可能因此改變路由。啟用後若無法存取印表機或 NAS，請先查看路由表與 Clash 記錄，不要直接將所有私有位址加入代理規則。

IPv6 也要納入同一套判斷

設定中的 dns.ipv6: false 表示 Clash DNS 不回傳 AAAA 結果，適合代理節點或目前網路沒有穩定 IPv6 的情況。如果本地網路支援 IPv6，代理節點也具備 IPv6 出口，可以改為 true，但必須同時確認 TUN、路由與規則能夠處理 IPv6。僅關閉 DNS 的 AAAA 回傳，不等於系統層級的 IPv6 已停用。

依固定順序重新測試並定位殘留問題

完成修改後，不要一次切換多個節點、模式與瀏覽器。固定一個節點，先重新載入設定，再依統一順序重新測試，才能判斷是哪個步驟產生變化。

  1. 在用戶端記錄中確認 YAML 已成功載入，沒有縮排、欄位或解析器位址錯誤。
  2. 確認目前設定的 dns.enable 為 true，監聽埠 1053 沒有被其他程式佔用。
  3. 開啟 TUN 與 dns-hijack，執行 ipconfig /flushdns。
  4. 關閉並重新開啟瀏覽器，造訪先前未開啟過的三個網域。
  5. 執行線上完整檢測，記錄 DNS 數量、地區與服務商。
  6. 同時使用 pktmon 檢查實體網卡是否仍向外傳送 UDP 53 或 TCP 53。
  7. 分別切換規則模式與全域模式再測試一次；如果只有規則模式出現本地 DNS，應檢查 DNS 策略與直連規則。

檢測結果仍顯示本地 DNS

網頁無法開啟但洩漏已消失

這通常不是檢測成功後的正常現象，而是 DNS 已被劫持，但 Clash 本身無法完成上游解析。先檢查 default-nameserver 是否為純 IP 位址，再確認 DoH 位址可連線。若代理伺服器使用網域，還要為它準備可直連的引導解析路徑。網路恢復後再逐步加入 fallback、策略解析與過濾項目，不要同時啟用所有進階欄位。

查看用戶端下載