Clash DNS 洩漏檢測與防護：fake-ip、nameserver-policy 設定教學

先分辨 DNS 洩漏與解析器位置差異

Clash 已啟用代理，但 DNS 檢測網站卻顯示台灣本地電信業者，通常代表仍有 DNS 查詢透過本機網路送出。不過，檢測結果出現多個國家或多個解析器，也不一定就是洩漏。先釐清需求：哪些網域可以在本地解析，哪些必須透過代理解析，再逐項檢查。

本文設定適用於 Clash Meta（mihomo）核心。舊版 Clash、部分行動裝置用戶端及其他代理工具支援的欄位可能不同。修改前，請先在用戶端的核心資訊或執行記錄中確認核心名稱，並備份目前的設定。請勿只根據用戶端名稱判斷是否支援 respect-rules 或下方的 TUN 參數。

檢測結果	可能代表的情況	下一步
網頁出口 IP 位於代理節點所在地	網頁連線經過代理，但 DNS 路徑尚未確認	繼續進行 DNS 延伸測試
解析器顯示台灣本地電信業者	系統、瀏覽器或核心可能直接向上游解析器查詢	比對記錄並擷取 53 埠封包
解析器顯示公共 DNS 服務商	查詢已送達公共遞迴解析器	確認連線至該解析器的出站路徑
同時出現預期中的台灣與海外解析器	可能是刻意設定的分網域解析	依照策略判斷，不要只看數量

建立基準：固定節點、瀏覽器與檢測條件

記錄以下三種條件的結果

關閉代理：記錄公網出口、電信業者名稱及 DNS 檢測結果，作為本地網路的基準。
只啟用系統代理：固定使用同一個節點、關閉 TUN，再執行標準測試與延伸測試。系統代理主要涵蓋遵循代理設定的應用程式，不會自動接管系統的所有 DNS 查詢。
啟用 TUN：維持節點、規則與瀏覽器設定不變，啟用 DNS 劫持後再測試。記錄解析器位址、時間，以及是否出現台灣本地電信業者。

可使用 DNS leak test 或 BrowserLeaks 的 DNS 檢測頁面。每次都要重新執行測試，別把頁面保留的上次結果當成新結果。連續測試兩輪；若只在其中一輪出現異常，先檢查瀏覽器快取、節點是否切換，以及設定是否已重新載入。

暫時停用瀏覽器自訂 DNS

桌面版 Chrome 通常可在「設定」→「隱私權和安全性」→「安全性」→「使用安全 DNS」中找到相關選項；Firefox 通常位於「設定」→「隱私權與安全性」→「基於 HTTPS 的 DNS」。測試期間請先停用瀏覽器自訂的 DoH，選項名稱可能隨版本變動。修復後若要重新啟用，請另外確認 DoH 連線的出站路徑。

無痕視窗不會自動停用安全 DNS。瀏覽器透過 HTTPS 連線至自訂解析器時，流量通常使用 443 埠；即使 TUN 已接管這條連線，dns-hijack 的 53 埠規則也不會將它轉成核心 DNS 查詢。

Windows 可使用 ipconfig /flushdns 清除系統 DNS 快取。
使用 systemd-resolved 的 Linux 系統可執行 resolvectl flush-caches；其他發行版請依實際使用的解析服務處理。
同時清除或重新啟動用戶端的 DNS 快取，並關閉檢測頁面後重新開啟。只清除系統快取，無法清除所有應用程式的快取。

fake-ip 的用途：保留網域對應，不會自動隱藏查詢

enhanced-mode: fake-ip 會為符合條件的網域回傳合成位址，常見的位址範圍為 198.18.0.1/16。應用程式連線至此位址時，mihomo 會依據對應關係還原網域，再套用規則並處理出站。因此，在本機看到以 198.18 開頭的解析結果通常是預期行為，不代表遠端伺服器真的位於該網段。

fake-ip 改變的是回傳給應用程式的解析結果。後續是否需要真實解析、由哪個解析器處理，以及查詢要直連還是透過代理，仍取決於連線方式、出站協定與 DNS 設定。只啟用 fake-ip，無法保證所有上游查詢都經過代理。

過濾清單只用來處理相容性例外

探索區域網路裝置、使用印表機，以及部分依賴真實位址的程式，可能需要加入 fake-ip-filter。例如 +.lan、+.local 可作為檢查區域網路網域的起點，但仍需有能解析這些名稱的本地 DNS 服務。將名稱加入過濾清單不會自動啟用 mDNS，也不會自動找到路由器。

不要為了解決單一應用程式的問題，就把所有網域都加入過濾清單。先確認出問題的網域，再新增範圍最小的例外，並重新測試該網域的解析路徑。回傳真實 IP 和發生 DNS 洩漏是兩回事。

設定範例：分網域解析與上游出站

以下提供 mihomo dns 與 tun 設定範例供參考，並非完整訂閱設定。請保留原設定中的節點、策略群組與規則；合併已有的同名欄位，勿在 YAML 最上層重複新增兩個 dns。建議透過用戶端的本機覆寫或合併設定儲存，避免訂閱更新時覆蓋修改。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '+.lan'
    - '+.local'
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    '+.cn':
      - https://dns.alidns.com/dns-query

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

欄位	範例中的用途
`default-nameserver`	解析 DNS 服務端網域，並非所有一般網域的預設上游
`proxy-server-nameserver`	單獨解析代理節點網域，降低建立代理前的解析依賴循環
`nameserver`	處理未符合解析策略的一般網域查詢
`nameserver-policy`	依查詢網域選擇解析器，不負責指定網頁連線使用的代理節點
`respect-rules`	讓 DNS 上游連線遵循路由規則，仍須確認實際使用的出站

還需要確認哪些設定？

上游出站：若要讓一般網域透過代理解析，請確認連線至 1.1.1.1:443 時使用預期的代理群組，而不是 DIRECT。若走了直連，請調整現有規則的順序與目標；不能只依賴 respect-rules: true 這一行設定。
台灣本地解析：+.cn 只會比對相應的網域範圍，不代表「所有中國大陸網站」。中國大陸的服務也可能使用 .com，海外服務也可能使用 .cn。必要時請依實際網域補上精確的解析策略。
引導查詢：範例保留可從本地連線的引導解析器與節點網域解析器，這些查詢可能會直接送出。若要求包括節點網域在內的所有解析都不經本地網路，必須另外規劃可用的引導路徑，不能直接照搬這段設定。
DoH 連線能力：HTTPS 加密可保護傳輸內容，但不代表連線經過代理。若目前網路無法直接連線至相應解析器，請先處理路由問題或改用可連線的上游解析器。

TUN DNS 劫持：涵蓋 53 埠，不涵蓋所有解析協定

範例同時列出 UDP 與 TCP 的 53 埠劫持設定。前提是相關封包確實進入 TUN；若被其他 VPN、靜態路由或應用程式綁定的介面繞過，這些規則就不會生效。auto-route 用於自動設定路由，auto-detect-interface 用於辨識出站介面；兩者都應搭配系統權限與實際路由表一併檢查。

別混淆監聽埠與劫持目標

listen: 127.0.0.1:1053 表示核心提供本機 DNS 監聽位址；dns-hijack 則會將進入 TUN 的指定 DNS 查詢交由核心處理。啟用 TUN 劫持後，不必因此將系統 DNS 設為「127.0.0.1:1053」；多數系統的 DNS 設定介面也不支援這種包含埠號的格式。

只監聽迴路位址可限制外部裝置存取。若要為區域網路裝置提供 DNS，請另外規劃監聽位址、防火牆與閘道；不要為了修復本機洩漏，就直接開放所有介面。

DNS over TLS：通常使用 TCP 853 埠，不會符合上述兩條 53 埠規則。
DNS over HTTPS：通常使用 HTTPS 443 埠，應比照一般網路連線檢查出站路徑。
Android 私人 DNS：排查時可先在系統的「私人 DNS」設定中停用自訂服務供應商，再測試用戶端 DNS。
IPv6：dns.ipv6: false 用於控制核心如何處理 AAAA 查詢，不會關閉系統 IPv6，也不會自動接管既有的 IPv6 連線。

重新測試與定位：從本機入口追查上游連線

先確認設定是否確實生效

儲存覆寫設定並重新載入，檢查記錄中是否有未知欄位、YAML 縮排錯誤或埠號繫結錯誤。
確認 TUN 介面與相關服務已啟動。Windows 通常需要用戶端服務或相應權限；只在介面開啟選項，不代表路由已建立。
暫時提高記錄詳細程度，觀察測試期間的網域、規則與出站記錄。排查完成後，請恢復平常使用的記錄層級。
清除快取後使用相同節點重新測試，並將新結果與最初的基準比對。

已安裝 dig 的裝置可直接查詢核心監聽埠，先確認 DNS 模組能正常回應：

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

fake-ip 模式下，A 查詢可能會回傳合成位址；依範例停用 DNS IPv6 時，AAAA 查詢可能不會取得位址回應。這組指令會直接連線至核心，只能確認監聽入口正常，無法驗證系統查詢是否已由 TUN 接管。仍須使用一般應用程式發起連線並觀察路由。

透過封包擷取檢查仍存在的旁路

請在實際的實體網路介面擷取封包，不要只查看 TUN 虛擬介面。Wireshark 可使用以下顯示篩選器；其中 853 埠可用來協助找出常見的加密 DNS 連線，但無法涵蓋所有加密解析方式。

udp.port == 53 || tcp.port == 53 || tcp.port == 853

若仍看到本機向電信業者 DNS 傳送一般網域查詢，請檢查系統解析服務、瀏覽器、其他 VPN 與 TUN 排除路由。若只看到引導解析器或節點網域查詢，請依前述設定範圍判斷是否符合預期。DoH 使用 443 埠，不能只因這項篩選器沒有結果，就認定所有問題都已修復。

常見問題與驗收標準

啟用 fake-ip 後，檢測網站仍顯示電信業者，該怎麼辦？

先確認測試查詢是否進入核心。若已進入，請檢查上游 DNS 連線的出站路徑及現有的 fallback；若未進入，優先檢查瀏覽器自訂 DNS、系統私人 DNS 與 TUN 路由。反覆更換 fake-ip 位址範圍，通常無法解決這類路徑問題。

nameserver-policy 會讓對應網站自動直連嗎？

不會。它會決定網域交由哪個解析器處理；網站連線的出站方式仍由 rules、模式與策略群組選項決定。請分別驗證「解析服務連線的出站路徑」與「目標網站連線的出站路徑」，不要把兩者混為一談。

更換網路後為什麼又出現異常？

Wi-Fi 與有線網路切換會改變閘道、介面與系統 DNS；從休眠狀態恢復後，也可能殘留舊路由。請重新檢查 TUN 服務、預設介面與本機 DNS 監聽，再清除快取並重新測試。若關閉用戶端後系統無法解析，請先還原系統 DNS 與路由，確認基本網路連線正常後再載入設定。

怎樣才算修復完成？

需要透過代理解析的測試網域，其上游連線必須使用預期的代理出站。
一般應用程式的 53 埠查詢已進入核心，實體網路介面上沒有出現不符合策略的明文 DNS 查詢。
瀏覽器 DoH、系統私人 DNS 與 IPv6 路徑都已分別檢查，而非只停用其中一項。
訂閱更新、用戶端重新啟動與網路切換後再次測試，覆寫設定與路由仍然有效。

DNS 防護的關鍵，是讓解析路徑清楚可查、能重複驗證。fake-ip 負責建立網域對應，nameserver-policy 選擇解析器，TUN 劫持統一查詢入口；最後還要透過路由規則決定上游連線從哪裡送出。四個環節都設定正確，檢測結果才有明確意義。