Clash DNS 洩漏怎麼檢測：瀏覽器測試、日誌定位與防洩漏設定

先釐清什麼才算 DNS 洩漏

造訪網站時，應用程式通常會先將網域交給 DNS 解析器，再使用回傳的 IP 建立連線。代理連線已經經過 Clash，不代表網域查詢也會走同一條路徑。系統仍可能向路由器、電信業者解析器或公司網路中的內部 DNS 發送請求。此時網站內容流量經過代理，網域查詢卻從本地網路送出，這正是排查 Clash DNS 洩漏時需要關注的核心現象。

判斷結果不能只看檢測頁面是否列出多個 DNS 伺服器。公共 DNS 服務可能使用任播、轉送叢集與不同出口，檢測網站看到的伺服器位址未必等於設定中填寫的位址。多個結果也可能屬於同一家解析服務。更可靠的判斷方式，是同時核對解析器所屬網路、地理位置、測試期間的 Clash 日誌，以及本機實際送出的 53、853 或 HTTPS 請求。

還要區分 DNS 洩漏、WebRTC 位址暴露與代理出口變化。WebRTC 測試可能顯示區域網路位址或公網候選位址，但它屬於瀏覽器即時通訊鏈路，不等於 DNS 查詢繞過代理。代理出口檢測若顯示本地公網 IP，應先檢查代理模式、規則命中與 UDP 接管，而不是直接修改 DNS。這三類問題需要分別蒐集證據。

常見的洩漏表現

啟用代理後，DNS 檢測頁面仍顯示家用寬頻或行動網路電信業者的解析器。
切換到其他地區的代理節點後，DNS 查詢仍持續從本地網路直接送出。
Clash 日誌能看到網站連線，卻看不到對應網域進入內建 DNS 模組。
瀏覽器與命令列測試結果不同，只有其中一個應用程式繞過了預期的解析路徑。
系統代理模式下網頁流量正常，但本機封包擷取仍出現傳送至路由器的 UDP 53 請求。

瀏覽器測試、命令列查詢與封包擷取應分層執行

瀏覽器 DNS 檢測適合作為入口。這類頁面通常會產生一批隨機子網域，迫使瀏覽器發起新查詢，再由權威 DNS 端記錄實際的遞迴解析器。測試前應關閉其他正在連線的軟體，清除作業系統與瀏覽器的 DNS 快取，並使用新的私密視窗。命中快取會跳過查詢，讓結果看起來比實際情況更乾淨。

完成標準測試與擴充測試後，先記錄解析器 IP、網路業者與國家或地區。預期結果取決於設定目標：如果 Clash 使用指定的遠端 DoH，結果應對應該服務的遞迴出口；如果依網域策略將中國大陸網域交給本地加密解析、其他網域交給遠端解析，檢測結果可能出現兩組服務。重點是每組結果是否符合明確設定，而不是強求頁面只出現一個位址。

用命令列區分系統 DNS 與指定解析器

瀏覽器可能啟用自身的安全 DNS，因此還需要測試作業系統的解析路徑。Windows 可使用 nslookup 或 PowerShell 的 Resolve-DnsName，macOS 與 Linux 可使用 dig。先查詢一個此前未造訪過的網域，再查看命令輸出中的伺服器位址。若顯示家用路由器位址，例如區域網路閘道，表示系統仍將查詢交給路由器；這本身不代表查詢最終一定洩漏，但說明 Clash 尚未直接成為該命令的 DNS 入口。

nslookup example.net

Resolve-DnsName example.net

dig example.net
dig @127.0.0.1 -p 1053 example.net

最後使用一條命令，明確查詢 Clash 或 mihomo 的本機監聽連接埠，適合與系統預設查詢進行比較。如果明確查詢符合預期，但預設查詢仍經過路由器，問題就在系統 DNS 指向或 TUN 的 DNS 劫持環節。如果兩種查詢都落到不期望的解析器，則繼續檢查核心設定與上游 DNS。

擷取連接埠與目標位址

需要確認本機是否直接向區域網路或公網傳送傳統 DNS 時，可在測試期間擷取 UDP/TCP 53 流量。Linux 可使用 tcpdump，Windows 可借助系統網路追蹤工具，macOS 也可在作用中的介面上執行 tcpdump。介面名稱應依實際環境替換。

sudo tcpdump -ni any 'port 53 or port 853'

sudo tcpdump -ni en0 'udp port 53 or tcp port 53'

封包擷取中若出現傳送至路由器或電信業者 DNS 的 53 連接埠請求，是直接解析仍在發生的有力證據。看不到 53 流量也不能立即結束排查，因為應用程式可能使用 DoH，將 DNS 封裝在 443 連接埠的 HTTPS 中。此時應結合 Clash 連線日誌、瀏覽器安全 DNS 設定與目標位址進行判斷。

沿著系統、Clash 核心與上游解析器定位路徑

DNS 路徑可以拆成三個節點：應用程式將查詢交給誰、Clash 是否收到查詢，以及 Clash 透過哪條網路連線存取上游。分別確認這三個問題，比反覆替換公共 DNS 位址更有效。

第一段：應用程式至系統或瀏覽器解析器

多數桌面應用程式會呼叫作業系統的解析介面，但瀏覽器可能啟用獨立 DoH，部分命令列程式也能直接查詢指定伺服器。系統代理只會設定 HTTP、HTTPS 或 SOCKS 代理位址，通常不會自動改寫所有系統 DNS。在系統代理情境中，瀏覽器先於本地完成解析，再將目標交給代理，是相當常見的路徑。

如果只有瀏覽器測試異常，先檢查瀏覽器的安全 DNS。可以將它關閉，交由系統與 Clash 管理；也可以明確設定為與 Clash 方案一致的 DoH 服務。若多個應用程式同時出現本地解析請求，則優先檢查作業系統 DNS、TUN 接管與用戶端的 DNS 開關。

第二段：確認查詢是否進入 Clash 內建 DNS

確認設定中的 dns.enable 已開啟，並檢查本地監聽位址是否與用戶端介面顯示一致。部分圖形用戶端會從介面產生執行設定，訂閱檔案中的 DNS 欄位可能遭到覆寫。排障時應查看核心實際載入的設定，而不只是訂閱原文。

將日誌層級暫時調整為 debug，清除日誌後查詢一個隨機子網域。日誌格式會因 Clash 分支與用戶端而異，但應重點尋找 DNS 查詢、規則命中、上游請求失敗、逾時與備援選擇。日誌中完全沒有該網域，表示請求尚未進入核心；出現網域但上游經由直連，則需要檢查 DNS 上游的撥號路徑。

第三段：Clash 至上游 DNS 的連線

即使查詢已進入內建 DNS，上游 DoH 或 DoT 仍可能透過 DIRECT 存取。加密能保護查詢內容在傳輸中的完整性與可見範圍，但上游連線仍會暴露解析服務的目標位址。若目標是讓遠端解析連線隨代理策略轉送，需使用目前核心支援的代理指定方式，或啟用依規則連線至 DNS 上游，並為代理伺服器網域準備獨立的引導解析器。

若代理節點本身以網域名稱填寫，核心必須先取得節點伺服器 IP，才能建立代理通道。這項啟動依賴不能再遞迴要求透過尚未建立的代理連線。mihomo 中的 proxy-server-nameserver 用於處理代理伺服器網域解析；default-nameserver 則負責解析 DoH 上游本身的網域等基礎工作。兩者職責不同。

用 fake-ip、遠端解析與備援策略收攏查詢

在支援 Clash Meta 設定的 mihomo 核心中，fake-ip 是常用的增強解析模式。應用程式查詢網域時，內建 DNS 會先從保留位址池回傳一個映射位址。應用程式連線至該位址後，核心會依據映射還原原始網域，再執行規則比對與代理選擇。如此可減少應用程式提前在本地取得真實 IP 的機會，也有利於依網域規則分流。

以下是一段用於理解欄位關係的基礎片段。公共解析端點僅為結構範例，部署時應依所在網路的可達性、服務條款與隱私要求選擇。不同用戶端內建的 mihomo 版本可能支援不同語法，修改前應核對目前核心文件並保留原始設定。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  respect-rules: true

listen 決定內建 DNS 的監聽位置。僅供本機使用時，應配合用戶端實作限制存取範圍；TUN 模式下，用戶端通常會自動管理監聽與劫持。fake-ip-range 使用專用位址段維護網域映射，不應與本地區域網路、容器網路或企業路由重疊。

fake-ip-filter 用來排除不適合 fake-ip 的網域。區域網路裝置探索、時間同步、部分遊戲平台，以及依賴真實區域網路位址的服務，可能需要回傳真實 IP。過濾項目應從實際故障出發逐項新增。將大範圍網域全部放入過濾清單，會讓大量請求重新使用真實 IP 解析，削弱 fake-ip 收攏解析路徑的效果。

respect-rules 讓 DNS 上游連線遵循規則，但啟用後必須確保代理伺服器網域能透過 proxy-server-nameserver 解析，否則可能出現核心為建立代理而等待 DNS、DNS 又等待代理的循環依賴。舊版 Clash 或部分已停止維護的分支可能沒有同名欄位，應以實際核心能力為準。

用 nameserver-policy 精確指定網域解析器

如果不同網域需要不同的解析路徑，可使用 nameserver-policy。它的優先順序通常高於通用的 nameserver，適合為內網網域、特定規則集或地區網域指定解析器。策略範圍過寬會導致檢測頁面出現多組遞迴出口，因此每條規則都應有明確用途。

dns:
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.10.1
  nameserver:
    - https://1.1.1.1/dns-query

將內部網域交給企業或家庭 DNS 時，對應請求會進入本地網路。這是刻意設計的分流，不應與意外洩漏混為一談。不過應避免通配規則涵蓋一般公網網域，也要確認內部解析器僅在可信任的網路中使用。

理解 fallback，而不是機械複製範本

部分設定會使用 fallback 與 fallback-filter。核心可以並行查詢主要與備援解析器，再依據地理 IP、網域類別或保留位址判斷採用哪個結果。這套機制主要用於處理解析污染、錯誤結果或不同網路的可用性，並不會天然保證 DNS 查詢經過代理。

dns:
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw

如果主要解析與備援解析都透過本地直連送出，檢測仍可能看到不期望的路徑。設定備援時，應同時核對上游連線如何路由、遠端端點是否穩定，以及規則集能否正常載入。現代 mihomo 設定也可透過 nameserver-policy 實現更明確的網域層級選擇，是否保留 fallback 應依情境決定。

TUN 模式要同時處理 DNS 劫持與應用程式繞過

系統代理主要影響遵循代理設定的應用程式。遊戲、系統服務、部分命令列程式與自行建立連線的軟體可能忽略它。TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量，因此更適合統一處理 UDP、未感知代理的應用程式與系統 DNS，但它依賴管理員權限、路由設定與平台網路堆疊。

mihomo 的 TUN 設定通常包含自動路由與 DNS 劫持。具體欄位會隨版本與用戶端封裝而變化，典型結構如下：

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

dns-hijack 會將經過 TUN 的傳統 53 連接埠查詢送入內建 DNS。啟用後應重新擷取封包，確認請求沒有繼續從實體網卡直接傳送至路由器。某些平台的安全軟體、虛擬機器、容器、VPN 或企業網路用戶端會安裝優先順序更高的路由與過濾驅動程式，導致部分流量繞過 TUN。此時應檢查路由表、介面優先順序，以及用戶端日誌中的介面選擇。

DNS 劫持通常針對傳統 UDP/TCP 53。瀏覽器內建的 DoH 使用 HTTPS 443，不能只靠劫持 53 連接埠來接管。如果瀏覽器安全 DNS 指向獨立服務，它可能透過 DIRECT 或依一般連線規則存取。處理方式有兩種：關閉瀏覽器獨立解析，讓請求統一進入系統與 Clash；或保留瀏覽器 DoH，並為該端點設定明確的代理規則。混合使用時應記錄每條路徑，避免將瀏覽器測試結果誤判為核心 DNS 失效。

IPv6 也要納入測試

本地網路支援 IPv6 時，應用程式可能優先請求 AAAA 記錄，並直接建立 IPv6 連線。只檢查 IPv4 出口與 A 記錄，會遺漏這條路徑。若代理節點、規則與 TUN 完整支援 IPv6，可保留 DNS 的 IPv6 功能，並分別測試 A、AAAA 查詢與雙堆疊出口。若目前代理鏈不支援 IPv6，則應在核心、系統介面與路由層採取一致處理，而不是只刪除某項 DNS 記錄，卻繼續保留可直接連線的 IPv6 路由。

修改後依固定清單重新測試

防洩漏設定是否有效，必須在清除快取後重新產生查詢。只重新整理已開啟的頁面，可能仍會使用瀏覽器、系統或 Clash 的快取結果。建議先重新啟動用戶端核心，清除系統 DNS 快取，關閉舊的瀏覽器程序，再以隨機子網域開始測試。

確認核心設定已生效：查看用戶端執行設定與啟動日誌，確認 DNS 模組、fake-ip 與 TUN 沒有解析錯誤。
核對代理出口：分別測試瀏覽器與不遵循系統代理的應用程式，確認連線依規則進入 DIRECT 或目標策略組。
執行瀏覽器 DNS 測試：記錄每個遞迴解析器的網路歸屬，並與 nameserver、策略解析及瀏覽器 DoH 設定進行比對。
執行系統命令查詢：比較預設解析與直接查詢 Clash 本地連接埠的結果，確認系統入口是否已統一。
查看核心日誌：使用新網域觸發解析，確認查詢進入 DNS 模組、上游請求成功，且規則與代理鏈符合預期。
擷取實體介面流量：檢查是否仍有傳送至路由器或公網伺服器的意外 53、853 連接埠請求。
測試雙堆疊與故障切換：分別檢查 IPv4、IPv6，並暫時停用一個上游，確認備援不會轉向未規劃的本地解析器。

常見故障與對應檢查點

現象	優先檢查	處理方向
瀏覽器顯示本地解析器，命令列正常	瀏覽器安全 DNS、擴充功能與快取	統一交給系統解析，或明確代理瀏覽器 DoH
系統查詢經過路由器，直接查詢本地連接埠正常	系統 DNS 位址、TUN 與 dns-hijack	修正系統入口或啟用有效的 DNS 劫持
啟用 respect-rules 後節點無法連線	代理伺服器網域解析	設定 proxy-server-nameserver，解除啟動依賴
啟用 fake-ip 後區域網路裝置失效	fake-ip-filter 與本地位址段	只為受影響的區域網路網域新增排除項目
檢測出現兩組預期外解析器	fallback、nameserver-policy、瀏覽器 DoH	逐項停用，並透過日誌確認實際選擇
只有 IPv6 顯示本地出口	AAAA 解析、TUN IPv6 路由與節點能力	統一接管雙堆疊，或依網路條件一致停用 IPv6

最終目標不是讓檢測頁面呈現某個固定國家或固定數量的 DNS 位址，而是讓解析路徑與設定一致：應用程式查詢進入預期入口，Clash 依規則選擇上游，上游連線透過規劃中的 DIRECT 或代理策略送出，備援與 IPv6 也沒有繞過這套設計。只要這四個環節都能透過日誌、命令列與封包擷取相互驗證，DNS 洩漏排查才算完成。