Clash DNS 洩漏怎麼檢查？解讀測試結果與 fake-ip、nameserver-policy 防洩漏設定

一、先釐清 DNS 洩漏的判定標準

瀏覽器顯示代理出口 IP，不代表網域解析也走相同路徑。一次連線至少涉及兩種請求：解析網域的 DNS 請求，以及連接目標伺服器的實際流量。Clash 的系統代理、TUN 接管、核心 DNS 和瀏覽器安全 DNS 各自負責不同環節，排查時應分開檢視。

本文所說的「DNS 洩漏」，是指原本應交由指定解析器或代理路徑處理的查詢，實際上卻送往非預期的解析器。例如，設定讓境外網站的網域透過代理解析，測試結果卻持續出現本地寬頻業者的遞迴 DNS，這才是需要追查的異常。若設定原本就讓本地域名交由業者解析，出現相應結果並不意外。

先記下預期，再檢視測試結果：哪些網域可以在本地解析、哪些必須透過代理解析，以及瀏覽器是否允許自行使用 DoH。沒有先釐清這三點，光憑「偵測到幾個國家」無法判定是否洩漏。

測試頁實際能顯示哪些資訊

公共 DNS 通常採用 Anycast 與分散式遞迴叢集。用戶端連線的服務位址，可能與測試頁顯示的遞迴出口不同，國家／地區標示也可能延遲更新。因此，代理出口位於日本、DNS 結果標示為美國，不能單獨作為洩漏證據；應一併確認解析服務供應商、設定中的上游，以及實際連線記錄。

二、依固定步驟重新測試，區分系統與瀏覽器

先記下目前使用的核心名稱、用戶端版本、已啟用的設定、代理模式、系統代理狀態與 TUN 開關。以下設定以 mihomo 為例，舊版 Clash 核心不一定支援所有欄位。Clash Nyanpasu 不同版本的設定分類可能有所變動；若找不到選項，應檢查最終生效的設定，而非只看訂閱原始檔。

1. 建立基準：在允許直連測試的網路環境中，關閉系統代理與 TUN，執行一次 DNS 測試，記下網頁出口、解析器 IP 與服務供應商。若對查詢隱私有嚴格要求，可略過直連基準測試。
2. 只啟用系統代理：保持瀏覽器設定不變，再測試一次。系統代理主要涵蓋遵循代理設定的應用程式，不代表系統的 UDP 53 查詢也會被接管。
3. 啟用 TUN 與 DNS 劫持：確認核心成功啟動後，再執行一次測試。如果結果到這一步才改變，優先檢查先前未進入核心的 DNS 流量。
4. 暫時統一瀏覽器 DNS 設定：記下原本的設定後，暫時關閉瀏覽器安全 DNS，再測試一次。在 Chrome 中可前往「設定」→「隱私權和安全性」→「安全性」，尋找「使用安全 DNS」；組織政策可能會鎖定這個選項。
5. 重複測試兩輪：每一輪都重新觸發測試，不要只重新整理舊的結果頁。必要時清除快取並重新啟動瀏覽器，避免將先前的解析結果誤認為目前的路徑。

瀏覽器 DoH 是透過 HTTPS 進行的網域解析，可能繞過 mihomo 的 DNS 模組，但其 HTTPS 連線仍可能由代理或 TUN 接管。因此，「繞過核心 DNS」和「查詢直接送往本地業者」並非同一回事，必須分別確認。

使用指令確認核心 DNS 是否有回應

假設核心 DNS 監聽於 127.0.0.1:1053，可用下列指令直接查詢。Windows PowerShell 的清除快取指令需依系統權限執行；已安裝 dig 的系統則可使用第二條指令查詢。這裡的 example.com 是診斷用網域，不是代理節點。

# Windows PowerShell：清除系統 DNS 快取
Clear-DnsClientCache

# 已安裝 dig 的 macOS / Linux：直接查詢核心 DNS
dig @127.0.0.1 -p 1053 example.com A

# 再查詢 IPv6 記錄，分別檢視結果
dig @127.0.0.1 -p 1053 example.com AAAA

在 fake-ip 模式下，一般 A 記錄查詢可能會回傳 198.18.0.0/16 範圍內的位址，通常屬於正常映射，並非 DNS 污染。若符合 fake-ip 排除規則、特殊網域處理或快取條件，回應方式可能不同。指令查詢成功，只能證明這個監聽埠可用，無法證明瀏覽器或系統預設查詢已指向它。

三、fake-ip 與 redir-host：差異在於解析時機

fake-ip 會讓核心在收到應用程式的連線後，透過虛擬位址找回網域，再依規則決定出口。若連線由遠端代理解析目標，本地可能不必先取得目標的實際 IP；但直連、IP 規則判斷及部分協定情境仍可能需要解析。這並不是「啟用後所有 DNS 都會自動走代理」的開關。

redir-host 更接近傳統的實際位址解析流程，也能搭配可靠的加密上游使用；不能只因採用這種模式就判定有洩漏。選擇模式時，應考量應用程式相容性、連線是否完整接管及規則需求，而不是把模式名稱當成隱私等級。

別用大範圍排除規則修復單一應用程式

若特定區域網路服務、遊戲或裝置探索功能與 fake-ip 不相容，可針對個別網域設定 fake-ip-filter。不要一開始就排除整個常見的公用網域後綴。排除範圍越大，越多請求會回到實際解析路徑，也會改變原本依賴虛擬映射的行為。切換模式後，請重新啟動相關應用程式，避免繼續使用舊的虛擬位址快取。

四、nameserver、fallback 與策略解析設定

先釐清三個欄位各自的用途：nameserver 是一般解析上游；nameserver-policy 可為符合條件的網域指定上游；fallback 則搭配篩選條件選擇解析結果。它們決定「向誰查詢」，但不會自動決定「透過哪個出口查詢」。加密 DNS 負責傳輸方式，代理路由負責連線路徑，兩者必須分別設定。

先建立可驗證的 DNS 基準

以下是需要合併到現有設定的 DNS 片段，並非完整訂閱。使用 IP 格式的 DoH 位址，可減少上游網域需要引導解析的情況。若網路無法直連所列服務，還需要設定代理路徑；不要把逾時誤判為 YAML 語法錯誤。

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
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

• default-nameserver 主要用來解析 DNS 上游本身的網域，不代表所有目標網域都會交由它解析。這裡的 223.5.5.5 是明文引導解析器；若要求引導查詢也加密，應使用目前核心支援且可連線的加密引導上游，並實際測試確認。
• listen 只監聽迴圈位址，避免直接將此範例變成對區域網路開放的解析服務。系統 DNS 設定通常無法指定 1053 這類自訂埠號，因此需要透過接管機制或本機轉發處理。
• ipv6: false 會控制核心 DNS 是否回覆 AAAA 記錄，不會停用作業系統的 IPv6，也無法阻止應用程式連線到已知的 IPv6 位址。IPv6 連線仍需由路由或 TUN 正確處理。

使用 nameserver-policy 區分區域網路與公用網域

以下片段須放在同一個 dns 物件中。範例假設路由器 DNS 為 192.168.1.1；實際位址請依目前網路環境確認。PROXY 必須是現有設定中實際使用的策略群組名稱，且大小寫須完全一致；若不符，請先改成實際群組名稱再套用。

  nameserver-policy:
    "+.lan":
      - 192.168.1.1
    "+.github.com":
      - "https://1.1.1.1/dns-query#PROXY"

+.github.com 會比對該網域及其子網域。引號中的 #PROXY 是 mihomo 支援的 DNS 上游出口指定語法，讓這條 DoH 連線使用指定策略。若該群組選擇 DIRECT，請求仍會直連；若選到無法使用的節點，連線就會逾時。策略解析只涵蓋列出的網域，不會自動套用到所有公用網站。

fake-ip 排除清單與策略解析是不同功能：前者決定回傳虛擬位址或進行實際解析，後者則選擇解析上游。將 *.lan 加入排除清單後，還須確認相應的區域網路解析器確實有這些記錄。

fallback 不只是逾時時的備用解析器

設定 fallback 後，核心可能會平行進行解析，並依據 fallback-filter 判斷採用哪個結果。不要以為主解析器可用時，fallback 就一定不會收到網域查詢。以下僅示範一種依賴 GeoIP 資料篩選結果的方式，不必與前面的最小設定同時啟用。

  fallback:
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

這個範例透過 GeoIP 的 CN 判定與指定網段篩選，協助選擇解析結果。資料庫過舊或 CDN 位址歸屬改變，都可能影響判斷。fallback 也不是預設的代理通道；其 HTTPS 連線仍依實際出站設定運作。若目標是縮小查詢接收方的範圍，請先用單一且明確的上游排查，再評估是否需要加入 fallback。

五、TUN 接管與 DNS 出站：補齊兩段路徑

第一段是從應用程式到核心，第二段是從核心到上游。只設定 dns.enable 不會讓所有應用程式自動使用核心 DNS；只啟用 TUN，也應確認 DNS 劫持確實生效。以下是常見的 mihomo TUN 片段，啟用前請確認用戶端已取得必要的系統權限，且路由不會與其他 VPN 衝突。

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

這裡接管的是進入 TUN 的一般 UDP／TCP 53 流量。瀏覽器 DoH 通常使用 HTTPS 443，DoT 常用 853；設定劫持 53 埠不會讓這些流量自動交由核心 DNS 處理。部分系統的區域網路路由、介面綁定與多網卡行為也會影響接管，必須搭配記錄與重新測試確認。

需要讓 DNS 遵循路由規則時

mihomo 的 respect-rules 可讓 DNS 上游連線遵循路由規則。啟用時也應設定 proxy-server-nameserver，為代理節點網域提供獨立的解析入口，避免出現「必須先連上代理才能解析，但又得先解析才能連上代理」的循環依賴。

  respect-rules: true
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

這兩行同樣屬於 dns 物件。範例中的節點網域解析入口，必須在代理尚未建立前就能連線；若目前網路無法直連，請改用該網路可連線的入口，並留意相應的解析可見範圍。不要把所有 DNS 上游都強制指向尚未建立連線的代理群組。

合併設定時，頂層只保留一個 dns 鍵。不要逐段新增多個同名區塊。訂閱更新也可能覆蓋手動修改，請使用用戶端支援的覆寫或合併機制保存，並在重新載入後確認最終設定。具體操作位置會隨用戶端版本變動，可參閱使用指南確認操作方式。

六、依症狀定位問題，並完成最後一次測試

檢查記錄時，請針對剛發出的查詢確認三件事：核心是否收到請求、選用了哪個上游，以及該上游連線使用哪項策略。DoH 請求通常會在連線面板中顯示為連往解析服務的 HTTPS 連線，不能只憑一條 443 連線就判定網站流量走錯出口。必要時可短暫提高記錄層級，排查完成後再還原；分享記錄前，請移除訂閱網址、憑證與私人網域。

1. 儲存設定後重新載入核心，確認沒有未知欄位、YAML 縮排錯誤或埠號被占用。
2. 使用 dig @127.0.0.1 -p 1053 確認監聽正常，再以實際瀏覽器連線驗證是否完整接管。
3. 重新執行 DNS 測試，分別記錄一般視窗、另一個瀏覽器，以及 IPv4／IPv6 的結果。
4. 逐項還原原本的瀏覽器安全 DNS、應用程式與網路環境，找出造成結果改變的特定設定。
5. 重新啟動用戶端或更新一次訂閱後再測，確認覆寫內容仍然保留，而非只在這次執行期間有效。

最終目標不是讓測試頁只顯示一個位址，而是確保各類查詢都符合預先設定的路徑：區域網路網域交由內部解析器處理，需要透過代理的網域依指定策略解析，節點網域則有可用的引導入口。分別驗證接管、上游與出站這三個層面，比反覆切換 fake-ip 和 redir-host 更容易找出問題。