DNS 洩漏檢測與設定

先確認 DNS 洩漏的判定標準

Clash DNS 洩漏通常是指：原本應交由指定解析器處理，或透過代理傳送的網域查詢，繞過預期路徑，改送至本機網路、電信業者或其他解析服務。判斷前必須先明確定義預期路徑。例如，中國大陸網域可直接解析，其他網域則需透過代理使用指定的 DoH 服務。若沒有這條界線，只憑檢測頁面顯示某個國家或服務商名稱，無法判定是否發生洩漏。

一次連線至少涉及三條彼此獨立的路徑：應用程式將查詢交給誰、Clash 將查詢送往哪個上游，以及連線至上游時採用直連還是代理。nameserver-policy 只負責依網域選擇上游；它本身不是流量接管開關，也不代表 DNS 連線會經過代理。

建立可重現的 DNS 檢測流程

1. 記錄基準狀態，再啟用代理

1. 關閉其他 VPN、代理與網路加速工具，並記下目前網卡的 DNS 位址。Windows 可執行 ipconfig /all；macOS 可執行 scutil --dns；使用 systemd-resolved 的 Linux 可執行 resolvectl status。
2. 記下瀏覽器是否啟用安全 DNS。先以系統解析模式測試一次，再另外測試瀏覽器 DoH，避免混淆兩條路徑。
3. 尚未啟用 Clash 時先執行一次 DNS 檢測，記錄解析服務商、解析器位址與目前時間。啟用 Clash 後，使用相同網路與瀏覽器重新測試。
4. 同時開啟用戶端記錄或連線清單，觀察測試期間的網域、目標位址、命中規則與連線策略。檢測頁面只能提供線索，應以本機記錄判讀實際路徑。

公共 DNS 可能使用任播位址，遞迴節點的位置也可能與代理出口不同。檢測頁面列出多個解析位址，可能是使用了多個上游，也可能來自同一服務的節點池。不要直接把位址數量或地理位置視為洩漏次數。

2. 分別驗證 Clash 的 DNS 監聽

以下設定會將 DNS 監聽在 127.0.0.1:1053。此位址僅供本機存取，1053 是 DNS 連接埠，不是 HTTP 代理連接埠。如果應用程式仍向路由器的 53 連接埠查詢，不會因為這裡啟用了監聽就自動改道。

# macOS / Linux，需先安裝 dig
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

# Windows
nslookup -port=1053 example.com 127.0.0.1

指令有回傳結果，表示本機可連上 Clash 的 DNS 入口；但這不代表系統 DNS 已被接管。若發生逾時，請先檢查設定是否載入、核心是否執行，以及 1053 連接埠是否衝突，不要立刻更換代理節點。

3. 檢查實體網卡上的明文查詢

在具備權限的裝置上，可使用封包擷取工具篩選 udp.port == 53 || tcp.port == 53。Linux 也可執行以下指令；其中的 any 會包含虛擬介面，判讀時應區分實體網卡與 TUN 介面。

sudo tcpdump -ni any '(udp port 53 or tcp port 53)'

如果看到傳往區域網路 DNS 的查詢，請確認該網域是否屬於允許直連的範圍。沒有觀察到 53 連接埠流量，也不能證明所有 DNS 都經過代理：DoH 通常使用 HTTPS 的 443 連接埠，DoT 通常使用 TCP 853，兩者都不在此篩選條件內。

了解 nameserver 與解析引導

dns.enable 用來啟用核心 DNS 服務；listen 指定監聽位址；nameserver 提供一般查詢所用的上游。上游可以是一般 DNS 位址，也可以是核心支援的加密 DNS URL。將一般 DNS 換成 DoH，只能保護用戶端與 DoH 服務之間的傳輸，無法對該解析服務隱藏查詢內容。

• default-nameserver：主要用來解析 DNS 上游本身的網域，解決「先取得解析器位址」的啟動問題；並非所有一般網域的預設群組。
• proxy-server-nameserver：在 mihomo 中為代理節點網域提供專用解析入口，避免節點尚未連線時，解析自身位址仍得依賴該節點。
• nameserver：處理未套用專屬策略的一般查詢。
• nameserver-policy：讓指定網域或支援的網域集合使用特定解析器。

以下範例使用 IP 格式的 DoH 位址進行引導。所在網路必須能連線至這些位址，且核心必須通過 TLS 驗證。若網路封鎖相關服務，請改用當地可連線且可信任的解析器，並重新評估其直連範圍；不要關閉憑證驗證來規避問題。

可直接套用的 mihomo DNS 設定

這是一段供合併至現有設定的片段，不包含節點與訂閱。範例將一般網域交由 Cloudflare DoH 解析，將 .cn 後綴網域交由阿里 DoH 解析，並透過規則區分 DNS 服務連線的出口方式。.cn 僅代表網域後綴，不等於所有中國大陸網站。

套用前，請確認現有設定中有名稱完全相同的 PROXY 策略群組，並為其選好可用節點。若你的策略群組名稱不同，必須替換規則中的 PROXY。請將下方規則插入現有 rules 清單前段，保留原有業務規則與末尾的兜底規則；不要建立第二個同名 YAML 鍵。

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

# 合併至現有 rules 前段，勿覆蓋後續業務規則。
rules:
  - DOMAIN,cloudflare-dns.com,PROXY
  - DOMAIN,dns.alidns.com,DIRECT
  - IP-CIDR,1.1.1.1/32,DIRECT,no-resolve

respect-rules: true 會讓一般 DNS 上游連線遵循路由規則。範例以明確的網域規則，讓 Cloudflare DoH 透過 PROXY 連線，阿里 DoH 則採直連；IP 規則則為引導位址保留直連路徑。代理節點網域的專用解析仍是啟動依賴，因此不能宣稱此設定會讓每一次 DNS 查詢都經過代理。

ipv6: false 在此限制的是核心 DNS 的 AAAA 回應，不會關閉作業系統的 IPv6，也不是 IPv6 流量防洩漏開關。需要 IPv6 的環境應另行驗證 IPv6 路由、TUN 接管與上游支援情況，再決定是否啟用。

nameserver-policy 的比對方式與適用範圍

在 mihomo 的網域比對語法中，"+.example.com" 可涵蓋該網域及其子網域。建議為含特殊字元的策略鍵加上引號，並使用兩個空格縮排。策略值可設定為解析器清單；使用多個解析器時，不應將清單順序解讀為固定的主備順序。

dns:
  nameserver-policy:
    "+.example.com":
      - https://cloudflare-dns.com/dns-query
    "+.cn":
      - https://dns.alidns.com/dns-query

這段僅示範策略寫法，應合併至上一段的 dns 區段內，而非另設重複的鍵。example.com 是用來驗證比對結果的示範網域，正式使用時請依實際業務網域調整。不要依賴大量範圍重疊的寬泛策略來猜測優先順序；請明確界定範圍，並分別測試主網域與子網域。

企業內部網域需另外處理

公司內部網域通常只有辦公室網路的 DNS 才能解析。可將實際的內部網域後綴對應至內網 DNS，並為該 DNS 位址保留直連路由；使用 Fake-IP 時，還需依應用程式需求評估是否加入 fake-ip-filter。不要將內部網域送交公共解析器，也不要把公共 DNS 回傳的解析失敗誤判為節點故障。

將網域加入 fake-ip-filter，只會改變回傳真實位址或映射位址，不會自動指定上游，更不會強制直連。解析器選擇、Fake-IP 例外與連線路由屬於三個不同的設定層，應分別驗證。

fallback 不是防洩漏開關

fallback 提供另一組解析上游，fallback-filter 則參與結果選擇。不能簡單理解為「主要 DNS 完全失效後才會查詢備用 DNS」：相關查詢可能同時發生，實際行為會受核心與篩選條件影響。如果兩個上游位於不同的信任範圍，查詢本身就可能傳送給雙方。

以下是針對異常位址結果的獨立設定範例。請將其追加至現有的 dns 區段內，不要取代整份設定。使用 Quad9 時，也要將相關連線的出口策略納入檢查；僅指定 HTTPS 位址不會自動使用代理。

  fallback:
    - https://dns.quad9.net/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/32
      - 127.0.0.0/8

此處關閉以 GeoIP 為基礎的篩選，只示範篩除指定的異常位址範圍。這不是完整的污染辨識規則；某些安全篩選服務會刻意回傳空位址，某些測試網域也可能合法指向迴路位址。只有在確有需要時才加入條件；篩選項目越多，不代表越可靠。

系統代理、TUN 與瀏覽器 DoH 的注意事項

系統代理不會接管所有 DNS

HTTP 代理可讓代理端處理請求中的目標網域，但未使用系統代理的程式仍可能呼叫系統解析器。SOCKS 應用程式是否將網域交給代理解析，也取決於其遠端解析選項。啟用系統代理後網頁可以正常使用，不代表命令列工具、遊戲與背景服務都採用相同的解析路徑。

TUN 的 DNS 劫持有協定限制

若需接管未遵循系統代理的應用程式，可在支援的平台啟用 TUN。以下是常見的 mihomo 設定片段；自動路由通常需要相應的系統權限，而能否接管指向區域網路的 DNS，也取決於平台路由與用戶端實作。

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

這些劫持設定針對傳統 DNS 的 UDP/TCP 53 連接埠，不會解密瀏覽器 DoH，也不會將所有 443 連接埠連線轉換成核心 DNS 查詢。瀏覽器內建的 DoH 仍是獨立連線：它可能透過 TUN 路由至代理，但其網域查詢內容不會因此交由 nameserver-policy 處理。

瀏覽器與系統快取應分開測試

以桌面版 Chrome 為例，可在「設定」→「隱私權和安全性」→「安全性」中檢查「使用安全 DNS」；介面文字可能隨版本變動。若要驗證 Clash 核心 DNS，請先暫時關閉自訂安全 DNS。若保留瀏覽器 DoH，則應另外核對該 DoH 服務連線的出口策略。

Windows 可執行 ipconfig /flushdns 清除系統快取；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。瀏覽器快取與核心快取可能仍存在，請重新啟動相關程序後再測試。不要以一次命中快取的快速回應，證明上游已經切換。

依症狀完成最後測試

最後依相同順序重新測試：確認本機 1053 監聽可用，確認系統或 TUN 已將目標查詢送入核心，確認策略選用了預期上游，再確認該上游連線命中正確出口。請保留測試時間、查詢網域、解析器與策略記錄。四個環節的結果一致，才表示這條查詢路徑符合預期；單次檢測頁面的截圖無法代表所有應用程式、所有網路與 IPv6 情境。