NT-03.1DNS 洩漏是什麼,為什麼代理已連上還會發生
DNS 洩漏指的是:流量轉發走了代理,但網域名稱到 IP 的解析請求沒有經過代理,而是直接送到本機原有的 DNS 伺服器(通常是電信業者或本地路由器分配的位址)。這意味著即便網頁內容透過代理傳輸,存取過哪些網域這條資訊仍暴露在本地網路上,同時也可能因為解析結果不一致導致連線不穩定或遭汙染。
造成這種情況的根源通常有兩個層面。一是系統代理模式下,作業系統只接管了應用層的 HTTP/HTTPS 流量轉發,DNS 請求走的是獨立的 UDP 53 埠,如果客戶端沒有專門處理這條通道,請求會繞過代理直接發出。二是即便客戶端接管了 DNS,如果 dns 配置段裡的 nameserver 仍指向本機或電信業者位址,解析結果照樣受本地網路環境影響,和「網域請求走不走代理」是兩件需要分別確認的事。
Clash 與 Clash Meta(mihomo)核心都在設定檔裡提供獨立的 dns 配置段,透過 enhanced-mode 決定如何處理解析請求。理解這個欄位的行為,是排查與修復洩漏的前提。
NT-03.2檢測流程:先確認問題,再動配置
動手改配置前,先用一套可重複的流程確認是否真的存在洩漏,避免憑感覺調整參數。以下步驟在任何平台的客戶端上都適用。
- 斷開代理,記錄一次本機的 DNS 出口位址(可在系統網路設定裡查看目前網卡使用的 DNS 伺服器)。
- 連上代理並確認策略群組已選中可用節點,打開客戶端日誌面板,過濾關鍵字
DNS或resolve,觀察解析請求的輸出。 - 訪問一個會回顯請求來源資訊的檢測頁面,對比兩次結果:代理開啟前後回傳的解析伺服器位址是否一致。若開啟代理後仍顯示本機電信業者的 DNS 出口,即為洩漏。
- 在客戶端的連線面板(Connections)裡查看目前活躍連線的目標位址,確認解析出的 IP 是否落在預期的代理網段內,而不是被解析成了本地網路能直接觸及的位址。
- 切換 TUN 模式重複上述步驟,對照系統代理模式下的結果,判斷洩漏是否只在特定接管方式下出現。
只要代理開啟後,解析請求的出口位址與代理關閉時保持一致,就說明這部分請求沒有經過 dns 配置段的處理邏輯,需要檢查 enhanced-mode 與系統層的 DNS 設定是否被其他程式覆蓋。
NT-03.3enhanced-mode 的兩種取值與行為差異
dns 配置段的核心欄位是 enhanced-mode,決定客戶端如何把網域解析納入統一處理,常見取值為 fake-ip 與 redir-host。
| 模式 | 解析行為 | 適用場景 |
|---|---|---|
fake-ip | 客戶端回傳一個虛擬網段內的假 IP,真實解析延遲到連線建立時再依網域比對規則處理 | 預設建議,搭配 TUN 模式與規則分流,相容性最好 |
redir-host | 直接向上游 nameserver 請求真實 IP 並回傳給應用程式 | 部分應用程式對回傳的 IP 有嚴格驗證、無法使用假 IP 時的相容選項 |
一段可用的 dns 配置範例如下,重點是讓 nameserver 指向支援加密傳輸的位址,而不是繼續沿用本機原有的解析伺服器:
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.market.xiaomi.com"
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback:
- tls://8.8.4.4:853
其中 nameserver 是主解析清單,建議統一換成走 DoH(DNS over HTTPS)或 DoT(DNS over TLS)協定的位址,這樣解析請求本身也會加密傳輸,不會被本地網路明文截取。fallback 清單在主 nameserver 判斷為遭汙染結果時啟用,同樣建議使用加密協定位址。
NT-03.4fake-ip-filter 設定不當引發的區域網路存取問題
啟用 fake-ip 後,一個常見的副作用是區域網路內的裝置名稱解析(如路由器管理頁面、NAS、印表機)也被替換成假 IP,導致無法存取。fake-ip-filter 欄位用於宣告哪些網域不走假 IP 解析邏輯,直接使用真實結果:
dns:
fake-ip-filter:
- "*.lan"
- "*.local"
- "localhost.ptlogin2.qq.com"
- "+.msftconnecttest.com"
- "+.msftncsi.com"
這裡 +. 前綴表示比對該網域及其所有子網域,* 為萬用字元比對。如果發現某個區域網路裝置或需要精確出口 IP 的服務(例如企業內網辦公系統)在開啟代理後無法存取,優先檢查它的網域是否需要補進這個過濾清單,而不是直接關閉 fake-ip。
把 enhanced-mode 直接改成 redir-host 能繞開假 IP 帶來的相容性問題,但會削弱基於網域的規則分流能力,部分依賴 SNI 或 IP 段比對的策略群組規則可能因此失效。遇到相容性問題,先嘗試補上 fake-ip-filter,而不是整體切換模式。
NT-03.5系統代理模式與 TUN 模式下的差異排查
系統代理模式只接管應用程式主動讀取系統代理設定的那部分流量,一些命令列工具、部分 UDP 通訊、以及不遵循系統代理設定的程式,其 DNS 請求可能完全繞過客戶端。這類洩漏無法單靠調整 dns 配置段解決,需要開啟 TUN 模式,讓虛擬網卡在網路層統一接管包括 DNS 查詢在內的全部流量。
開啟 TUN 模式後,還需確認以下兩點,避免出現「接管了流量、卻沒接管解析」的半成品狀態:
- 確認
tun配置段中dns-hijack欄位已啟用(常見取值為0.0.0.0:53或any:53),這一項負責在網路層攔截所有 53 埠的 DNS 請求並轉交給內建 DNS 服務處理。 - Windows 與 macOS 上如果系統同時保留了原有網卡的 DNS 設定,某些程式可能優先走系統解析快取,建議在確認 TUN 模式生效後清空一次本機 DNS 快取再重新測試。
具體的 TUN 模式開啟步驟與各平台差異,可參考站內關於虛擬網卡接管流量的專題說明,這裡不重複展開。完成 dns-hijack 與 enhanced-mode 的設定後,重複本文第二部分的檢測流程,直到代理開啟前後的解析出口位址不再一致,即完成一次閉環驗證。
NT-03.6設定調整後的複核建議
修改 dns 配置段屬於影響面較廣的操作,建議按以下順序複核,減少因設定錯誤導致的連線異常:
- 先在測試環境或備用設定檔中修改,確認無誤後再套用到日常使用的 Profile,避免直接覆蓋正在使用的訂閱設定。
- 逐項檢查
nameserver位址格式是否正確(DoH 位址需為完整 URL,DoT 位址需帶tls://前綴與埠號)。 - 重新執行一次本文第二部分的檢測流程,記錄解析出口位址的變化。
- 觀察一段時間的正常使用,確認區域網路裝置存取、企業內網服務等場景未受影響。
DNS 洩漏的排查本質上是確認「網域解析」這一步是否也被納入了代理鏈路,而不僅僅是流量轉發。把 enhanced-mode、nameserver 與 fake-ip-filter 三項配對檢查清楚,多數洩漏問題都能在設定層面解決。