Clash Fake-IP 模式原理詳解:與 Redir-Host 的差異及適用場景

DNS 解析在代理鏈路裡扮演什麼角色

在討論 Fake-IP 之前,有必要先理清一個容易被忽略的問題:客戶端在存取一個網域時,究竟是先解析出真實 IP,再決定走哪條路徑,還是反過來?這個先後順序直接決定了代理軟體的分流準確度與回應速度。傳統作業系統的網路堆疊遵循的是「先解析、再連線」的順序——應用程式呼叫系統的 DNS 解析函式取得一個真實 IP,再用這個 IP 發起 TCP 或 UDP 連線。如果代理軟體也照搬這個順序,就會遇到一個尷尬的局面:網域解析這一步往往還沒經過代理,直接暴露給了本機網路的 DNS 伺服器,而後續的連線卻要走代理規則做分流判斷。

Clash 核心(包括 Clash Premium 與 Clash Meta/mihomo)在設計規則比對時,大量規則類型都是基於網域的,例如 DOMAIN-SUFFIX、DOMAIN-KEYWORD。這類規則在連線發起階段就能完成比對,不依賴 IP。但也有一部分規則依賴 IP,例如 GEOIP、IP-CIDR,這類規則要求客戶端在做分流決策前,必須先取得一個可用的 IP 位址。矛盾由此產生:如果照常規流程先做真實 DNS 解析,解析請求本身可能已經洩露到本機網路運營商或區域網路的 DNS 伺服器,這就是所謂的 DNS 洩露;而如果完全不做解析就把網域交給遠端代理節點處理,又會讓本機基於 IP 的規則失效。Fake-IP 正是為了在這兩者之間找到一個折衷方案而設計的機制。

Fake-IP 如何用虛假位址換取速度與隱私

Fake-IP 的核心思路可以用一句話概括:客戶端在本機維護一個「網域到虛假 IP」的對應表,當應用程式請求解析某個網域時,Clash 核心不去真正查詢公共 DNS,而是從一個保留的私有網段(通常是 198.18.0.0/16)裡分配一個從未使用過的位址,直接回傳給應用程式。應用程式取得這個看似正常的 IP 後,照常發起連線,資料封包被本機路由或 TUN 網卡截獲,核心再根據這個虛假 IP 反查出對應的原始網域,把網域交給遠端代理節點去做真正的 DNS 解析與連線。

這套流程帶來的第一個好處是速度。因為應用程式取得虛假 IP 幾乎是零延遲的本機操作,不需要等待任何真實網路往返,首包建立的等待時間被大幅壓縮。第二個好處是隱私:本機網路環境完全看不到使用者實際存取的網域對應的真實 IP 是什麼,DNS 查詢請求也沒有真正發往本機網路的解析伺服器,從而減少了 DNS 層面的資訊暴露。第三個好處是規則相容性:由於每個虛假 IP 都能唯一對應回原始網域,基於網域的規則可以照常在本機完成比對,而不必等待遠端解析結果。

典型的 Fake-IP DNS 設定結構大致如下(以 mihomo 核心為例):

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'time.*.com'
    - 'ntp.*.com'
    - '+.push.apple.com'
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query

其中 enhanced-mode: fake-ip 明確指定啟用 Fake-IP 增強解析模式,fake-ip-range 劃定了虛假位址池的網段範圍,而 fake-ip-filter 則是決定哪些網域不走 Fake-IP、直接使用真實解析結果的關鍵設定項,後文會專門展開說明它的必要性。

Fake-IP 與 Redir-Host 的本質差異

在 Fake-IP 出現之前,Clash 生態裡更早被廣泛使用的是 Redir-Host 模式,二者都屬於「增強 DNS 模式」(enhanced-mode)的設定選項,但運作方式完全不同,理解這個差異有助於判斷該在什麼場景下用哪一種。

• Redir-Host 的做法:客戶端在收到 DNS 請求後,會真實地向上游伺服器發起解析,取得網域對應的真實 IP,再把這個真實 IP 直接回傳給應用程式。規則比對主要依賴後續流量重新導向階段對網域的紀錄做判斷,連線建立時使用的是真實 IP。
• Fake-IP 的做法:如前文所述,不做真實解析,直接回傳一個虛假位址,真實解析被推遲到連線真正建立、流量進入代理節點之後才在遠端完成。

這個差異帶來幾個可以感知的實際差異。首先是速度:Redir-Host 每次解析都要等待一次真實的 DNS 往返,而 Fake-IP 省去了這一步,首次建立連線速度更快,尤其在跨境網路環境下體感差異明顯。其次是隱私邊界:Redir-Host 模式下,本機依然會把真實網域交給上游 DNS 伺服器解析,即使這個上游是可信的加密 DNS,解析紀錄也會經過本機網路出口;Fake-IP 則把解析這一步完全移到了代理節點之後,本機網路看不到任何真實網域對應的解析行為。第三是相容性:一些依賴「應用層直接取得真實 IP」的場景(例如某些遊戲客戶端會把伺服器 IP 用於連線品質偵測、或是某些內網穿透工具需要真實位址做驗證)在 Fake-IP 下可能出現異常,因為應用程式取得的始終是一個虛假位址,而 Redir-Host 至少能保證應用層看到的 IP 是真實的。

因此,現階段主流客戶端(包括基於 mihomo 核心的各類 GUI 客戶端)預設推薦使用 Fake-IP,把 Redir-Host 保留為相容性問題的備選方案,而不是反過來。如果你在使用中發現某個應用出現連線異常、位址顯示錯亂或握手失敗,先檢查是否是 Fake-IP 機制導致的真實 IP 不可見問題,再考慮暫時切換到 Redir-Host 做排查。

為什麼必須正確設定 fake-ip-filter

Fake-IP 雖然帶來了速度與隱私的雙重收益,但也不是對所有網域都適用。有一類網域場景下,應用程式確實需要取得真實 IP 才能正常運作,這時就必須把它們加入 fake-ip-filter 名單,讓這些網域跳過 Fake-IP 邏輯,走真實解析。

區域網路與內網服務

如果家裡或公司內網有透過網域存取的 NAS、路由器管理頁面、內網穿透服務等,這些網域解析出的應該是區域網路內的真實 IP,而不是一個虛假位址——否則裝置將無法定位到內網中的實際主機。常見做法是把 *.lan、*.local 以及自訂的內網網域後綴統一加入過濾名單。部分企業內網還會使用自建網域解析到私有網段,這類網域也應當歸入過濾範圍。

時間同步與低延遲偵測服務

作業系統的時間同步協定(NTP)通常直接使用 IP 通訊而非依賴代理轉發,如果被 Fake-IP 接管,反而會導致時間同步失敗或延遲異常。類似的還有部分系統層級的網路品質偵測服務,這些請求本身不需要經過代理,也不適合被虛假位址干擾,因此常見設定範本裡會預置 ntp.*.com、time.*.com 這類規則。

推播服務與即時通訊

一些作業系統層級的推播通道(例如裝置與廠商推播伺服器之間維持的長連線)對連線穩定性和真實位址有較高要求,如果被 Fake-IP 接管可能出現推播延遲或斷線,設定範本中常見的 +.push.apple.com 一類通配規則就是為了避免這種情況。

遊戲平台與即時對戰服務

部分網路遊戲客戶端會在連線伺服器前對目標 IP 做主動的網路品質偵測,或者在遊戲內顯示伺服器的真實延遲與位址資訊,這類場景下如果應用層取得的是虛假 IP,偵測結果會失真,甚至觸發遊戲客戶端自身的異常連線判定。對於經常出現連線異常、配對失敗的遊戲平台網域,建議先嘗試將其加入 fake-ip-filter,觀察問題是否消失,再決定是否需要單獨為該遊戲建立分流規則。

實際使用中常見的疑惑與排查思路

啟用 Fake-IP 之後,一些使用者會在使用體驗裡遇到看似奇怪的現象,這裡列出幾種典型情況以及對應的排查方向。

為什麼某些應用顯示的伺服器 IP 是 198.18 開頭的陌生位址

這正是 Fake-IP 網段在起作用——只要看到形如 198.18.x.x 的位址出現在應用程式的連線資訊裡,通常就說明這個連線被 Fake-IP 接管了,網域解析結果是虛假位址而非真實 IP。這本身是正常現象,不代表設定出錯,除非該應用因此出現功能異常。

切換網路後位址對應表是否需要清理

Fake-IP 的對應表是在客戶端本機維護的,通常會隨行程重啟或手動清空 DNS 快取而重置。如果切換了網路環境後出現連線異常,可以嘗試在客戶端介面裡尋找「清空 Fake-IP 快取」或類似選項,部分 GUI 客戶端會把這個操作放在 DNS 設定或進階設定分區裡。

IPv6 環境下要注意什麼

Fake-IP 預設場景下主要覆蓋 IPv4 位址池,如果本機網路同時啟用了 IPv6 且系統優先嘗試 IPv6 連線,可能出現部分流量繞過 Fake-IP 邏輯直接發起 IPv6 連線的情況。多數設定範本會明確將 DNS 設定中的 ipv6 項設為 false,或者配合規則集單獨處理 IPv6 流量,避免出現繞過代理判斷的連線路徑。

如何驗證 DNS 洩露是否得到改善

可以借助支援查看 DNS 解析來源的線上檢測工具,在開啟 Fake-IP 前後分別檢測一次,對比解析紀錄歸屬地是否發生變化。正常情況下,啟用 Fake-IP 並配合遠端可信 DNS 解析後,檢測結果應顯示解析行為發生在代理節點所在網路,而不是本機網路運營商的 DNS 伺服器。

Fake-IP 與 TUN 模式的配合關係

Fake-IP 常常與 TUN 模式一起被提及,但兩者解決的是不同層面的問題,不要混為一談。TUN 模式是在系統網路層建立一張虛擬網卡,讓所有出站流量(不只是瀏覽器或個別應用)都經過 Clash 核心處理,解決的是「哪些流量能被納入代理」的覆蓋面問題;而 Fake-IP 解決的是「網域解析這一步該怎麼處理」的問題,二者可以獨立開啟,也可以同時使用。實際設定中,啟用 TUN 模式後往往會同步建議開啟 Fake-IP,因為這樣才能確保 TUN 網卡截獲的流量在網域規則比對階段取得足夠資訊,同時避免系統層級 DNS 請求繞過虛擬網卡直接發往本機網路,形成完整的閉環。

如果只開啟 TUN 模式而 DNS 增強模式設為空白或使用系統預設解析,依然可能出現 DNS 請求繞過代理直接發往本機設定的 DNS 伺服器的情況,這也是排查「TUN 模式開了但還是提示解析失敗/DNS 洩露」問題時最先應該檢查的設定項。

設定建議小結

綜合以上原理,提出幾條可以直接落地的建議:一般使用者在沒有特殊內網需求的情況下,保持客戶端預設的 Fake-IP 設定即可,不需要額外調整;有內網服務、企業網域解析需求的使用者,應主動檢查並補充 fake-ip-filter 名單,把內網網域後綴加入其中;遊戲與即時通訊類應用出現連線異常時,優先懷疑 Fake-IP 影響,透過暫時過濾對應網域或切換到 Redir-Host 做對比測試來定位問題;開啟 TUN 模式的使用者,應確認 DNS 增強模式與 Fake-IP 網段設定已經同步生效,避免出現流量被截獲但解析仍走本機預設 DNS 的半套設定狀態。