Clash DNS 洩漏檢測與防護設定：從測試結果到規則修正

先判斷哪些情況屬於 DNS 請求繞行

存取網域之前，裝置通常需要先將網域解析為 IP 位址。Clash 可以接管這個步驟，也可能只代理解析完成後的 TCP 或 UDP 連線。如果網頁流量經過代理，而網域查詢仍直接送往本地網路提供的 DNS 伺服器，查詢路徑便會與業務流量分離。檢測網站通常會將這種情況標記為 DNS 洩漏。

不過，檢測結果中出現本地電信業者、公共 DNS 或不同地區的解析器，不一定代表設定失效。公共 DNS 經常使用 Anycast 網路，同一個伺服器位址可能在不同城市落地；解析服務也可能將查詢轉交給其他出口節點。檢測頁面顯示的是遞迴解析器或出口基礎設施，不一定是設定檔中填入的位址。

更準確的判斷需要同時回答三個問題：應用程式將查詢交給誰、Clash 核心如何存取上游解析器，以及解析後的業務連線符合哪一條代理規則。只看檢測頁面上的國家、城市或伺服器名稱，無法完整還原這條鏈路。

建立可重複的 Clash DNS 洩漏檢測流程

排查前先固定測試條件。不要在切換設定、切換節點和修改瀏覽器設定的同時反覆重新整理頁面，否則很難確認是哪一項改變了結果。建議保留目前設定副本，並記錄核心類型、執行模式、系統代理狀態、TUN 狀態與瀏覽器安全 DNS 狀態。

第一步：建立未啟用代理時的基準線

暫時關閉系統代理與 TUN，開啟檢測頁面並記錄解析器名稱、數量與大致位置。這組結果代表目前網路的常規 DNS 路徑。接著啟用 Clash，再使用新的瀏覽器隱私視窗進行測試。若兩次結果完全相同，表示系統查詢可能仍沿用原有路徑，但還需要結合快取與應用程式內建 DoH 進一步確認。

第二步：清除快取並使用新網域

系統、瀏覽器、Clash 核心與上游伺服器都可能快取解析結果。只重新整理同一個頁面，可能不會產生新的 DNS 查詢。測試時應清除作業系統 DNS 快取，關閉並重新開啟瀏覽器，再使用檢測工具提供的新隨機網域。若用戶端提供清除 DNS 快取或重新啟動核心功能，也應在修改設定後執行。

第三步：區分系統代理與 TUN

系統代理主要影響遵循 HTTP 或 SOCKS 代理設定的程式。一般 UDP 53 查詢通常不會因為開啟系統代理就自動進入 Clash。TUN 模式則會在網路層接收更多流量，並可透過 DNS 劫持規則將傳統 DNS 查詢交給核心。因此，同一組設定在系統代理模式與 TUN 模式下，可能得到不同的檢測結果。

第四步：查看核心日誌與連線記錄

檢測期間開啟用戶端日誌，搜尋測試網域、DNS、UDP、DoH 或規則匹配記錄。日誌中可以看到網域被 fake-ip 對應、查詢送往某個 nameserver，或連線命中 DIRECT、PROXY 等策略；這些證據通常比檢測頁面的地理標籤更直接。若日誌完全沒有測試網域，查詢很可能未進入目前使用的核心。

1. 固定一個設定檔與一個代理節點。
2. 記錄系統代理、TUN、IPv6 與瀏覽器安全 DNS 狀態。
3. 清除快取後執行一次檢測。
4. 只修改一個選項，再進行下一輪檢測。
5. 對照核心日誌、連線清單與檢測結果。

fake-ip 與 redir-host 的路徑差異

Clash 常見的增強 DNS 模式包括 fake-ip 與 redir-host。兩者都能讓核心參與網域解析，但運作方式不同。選擇模式時應同時考量規則匹配、區域網路裝置相容性與應用程式行為，不能只看檢測頁面顯示了幾個解析器。

fake-ip：先回傳保留位址，再由核心還原網域

在 fake-ip 模式下，Clash 會從專用位址區段回傳一個對應位址。應用程式向該位址建立連線時，核心會根據對應表找回原始網域，再依網域規則選擇策略。這樣可以減少系統先取得真實目標 IP 後才交給代理的情況，也有助於維持網域規則的有效性。

fake-ip 並不代表所有 DNS 流量都會自動被接管。應用程式仍需將查詢送到 Clash 的 DNS 監聽埠，或由 TUN 的 DNS 劫持規則轉交給核心。若瀏覽器直接存取外部 DoH 服務，查詢會封裝在 HTTPS 中，普通的 53 埠劫持無法辨識其中的 DNS 內容。

區域網路名稱、印表機探索、網路連線能力檢測與部分遊戲平台可能不適合使用 fake-ip。這類網域可加入 fake-ip-filter，讓核心回傳真實位址。過濾範圍應依實際故障逐項加入，設定過寬會削弱 fake-ip 的網域對應效果。

redir-host：回傳真實位址並保留網域處理

redir-host 會向應用程式回傳真實解析位址。它對部分依賴真實 IP 的程式相容性較高，但解析動作會更早發生，也更依賴上游 DNS 的可達性與回傳結果。舊版 Clash 用戶端中常見此模式；mihomo 仍可處理相關設定，但新設定通常需要配合用戶端能力與網路環境進行測試。

修正上游 DNS 與規則路徑

以下設定用於說明各欄位的職責，不應直接覆蓋現有訂閱內容。不同 Clash 分支支援的欄位不完全相同。原版 Clash 的舊核心通常支援基本的 enable、enhanced-mode、nameserver、fallback 與 fake-ip-filter；proxy-server-nameserver、direct-nameserver、nameserver-policy 與 respect-rules 等功能主要見於較新的 mihomo 核心。

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
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

  nameserver-policy:
    "geosite:private":
      - system
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

  fake-ip-filter:
    - "*.lan"
    - "localhost"

default-nameserver 負責啟動階段解析

加密 DNS 位址本身通常包含網域名稱，例如 dns.alidns.com。核心需要先取得該網域的位址，才能建立 DoH 連線。default-nameserver主要負責這類初始解析，也可能參與代理伺服器網域的引導解析。它不是所有業務網域的最終上游，填寫後仍須設定 nameserver。

nameserver 是一般查詢入口

nameserver定義一般網域查詢所使用的上游。同時列出多個伺服器可以提高可達性，但測試時也可能觀察到多個解析基礎設施。若排查目標是確認請求從何處發出，可以先保留一個穩定上游，確認路徑後再加入備用項目。

DoH 或 DoT 可以避免傳統 DNS 封包在本地鏈路上以明文傳輸，但加密本身不會決定連線走 DIRECT 還是代理。若上游連線以直連方式發出，出口仍屬於本地網路；若希望它依規則選擇出口，需確認核心是否支援並啟用了相應的規則跟隨功能。

proxy-server-nameserver 處理節點網域

訂閱中的代理伺服器可能使用網域名稱，而非固定 IP。核心必須先解析節點網域，才能建立代理連線。若解析節點網域的過程又依賴尚未建立的代理，就會形成循環。mihomo 的 proxy-server-nameserver用於指定這類查詢的解析器，應選擇目前網路可直接存取且穩定的上游。

nameserver-policy 僅選擇解析器

nameserver-policy可以依網域或規則集選擇上游，例如讓私人網域交由系統解析，讓特定區域網域使用對應解析器。它控制的是「向哪一台 DNS 伺服器查詢」，不是「網站連線最終採用哪個策略群組」。業務流量仍由 rules中的網域、IP、規則集與兜底規則決定。

範例中的 geosite依賴核心已載入相應的規則資料。若用戶端沒有規則集、資料版本過舊或規則名稱不存在，策略可能無法依預期匹配。遇到這類情況，應先使用明確的網域後綴測試，再檢查規則資料來源與更新時間。

謹慎處理 fallback 與過濾條件

舊設定常用 fallback搭配地理 IP 判斷來選擇解析結果。設定不當時，一般上游與備用上游可能同時查詢，於是檢測頁面顯示多個 DNS 服務。這不一定是繞行，也可能是並行查詢機制。遷移到 mihomo 後，可依實際需求改用 nameserver-policy明確劃分網域，減少難以解釋的並行結果。

處理作業系統、瀏覽器與應用程式內 DNS

Clash 核心設定正確，並不代表所有程式都會使用它。DNS 請求可能來自系統解析器、瀏覽器安全 DNS、應用程式內建 DoH、虛擬機器、容器或區域網路中的另一台裝置。排查時應依請求來源逐層確認。

系統代理不會接管所有 DNS

啟用系統代理後，瀏覽器通常會將 HTTP 或 HTTPS 連線交給代理，但系統服務與不遵循代理設定的程式仍可能直接連線。傳統 DNS 查詢主要透過 UDP 或 TCP 53 埠傳送，不會自然進入 HTTP 代理。若使用的用戶端只開啟系統代理，應預期部分系統層級查詢仍會使用網路介面卡設定的 DNS。

部分用戶端在啟用 TUN 時，會自動修改系統 DNS 或安裝網路服務。此時不宜同時手動將多張網路介面卡設為不同 DNS，否則可能產生衝突。應先查看用戶端文件與執行日誌，確認它是否負責 DNS 設定，再決定是否手動調整。

瀏覽器安全 DNS 可能形成獨立路徑

現代瀏覽器可以直接連線至指定的 DoH 服務。這類連線表現為一般 HTTPS 流量，可能繞過系統解析器，也不會被 dns-hijack: any:53捕獲。測試 Clash 內建 DNS 時，可以暫時將瀏覽器安全 DNS 設為跟隨系統，清除瀏覽器 DNS 快取後重新檢測。

如果需要保留瀏覽器 DoH，應將它視為獨立的 DNS 方案。此時需要檢查 DoH 服務網域對應的代理規則、連線出口與失敗回退行為，而不是期待 Clash 的 fake-ip 設定接管瀏覽器內部查詢。

IPv6 需要個別核對

關閉 Clash DNS 設定中的 ipv6通常表示不向應用程式回傳 AAAA 結果，但不會自動關閉作業系統的 IPv6 網路。應用程式仍可能使用快取中的 IPv6 位址，或透過自己的解析器取得 AAAA 記錄。若測試結果只在 IPv6 環境中出現異常，應分別檢查系統 IPv6、核心 IPv6 支援、代理節點能力與規則中的 IPv6 路徑。

不建議僅為了讓檢測頁面顯示單一結果，就永久關閉整個系統的 IPv6。更可靠的方法是先透過受控測試確認異常是否確實來自 IPv6，再依節點與網路支援情況進行調整。

區域網路與容器可能不使用主機解析器

虛擬機器、Docker 容器、Android 模擬器與區域網路裝置往往擁有獨立的 DNS 設定。即使主機上的 Clash 已正確接管查詢，這些環境仍可能向路由器或外部伺服器發出請求。若需要讓其他裝置使用 Clash DNS，還應檢查監聽位址、防火牆與區域網路存取權限，避免只綁定回環位址後，卻期待其他裝置能夠連入。

TUN 模式下檢查 DNS 劫持與路由順序

TUN 模式可以接收不遵循系統代理的流量，是處理系統層級 DNS 繞行的常用方式。mihomo 設定中可使用 dns-hijack捕獲傳統 53 埠查詢，再交給內建 DNS 模組。實際欄位也會受到用戶端產生的設定與執行權限影響。

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

auto-route用於自動設定路由，auto-detect-interface協助核心選擇目前的出口網路介面卡。若裝置同時連線至有線網路、無線網路、其他 VPN 或虛擬網路介面卡，自動偵測可能選到不符合預期的介面。出現 DNS 逾時或啟用 TUN 後完全斷網時，應檢查預設路由與介面變化，而不是只修改 nameserver。

any:53主要處理傳統 DNS。它無法解密外部 DoH，也無法保證 QUIC、私人 DNS 或應用程式自行建立的通道進入內建解析器。針對這些協定，應在應用程式設定中統一 DNS 行為，或透過網域與網路策略控管對應連線。

啟用 TUN 後，還要確認 Clash 自身存取上游 DNS 的連線不會再次被錯誤送回 TUN，形成循環。成熟的用戶端通常會針對核心程序、路由標記或出口介面進行處理。若日誌持續重複相同的 DNS 請求並最終逾時，應檢查用戶端的服務模式、核心權限與排除規則。

依檢測現象修正规則與設定

最終核對清單

• 目前啟用的 Profile 與正在編輯的檔案一致。
• 核心類型與版本支援所使用的 DNS 欄位。
• 能在核心日誌中找到測試網域。
• 已區分系統代理與 TUN 的適用範圍。
• 已確認瀏覽器與應用程式內建 DoH 狀態。
• nameserver、fallback 與策略規則沒有無目的地重複查詢。
• 節點網域具備獨立且可達的啟動解析路徑。
• 修改設定後已重新啟動核心並清除相關快取。
• IPv4、IPv6 與區域網路裝置已分別完成測試。

DNS 防護的目標不是讓所有檢測頁面只顯示一個固定名稱，而是讓查詢路徑可解釋、可控制，並與代理規則保持一致。先確認請求是否進入 Clash，再確認核心選擇哪個上游，最後檢查上游連線與業務流量的出站策略。依照這個順序處理，可以避免在多個 DNS 欄位之間反覆試錯。