Clash DNS 洩漏檢測與修復：解析鏈路、防洩漏設定實作

DNS 洩漏與 Clash 解析鏈路

造訪網站時，應用程式通常會先將網域交給 DNS 解析器，再連線至回傳的 IP 位址。代理規則可以決定後續連線採用直連或代理，但 DNS 查詢不一定會自動沿用相同路徑。如果網頁流量已經經過代理，網域查詢卻仍送往本地路由器、電信業者解析器或其他非預期的伺服器，就形成了通常所說的 DNS 洩漏。

這裡的「洩漏」需要配合預期情境判斷。中國大陸直連網域交由當地 DNS 解析不一定是錯誤；真正需要關注的是，原本應由代理端解析的網域是否暴露給本地網路、查詢結果是否遭到錯誤改寫，以及不同應用程式是否繞過 Clash 的 DNS 模組。合理目標不是讓檢測頁面只顯示某個固定位址，而是讓解析路徑與規則設計一致。

常見的解析鏈路可以拆成四層：應用程式發起查詢，作業系統選擇 DNS 伺服器，Clash 或 mihomo 接收並處理查詢，上游解析器回傳結果。啟用系統代理只會影響遵循 HTTP 或 SOCKS 代理設定的連線，通常不會接管作業系統送往 UDP 53 埠的 DNS 請求。啟用 TUN 後，用戶端可以進一步攔截系統網路流量，但仍需設定 DNS 劫持，才能將一般 UDP/TCP DNS 查詢導入內建解析器。

瀏覽器也可能啟用 DNS over HTTPS，也就是 DoH。它會將 DNS 封裝在 HTTPS 連線中，送往瀏覽器指定的服務端。這類流量使用 443 埠，一般的 53 埠劫持無法識別，因此會形成獨立的解析路徑。排查時必須同時檢查 Clash、作業系統與瀏覽器，不能只查看用戶端面板中的 DNS 開關。

分層檢測 DNS 出口：瀏覽器、系統與日誌

檢測前先記錄目前模式，包括是否開啟系統代理、是否啟用 TUN、Clash DNS 是否啟用，以及瀏覽器安全 DNS 是否開啟。接著分別在完全關閉 Clash、只開啟系統代理、開啟 TUN 三種狀態下測試。比較結果比單次截圖更有價值，因為快取、網路切換與公共 DNS 調度都可能使結果改變。

第一步：用瀏覽器測試實際連線環境

1. 關閉瀏覽器所有視窗後重新啟動，避免舊連線與記憶體快取影響結果。
2. 造訪可信任的 DNS 檢測頁面，執行基本測試與進階測試，記錄解析器 IP、網路提供者與地區。
3. 切換 Clash 的系統代理或 TUN 狀態，再次測試並比較解析器是否改變。
4. 檢查瀏覽器設定中的安全 DNS、使用安全 DNS 或 DNS over HTTPS 選項，確認是否指定了獨立的服務商。

檢測頁面通常會透過產生隨機子網域，觀察哪個解析器向權威 DNS 發出請求。它反映的是該頁面觸發查詢時的出口，不代表所有應用程式都使用同一條解析路徑。瀏覽器擴充功能、企業政策、系統快取與網路中的透明代理也可能改變結果，因此還要搭配系統指令與 Clash 日誌確認。

第二步：檢查作業系統目前使用的 DNS

Windows 可以在 PowerShell 中查看網路介面卡的 DNS，並主動查詢一個尚未快取的網域：

Get-DnsClientServerAddress
Resolve-DnsName example.com

macOS 可查看目前的解析器清單與系統解析結果：

scutil --dns
dscacheutil -q host -a name example.com

使用 systemd-resolved 的 Linux 發行版可執行：

resolvectl status
resolvectl query example.com

指令輸出中的 DNS 伺服器可能是本機迴路位址、區域網路閘道或 TUN 分配的虛擬位址。看到本機位址不代表查詢停留在本機，還要確認 Clash 最終選用了哪個上游。相反地，如果系統明確將查詢直接送往路由器，而 Clash 日誌中沒有對應記錄，表示該請求很可能沒有進入 Clash DNS 模組。

第三步：搭配日誌定位查詢路徑

在用戶端中暫時將日誌層級調整至可觀察 DNS 行為的等級，然後查詢一個先前未造訪的網域。檢查日誌是否出現網域解析、規則命中、上游連線或失敗重試。測試結束後恢復常用日誌層級，避免大量除錯資訊長期佔用儲存空間。

如果日誌完全沒有查詢記錄，優先檢查系統 DNS、TUN DNS 劫持與瀏覽器 DoH。如果日誌記錄了查詢，但上游連線採用了非預期的 DIRECT 或代理策略，則要檢查解析器位址本身如何套用規則。如果只有首次造訪出現異常，後續恢復正常，還應考慮系統、瀏覽器與 Clash 各自的 DNS 快取。

Clash Meta（mihomo）DNS 設定與 fake-ip

mihomo 的 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
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "+.local"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - tls://1.1.1.1
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

理解 nameserver 與 default-nameserver

nameserver 是一般網域查詢使用的主要上游，可以填寫一般 DNS、DoT 或 DoH 位址。加密 DNS 能降低本地鏈路直接讀取與修改查詢內容的機會，但上游服務本身仍能處理查詢，因此應選擇可用且符合自身信任範圍的解析服務。

default-nameserver 主要負責引導解析。例如 DoH 上游寫成網域時，核心需要先取得這個 DoH 網域的 IP，才能建立加密連線。此欄位通常使用可直接連線的 IP 位址，避免「解析 DNS 服務本身時，還要先使用同一個 DNS 服務」的循環。引導查詢仍可能以一般 DNS 形式進行，因此應選擇穩定且符合目前網路預期的位址。

proxy-server-nameserver 用於解析代理伺服器網域。若代理節點以網域填寫，建立代理連線前必須先取得節點 IP。將這類查詢獨立設定，可以降低節點網域解析與一般規則互相循環的機率。使用支援 respect-rules 等新欄位時，應先確認目前 mihomo 核心版本及用戶端實作；舊核心可能忽略欄位或回報設定錯誤。

fake-ip 如何參與規則匹配

在 fake-ip 模式下，Clash 會向應用程式回傳保留位址範圍內的暫時映射位址，同時儲存網域與假 IP 的對應關係。應用程式連線至該位址時，核心能還原原始網域並繼續匹配網域規則。這種方式有助於及早接管請求，也能減少應用程式自行使用解析結果直連的情況。

198.18.0.0/15 是常用於基準測試的保留網段，範例中的 198.18.0.1/16 位於該範圍內。不要將 fake-ip 位址當成網站的真實 IP，也不要用 ping 假 IP 的結果判斷遠端伺服器是否正常。用戶端的映射只在目前核心與快取的生命週期內有效。

區域網路裝置探索、印表機、投放、部分遊戲，以及依賴真實 IP 的程式可能不適合 fake-ip。此時應將必要網域加入 fake-ip-filter，讓它們回傳真實解析結果。過濾範圍不宜無限擴大，否則大量網域會重新採用真實 IP 解析，削弱統一接管與網域規則匹配的效果。

TUN 模式與 DNS 劫持設定

僅啟用 mihomo 的 DNS 服務，不代表系統會主動將查詢交給它。用戶端可以修改系統 DNS，使其指向本機監聽埠，也可以在 TUN 中劫持傳統 DNS 流量。桌面版常見設定如下：

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

dns-hijack 會將經過 TUN 的 53 埠查詢導向 mihomo DNS 模組，涵蓋應用程式自行指定一般 DNS 伺服器的常見情況。它通常能處理 UDP 53 與 TCP 53，但不能自動識別送往 443 埠的 DoH，也不能保證所有使用自帶網路堆疊、特殊虛擬網卡或核心級旁路的程式都會進入 TUN。

Windows 啟用 TUN 通常需要系統管理員權限與可用的虛擬網卡元件。macOS 會透過系統網路延伸功能或 VPN 設定建立通道。Linux 需要 TUN 裝置權限、路由表與防火牆規則配合。Android 與 iOS 用戶端通常借助系統 VPN 介面接管流量，同一時間一般只能維持一個主要 VPN 設定處於啟用狀態。

如果啟用 TUN 後完全無法解析網域，先檢查 TUN 路由是否建立，再檢查 mihomo DNS 監聽埠是否被佔用。還要確認防火牆沒有阻止核心連線至上游 DNS，以及代理節點網域能否透過 proxy-server-nameserver 解析。節點網域解析失敗時，代理通道無法建立；如果設定又要求上游 DoH 透過代理存取，便會形成啟動循環。

同時執行企業 VPN、遊戲加速器、虛擬機網路、容器網路或其他代理工具時，多個程式可能爭用預設路由與 DNS 設定。排查期間應逐一暫停衝突工具，確認單獨執行 Clash 時的結果，再決定路由優先順序。頻繁切換網路後若 DNS 指向殘留，可先退出用戶端並恢復系統自動取得 DNS，然後重新啟用 TUN。

瀏覽器 DoH與應用程式內建解析器

Chrome、Edge、Firefox 等瀏覽器可以獨立啟用加密 DNS。有些瀏覽器會嘗試將系統 DNS 自動升級為對應服務商的 DoH，有些則允許使用者手動指定解析器。若指定的服務與 Clash 設定不同，瀏覽器測試會顯示另一組 DNS 出口，這不一定代表 TUN 失效，而是瀏覽器主動建立了獨立的 HTTPS 查詢連線。

若要讓瀏覽器統一使用 Clash DNS，可以關閉瀏覽器中的自訂安全 DNS，讓查詢回到作業系統，再由系統 DNS 或 TUN 劫持交給 mihomo。另一種方案是保留瀏覽器 DoH，並透過 Clash 規則控制 DoH 服務連線採用代理或直連；但此時網域查詢發生在遠端 DoH 服務中，mihomo 無法直接取得每次查詢內容，基於網域的分流行為也可能依賴瀏覽器後續連線攜帶的網域資訊。

部分應用程式會內建固定 DNS、DoH 或 DoT，防毒軟體與家長監護程式也可能部署本機過濾解析器。若發現只有某個應用程式的結果異常，應檢查該應用程式的網路設定、啟動參數與系統政策，而不是反覆更換 Clash 上游。Android 的「私人 DNS」通常使用 DoT；如果它與 VPN 用戶端同時運作異常，可以暫時設為自動或關閉以進行對照測試。測試完成後，再依實際需求決定最終設定。

常見 DNS 洩漏與解析故障排查順序

檢測結果仍顯示本地電信業者 DNS

先確認瀏覽器安全 DNS 是否關閉，再查看系統 DNS 是否已指向用戶端接管位址。若只開啟系統代理而未啟用 TUN，系統層級的 UDP DNS 繼續送往路由器是常見現象。需要統一接管時，啟用相容的 TUN 與 DNS 劫持，並確認查詢能在用戶端日誌中出現。

啟用 fake-ip 後區域網路裝置無法存取

將區域網路網域後綴加入 fake-ip-filter，並確認區域網路網段規則位於兜底代理規則之前。存取 NAS、路由器或印表機時，優先使用其區域網路位址驗證基本連通性。若 IP 可以存取但網域不行，應重點檢查本地域名是否由路由器 DNS、mDNS 或內部 DNS 提供。

DoH 上游連線逾時

檢查 DoH 網域能否透過 default-nameserver 完成引導解析，再檢查其 IP 是否被錯誤分流。某些網路會限制特定公共解析服務，盲目增加多個無法連線的上游只會延長重試時間。保留少量經過驗證的上游，並分別依直連與代理鏈路設定，比堆疊大量位址更容易定位問題。

代理節點顯示可用，但網頁提示網域無法解析

節點連通性測試可能使用既有 IP 或快取結果，不能證明 DNS 鏈路正常。檢查節點位址是 IP 還是網域；如果是網域，確認 proxy-server-nameserver 可用。接著查詢一般網域並觀察日誌，區分「節點網域無法解析」、「上游 DNS 無法連線」與「回傳結果遭規則拒絕」三類問題。

測試結果出現多個解析器

多個解析器可能來自上游服務的叢集、瀏覽器並行查詢、備援解析，或系統與瀏覽器兩條鏈路同時運作。先不要直接依數量判斷異常。重複測試隨機網域，並分別關閉瀏覽器 DoH、fallback 與其他網路工具，觀察是哪項設定引入了額外出口。若所有解析器都屬於預期上游，且本地網路解析器未處理代理網域，結果可能符合設計。

設定更新後問題再次出現

訂閱更新可能覆蓋用戶端的 DNS 段落，也可能變更規則組名稱，使原有 nameserver-policy 或上游分流失效。檢查用戶端採用的是訂閱原始設定、覆寫設定，還是合併設定。需要長期保留的 DNS 設定應放在用戶端支援的覆寫機制中，並在每次更新後確認最終生效的設定，而不是只檢查訂閱來源檔案。

完整排查應形成閉環：先明確哪些網域應在本地解析、哪些查詢應交由代理端處理；再用瀏覽器測試發現現象，用系統指令確認 DNS 指向，用日誌驗證查詢是否進入 mihomo；最後調整 fake-ip、上游解析器、TUN 劫持與瀏覽器 DoH。每次只修改一個變數並重新測試，才能判斷修復究竟來自哪項設定。