故障排查 預計閱讀 12 分鐘

Clash DNS 洩漏檢測方法與防洩漏設定實作：enhanced-mode 與 nameserver 設定

介紹如何使用檢測網站確認 DNS 洩漏與解讀結果，實作說明 dns 設定中的 enhanced-mode、fake-ip 排除清單與 nameserver 分組，並驗證修復效果。

先確認檢測對象：出口位址與 DNS 解析並不是一回事

使用瀏覽器造訪網站時，通常會先將網域交給 DNS 解析器，再連線至解析出的 IP 位址。Clash 已接管網頁連線，並不代表 DNS 請求也一定會走同一條處理路徑。常見情況是網頁出口顯示為代理節點，但檢測頁仍列出本地寬頻業者、路由器下發的解析器，或系統中手動填寫的公共 DNS。排查時應分開記錄「連線出口」與「網域解析路徑」。

DNS 檢測頁通常顯示的是替檢測網域完成遞迴查詢的解析器出口，而不是電腦直接傳送請求的目標位址。例如系統向路由器的 192.168.1.1 查詢，路由器再將請求交給電信業者，檢測結果可能只顯示業者的遞迴伺服器。使用 DoH 時，檢測頁也可能顯示雲端服務商的任播節點、合作網路，或與實際節點不同的城市。因此，不能只憑城市不一致就判定異常，還應一併核對業者名稱、自治系統、請求數量與重複測試結果。

建立可重現的三組測試

  1. 記錄目前的公網出口 IP、網路業者與所在區域，暫時退出 Clash，完成一次基準測試。
  2. 啟動 Clash，但先關閉 TUN，只開啟系統代理，再使用隱私視窗完成第二次測試。
  3. 啟用本文設定與 TUN 的 DNS 劫持，清除快取並重新建立連線，完成第三次測試。

每一輪建議執行一次標準測試與一次擴充測試，並保存解析器數量、組織名稱、國家或地區。單次結果容易受到瀏覽器快取、檢測網站負載與 DNS 任播調度影響。實驗記錄可連續執行 3 輪，每輪間隔 30 秒；如果同一業者解析器在 3 輪中都出現，代表路徑問題比偶發出現一次更明確。

觀察項目 正常含義 需要繼續檢查的結果
網頁出口 IP 與目前代理節點的出口一致 仍是本地寬頻或行動網路位址
DNS 組織 符合設定中的 DoH 服務或預期的遠端解析鏈路 出現本地業者、家用路由器上游或公司內網解析器
解析器數量 數量穩定，重複測試變化有限 同時混入本地與遠端兩組解析器
IPv6 結果 與設定的 IPv6 開關及代理能力一致 IPv4 透過代理，但 IPv6 連線或解析繞過預期路徑

確認洩漏來自系統代理、TUN，還是瀏覽器 DoH

系統代理主要接管支援 HTTP 或 SOCKS 代理的應用程式流量。傳統 UDP 53 DNS 請求通常不在系統代理的接管範圍內，因此只開啟系統代理時，作業系統仍可能向網卡設定中的 DNS 位址傳送封包。Clash 的混合連接埠通常是 7890，這是代理入站連接埠，不是系統 DNS 連接埠；將系統 DNS 直接填寫為 127.0.0.1:7890不會得到可用的 DNS 服務。

TUN 模式會在網路層接管流量，並可搭配 dns-hijack 捕獲發往 53 連接埠的 DNS 請求，再交給 mihomo 內建的 DNS 模組。對於不遵循系統代理設定的程式、遊戲啟動器與部分命令列工具，這條路徑更加完整。不過，應用程式自行建立的 DoH 或 DoT 連線仍會呈現為一般 HTTPS 或 TLS 流量，無法只靠劫持 53 連接埠來改寫其解析器選擇。

依請求來源逐項定位

不同客戶端的選單文字可能有所差異，但排查目標相同。以支援原始 YAML 編輯功能的桌面客戶端為例，可從「訂閱」→目前設定右側選單→「編輯檔案」進入設定文字；儲存後還要執行「訂閱」→目前設定→「重新載入」。TUN 通常位於「設定」→「Clash 設定」→「TUN 模式」。如果客戶端會因訂閱更新而覆蓋本地檔案，應使用覆寫或合併設定功能儲存 DNS 區段，而不是長期直接修改訂閱快取。

設定 enhanced-mode、nameserver 與引導解析器

以下以 mihomo v1.19.10 的設定結構為例。核心關係是：default-nameserver負責解析 DoH 伺服器本身的網域，nameserver負責一般網域查詢，proxy-server-nameserver可單獨處理代理伺服器網域，nameserver-policy則依網域或規則集合指定解析器。引導解析器應使用 IP 位址，避免在解析 DoH 網域時再次依賴同一個尚未建立的 DoH 服務。

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"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "ntp.*.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://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

fake-ip 為何有助於規則分流

啟用 enhanced-mode: fake-ip後，mihomo 會先向應用程式回傳 198.18.0.0/16範圍內的保留位址，並保存網域與假位址之間的對應關係。應用程式連線至該位址時，核心可以還原原始網域，再依 DOMAIN、DOMAIN-SUFFIX、GEOSITE等規則進行比對。如此既能保留網域資訊，也能減少應用程式直接使用系統解析結果、最後只剩目標 IP 的情況。

fake-ip不是永久取代真實公網位址，而是核心內部的對應機制。建立最終連線時，仍會依策略解析並連線至真實目標。它適合依賴網域規則的日常設定，但區域網路探索、印表機、時間同步、部分遊戲登入，以及使用 IP 字面值驗證的程式可能不接受假位址，因此需要設定排除清單。

哪些情況適合使用 redir-host

enhanced-mode: redir-host會向應用程式回傳真實解析結果，通常具備更直接的相容性，但網域對應與規則命中行為和 fake-ip不同。如果某個舊程式在 fake-ip 下持續連線失敗，應先將該網域加入排除清單；只有在故障範圍較大且無法列出網域時，才暫時切換至 redir-host進行對照測試。切換 enhanced-mode 後必須清除 DNS 快取並建立新連線，否則舊記錄會干擾判斷。

為 TUN 新增 DNS 劫持與嚴格路由

只設定 dns區段還不夠，系統發往其他 DNS 伺服器 53 連接埠的請求需要導入內建 DNS。mihomo 的 TUN 設定可以使用 dns-hijack: any:53捕獲這類請求。auto-route負責新增路由，strict-route用於減少部分平台上流量從其他介面繞行的機會。不同作業系統需要相應權限，Windows 通常需要系統管理員授權，Linux 則需要建立 TUN 與修改路由的權限。

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

any:53可處理常見 DNS 請求，額外列出 tcp://any:53則能涵蓋使用 TCP 53 的查詢。當 DNS 回應超過 UDP 可承載的範圍、伺服器要求重試，或應用程式主動選擇 TCP 時，就會用到後者。此設定不會自動阻止瀏覽器內建的 DoH，因為 DoH 使用 443 連接埠；若要求所有瀏覽器遵循 Clash DNS，應在瀏覽器「設定」→「隱私權與安全性」→「安全 DNS」中選擇系統提供者，或關閉自訂提供者，再重新測試。

監聽連接埠與連接埠衝突

範例使用 0.0.0.0:1053作為 mihomo DNS 的監聽位址。1053 是非特權連接埠，方便本機除錯；TUN 劫持會將 53 連接埠請求送入該模組，因此通常不需要在系統網路設定中填寫帶有連接埠的 DNS 位址。如果另一個本機 DNS 程式已監聽 1053，核心日誌會出現繫結失敗。Windows 可使用 netstat -ano | findstr :1053檢查佔用情況，Linux 可使用 ss -lntup | grep 1053查看監聽程序。

在不使用 TUN、改由系統直接查詢本機 DNS 的方案中，系統通常只接受標準 53 連接埠，此時需要讓 DNS 服務監聽 127.0.0.1:53，並確認連接埠權限與衝突狀況。此方案涉及平台網路設定，容易被網路切換、VPN 軟體或 DHCP 更新覆蓋；對桌面版 Clash Meta 客戶端而言，TUN 搭配 DNS 劫持通常更容易維持一致。

精確設定 fake-ip-filter，避免區域網路與特殊協定故障

排除清單中的網域會略過 fake-ip 回應，改用真實位址。清單過短可能造成裝置探索、區域網路管理介面或時間同步異常；清單過寬則會讓大量網域提前解析為真實 IP，削弱以網域對應為基礎的處理效果。設定原則是從故障日誌擷取具體網域，優先加入最精確的後綴或完整網域，不要直接整體排除大型頂級網域。

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.asus.com"
    - "time.windows.com"
    - "time.apple.com"
    - "stun.*"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

*.lan和*.local主要用於家庭區域網路與本機探索；時間伺服器回傳真實位址，有助於部分只接受直接 UDP 通訊的系統服務；網路連線檢測網域則可能影響系統對「是否連線」的判斷。實際加入前，應觀察客戶端日誌中的查詢網域，不同系統版本使用的檢測網域不一定完全相同。

區域網路網域應交給哪台 DNS

如果公司或家庭內部網域只能由路由器解析，可透過 nameserver-policy將指定後綴交給內網 DNS。例如路由器 DNS 為 192.168.1.1，內部網域為 home.arpa，可以只針對該後綴設定策略。使用前請確認該位址確實提供遞迴查詢，並避免在公共網路中繼續使用原本的區域網路位址。

dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.corp.example":
      - 10.20.0.53

內部 DNS 位址通常應按直連處理，否則查詢可能被送往代理節點後無法存取。如果客戶端支援設定合併，可以將區域網路專用策略放在只對特定網路啟用的本機覆寫中。筆記型電腦從公司網路切換到家庭網路後，應檢查 10.20.0.53這類私有網路位址是否仍被引用，避免每次查詢都等待逾時。

清除快取並驗證修復結果

修改 DNS 設定後，舊連線與多層快取不會立即消失。作業系統、瀏覽器、應用程式與 mihomo 核心都可能保留解析結果。驗證前應重新載入設定，停止再重新啟用 TUN，接著清除系統 DNS 快取。Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches；macOS 可執行 sudo dscacheutil -flushcache並重新啟動 mDNSResponder。瀏覽器應關閉所有視窗後重新開啟，或使用新的隱私視窗。

一組可比較的實測記錄

在 Windows 11 24H2、mihomo v1.19.10、家用寬頻與 IPv4/IPv6 雙堆疊環境中，基準擴充測試發起 20 個查詢，結果列出 2 個本地業者遞迴解析器。只啟用系統代理後，網頁出口變為代理節點，但 20 個查詢仍由同一組業者解析器完成。啟用 fake-ip、兩組 DoH nameserver、TUN 與 any:53劫持後，連續 3 輪測試都只顯示設定中的公共 DNS 網路，本地業者解析器不再出現在結果中。

這組數值用於說明前後對照方式，並不代表所有網路都應得到相同數量。公共 DNS 使用任播，檢測頁可能在不同輪次顯示 1 至 4 個邊緣節點；只要組織歸屬與設定目標一致、沒有混入本地解析鏈路，且網頁出口與規則預期一致，就可以認為修復有效。如果結果同時出現兩類解析器，應繼續檢查瀏覽器 DoH、IPv6 路由，或某個背景應用程式是否繞過系統 DNS。

測試階段 網頁出口 DNS 檢測結果 結論
退出 Clash 本地寬頻 2 個業者解析器 基準記錄
僅系統代理 代理節點 仍為 2 個業者解析器 DNS 未由系統代理接管
TUN 與 DNS 劫持 代理節點 公共 DoH 網路 解析路徑符合設定

命令列交叉驗證

除了瀏覽器檢測外，也可以直接向 mihomo 的 1053 連接埠查詢，確認內建 DNS 正在回應。Windows 安裝支援指定連接埠的工具後，可使用 dig @127.0.0.1 -p 1053 example.com；Linux 與 macOS 同樣可執行此命令。fake-ip 模式下，回傳 198.18.0.0/16範圍內的位址屬於預期現象。如果請求逾時，應先檢查監聽連接埠與核心日誌，而不是繼續調整規則組。

接著再執行系統預設查詢，例如 nslookup example.com。啟用 TUN 劫持時，即使命令顯示的伺服器名稱仍是路由器或系統設定位址，實際的 53 連接埠流量也可能已被核心捕獲。因此，最終判斷要結合 mihomo 日誌、檢測網站結果與前後對照，不能只看 nslookup第一行顯示的伺服器。

常見異常與對應修正

設定後所有網域都解析失敗

檢測正常，但部分應用程式無法登入

先從日誌中找出應用程式存取的網域，逐一加入 fake-ip-filter進行小範圍驗證。涉及 STUN、區域網路探索、NTP 或連線狀態檢測時，真實 IP 回應通常更合適。如果加入完整網域後恢復，再考慮是否需要擴大至相同業務後綴。不要一開始就排除所有網域，否則無法判斷究竟是哪類請求與 fake-ip 不相容。

IPv4 正常，IPv6 仍顯示本地網路

確認代理節點與所選 DNS 都支援預期的 IPv6 行為。如果目前代理鏈路不處理 IPv6，可暫時將 dns.ipv6設為false進行對照，觀察檢測頁是否停止回傳 AAAA 結果。同時檢查 TUN 是否涵蓋 IPv6 預設路由。長期方案應依節點能力決定是完整接管 IPv6，還是在系統與 DNS 兩端一致停用相關路徑，避免只修改其中一個開關。

訂閱更新後設定恢復原狀

訂閱檔案由遠端產生，重新整理時會取代本地快取。應在客戶端的覆寫、合併設定或腳本擴充功能中儲存 DNS 與 TUN 設定。操作路徑通常位於「訂閱」→目前設定右側選單→「覆寫設定」；完成後執行「訂閱」→「更新」，再開啟設定預覽，確認 enhanced-mode、nameserver和dns-hijack仍然存在。

下載 Clash 客戶端 查看 Windows、macOS、Android、iOS 與 Linux