Clash DNS 洩漏怎麼查：檢測方法與 fake-ip、nameserver 防洩漏設定實作

先判斷問題是否為 DNS 洩漏

DNS 洩漏通常是指網域查詢沒有進入預期的 Clash 或 mihomo DNS 處理鏈，而是直接由作業系統、路由器、瀏覽器內建的安全 DNS，或網路業者提供的解析器處理。即使網頁流量已經經過代理，網域查詢仍可能從本地網路獨立送出。外部觀察者因此可能看見查詢目標，使用者也可能遇到錯誤解析、污染結果、規則命中異常，或同一網站在不同程式中的表現不一致。

看到本地網路業者的 DNS 伺服器，不一定代表設定失效。請先確認預期行為：如果設定中的 nameserver 原本就是本地公共 DNS，檢測頁顯示對應服務商屬於正常結果；如果預期使用指定的 DoH、DoT 或遠端解析器，但檢測頁反覆出現路由器位址、寬頻業者解析器或公司網路 DNS，才需要繼續排查。

常見症狀

• 瀏覽器可以正常存取，但終端機中的 curl、軟體更新程式或遊戲平台無法連線到同一網域。
• 切換代理節點後，DNS 檢測結果始終顯示本地寬頻業者的解析器。
• 規則使用網域比對，但日誌中只出現 IP，導致 DOMAIN-SUFFIX 規則沒有按照預期運作。
• 啟用 TUN 後，部分網站顯示錯誤地區的內容；關閉 TUN 後又恢復正常。
• 同一網域在瀏覽器、nslookup 和 Clash 日誌中得到不同位址。
• 設定使用 fake-ip，但系統查詢直接回傳公網 IP，而不是 198.18.0.0/16 範圍內的位址。

先記錄基準，不要立即修改設定

1. 記錄目前使用的客戶端、核心版本，以及正在使用的設定檔名稱。
2. 確認執行模式為規則、全域還是直連，並記錄 TUN 與系統代理的啟用狀態。
3. 清除瀏覽器和系統的 DNS 快取，再重複測試兩次。
4. 分別測試瀏覽器、命令列和一個獨立應用程式，避免把單一程式的行為當成整個系統的結論。
5. 查看 Clash 日誌中是否出現 DNS 請求、規則比對和連線目標。

只啟用系統代理時，作業系統的一般 DNS 查詢不一定會被接管。HTTP 或 SOCKS 代理負責的是應用程式連線，系統解析器仍可能向網卡設定的 DNS 伺服器傳送 UDP 53 請求。TUN 模式搭配 DNS 劫持可以涵蓋更多應用程式，但前提是 TUN、路由、DNS 監聽位址和劫持規則都確實生效。

使用瀏覽器檢測頁與命令列交叉驗證

瀏覽器檢測頁的正確用法

開啟常見的 DNS leak test 頁面後，先執行標準測試，再執行擴充測試。測試前關閉其他代理擴充功能，只保留一個瀏覽器視窗，並重新整理檢測頁。結果通常會列出解析器的 IP、網路組織和地區。請將這些資訊與設定中的 DoH、DoT 或一般 DNS 服務商互相比對，而不是只看地區是否與代理節點一致。

瀏覽器可能啟用自己的安全 DNS。Chrome、Edge 和 Firefox 都能繞過作業系統解析器，直接向瀏覽器指定的 DoH 服務傳送請求。因此，瀏覽器檢測頁只能說明該瀏覽器當下的路徑，不能單獨證明整個系統都由 Clash 接管。

• Chromium 系瀏覽器請檢查「設定」→「隱私權和安全性」→「安全性」→「使用安全 DNS」。
• Firefox 請檢查「設定」→「隱私權與安全性」→「DNS over HTTPS」。
• 測試 Clash DNS 接管時，可以暫時關閉瀏覽器安全 DNS；完成驗證後，再依實際方案決定是否重新啟用。
• 如果保留瀏覽器 DoH，就必須將它視為獨立的解析路徑，不能再用它來驗證 Clash 的 dns 區段。

直接查詢 Clash DNS 監聽連接埠

假設設定中寫有 listen: 127.0.0.1:1053，在 Windows、macOS 或 Linux 安裝 dig 後，即可直接向該連接埠查詢：

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

在 fake-ip 模式下，A 記錄通常會回傳 198.18.0.0/16 中的保留位址，例如 198.18.0.23。這個結果不是目標網站的真實位址，而是核心建立網域對應時使用的虛擬位址。後續連線命中該位址時，核心會還原原始網域，再依規則選擇代理策略。

如果設定使用 enhanced-mode: redir-host，通常會回傳真實公網 IP。此時不能用是否出現 198.18.x.x 來判斷是否洩漏，必須結合日誌、封包擷取和上游解析器結果確認路徑。

檢查系統目前使用的 DNS

Windows PowerShell 可以查看各網卡的 DNS 位址：

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

如果結果仍是路由器位址，例如 192.168.1.1，在只使用系統代理時相當常見。啟用 TUN 後是否需要改成迴圈位址，取決於客戶端實作；不少 mihomo 圖形化客戶端會透過 DNS 劫持接管 UDP 53，而不是永久修改網卡 DNS。不了解客戶端行為時，不要手動把所有網卡改成 127.0.0.1，否則核心退出後可能導致整個系統無法解析網域。

Linux 使用 systemd-resolved 時，可以執行：

resolvectl status
resolvectl query example.com

macOS 可以查看系統解析器順序：

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

透過封包擷取確認是否有直連 53 連接埠

檢測結果仍不明確時，可以在測試期間擷取 DNS 流量。在 Linux 上使用以下命令觀察傳統 UDP、TCP DNS：

sudo tcpdump -ni any 'port 53'

Windows 可使用系統內建的 pktmon，也可以在網路分析工具中設定 dns 或 udp.port == 53 篩選條件。執行測試查詢後，如果看到實體網卡直接向路由器或網路業者 DNS 傳送封包，表示仍有傳統 DNS 繞過預期鏈路。DoH 使用 443 連接埠、DoT 使用 853 連接埠，單獨篩選 53 無法發現它們，必須結合目標 IP、程序和 Clash 日誌判斷。

理解 fake-ip、redir-host 與 DNS 劫持

fake-ip 的處理流程

1. 應用程式向系統要求解析網域。
2. 查詢會傳送至 Clash DNS 監聽器，或被 TUN 的 DNS 劫持規則攔截。
3. 核心會回傳 198.18.0.0/16 範圍內的虛擬位址，並儲存虛擬位址與網域之間的對應。
4. 應用程式連線到該虛擬位址，TUN 或透明代理層會攔截連線。
5. 核心還原原始網域，執行網域規則，再依策略群組建立真實連線。

這種方式可以減少本地提前解析造成的規則資訊遺失，也方便依網域執行分流。這不代表上游 DNS 不再存在。核心仍可能需要解析代理伺服器網域、直連目標或某些排除的網域，因此 default-nameserver、nameserver、proxy-server-nameserver 和規則行為仍需正確設定。

redir-host 的適用範圍

redir-host 會向應用程式回傳真實 IP，相容性通常較直觀，但網域與連線之間的關聯可能更依賴嗅探、快取和對應。使用大量網域規則、TUN 接管和複雜分流時，mihomo 通常更適合採用 fake-ip。遇到區域網路裝置探索、印表機、遊戲登入、企業內網，或依賴真實 DNS 結果的應用程式時，可以先將特定網域加入 fake-ip-filter，而不是直接關閉整個 fake-ip 模式。

fake-ip-filter 應該放入哪些內容

過濾清單中的網域會跳過虛擬位址處理。應以實際故障為依據，避免使用涵蓋範圍過大的萬用字元規則。常見的起點如下：

fake-ip-filter:
  - "*.lan"
  - "*.local"
  - "localhost"
  - "time.*.com"
  - "time.*.gov"
  - "ntp.*.com"
  - "+.stun.*.*"
  - "+.stun.*.*.*"

*.local 常用於 mDNS 和區域網路服務探索，NTP、STUN 等協定也可能依賴特殊解析或直接位址行為。不同 mihomo 版本和客戶端內建範本可能已經包含一組預設過濾項目。合併訂閱設定時，請先查看最終生效設定，避免自訂清單覆蓋客戶端提供的相容規則。

DNS 劫持不等於惡意竄改

在 TUN 設定中，dns-hijack 表示將指定目標的 DNS 請求重新導向至核心處理。例如 any:53 用於接管傳送至任意位址 53 連接埠的請求。它解決的是應用程式繞過系統 DNS、直接查詢固定伺服器的問題。瀏覽器 DoH 走 HTTPS，目標連接埠為 443，不會被 any:53 攔截。

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

不同核心版本在欄位格式和協定支援上可能存在差異。修改前，請在客戶端的「設定」→「核心」或「關於」中確認實際使用的是 mihomo，並透過設定驗證功能檢查語法。只編輯訂閱原始檔通常不夠，訂閱更新可能會覆蓋修改內容，優先使用客戶端提供的覆寫、合併或 Mixin 功能。

可作為起點的 mihomo DNS 設定

以下設定適合用來理解各欄位之間的關係。監聽連接埠設為 1053，避免直接與系統現有的 53 連接埠服務衝突。實際接管方式由客戶端的 TUN 和 DNS 劫持設定決定。

dns:
  enable: true
  listen: 127.0.0.1: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:
    - tls://1.1.1.1:853
    - https://1.1.1.1/dns-query

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

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "time.*.gov"
    - "ntp.*.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

default-nameserver：解析上游伺服器本身的網域

default-nameserver 用於解析 DoH、DoT 上游伺服器或其他基礎連線所需的網域，通常填寫可直接存取的 IP 格式 DNS。它不是所有業務網域的唯一解析器。如果只填寫網域格式的 DoH 位址，卻沒有可用的引導解析器，可能會形成循環依賴：必須先解析 DoH 網域才能使用 DoH，但目前又沒有可用的伺服器來解析它。

nameserver：主要解析路徑

nameserver 是一般網域查詢的主要上游。範例使用 HTTPS DNS，可以加密裝置到解析器之間的查詢內容。兩個上游用於提高可用性，不代表查詢一定會按照清單順序逐一執行；具體的並行、快取和結果選擇取決於核心實作與版本。

一般 UDP DNS 也可以寫成 223.5.5.5，但查詢內容會以傳統 DNS 形式傳輸。DoT 使用類似 tls://1.1.1.1:853 的寫法，DoH 則使用完整的 HTTPS 位址。設定成功載入不代表網路一定允許存取對應連接埠，還要查看日誌中是否有逾時、TLS 交握失敗或憑證錯誤。

fallback 與 fallback-filter：依結果篩選備用解析

fallback 提供另一組解析器，fallback-filter 決定何時採用備用結果。範例中的 geoip: true 與 geoip-code: CN 會結合 IP 地理資料庫判斷結果；240.0.0.0/4 等特殊位址區段可作為異常結果的過濾條件。

這套機制依賴 GeoIP 資料的準確性。CDN 位址、Anycast 位址和新分配的網段可能被錯誤分類，因此不能把地區判斷視為絕對標準。如果某個網站只在啟用 fallback 後出現異常，請先查看兩組解析器各自回傳哪些位址，再調整網域策略或過濾條件。

ipv6：依網路條件明確啟用

範例使用 ipv6: false，適合本地沒有穩定 IPv6、代理節點不支援 IPv6，或希望先縮小排查範圍的情況。如果本地與代理鏈路都完整支援 IPv6，可以改為 true，同時檢查 TUN 路由、代理出口和 AAAA 查詢。只關閉 DNS 的 AAAA 回傳，並不能修復所有 IPv6 繞行問題；系統現有的 IPv6 連線和應用程式內建解析仍需另外檢查。

依序修復 DNS 繞過問題

第一步：確認最終生效設定

訂閱內容、客戶端覆寫和執行時設定可能共同產生最終設定。進入客戶端的「設定」→「目前設定」或「設定」→「查看執行設定」，確認 dns.enable、enhanced-mode、監聽位址與 TUN 設定確實存在。選單名稱會因客戶端而略有不同，但檢查對象必須是核心實際載入的設定，而不是訂閱下載目錄中的原始 YAML。

第二步：檢查連接埠是否正在監聽

Windows 可以執行：

Get-NetTCPConnection -LocalPort 1053 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue

macOS 或 Linux 可以執行：

lsof -nP -iTCP:1053 -iUDP:1053
ss -lntup | grep 1053

如果沒有監聽結果，請先查看核心日誌。常見原因包括 YAML 縮排錯誤、連接埠已被占用、客戶端未載入修改後的設定，以及安全軟體阻止核心繫結連接埠。如果改用其他連接埠，例如 1054，直接查詢命令和客戶端接管設定也要同步調整。

第三步：分別驗證直連查詢與系統查詢

1. 使用 dig @127.0.0.1 -p 1053 確認 Clash DNS 本身可以回應。
2. 使用未指定伺服器的 dig example.com 或 nslookup example.com 檢查系統預設路徑。
3. 分別在 TUN 啟用和停用的狀態下測試，並記錄回傳位址。
4. 開啟瀏覽器檢測頁，確認瀏覽器安全 DNS 是否影響結果。
5. 觀察核心日誌中是否出現測試網域，以及最終命中的規則和策略。

直接查詢 Clash 正常，但系統預設查詢仍經過路由器，表示問題位於接管層，而不是 nameserver 本身。此時應檢查 TUN 是否確實啟動、是否取得所需的系統權限、DNS 劫持是否存在，以及目前網卡是否被排除。如果直接查詢也逾時，則先修復 DNS 監聽器或上游連線。

第四步：清除快取後重新測試

Windows 清除系統 DNS 快取：

ipconfig /flushdns

macOS 可以執行：

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux 的快取機制取決於發行版。使用 systemd-resolved 時可以執行：

sudo resolvectl flush-caches

接著完全退出並重新開啟瀏覽器。只重新整理網頁不會清除瀏覽器自己的主機快取和既有連線。對於長時間維持連線的聊天、遊戲平台和同步工具，也應退出程序後再重新啟動。

第五步：處理瀏覽器和應用程式內建的 DoH

如果命令列與系統查詢都已進入 Clash，但瀏覽器檢測仍顯示另一組解析器，請優先檢查瀏覽器安全 DNS。部分安全軟體、企業客戶端和行動應用程式也會內建 DoH。它們的 HTTPS 請求可能像一般網頁流量一樣經過 Clash，也可能依規則設定直連，但無論哪種情況，都不會進入 Clash 的本地 DNS 模組。

處理方式有兩種：關閉應用程式內建的 DoH，讓系統統一交由 Clash 處理；或保留應用程式 DoH，並為它明確設定路由規則。前者便於集中控制和故障排查，後者適合需要應用程式採用獨立解析策略的情境。不要同時維護多組未知上游，否則檢測結果會隨應用程式和網域而變化。

常見錯誤設定與修正方式

只填寫 nameserver，卻沒有啟用 DNS

dns:
  enable: false
  nameserver:
    - https://dns.alidns.com/dns-query

enable: false 時，後續的上游設定不會建立預期的本地 DNS 服務。請改為 true，再檢查監聽連接埠和接管方式。

將監聽位址暴露在區域網路中

listen: 0.0.0.0:1053 會在所有介面上監聽。只有需要讓區域網路裝置將這台機器當作 DNS 伺服器時，才考慮這種寫法，並搭配防火牆限制來源。單機使用時，建議優先繫結 127.0.0.1:1053，減少不必要的區域網路存取面。

把 fake-ip 回傳值誤認為污染結果

198.18.x.x 是 fake-ip 正常的虛擬位址範圍。看到該位址後，應繼續測試應用程式連線和規則命中，不要將它寫入 hosts 或直接加入直連規則。如果某個應用程式確實不相容，請將對應網域精確加入 fake-ip-filter。

讓多個程式同時占用 53 連接埠

本地廣告過濾器、虛擬機軟體、容器服務和其他代理工具都可能監聽 53 連接埠。兩個程式無法在相同位址和協定上穩定占用同一連接埠。可以讓 Clash 監聽 1053，再由前置 DNS 轉發給它；也可以停用衝突服務，改由 Clash 統一接管。變更後需同時檢查 UDP 與 TCP 的監聽狀態。

誤以為系統代理等於全域 DNS 接管

系統代理主要影響支援 HTTP 代理設定的應用程式。DNS、遊戲流量、命令列工具和不讀取系統代理的程式可能繼續直連。需要更完整的接管時，請使用 TUN，並確認自動路由、網卡偵測、DNS 劫持和系統權限全部生效。TUN 也不是簡單的「更強代理」開關，它會改變網路堆疊路徑，排查時應一次只修改一個選項。

修復後的驗收清單

• 核心日誌中沒有 DNS 上游逾時、監聽失敗或設定欄位錯誤。
• dig @127.0.0.1 -p 1053 能在正常延遲內回傳結果。
• 在 fake-ip 模式下，測試網域回傳 198.18.0.0/16 範圍內的位址。
• 啟用 TUN 後，系統預設查詢能在 Clash 日誌中找到對應網域。
• 在實體網卡擷取封包時，不再出現非預期的直連 UDP 或 TCP 53 查詢。
• 瀏覽器安全 DNS 的啟用狀態與目前方案一致，不再形成未知的獨立路徑。
• DNS 檢測頁顯示的解析服務與 nameserver、fallback 的設計相符。
• 區域網路、NTP、STUN 或企業內網網域若不相容，已使用精確的 fake-ip-filter 規則處理。
• 訂閱更新後仍能保留覆寫內容，重新啟動客戶端與裝置後結果不變。

DNS 洩漏排查的核心是拆分鏈路：先確認 Clash DNS 是否能回應，再確認作業系統查詢是否進入核心，最後檢查瀏覽器和應用程式是否存在獨立 DoH。檢測頁、命令列、日誌和封包擷取必須相互印證。只更換一個 nameserver 位址通常無法解決接管層問題，只有監聽、劫持、上游和應用程式行為同時一致，解析路徑才算穩定。