Clash DNS 洩漏測試與修復：fake-ip、nameserver-policy 防漏設定教學

先釐清 DNS 洩漏與解析器地區差異

網頁流量經過代理，不代表 DNS 查詢也經過代理。系統代理通常只影響遵循代理設定的應用程式；系統 DNS 解析、瀏覽器安全 DNS，以及其他程式內建的 DoH，都可能使用不同的連線出口。修復前要分別確認「由誰發起查詢」、「使用哪個解析器」，以及「連往解析器的流量採用哪種路由策略」；只切換成 fake-ip 並不足以解決問題。

本文設定以 mihomo 核心為例。舊版 Clash 與不同用戶端封裝支援的欄位可能不盡相同。請先查看用戶端的核心資訊或啟動記錄，確認核心名稱；若設定檢查指出欄位不明，請參照目前使用的核心文件處理，不要假設名稱相同的開關功能也相同。

• DNS 洩漏：原本預期透過代理送出的網域查詢，卻經由本機網路送給電信業者或其他非預期的解析器。
• 解析器位置不同：測試網站顯示的國家通常是根據解析器出口 IP 的資料庫判定，並不等於代理節點的實際位置。
• 刻意直連：區域網路名稱、直連網站或代理伺服器網域可能會採用直連解析。是否接受這類查詢，應先釐清自己的分流需求。

建立測試基準：分別檢查瀏覽器、系統與核心

使用相同條件比較前後兩次結果

1. 先暫停其他 VPN 與代理工具，固定使用同一個代理節點，並記錄系統代理、TUN 及瀏覽器安全 DNS 目前的設定狀態。
2. 開啟 DNSLeakTest，執行 Extended test。記下頁面列出的解析器 IP、所屬組織與地區。
3. 如果可以接受一次直連測試，請關閉代理後再測一次，作為本機網路的基準。重新開啟代理後再測；不要把舊分頁顯示的結果當成最新測試。
4. 若開啟代理後仍看到基準測試中的電信業者解析器，請繼續排查。即使只顯示預期的公用解析器，也要確認連線究竟是直連還是經過代理。

測試網站主要顯示遞迴解析器連線至其權威 DNS 時的出口，無法單憑結果證明「電腦連往遞迴解析器」的傳輸路徑。共用解析服務、Anycast 與快取都會影響結果。因此，請搭配用戶端連線記錄判讀，不能只根據顯示的國家名稱下結論。

暫時統一瀏覽器的 DNS 路徑

以桌面版 Chrome 為例，前往「設定」→「隱私權和安全性」→「安全性」→「使用安全 DNS」。若要先檢查系統至 mihomo 的連線路徑，可暫時關閉此選項，測試後再決定是否重新開啟。受機構政策管理的瀏覽器可能無法變更此設定。

瀏覽器內建的 DoH 使用 HTTPS，通常不會產生 UDP 53 流量。在 TUN 模式下，這類流量仍可能經由代理傳送，但設定 dns-hijack 不會自動讓瀏覽器改用 mihomo 的 DNS 模組。Android 的「私人 DNS」也應分開記錄，避免混淆不同解析路徑的測試結果。

確認核心 DNS 是否確實收到查詢

以下範例會讓核心 DNS 在本機 1053 連接埠監聽。已安裝 dig 的 macOS 或 Linux 使用者可直接指定此連接埠測試：

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

Windows 使用者可在 PowerShell 執行下列命令，檢查系統預設的解析路徑；這不等於直接查詢本機 1053 連接埠。啟用 TUN 後，也應確認核心 DNS 記錄是否收到這次請求。

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

fake-ip、nameserver 與引導解析各自負責什麼

fake-ip 通常會向應用程式回傳對應的虛擬位址，再由核心將後續連線對應至原始網域。範例中的 198.18.0.1/16 屬於基準測試專用的位址範圍，並非實際網站的公網位址。查到這類位址不代表網站解析異常，也無法證明上游查詢已受到代理保護。

fake-ip-filter 用來決定哪些網域不會回傳 Fake-IP。部分區域網路服務需要取得真實位址，可視需求加入例外；不要只為了解決單一相容性問題，就把所有網域都加入過濾清單。過濾設定只會影響回傳位址的處理方式，不能取代上游路由設定。

設定上游 DNS：明確指定代理策略

以下是用來說明解析路徑的 mihomo 設定片段，並非完整設定檔。範例假設現有設定已定義名為 Proxy 的策略群組，且群組內有可用節點。一般查詢及 example.com 測試網域的查詢會送往代理上游，同時保留明確的直連引導路徑。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#Proxy"
  nameserver-policy:
    "+.example.com":
      - "https://8.8.8.8/dns-query#Proxy"

• #Proxy 會為此 DNS 上游指定既有的出口策略。策略群組名稱必須完全相符，包括大小寫；加上引號可確保整個位址都以 YAML 字串讀取。
• +.example.com 會比對此網域及其子網域。這只是可重現的測試項目，並非實際服務網域清單；正式使用前，請依需求替換或移除。
• 範例中的 default-nameserver 是直連的引導解析器，proxy-server-nameserver 也刻意保留直連解析路徑。若節點伺服器使用網域名稱，透過後者查詢時，節點網域會透露給該解析器。
• 範例使用 IP 格式的 DoH 端點，可減少對解析上游主機名稱的依賴，但仍須確保網路連線正常、憑證驗證通過，且代理節點支援相應連線。

現有設定使用 respect-rules 時的處理方式

mihomo 的 respect-rules: true 可讓 DNS 連線遵循路由規則，但「遵循規則」不代表「一定經過代理」：若規則將解析器目標配對至 DIRECT，連線仍會直連。採用此設定時，請設定合適的 proxy-server-nameserver，並檢查路由規則實際如何比對上游解析器位址。

請先選擇一種容易驗證的上游路由方式，再逐步整合。不要一次新增多組 fallback、多條策略及多層規則後才開始測試，否則很難找出是哪次修改改變了查詢出口。也不要只在檔案末尾再新增一個 dns:；應編輯現有的設定區塊，避免重複鍵值導致設定遭覆寫或載入失敗。

透過 TUN 接管系統 DNS：補上 53 連接埠入口

只啟用系統代理時，未使用代理設定的程式仍可能直接呼叫系統 DNS。TUN 可接管更多 IP 流量，再搭配 DNS 劫持，將傳統 DNS 請求送進核心。以下設定片段適用於支援相應 TUN 功能的 mihomo 環境；用戶端需要具備建立虛擬網卡及修改路由的權限。

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

any:53 對應 UDP DNS，tcp://any:53 則補上 TCP DNS。此處的劫持僅作用於進入 TUN 處理路徑的連線，不會強制變更整個區域網路的 DNS。部分系統對連往本機網段 DNS 的路由有特殊處理，仍須透過實際記錄確認請求是否進入核心。

• DoH 與 DoT：HTTPS DNS 通常使用 443 連接埠，DoT 通常使用 853 連接埠，不在上述 53 連接埠劫持範圍內。請檢查這些連線各自採用的出口策略。
• 多張網路介面卡：有線網路、Wi-Fi、虛擬機網路介面卡及其他 VPN 都可能改變預設出口。啟用 TUN 後若無法連線，請先確認自動偵測到的出口網路介面卡。
• IPv6：dns.ipv6 控制 DNS 的 AAAA 回應行為，不是系統 IPv6 的總開關。即使只測試 A 記錄，也不能因此認定 IPv6 流量已由 TUN 接管。
• 區域網路：NAS、印表機及企業內網名稱可能需要專用解析器。請為這些網域個別設定策略，並將預期的直連查詢納入測試記錄。

若不打算使用 TUN，且作業系統支援，也可將 DNS 指向核心的監聽位址；但一般的系統 DNS 設定通常無法指定自訂連接埠。範例監聽的是 1053，而非系統常用的 53；只填入 127.0.0.1 並不會自動連通。變更監聽連接埠時，也要考量所需權限及連接埠是否已被占用。

儲存、清除快取並重新測試：依序確認修復結果

先確認生效設定，再清除快取

管理訂閱的用戶端可能會在更新時重建設定。請使用用戶端支援的覆寫或合併機制保存 DNS 修改，並查看最後生效的設定，而不只是編輯下載後的暫存檔。命令列部署可先執行設定檢查；若執行檔名稱為 mihomo，命令如下：

mihomo -t -f config.yaml

檢查通過後再重新載入。檢查通過只代表核心能接受設定，不保證節點、解析器或網路連線正常。若使用圖形介面用戶端，重新載入後請查看啟動記錄，確認是否有 DNS 監聽失敗、權限不足或策略群組不存在等錯誤。

Windows 可先清除系統 DNS 快取，再重新查詢。瀏覽器可能仍保留自己的快取或既有連線，必要時請完全關閉瀏覽器，再重新開啟測試網站；行動裝置則可先中斷目前的網路連線，再重新連線並測試。

ipconfig /flushdns
Resolve-DnsName example.com -Type A

同時核對三項證據

1. 入口證據：發出系統查詢時，核心確實收到 DNS 請求；直接查詢 1053 連接埠與透過系統查詢，必須分開驗證。
2. 路由證據：確認連線記錄中，前往範例 DoH 端點 1.1.1.1:443 或 8.8.8.8:443 的連線使用預期的代理策略。必要時可暫時設定 log-level: debug 進行排查，完成後請恢復原本的記錄層級。
3. 外部證據：重新執行測試網站，確認解析器所屬組織符合預期，且沒有出現未計畫使用的本地電信業者解析器。顯示的地區不同，本身不代表測試失敗。

除錯記錄可能包含瀏覽過的網域、節點位址或其他網路資訊。分享記錄前，請刪除訂閱連結、驗證資訊及不宜公開的網域；不要將完整設定直接貼到公開討論區。

常見測試結果與後續檢查

最終驗收標準是解析路徑符合預定策略，而不是測試網站只顯示一個 IP。先確認哪些網域允許直連解析，再讓系統入口、核心上游與代理路由彼此對應，才能區分真正的洩漏、正常分流及解析器顯示差異。欄位說明請參閱 進階設定；基本啟用步驟請見 用戶端設定教學。

設定參考與核對資源

• mihomo 文件：DNS 設定，可核對上游解析、網域策略、Fake-IP 與代理伺服器解析相關欄位。
• mihomo 文件：TUN 入站，可核對 DNS 劫持、自動路由及不同系統的差異。
• DNSLeakTest 測試網站，可用來查看遞迴解析器的出口；請搭配核心記錄判讀結果。