Clash DNS 洩漏如何檢測：檢測方法與 fake-ip 防洩漏設定

判斷 DNS 洩漏：先分清解析與連線

網頁透過代理開啟，不代表網域名稱解析也經過代理。應用程式可能先向路由器或電信業者的 DNS 查詢 IP 位址，再將 HTTPS 連線交給 Clash；也可能直接把網域名稱交給代理，由遠端進行解析。這兩種情況下網頁看起來一樣，但 DNS 暴露的範圍不同。排查時要一併確認應用程式如何解析、請求由誰接管，以及上游 DNS 經由哪條路由傳送。

本文所稱的「DNS 洩漏」，是指原本應透過代理或指定的加密解析服務處理，卻意外送往本機網路或其他非預期解析器的查詢。中國大陸網站依照設定直連並使用本機 DNS，屬於分流策略；不能只因檢測頁面顯示本機解析器，就判定發生故障。請先確認目標：只保護代理網域，還是除了節點網域等必要查詢外，所有應用程式的 DNS 都要走指定路徑。

常見的四種旁路

只有系統代理：不遵循系統代理設定的應用程式，仍可能透過 UDP 53 直接向路由器查詢。
瀏覽器安全 DNS：瀏覽器透過 HTTPS 向自己的 DoH 服務送出請求，繞過核心 DNS 模組；這條連線是否經過代理，仍取決於接管設定與規則。
多組 DNS 設定：訂閱、用戶端覆寫與系統網路設定同時生效，實際執行的設定可能不是你修改的那份檔案。
IPv6 或其他 VPN：其他網路介面、IPv6 路由或 VPN 的 DNS 策略，可能提供未納入接管的路徑。

檢測步驟：交叉比對網頁結果、核心日誌與系統查詢

檢測前先記下用戶端名稱、核心類型、系統代理狀態、TUN 狀態與目前模式。本文後續的 respect-rules、proxy-server-nameserver 範例適用於支援這些欄位的 mihomo 核心，不要直接套用到舊版 Clash。圖形用戶端版本與核心版本是兩項不同資訊，可分別在用戶端的「關於」頁面及啟動日誌中確認。

步驟一：在相同網路環境下進行比對

先關閉其他 VPN、網路加速器與代理擴充功能，並記下瀏覽器是否啟用安全 DNS。
暫時關閉 Clash 接管，在 dnsleaktest.com 執行 Extended test，記下解析器 IP、網路歸屬與檢測時間。
啟用準備檢查的設定，保持瀏覽器設定不變，再執行相同測試。也可以使用 browserleaks.com/dns 交叉檢查。
接著暫時關閉瀏覽器安全 DNS，再測試一次，以區分「瀏覽器本身的解析路徑」與「系統及核心的解析路徑」。測試結束後，依實際需求還原設定。

檢測網站通常會讓瀏覽器連線至隨機子網域，再從權威 DNS 端觀察遞迴解析器。結果中的 IP 是解析器的出口位址，不一定是代理節點的 IP。使用公共 DNS 時，解析器所在城市與代理出口城市不同很常見；服務採用 Anycast 或轉送架構時，也可能一次顯示多個位址。應確認服務營運者與預期的連線路徑，而不是只比較國家名稱。

步驟二：確認 DNS 模組確實有回應

以下查詢是針對本文範例中的本機監聽連接埠 1053。這只能驗證核心 DNS，不能證明系統和瀏覽器都已使用該連接埠。啟用 fake-ip 且網域未遭過濾時，A 查詢通常應回傳 198.18.0.0/16 範圍內的映射位址。

# Windows PowerShell 或命令提示字元
nslookup -port=1053 example.com 127.0.0.1

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

接著查看用戶端的「日誌」頁面，暫時將日誌層級設為 debug，重新執行一次查詢並開啟網頁；再到「連線」頁面檢查目標網域、命中的規則與最終策略。日誌格式會因核心版本而異，請留意是否有解析失敗、連線逾時或循環解析的訊息。排查完畢後將層級恢復為 info，避免持續記錄過多網域資訊。

步驟三：區分快取與實際旁路

修改後仍看到舊的解析器時，先重新載入設定，再清除系統 DNS 快取並重新啟動測試用瀏覽器。Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。這些命令無法清除所有應用程式的內部快取，因此仍需重新執行使用隨機網域的檢測。

若要進一步確認，可在實體網路介面上擷取封包，並使用 Wireshark 顯示篩選器 dns || tcp.port == 853 || udp.port == 853 檢查傳統 DNS、DoT 或 DoQ 的相關流量。DoH 通常使用 443 連接埠，無法只靠此篩選器識別；需搭配目的位址與核心連線記錄判斷。網路介面上出現連往代理伺服器的連線屬正常現象，不要把所有對外流量都視為洩漏。

設定欄位對照：nameserver、fallback 與 respect-rules

欄位	用途	排查重點
`enable`	啟用核心 DNS 模組。	啟用後仍須確保應用程式的查詢能送達該模組。
`listen`	提供本機 DNS 監聽入口。	`127.0.0.1:1053` 不會自動變更系統 DNS 設定。
`enhanced-mode`	選擇 fake-ip 等處理模式。	映射方式與上游連線路徑是兩回事。
`nameserver`	設定預設解析上游。	確認通訊協定、連線能力，以及最終採用直連或代理。
`fallback`	提供另一組解析上游。	搭配過濾條件選擇結果，不代表只會在主要上游失敗時才查詢。
`fallback-filter`	依據位址或網域等條件篩選結果。	篩選結果不代表另一組上游不會收到查詢。
`respect-rules`	讓 DNS 上游連線遵循路由規則。	只設定為 true 並不足夠，還要設定節點網域解析並檢查規則順序。
`proxy-server-nameserver`	專門解析代理伺服器的網域名稱。	避免建立代理連線前，又依賴該代理來解析節點，形成循環。
`default-nameserver`	用來解析 DNS 上游本身的網域名稱。	這是引導解析，不是預設的業務查詢上游；也要納入隱私範圍考量。

例如，同時設定電信業者的 UDP DNS 與境外 fallback，即使最後採用境外解析結果，也不代表電信業者完全沒有收到查詢。若要減少業務網域暴露給本機明文 DNS，應先移除不必要的明文上游，而不是只調整 fallback-filter。

nameserver-policy 也能為特定網域指定不同的上游。若現有訂閱保留了這個欄位，部分網域可能不會使用你剛修改的預設 nameserver。排查時應檢查最終執行中的設定，而不只是新增的片段。加密 DNS 能保護裝置與解析服務之間的查詢內容，但解析服務本身仍能處理並看見網域名稱。

mihomo fake-ip 設定片段：明確指定上游與代理路由

以下是可合併至現有 mihomo 設定的 DNS 片段，並非完整訂閱。此設定使用 IP 位址格式的 Cloudflare DoH 上游，減少為了解析服務網域而進行引導查詢的需求。使用前請確認該解析服務符合你的網路政策，且代理節點能連線至該服務。若原設定已有 fallback 或 nameserver-policy，也應一併檢查，不要假設貼上片段就會自動移除舊欄位。

# DNS 設定片段：取代或合併現有的 dns 區段
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  respect-rules: true
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

這裡的 ipv6: false 是為了先排除核心 DNS 的 AAAA 結果，避免它成為排查變因；這不等於關閉系統 IPv6，也無法阻止其他應用程式自行取得 IPv6 位址。若需要 IPv6，請在確認接管設定與出口支援後重新啟用，並另外測試 IPv6 連線路徑。

讓業務 DNS 上游連線使用實際代理策略

respect-rules: true 會讓業務 DNS 上游連線遵循規則。若設定中有中國大陸直連、其他直連或預設直連，必須明確指定該上游的連線方式。以下規則應放在現有 rules 清單的前段，排在較廣泛的 IP 規則與 MATCH 之前。範例假設現有策略群組名稱確實是 PROXY；若名稱不同，請改成實際使用的策略群組名稱，不要新增第二個 rules 鍵。

# 規則片段：插入現有 rules 清單，保留其他原有規則
- IP-CIDR,1.1.1.1/32,PROXY,no-resolve

還要在「代理」頁面確認 PROXY 目前選擇的是代理節點，而不是 DIRECT。上述規則用於業務解析上游的連線；proxy-server-nameserver 則負責解析建立代理所需的節點網域，不能要求它依賴尚未建立的同一個代理。此範例的節點引導解析使用直連加密 DoH，本機網路仍看得到連往解析服務的連線，而解析服務仍會處理節點網域名稱。

fake-ip-filter 只加入確實需要的網域

需要取得真實位址的區域網路裝置或特定應用程式，可加入 fake-ip-filter。經過濾後會改為回傳真實位址，但這不代表連線一定直連，也不是防止 DNS 洩漏的開關。不要為了修復單一裝置就把所有網域加入過濾清單，否則會失去 fake-ip 保留網域映射的主要優點。

TUN 與瀏覽器設定：將查詢納入接管範圍

系統代理主要影響遵循代理設定的應用程式，無法普遍接管 UDP DNS。若要接管更多應用程式，可在具備系統權限的前提下使用 TUN。Windows 通常需要用戶端服務模式或系統管理員權限；macOS、Linux 也需要相應授權或權限設定。請先確認虛擬網路介面已成功建立，再設定 DNS 劫持，避免只開啟介面上的選項，就以為接管已完成。

# 選用 TUN 設定片段：搭配上方的 dns 區段
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

這段設定會將進入 TUN 的一般 UDP、TCP 53 查詢交給核心 DNS 處理，實際效果仍取決於作業系統、路由與核心支援。系統 DNS 設定通常只接受伺服器 IP，不能填入 127.0.0.1:1053 這種含連接埠的位址；未使用 TUN 時，若要讓系統直接使用本機解析器，需要另外設定 53 連接埠監聽，並處理權限與連接埠衝突。

Chrome：「設定」→「隱私權和安全性」→「安全性」→「使用安全 DNS」。診斷時請暫時關閉，再比較檢測結果。
Firefox：「設定」→「隱私權與安全性」→「透過 HTTPS 的 DNS」。檢查保護等級與指定的服務提供者；不同版本的繁體中文名稱可能略有差異。
Android：在系統「設定」中檢查「私人 DNS」。選單位置會因製造商而異，其加密查詢不在一般 UDP 53 劫持的範圍內。

瀏覽器 DoH 與系統 DoT 使用獨立的加密連線，dns-hijack 不會將它們拆解成核心的一般 DNS 查詢。你可以保留這些功能，但必須確認對應連線是否依預期經由代理傳送。關閉這些功能只是診斷方法，並非唯一的長期解決方案。

修改後無法連線：依照依賴順序排查

現象	優先檢查	處理方向
本機 1053 查詢逾時	設定載入錯誤、DNS 啟用狀態、連接埠是否被占用。	先確認本機查詢成功，再檢查網頁檢測結果。
使用網域名稱的節點無法連線	`proxy-server-nameserver` 是否可連線。	修復節點引導解析，避免解析與代理互相依賴。
節點連線正常，但網域無法連線	DoH 上游路由與目前選用的策略群組。	確認上游連線使用代理，且代理能連線至解析服務。
只有部分區域網路應用程式異常	是否收到 fake-ip，以及是否需要區域網路的真實位址。	只加入必要的過濾項目與區域網路繞行規則。
檢測仍出現非預期的解析器	瀏覽器 DoH、私人 DNS、其他 VPN 與 IPv6。	逐項關閉並比對，找出旁路後再決定是否保留及如何設定。

每次只修改一個環節：先調整 DNS 上游，再改規則，接著設定 TUN，最後處理瀏覽器與系統各自的解析功能。一次同時更換節點、啟用 TUN、修改系統 DNS，很難判斷是哪項設定生效。若啟用 TUN 後整台裝置都無法上網，請先關閉 TUN 恢復網路，再檢查預設路由、權限與其他 VPN 是否衝突，不要繼續疊加不同的 DNS 位址。

最終複測清單

本機 1053 查詢能回傳預期的映射位址，核心日誌沒有持續出現解析逾時。
業務 DoH 連線使用指定的代理策略，且節點網域解析有獨立可用的引導路徑。
網頁檢測結果中的解析服務符合預期；不以「解析器 IP 必須等於節點 IP」作為判斷標準。
瀏覽器安全 DNS、系統私人 DNS、IPv6 與區域網路應用程式都已分別測試。
重新啟動用戶端、更新訂閱後再次測試，確認覆寫設定仍持續生效。

DNS 防洩漏設定的關鍵，不是把某個欄位設為 true，而是讓接管、映射、上游與路由組成可驗證的連線路徑。更換網路、節點或用戶端核心後，都應重新進行這一輪比對。若要進一步設定連接埠、策略群組與啟動選項，請參閱進階手冊的連接埠說明與說明中心的故障排除。