Clash DNS 洩漏檢測與 fake-ip 防洩漏設定教學

如何判斷 DNS 洩漏

Clash 已顯示代理連線，DNS 檢測頁卻出現本地電信業者的解析器，這是常見的排查起點。不過，「偵測到多個 DNS 位址」不代表一定有洩漏。首先要釐清目標：只讓需要代理的網域透過代理解析，還是除了節點連線所需的引導解析外，所有公網網域查詢都必須經指定出口送出？兩種目標的合格結果並不相同。

本文將 DNS 洩漏定義為：網域查詢未依預定策略送出，而是經由系統、本地網路或其他未授權的解析器。檢測頁顯示的通常是接收測試網域查詢的遞迴解析器，不是電腦設定的 DNS 位址，也不是代理節點本身。因此，DNS 所在地區與網頁出口地區不同，只能當作線索，不能單憑這點下結論。

觀察結果	可能原因	下一步
出現本地電信業者的解析器	系統查詢未由代理接管，或規則明確允許直連解析	比對策略與 53 埠流量
出現公共 DNS 服務商	核心或瀏覽器使用了該服務	確認是否為預期的上游解析器與出口
解析器與節點不在同一個國家	公共 DNS 的任播、遞迴出口或地理資料庫判定差異	搭配連線記錄判斷路由
每次都出現多個位址	同一服務可能使用多個遞迴出口，也可能存在多條解析路徑	比較服務營運商，不要只看 IP 數量

先進行可重現的 DNS 洩漏測試

記錄環境，每次只變更一個項目

記下用戶端名稱、核心名稱與版本，以及目前使用系統代理還是 TUN。本文範例適用於 mihomo，不適合直接套用在已停止更新的舊版 Clash 核心。
先退出其他 VPN、網路加速器與代理工具，只保留一個用戶端執行，避免多張虛擬網卡與 DNS 設定互相覆蓋。
在瀏覽器中手動開啟 dnsleaktest.com，先執行 Standard test，再執行 Extended test。記錄解析器 IP、營運商、檢測時間與網頁出口位址，不要只截取國家欄位。
關閉代理進行一次基準測試，再啟用目標設定重測。基準測試會透過本地網路連線，若環境有嚴格的網路隔離要求，請勿執行。
修改設定後重新載入核心、清除系統快取並完全退出瀏覽器，再進行第二輪測試。使用相同節點、網路與檢測頁面，方便比較結果。

Windows 可在終端機執行 ipconfig /flushdns 清除系統 DNS 快取。這不會清除瀏覽器本身的解析快取，也不會重設 mihomo 核心的所有執行狀態。若檢測結果始終沒變，請先重新啟動瀏覽器與核心，再確認設定是否生效。

區分瀏覽器與系統的測試結果

瀏覽器的安全 DNS 可能直接透過 HTTPS 查詢，繞過系統的 53 埠解析流程。排查時可先到瀏覽器設定搜尋「安全 DNS」，暫時關閉後進行比對；確認核心接管正常後，再決定是否重新啟用，並為該 DoH 連線設定明確的代理規則。瀏覽器測試正常，也不能證明命令列工具、遊戲或其他應用程式使用相同路徑。

例如，可以將一次比對結果記錄為「系統代理：偵測到電信業者與公共 DNS；TUN：只偵測到已設定的公共 DNS」。這只是記錄格式，不代表實測結論。請保留自己的測試結果，並透過核心連線記錄確認變化來源。

啟用 fake-ip 並指定 DNS 上游

編輯前先備份目前可用的設定檔。訂閱內容通常會定期更新並覆蓋設定，請使用用戶端提供的覆寫或合併功能；若不確定如何合併，請複製一份獨立的本機設定檔進行驗證。最終生效的設定檔只能有一個頂層 dns:，不要在檔案末尾重複貼上同名區段。

以下是 mihomo 的 DNS 設定片段，請整合至已有節點、策略群組與規則的完整設定檔中。範例會將一般查詢送往 Cloudflare DoH，並將 qq.com 及其子網域交由中國大陸的 DoH 解析；這是明確的分網域策略，不代表「所有查詢都走代理」。

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
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.qq.com":
      - https://223.5.5.5/dns-query

listen: 127.0.0.1:1053 只會監聽本機，不會向區域網路開放解析服務。系統 DNS 設定通常不能填入 1053 這類自訂連接埠，因此還需要透過後續的 TUN 接管，或使用系統支援的本機轉發器。
198.18.0.1/16 是此處採用的虛擬位址池。應用程式取得這個範圍內的位址屬正常情況；如果網路中剛好也使用這個網段，請先處理位址衝突。
fake-ip-filter 中的網域會改以真實位址回應，主要用於相容區域網路探索等情境。它不是分流規則，也不代表這些查詢一定會直連。
proxy-server-nameserver 專門用來解析代理伺服器的網域，避免出現「連線節點需要 DNS，但 DNS 又在等節點連線」的循環依賴。若節點使用 IP 位址，可能不會觸發這類查詢。
default-nameserver 用於解析 DNS 伺服器網域等引導需求。若實際觸發此處的一般 DNS 查詢，本地網路可能會看到引導網域；不要誤以為所有業務查詢都會使用這個位址。

透過 nameserver-policy 與規則指定解析出口

nameserver-policy 用來指定「某個網域要交給哪個解析器」；respect-rules: true 則讓 DNS 上游連線遵循路由規則。兩者解決的問題不同。只把上游換成國外公共 DNS，並不能保證查詢會經由代理送出。

假設現有設定中已有名為 代理選擇 的可用策略群組，可以將以下兩條規則加入原有的 rules: 清單，並放在可能先行比對的規則之前。不要用這兩行取代整份規則清單；若策略群組不存在，也不要直接儲存。

rules:
  - IP-CIDR,1.1.1.1/32,代理選擇,no-resolve
  - IP-CIDR,223.5.5.5/32,DIRECT,no-resolve

第一條規則會讓範例中的 1.1.1.1:443 DNS 上游連線使用指定的代理群組；第二條則讓中國大陸的上游直連。no-resolve 可避免為了判斷這條 IP 規則而額外觸發網域解析。規則會依序比對；如果上方已有範圍更廣的直連規則，新增規則可能不會生效。

分別驗收全代理解析與中國大陸分流

中國大陸分流目標：保留範例中的 nameserver-policy，允許指定網域交由中國大陸的解析服務查詢。測試頁產生的隨機網域通常不符合這項策略，因此應走一般上游。
更嚴格的代理解析目標：移除這類中國大陸分網域例外，並檢查其他 DNS 上游、備用解析器與直連解析設定。節點網域的引導解析仍須另外規劃，不能只刪除一行就宣稱所有查詢都已封鎖。
企業或校園內網需求：內網網域可能必須交由本地 DNS 解析。請先詢問網路管理員，保留必要的分網域解析設定，不要將內網網域大量送往公共服務。

驗證時，在用戶端連線清單中搜尋 1.1.1.1，確認目標連接埠是否為 443，以及命中的策略是否為預期代理群組。不同用戶端呈現 DNS 內部連線的能力各異；若清單中沒有顯示，請搭配偵錯日誌與網路封包擷取確認，不要把「看不到」當成「沒有請求」。

透過 TUN 接管系統 DNS 並劫持 53 埠

系統代理主要影響遵循代理設定的應用程式，不會自動接管所有系統 DNS 查詢。若要涵蓋更多應用程式，可在支援 mihomo TUN 的用戶端中啟用虛擬網卡，並合併以下設定。啟用時可能需要管理員權限或安裝虛擬網卡服務。

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

此處的 any:53 與 tcp://any:53 分別用來接管經過 TUN 的一般 UDP DNS 與 TCP DNS。它們無法自動將任意應用程式的 HTTPS 解析改寫為核心 DNS，也無法接管未經虛擬網卡的連線。實際涵蓋範圍會受系統、路由表與用戶端權限影響。

本機驗證步驟

確認用戶端顯示 TUN 已啟動，且日誌中沒有權限不足、建立網卡失敗或新增路由失敗等訊息。
執行 nslookup example.com 127.0.0.1 前，請先確認本機確實有程式監聽 53 埠；本文使用的監聽埠是 1053，不能因為這個指令失敗就直接判定 DNS 故障。
如果系統已安裝 dig，請執行下方指令，直接測試核心的 1053 埠。若命中 fake-ip，通常會看到 198.18.0.0/16 範圍內的回應位址。
接著執行 nslookup example.com 8.8.8.8，檢查一般系統查詢是否已被接管。請搭配日誌確認；指令顯示的伺服器名稱本身並不能證明接管成功。
最後重新執行瀏覽器擴充功能的檢測，並實際測試常用應用程式的網路連線。

dig @127.0.0.1 -p 1053 example.com A
nslookup example.com 8.8.8.8

在 Windows 11 中，可前往「設定」→「網路和網際網路」→「Proxy」查看是否仍有其他工具設定的手動 Proxy。TUN 與系統代理可以依用戶端設計搭配使用，但排查期間應先採用單一、明確的接管方式，再逐一恢復其他功能。

IPv6、瀏覽器 DoH 與快取的其他風險

DNS 的 IPv6 選項不等於系統 IPv6 選項

範例中的 dns.ipv6: false 控制核心如何處理 AAAA 查詢，不會關閉作業系統的 IPv6，也不會自動阻止應用程式使用自己的解析結果建立 IPv6 連線。既有快取、應用程式內建的 DoH 或靜態位址仍可能走其他路徑。請分別驗證 IPv4 與 IPv6 的出口；若目前的用戶端無法完整接管 IPv6，可暫時關閉測試網卡的 IPv6 進行比對，確認原因後再決定長期方案。

53 埠以外的解析方式須另外處理

DoT 通常使用 TCP 853，DoH 通常使用 HTTPS 443，也可能透過 HTTP/3 使用 UDP 443。dns-hijack 中的 53 埠規則不會將這些加密連線轉換成一般 DNS。若瀏覽器或應用程式使用內建的安全 DNS，請改用系統解析，或為其解析服務連線設定符合需求的代理規則。

透過封包擷取確認是否仍有非預期的明文查詢

若有封包擷取工具，可在實體網卡上使用顯示篩選條件 udp.port == 53 || tcp.port == 53，觀察測試期間的流量，並依查詢網域、目標位址與時間比對日誌。TUN 網卡上的 DNS 封包可能只是接管前的內部流程；判斷是否外洩時，應著重檢查實體網卡是否將查詢送往非預期的外部 DNS。

擷取不到 53 埠資料，不代表沒有 DNS 流量，因為 DoH 與 DoT 已經加密。反之，節點引導、區域網路裝置或其他處理程序的查詢，也不能直接歸咎於正在測試的網頁。請依處理程序、網域與時間區分來源。

設定驗收與故障復原

可靠的驗收至少要確認三件事：解析器符合預期、DNS 上游連線使用正確出口，以及業務應用程式可正常連線。只看檢測頁「沒有本地位址」，無法確認內網網域是否失效、節點解析是否陷入循環，或其他應用程式是否繞過代理。

設定檔無法載入：檢查 YAML 縮排、重複的頂層欄位與未知選項；確認執行的核心是 mihomo，不要只憑用戶端介面判斷核心版本。
所有網域都逾時：先確認節點是否能連線、代理伺服器的網域是否能透過專用上游解析，再檢查 1.1.1.1:443 的代理路徑。故障時不要同時更換節點、DNS 與規則。
檢測正常但無法連線內網：確認內網網域是否需要本地解析，並檢查 fake-ip-filter 與分網域策略；不要只擴大過濾清單，卻不檢查實際使用的上游解析器。
訂閱更新後問題再現：比較更新前後實際生效的設定，確認 DNS、TUN 與規則覆寫仍然存在；不要只檢查編輯器中儲存的文字。
關閉用戶端後無法上網：檢查系統 DNS、手動 Proxy 與路由是否已還原；先關閉 TUN、退出用戶端，再依備份還原網路設定。

fake-ip 負責網域映射，nameserver-policy 負責選擇解析器，路由規則決定上游連線出口，TUN 則擴大系統接管範圍。分別驗證這四個層面，比反覆切換「防洩漏」選項更容易找到問題原因。若想了解基本分流與訂閱操作，可繼續閱讀Clash 設定教學；欄位說明請參閱完整文件。