故障排除
預計閱讀 13 分鐘

Clash DNS 洩漏檢測與防洩漏設定實作：Fake-IP 與 nameserver 設定

先用檢測網站確認 DNS 請求的實際出口，再逐項調整 dns 設定：選擇 enhanced-mode、設定 fake-ip-filter 例外，以及分配主要與備援 nameserver，並附上完整的洩漏修復驗證步驟。

先判斷什麼才算 DNS 洩漏

在瀏覽器連線至網域之前，必須先將網域解析為 IP 位址。啟用 Clash 後，網頁連線可能已經經過代理，但 DNS 查詢仍可能直接送往路由器、電信業者 DNS、系統指定的公共 DNS，或由瀏覽器自行啟用的加密 DNS。此時，代理出口與 DNS 請求出口並不在同一條路徑上。

排查重點不是單純比較「檢測頁面顯示的 DNS 位址是否等於代理節點 IP」。公共 DoH 服務通常由獨立伺服器回應，Anycast 也可能將查詢分派至鄰近的機房，因此兩者原本就可能不同。真正需要確認的是：檢測結果中是否出現本地電信業者、公司網路、校園網路或家用路由器提供的解析服務，以及這些查詢是否繞過預期的代理與規則路徑。

常見的四條 DNS 路徑

請求來源 可能的去向 排查重點
系統一般 DNS UDP 或 TCP 53 埠 TUN 是否接管 53 埠，以及系統代理模式能否涵蓋該程式
瀏覽器安全 DNS 瀏覽器自行選擇的 DoH 位址 瀏覽器設定是否覆蓋系統 DNS，以及檢測時是否維持相同策略
Clash 內建 DNS nameserver、fallback 或策略指定的伺服器 上游位址、代理路徑與規則是否正確
應用程式內建解析 硬編碼 DNS、DoH 或 DoT TUN 路由是否涵蓋該應用程式，以及應用程式是否繞過系統代理

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

單次檢測結果容易受到快取、瀏覽器連線重用與上游 Anycast 分流影響。可靠的做法是先記錄基準，再清除快取，最後分別在直連與代理狀態下重複測試。整個過程應使用同一個瀏覽器、同一個網路與同一份設定，避免同時變更多個變數。

第一步：記錄未啟用 Clash 時的基準

  1. 完全退出 Clash 用戶端，確認系統代理與 TUN 都已關閉。
  2. 開啟 dnsleaktest.com 或 browserleaks.com/dns，分別執行一次標準檢測與一次擴充檢測。
  3. 記錄檢測到的 DNS 服務商、國家或地區，以及伺服器數量。家用寬頻常見結果為 1 至 4 個解析位址。
  4. 接著開啟作業系統的網路詳細資訊，記錄目前網路介面取得的 DNS 位址。常見值可能是路由器位址，例如 192.168.1.1，也可能是網路指派的公共位址。

這組結果可用來辨識本地解析器。之後啟用 Clash，如果再次出現相同的服務商與位址，就能判斷查詢是否仍從本地網路送出。

第二步：清除快取並啟用代理

Windows 可先在終端機執行 ipconfig /flushdns。macOS 可執行 sudo dscacheutil -flushcache，再執行 sudo killall -HUP mDNSResponder。Linux 的快取清除方式取決於解析服務；使用 systemd-resolved 時可執行 resolvectl flush-caches。

接著啟動用戶端，匯入目標設定並啟用代理。如果準備驗證所有應用程式的 DNS，請進入「設定」→「網路」→「TUN 模式」開啟 TUN；如果只測試瀏覽器的系統代理，則保持 TUN 關閉，並明確知道這次結果只能代表該瀏覽器的流量路徑。

第三步：執行兩輪檢測

  • 第一輪使用一般視窗，確認日常瀏覽環境下的實際結果。
  • 第二輪使用新的隱私視窗，降低頁面快取、Service Worker 與舊連線的影響。
  • 每一輪至少執行一次擴充檢測。擴充檢測通常會觸發更多隨機子網域查詢，更容易暴露混合解析路徑。
  • 如果第一輪顯示 2 個指定的 DoH 解析器，第二輪卻突然多出 3 個本地電信業者解析器，應按照間歇性洩漏處理，而不是只採信較理想的那一次結果。

Fake-IP 模式如何接管網域解析

在 mihomo 核心中，enhanced-mode: fake-ip 會為一般網域回傳一個保留位址，並在核心中維護「網域—Fake-IP」對應。應用程式連線至這個保留位址時，核心可以還原原始網域，再繼續執行網域規則、策略群組選擇與真實目標解析。預設常見的位址池是 198.18.0.1/16，它來自網路基準測試保留範圍，不應作為公共網路目標使用。

Fake-IP 的價值在於將網域資訊保留到連線階段。相較於直接向應用程式回傳真實 IP，它更容易讓 DOMAIN、DOMAIN-SUFFIX、GeoSite 等規則穩定參與比對，也能減少應用程式先自行取得真實位址、再發起連線所造成的規則偏差。

可作為起點的 DNS 設定

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  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://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

範例中的監聽埠是 1053，可避免直接佔用系統常用的 53 埠。真正接管系統 DNS 時，通常由 TUN 的 dns-hijack 將 53 埠查詢導向核心，而不是要求一般使用者程序直接監聽特權埠。

default-nameserver 負責啟動解析

default-nameserver 主要用於解析 DoH、DoT 等上游伺服器本身的網域。例如 nameserver 設定為 https://dns.alidns.com/dns-query 時，核心必須先知道 dns.alidns.com 的 IP，才能建立 HTTPS 連線。這裡優先填入可直接存取的 IP 位址，避免出現「解析 DNS 伺服器還需要先查詢 DNS」的循環依賴。

它不是所有業務網域的主要解析清單，也不等同於系統網路介面中的 DNS 設定。將十幾個位址塞進 default-nameserver 不會自動提升可靠性，反而會增加測試變數。通常保留 2 個路徑穩定、可直接連線的位址就足夠。

nameserver 處理主要網域查詢

nameserver 是一般查詢的主要上游。可以使用 UDP DNS，也可以使用 DoH 或 DoT。為了減少本地網路讀取明文 53 埠查詢的機會，常見做法是選用 DoH 位址，例如 https://1.1.1.1/dns-query。但加密只能保護用戶端與 DNS 服務之間的傳輸，不代表所有網域都應交給同一個上游，也不代表請求一定會經過代理。

如果設定需要讓 DNS 連線遵循規則，可以在支援相應欄位的 mihomo 版本中使用 respect-rules: true。此時也應設定 proxy-server-nameserver，用於解析代理節點伺服器的網域，否則節點網域本身可能出現循環解析。

nameserver-policy 進行精確分工

需要依網域指定解析器時，可以使用 nameserver-policy。它適合處理內部網域、區域網路服務或需要特定解析結果的區域性網站，比起將所有請求交給多組並行上游，更容易進行驗證。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.1.1

最後一項只適用於確實存在內部網域的情境。如果 192.168.1.1 是家用路由器，向它查詢就代表這部分請求會經過本地網路。這是明確的策略選擇，不應與意外洩漏混為一談。

fake-ip-filter 應排除哪些網域

並非所有網域都適合回傳 Fake-IP。區域網路探索、裝置投放、部分 STUN 探測、作業系統連線能力檢查，以及少數依賴真實位址的程式，可能需要例外。fake-ip-filter 的作用是讓符合條件的項目取得真實解析結果，而不是關閉整個 Fake-IP 模式。

從最小例外集合開始

  • *.lan、*.local：常用於本地裝置與區域網路服務。
  • 路由器管理網域：只有在實際使用時才加入，不要複製與本機無關的廠商網域。
  • 出現語音、影片或連線異常時，再針對記錄中的 STUN 網域新增規則。
  • 如果某個應用程式只有加入過濾規則後才能運作，應記錄具體網域，而不是直接排除整個頂級網域。

過寬的過濾清單會削弱 Fake-IP 的網域對應能力。例如直接加入 *.com 會讓大量網站回傳真實 IP，也更難追蹤網域規則的命中過程。建議每增加一項就保留故障現象、記錄中的網域與複測結果，方便日後移除已失效的例外。

TUN 模式與 DNS 劫持的關鍵設定

系統代理主要影響遵循 HTTP 或 SOCKS 代理設定的程式。許多遊戲、命令列工具、背景服務與自帶網路堆疊的應用程式不會讀取系統代理，因此只啟用系統代理無法保證它們的 DNS 會進入 Clash。TUN 模式透過虛擬網路介面接管 IP 流量，更適合驗證整台裝置的 DNS 路徑。

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

any:53 用於接管一般 53 埠 DNS 查詢，補充的 tcp://any:53 可涵蓋 TCP DNS。auto-route 負責自動加入路由，auto-detect-interface 用於辨識預設出口。strict-route 可減少查詢繞過 TUN 的機會，但在虛擬機、企業 VPN、區域網路分享與多網路介面環境中可能影響原有路由，需要逐項驗證。

用戶端內的檢查順序

  1. 進入「設定檔」頁面，確認目前設定已成功載入，介面沒有 YAML 解析錯誤。
  2. 進入「設定」→「網路」→「TUN 模式」，開啟 TUN，並依系統提示授予網路或管理員權限。
  3. 進入「設定」→「參數設定」，確認使用的是目標核心與目標設定，而不是先前快取的設定副本。
  4. 開啟「記錄」，將層級暫時調整為 Debug，搜尋 dns、fake-ip 或測試網域。
  5. 測試完成後將記錄層級恢復為 Info，避免長期記錄大量除錯資訊。

不同用戶端版本的選單文字可能略有差異，但檢查目標相同：目前設定、核心 DNS、TUN 開關、路由接管與記錄功能必須對應同一個執行個體。如果系統匣中還有另一個 Clash 用戶端，兩個程序可能同時修改代理、連接埠與路由。

常見洩漏原因與對應修復方式

只開啟系統代理，未啟用 TUN

瀏覽器網頁連線可能經過代理，但系統解析仍會送往網路介面的 DNS。修復方式是啟用 TUN 與 DNS 劫持，或明確將系統 DNS 指向用戶端的監聽位址。對於整台裝置接管的情境，前者通常更容易統一管理。

瀏覽器自行啟用 DoH

瀏覽器可能直接連線至自行選定的 DoH 服務，因而繞過 Clash 的網域分流。先關閉瀏覽器安全 DNS 進行對照；如果關閉後檢測結果恢復正常，再決定要讓瀏覽器跟隨系統，或透過規則明確接管該 DoH 連線。不要只根據單一瀏覽器的結果推論所有應用程式。

nameserver 使用明文 UDP 且直接連線

如果 nameserver 只填入 8.8.8.8、1.1.1.1 之類的 IP，查詢通常會透過 UDP 53 發出。它可能仍由 TUN 路由處理，但傳輸本身不是加密 DNS。若希望減少本地網路側錄，可改用對應的 DoH 位址，並在記錄中確認 HTTPS 連線實際採用的策略。

節點網域出現解析循環

如果代理節點位址是網域，核心必須先解析節點才能建立代理；但若該解析又被規則要求經由尚未建立的代理，就會形成循環。通常表現為設定載入成功，但節點全部逾時。請為節點網域單獨設定 proxy-server-nameserver，並確保這些解析器在代理建立前即可連線。

IPv6 查詢或連線走上另一條路徑

在設定中寫入 ipv6: false 只會影響核心 DNS 是否回傳 AAAA 結果，不一定會關閉作業系統的所有 IPv6 流量。如果本地網路提供 IPv6，而 TUN 路由只涵蓋 IPv4，應用程式可能改走 IPv6。測試時應同時檢查 IPv4、IPv6 位址與 DNS 結果；暫時關閉系統網路介面的 IPv6 可用於對照，但最終仍應修正 TUN 與路由的涵蓋範圍。

舊快取造成假象

系統、瀏覽器、應用程式與 mihomo 核心都可能快取解析結果。修改設定後立即重新整理原頁面，可能不會觸發新的查詢。應清除系統快取、重新啟動瀏覽器，並使用隨機子網域或檢測網站的擴充模式重新觸發解析。

修復後的完整驗證清單

驗證階段不要只看網頁是否能開啟。連線成功只能表示至少有一條路徑可用，無法證明所有 DNS 都依預期流動。建議依照下列順序執行，並記錄每一步的結果。

  1. 檢查設定載入：記錄中沒有 yaml、parse、dns config 相關錯誤。
  2. 檢查監聽埠：確認範例中的 1053 或實際設定埠由目前核心監聽，且未被其他程序佔用。
  3. 檢查 Fake-IP：查詢一般網域時，應能觀察到 198.18.0.0/16 範圍內的回傳值；過濾清單中的網域則應回傳真實位址。
  4. 檢查規則命中：在連線或記錄頁面查看測試網域使用的規則與策略群組，確認沒有意外落入 DIRECT。
  5. 執行擴充檢測：連續執行兩次，結果中不再出現基準階段記錄的本地電信業者解析器。
  6. 切換瀏覽器設定後複測：分別在啟用安全 DNS 與跟隨系統兩種狀態下測試，釐清差異來源。
  7. 測試非瀏覽器應用程式：使用命令列工具或另一個應用程式發起連線，確認 TUN 接管不只是對瀏覽器有效。
  8. 重新啟動後複測：重新啟動用戶端與系統，確認 TUN、DNS 與設定選擇都能依預期恢復。
nslookup example.com 127.0.0.1
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

指令中的位址與連接埠應依實際監聽值調整。如果用戶端只監聽 127.0.0.1:1053，就不能省略 -p 1053。在 Fake-IP 模式下，A 記錄回傳 198.18.x.x 通常是正常現象；這不是目標網站的真實公共 IP 位址。

更穩妥的調整順序

實際排查時，建議依照「確認基準—統一接管—縮小例外—驗證記錄」的順序操作。先保留 2 個明確的 nameserver，啟用 Fake-IP 與 TUN DNS 劫持，確保基本路徑穩定；之後再加入 nameserver-policy、區域網路解析與應用程式相容項目。

不要一次複製規模很大的 DNS 設定。欄位越多，解析路徑越難說明。對多數個人裝置而言，能夠說明每個上游的用途、每個例外的來源，以及每次查詢是否經過代理，比堆疊大量解析器更重要。完成修改後，使用相同的檢測網站、相同的瀏覽器狀態與相同的網路重複測試，才能判斷洩漏是否真正修復。

前往下載用戶端 Windows、macOS、Android、iOS、Linux