· 故障排除 · 預計閱讀 12 分鐘

Clash DNS 洩漏檢測與修復：自我檢查步驟及防洩漏設定教學

說明 DNS 洩漏的成因與檢測方式，提供 TUN 模式、fake-ip、停用系統 DNS 回退等防洩漏設定，並附上逐步複測清單。

如何判定 DNS 洩漏

DNS 洩漏是指網域名稱查詢離開預期的解析路徑。例如，原本要求所有公網網域都透過代理端解析，實際上卻由本地路由器轉送至電信業者的 DNS。網頁出口 IP 已變更，不代表 DNS 查詢路徑也跟著改變：應用程式可能先呼叫系統解析器，再將取得的 IP 位址交給代理。

先釐清目標，再判斷結果。本文區分兩種目標：一是讓系統查詢統一交由 Clash 核心處理，並使用指定的加密 DNS；二是進一步讓連往上游 DNS 的連線也經由代理出口。前者允許加密 DNS 直連，後者則不允許。不能用同一個「檢測通過」的結論概括兩者。

建立基準：同時記錄出口與解析器

固定測試條件

  1. 記錄目前使用的用戶端、核心版本、作業系統、網路介面，以及是否同時執行其他 VPN。
  2. 關閉其他代理軟體，並暫時停用瀏覽器的「安全 DNS」，避免兩套解析機制混用。之後再分別重新啟用並測試。
  3. 分別記錄關閉代理、僅啟用系統代理、啟用 TUN 三種狀態下的網頁出口 IP 與 DNS 檢測結果。
  4. 每一輪測試前，先清除系統與瀏覽器快取，再開始新測試；測試頁面應使用新產生的網域，而非重複查詢同一個快取網域。

可在瀏覽器中手動開啟 https://www.dnsleaktest.com/ 或 https://browserleaks.com/dns。這些網站會接觸目前的存取 IP 與測試查詢資訊，屬於外部測試服務。檢測結果通常反映遞迴解析器向權威伺服器發出查詢時使用的出口，無法單獨證明應用程式與解析器之間採用哪種傳輸協定。

觀察結果可能原因後續檢查
網頁出口已變更，DNS 仍顯示本地電信業者系統查詢未被接管，或設定仍主動使用本地解析器檢查 TUN、DNS 劫持與實際生效的設定
DNS 顯示的是公共解析服務，位置與節點所在國家不同可能是 DoH 直連，也可能是服務商採用分散式解析出口檢查上游連線使用的出口與策略
瀏覽器測試正常，命令列仍使用本地 DNS瀏覽器可能使用獨立的 DoH關閉瀏覽器的安全 DNS，再重新測試系統解析
只有啟用 IPv6 後才出現額外解析器IPv6 路由或 DNS 接管可能不完整檢查實體網路介面的 IPv6 DNS 與預設路由

「出現多個 DNS IP」並不足以證明有洩漏。公共解析服務可能使用多個出口，設定中的多個上游也可能參與查詢。判斷重點在於這些解析器是否符合預期，以及查詢是否繞過原定的代理路徑。

自行檢查系統：介面 DNS、快取與 53 連接埠

Windows：檢查每個介面，不只看 Wi-Fi

在 PowerShell 執行以下指令。第一個指令查看介面 DNS，第二個清除快取，第三個則發出一次查詢。如果有乙太網路、Wi-Fi 或虛擬網卡，請檢查所有正在使用的介面。

Get-DnsClientServerAddress
Clear-DnsClientCache
Resolve-DnsName example.com -Type A

Resolve-DnsName 成功只代表取得了查詢結果，無法證明查詢經由代理。nslookup example.com 顯示的預設伺服器，也不代表查詢經透明劫持後實際使用的上游。還需搭配核心記錄、路由資訊及實體網路介面上的流量判斷。

macOS 與 Linux：辨識本機 DNS stub

# macOS：查看各範圍的 DNS 設定
scutil --dns
# macOS：清除系統解析快取
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# 使用 systemd-resolved 的 Linux
resolvectl status
resolvectl flush-caches
resolvectl query example.com

Linux 的 /etc/resolv.conf 若指向 127.0.0.53，通常表示使用 systemd-resolved 的本機 stub，不代表上游也在本機。請接著查看 resolvectl status 中各連線的 DNS Servers 與 DNS Domain。未使用 systemd-resolved 的發行版，則需改用相應的網路管理工具。

封包擷取時選擇實體介面

在 Wireshark 中可先使用顯示篩選器 dns || tcp.port == 853，找出一般 DNS 與常見的 DoT 連線。macOS、Linux 也可使用以下指令；請將 en0 換成實際連網介面的名稱。

sudo tcpdump -ni en0 '(udp port 53 or tcp port 53 or tcp port 853)'

若在實體介面上看到明文公網網域查詢傳送至路由器或電信業者，請繼續追查來源。DoH 通常使用 443 連接埠，無法透過上述篩選器排除。若在 TUN 虛擬介面看到查詢，可能只是接管前的流量，不應直接視為已從實體網路送出的洩漏。

mihomo 設定：TUN、fake-ip 與 DNS 劫持

以下是要合併至現有設定的片段，並非完整訂閱。請保留原有的 proxies、proxy-groups 與 rules；若已存在 tun 或 dns，請修改原有區段，避免 YAML 鍵重複。請透過用戶端的覆寫或合併功能保存設定，避免修改在下次更新訂閱時被覆蓋。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

主要欄位的實際作用

fake-ip 常見的回傳位址位於 198.18.0.0/16。看到這個位址代表使用了映射機制，不表示遠端網站的真實位址變成了保留網段。若應用程式取得 fake-ip 後繞過核心直連，連線可能會失敗；此時應修正流量接管，而不是立刻擴大 fake-ip-filter。將網域加入篩選清單只會改變回傳位址的方式，不會自動改變上游 DNS 的出口。

讓上游 DNS 也經由代理：規則與引導解析

若目標是讓公網網域查詢的上游連線也經由節點，還需設定 DNS 出站策略。mihomo 可使用 respect-rules: true，讓 DNS 上游連線遵循路由規則；使用此設定時應一併設定 proxy-server-nameserver，確保節點網域有獨立的引導解析路徑。

以下範例假設現有設定中確實有名為 PROXY 的策略群組，而且該群組已選取代理節點，而非 DIRECT。請在前一段設定的 dns 區段加入第一個項目，並將規則插入現有 rules 中較前面的位置。請勿覆蓋原有規則清單。

# 合併至現有的 dns 區段
dns:
  respect-rules: true

# 合併至現有的 rules 清單，放在可能優先比對的規則之前
rules:
  - IP-CIDR,1.1.1.1/32,PROXY,no-resolve

此規則會讓連往 1.1.1.1 的連線選用 PROXY，也會影響其他連往該 IP 的流量。它只涵蓋範例中的 IPv4 上游；更換 DNS 位址時，應重新規劃規則。儲存後請查看核心連線記錄，確認 DNS 上游連線符合預期的策略，不能只因設定檔中出現了 respect-rules 就認定設定生效。

節點網域的引導解析仍須另外評估。即使業務網域透過代理解析，啟動時解析節點網域仍可能使用直連 DNS。若要求啟動階段也不進行直連解析，應使用服務提供者支援的穩定節點 IP 或受控的引導機制，並保留所需的 TLS 伺服器名稱設定。不要長期寫死暫時解析出的 IP，否則節點位址變更後可能無法連線。

停用系統 DNS 回退與獨立解析旁路

不要把 fallback 當成系統 DNS 回退開關

Clash 的 fallback 是核心中的另一組上游，會搭配 fallback-filter 決定如何使用查詢結果；它不是作業系統的備用 DNS。刪除它無法阻止系統向 DHCP 指定的解析器送出封包。反過來說，任意加入更多 fallback 位址，可能擴大查詢涉及的解析服務範圍。

若需要「代理無法使用時停止解析」的嚴格策略，應先確認解析路徑，再透過受控的路由或防火牆規則限制直連出口，並明確放行節點連線及必要的網路服務。只啟用 TUN 不等於已建立斷網保護。遠端設備、企業內網及需要入口網站認證的網路，尤其應事先準備復原方式。

逐步複測與故障排除

  1. 確認設定已載入：重新套用設定，確認沒有未知欄位、重複鍵或 YAML 縮排錯誤，並確認啟動記錄顯示 TUN 已成功建立。
  2. 清除舊結果：清除系統快取，完全關閉瀏覽器後再重新開啟。每輪都使用新的測試網域，避免快取掩蓋實際連線路徑。
  3. 確認系統解析：先用系統指令查詢，再執行瀏覽器 DNS 檢測。兩者結果都應能以目前設定解釋，而不是只有其中一個頁面顯示正常。
  4. 確認上游出口：檢查核心連線與記錄中的 DNS 目標、命中規則及策略群組的最終選擇。若要求經由代理，請確認沒有選到 DIRECT。
  5. 檢查實體網路：擷取 TCP/UDP 53 流量及必要的加密 DNS 連線。遇到未知的 443 連線時，應配合處理程序資訊判斷；不能把「沒有看到明文封包」當成完整證據。
  6. 涵蓋狀態變化：重複測試切換 Wi-Fi、從睡眠狀態喚醒、切換節點及更新訂閱後的狀況。確認覆寫設定仍然存在，且路由已重新建立。
  7. 檢查故障時的行為：在可復原的本機環境中，暫時讓所選代理無法使用，確認系統會依預期停止運作，還是悄悄改用其他解析路徑。

網頁完全無法開啟時

先判斷問題是 DNS 逾時還是代理連線失敗。若記錄顯示上游 DoH 連線失敗，請檢查連往 1.1.1.1:443 的出站策略與節點是否可用；若節點網域本身無法解析，請檢查引導解析；若能取得 fake-ip 卻連線逾時，請檢查 TUN 路由、排除的處理程序及其他 VPN 衝突。每次只修改一處，並保留修改前的設定，避免多項變動互相干擾。

下載Clash用戶端與系統需求