Fake-IP 模式運作原理詳解:DNS 映射池、劫持流程與適用場景

DNS 解析在代理鏈路中的位置

任何一次網路存取都從網域解析開始:應用程式先向系統或客戶端內建的 DNS 模組詢問某個網域對應哪個 IP,拿到答案後再發起 TCP 或 UDP 連線。在沒有代理軟體介入的情況下,這個 IP 是真實的、可以直接用來路由和分流的資訊。但對 Clash / mihomo 這類基於規則做流量分發的工具來說,單純依賴 IP 會帶來一個麻煩:很多網域背後是 CDN,同一個網站在不同時間、不同地區解析出的 IP 完全不同,基於 IP 段寫死的規則很快就會失效。於是規則引擎更希望拿到的是網域本身,而不是一個漂移不定的 IP。這就是 DNS 模式設計要解決的核心問題——如何讓「網域資訊」能夠傳遞到連線建立與規則比對的每一個環節。

Clash 的 DNS 模組提供了幾種工作模式,其中最常被討論、也最容易被誤解的就是 Fake-IP。要理解它,需要先放下「DNS 解析出的 IP 就是要連線的真實位址」這個預設假設。

Fake-IP 的映射池機制

Fake-IP 模式的思路是:客戶端接管本機的 DNS 請求,當應用程式查詢某個網域時,不去真正聯繫上游 DNS 伺服器要一個真實 IP,而是從一個保留的私有網段(預設是 198.18.0.0/16)裡,按順序或按快取策略分配一個從未使用過的 IP,直接回傳給應用程式。這個 IP 本身不指向任何真實伺服器,它只是一個「佔位符」,客戶端會在內部維護一張映射表,記錄「這個虛構 IP 對應哪個網域」。

整個流程可以拆成三步:

1. 應用程式發起 DNS 查詢,查詢請求被 TUN 或系統 DNS 劫持到 Clash 內部的 DNS 伺服器元件。
2. Clash 檢查映射池,若該網域此前沒有分配過 Fake-IP,就取一個尚未占用的位址,建立「網域 ↔ 虛構 IP」的雙向記錄並寫入記憶體表。
3. Clash 把這個虛構 IP 作為 DNS 回應回傳給應用程式,應用程式拿著這個 IP 去建立連線。

關鍵點在於第三步之後:應用程式用虛構 IP 發起連線時,這個連線會經過 TUN 網卡或系統代理進入 Clash 的轉發引擎。此時 Clash 並不會真的向 198.18.x.x 這個位址發包,而是先查一遍映射表,把虛構 IP 反查回網域,拿到真實網域後,再依代理規則決定走哪個代理群組,並對真實網域重新做一次實際的 DNS 解析(或直接把網域交給支援 SNI/HTTP Host 的下游代理處理)。這一步稱為「連線階段還原」,是 Fake-IP 能正常運作的核心——網域資訊全程被保留,虛構 IP 只是一個暫時載體,不會真正參與到底層網路傳輸裡。

為什麼規則比對更準確了

因為 Fake-IP 讓「網域」能一路傳遞到連線建立環節,規則引擎在做 DOMAIN-SUFFIX、DOMAIN-KEYWORD、RULE-SET 這類基於網域的比對時,拿到的始終是可靠的原始網域,而不是隨時可能變化的 CDN 出口 IP。這對於 CDN 密集的場景尤其重要——同一個網域可能今天解析到 A 記錄,明天解析到另一批 IP,如果規則寫的是 IP 段,很容易出現「昨天能匹配、今天匹配不上」的情況。網域相對穩定得多,基於網域的規則集也是目前 mihomo 生態裡更新最頻繁、覆蓋最廣的形式。

另外,Fake-IP 模式下客戶端不需要在系統層面每次都發起真實的 DNS 查詢才能判斷走不走代理——虛構 IP 分配與規則比對可以在本地記憶體裡完成,減少了一輪網路往返,這也是很多使用者回饋開啟 Fake-IP 後網頁開啟速度略有提升的原因之一。

Fake-IP 與 Redir-Host 的差異

在 Fake-IP 出現之前,另一種常見方案是 Redir-Host:客戶端劫持 DNS 請求後,不回傳虛構位址,而是直接向真實上游 DNS 伺服器查詢,拿到真實 IP 並原樣回傳給應用程式。規則比對這一步則依賴客戶端在 DNS 查詢階段就記下「網域對應哪些 IP」,隨後靠這份記錄在連線階段反查回網域。表面上兩者都實現了「網域參與規則比對」,但工作細節與適用邊界並不相同。

簡單說,Fake-IP 在速度與規則準確性上更有優勢,是目前 TUN 模式下的預設選擇;Redir-Host 因為應用程式拿到的始終是真實 IP,在一些直接依賴 IP 通訊、不經過網域解析習慣的場景裡相容性更穩妥,但整體已逐漸被 Fake-IP 加白名單排除的組合方案取代。

哪些場景必須用 fake-ip-filter 排除

虛構 IP 只是一個「給 Clash 內部用的佔位符」,一旦某個應用程式不經過 Clash 的連線劫持邏輯,直接把這個 IP 當作真實位址使用,就會出問題。常見的幾類場景需要顯式設定 fake-ip-filter,把對應網域排除在 Fake-IP 分配範圍之外,讓它們走真實 DNS 解析:

• 區域網路內部服務與路由器管理頁面——像 *.lan、router.asus.com 這類指向本地網路裝置的網域,如果被分配了虛構 IP,瀏覽器會嘗試連線一個根本不存在的位址,導致管理頁面打不開。
• 需要精確取得真實 IP 的應用程式——部分雲端硬碟客戶端、直播推流工具、P2P 類應用程式會在應用層直接讀取 DNS 回傳的 IP 用於顯示或建立點對點連線,虛構 IP 對它們沒有意義。
• 企業內網與 VPN 場景中的私有網域——公司內部系統網域往往解析到私有網段,這類網域同樣應加入排除清單,避免與代理邏輯產生衝突。
• 已知與 Fake-IP 存在相容問題的客戶端元件——例如某些系統內建的網路偵測、連通性檢測服務,建議依官方文件或社群維護的規則集統一排除,而不是逐條手動新增。

實踐中不需要從零手寫這份排除清單:主流規則集儲存庫通常已經維護了一份較完整的 fake-ip-filter 建議清單,客戶端在產生預設設定或使用規則訂閱時也會帶上一份基礎版本,遇到具體應用程式打不開的情況再依需要追加即可。

什麼時候該開、什麼時候該關

Fake-IP 模式的預設使用建議如下:

• TUN 模式下建議保持開啟。TUN 模式接管全域網路堆疊,需要一套高效、準確的網域還原機制來配合規則引擎,Fake-IP 正是為這種場景設計的,也是大多數客戶端在 TUN 模式下的預設 DNS 類型。
• 純系統代理模式(HTTP/SOCKS)下可以依需求選擇。如果只是讓瀏覽器等支援系統代理設定的應用程式走 Clash,Redir-Host 或直連上游 DNS 都是可行的替代方案,差異主要體現在規則比對的精細度上。
• 遇到區域網路裝置、內網系統存取異常時,先檢查 fake-ip-filter,而不是直接關閉整個 Fake-IP。大部分「開了代理內網裝置連不上」的問題,根源是排除清單沒覆蓋到對應網域,針對性追加規則比放棄整套機制更划算。
• 對精確 IP 有強依賴的少數應用程式,單獨走直連或排除網域。沒必要因為個別應用程式的特殊需求關閉全域 Fake-IP,規則分流本身就支援按網域或按行程做例外處理。

整體而言,Fake-IP 不是一個「要不要開」的二選一開關,而是需要配合排除清單一起維護的動態機制。規則集社群持續在更新已知需要排除的網域,客戶端也在不斷優化虛構 IP 池的分配與回收策略,理解其運作原理之後,遇到具體問題就能快速判斷該往哪個方向排查,而不是把整套 DNS 模式當作一個不可拆解的黑盒。