進階原理 2026-06-25 預計閱讀 9 分鐘

Clash Fake-IP 模式工作原理:DNS 映射機制與適用場景判斷

Fake-IP 是 Clash / mihomo 核心處理 DNS 與 TUN 分流時的關鍵設計,它用一段保留網段中的虛擬位址暫時取代真實解析結果,讓核心提前拿到落地判斷依據而不必等待完整的 DNS 往返。本文說明它的映射規則、與 Redir-Host 的差異,以及區域網路裝置、多人遊戲連線等容易踩坑的情境該如何處理。

DNS 解析在代理鏈路裡卡在哪一步

要理解 Fake-IP 的作用,先看沒有它時代理軟體要走的完整流程。用戶端存取一個網域時,系統先發出 DNS 查詢,取得真實 IP 後再建立 TCP 連線;如果這條連線需要走代理,核心還要根據規則(網域後綴、IP 網段、GEOIP 等)決定用哪個代理組轉發。問題在於,規則比對往往需要網域資訊,而不是等到取得 IP 之後才判斷——如果 DNS 查詢這一步本身也經過代理轉發或被劫持,首個封包建立前就會多出一輪甚至兩輪網路往返,尤其在 TUN 模式接管全域流量時,這個延遲會被放大到每一次新連線上。

另一個矛盾點是:很多分流規則寫的是網域規則(如 DOMAIN-SUFFIX),但作業系統底層轉發的是 IP 層資料封包。TUN 模式在網路卡層攔截流量時,取得的已經是目標 IP,如果這個 IP 是電信業者 DNS 或代理節點自身解析出來的真實位址,核心就遺失了「這個連線原本對應哪個網域」的資訊,規則引擎也就沒辦法按網域做判斷了。

Fake-IP 的映射機制:用虛擬位址佔位

Fake-IP 的思路是把這兩個問題一起解決:當用戶端發出 DNS 查詢時,mihomo 核心不去做真實解析,而是從一段保留的私有網段(常見設定是 198.18.0.0/16)裡按順序取一個尚未佔用的位址,直接回傳給用戶端,同時在記憶體裡建立「虛擬 IP ↔ 網域」的映射表。用戶端拿到這個假位址後,立刻發起連線,TUN 網路卡攔截到這個目標 IP,核心查一下映射表就知道真實網域是什麼,規則引擎照常按網域比對、決定走哪個代理節點,真正的網域解析在建立連線的同一時刻由代理節點或核心非同步完成,不再單獨佔用一輪往返時間。

整個過程對用戶端是透明的——應用程式不知道自己拿到的是一個假位址,它只管往這個 IP 送出封包。這也是為什麼 Fake-IP 能明顯縮短首個封包時間:DNS 查詢這一步幾乎變成了本地查表,不再依賴網路延遲。

映射表的生命週期

  • 映射關係存放在記憶體裡,通常帶有一定的 TTL,超過一段時間未使用的項目會被回收並重新分配給新的網域;
  • 同一網域短時間內多次查詢會沿用同一個虛擬 IP,確保同一會話內位址穩定;
  • 虛擬網段容量有限,長時間執行、存取網域極多的情境下偶爾會出現位址重用導致的短暫映射錯亂,重新啟動用戶端或清除 DNS 快取即可解決。

Fake-IP 與 Redir-Host 的行為差異

Redir-Host 是另一種較早的 DNS 處理方式:用戶端的 DNS 查詢會被直接轉發到真實的上游伺服器,取得真實 IP 後回傳給用戶端,核心再對這個真實 IP 做重新導向,靠維護「真實 IP ↔ 網域」的反查表來還原網域資訊用於規則比對。它的好處是用戶端手上始終是真實位址,相容性問題少;缺點是 DNS 查詢這一步沒有被截斷,該有的解析延遲一點也沒省下來,而且反查表依賴真實 IP 不重複、不飄移,一旦某個網域背後是 CDN 且頻繁更換 IP,反查關係就可能過期失效。

比較項目Fake-IPRedir-Host
用戶端收到的位址虛擬網段內的假位址真實解析位址
DNS 查詢耗時近似本地查表,幾乎沒有延遲等待真實上游解析
網域比對依據核心維護的虛擬 IP 映射表真實 IP 反查表
對 CDN 更換 IP 的敏感度不敏感,始終按網域比對較敏感,反查表可能滯後
相容性風險部分程式對非常規位址段敏感相容性較好

簡單說,Fake-IP 用「網域比對 + 假位址佔位」換來了速度和對 CDN 場景的穩定性,代價是用戶端手上的位址不是真的,極少數會主動檢查 IP 合法性或在憑證固定(certificate pinning)之外做位址驗證的程式可能出現異常。

哪些情境需要迴避 Fake-IP 或加入白名單

Fake-IP 對絕大多數網頁瀏覽、影片、下載情境沒有影響,但以下幾類情境需要留意,通常透過 fake-ip-filter 設定項把相關網域排除在 Fake-IP 處理之外,讓它們走真實 DNS 解析:

區域網路裝置與內部網路服務

存取路由器管理頁面、NAS、印表機、公司內部網路系統等本身解析到區域網路位址的網域時,如果被 Fake-IP 接管,用戶端拿到的會是假位址,核心再判斷該走直連還是代理,這中間任何一步處理不當都可能導致連不上。多數發行版預設已經把常見區域網路網域後綴(如 .lan、.local)與內部網路 IP 網段加入過濾名單,自建內部網路網域建議手動補上。

多人遊戲連線與 P2P 類應用程式

部分連線遊戲、P2P 下載工具、區域網路探索協定依賴真實 IP 做對等連線協商,或是對 DNS 回傳結果做合法性驗證,拿到 198.18.0.0/16 這類保留網段位址時會拒絕連線或比對失敗。這類應用程式的網域通常需要加入 fake-ip-filter 白名單,或是乾脆把整個應用程式設定為直連,不經過 TUN 網路卡處理。

系統層級探測與電信業者強綑綁服務

某些電信業者的寬頻認證、IoT 裝置的雲端配對流程會驗證解析出的 IP 是否落在特定網段,遇到假位址會判定異常。這類服務出現「能上網但功能異常」的情況時,優先檢查是不是被 Fake-IP 影響,再決定是否加入白名單。

設定範例與排查思路

以 mihomo 核心為例,DNS 段常見設定結構如下,重點關注 enhanced-mode 與 fake-ip-filter 兩項:

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
    - "time.*.com"
    - "*.market.xiaomi.com"
  nameserver:
    - 223.5.5.5
    - 8.8.8.8

排查一個「疑似 Fake-IP 導致異常」的問題時,建議按下面的順序驗證:

  1. 先確認現象是否只在開啟 TUN 模式或規則模式下出現,直連模式下正常,基本上可以鎖定和 DNS 處理方式有關;
  2. 檢查核心日誌或用戶端的連線詳情面板,看目標位址是否落在 198.18.0.0/16 這類保留網段內,確認走的是 Fake-IP;
  3. 把對應網域或網域萬用字元模式加入 fake-ip-filter,重新啟動核心或重新套用設定後複測;
  4. 如果網域不固定(例如電信業者探測服務經常變動),可以考慮把整個應用程式或該應用程式所在的區域網路段設為直連,而不是逐條加入過濾規則。

什麼情況下應該優先選擇 Fake-IP

對日常使用而言,Fake-IP 應作為預設選項保留,原因是它對絕大多數流量都能明顯降低連線建立的耗時,尤其是在切換節點頻繁、存取網域種類多樣的使用情境下差異更明顯。只有在遇到具體、可重現的連線異常,並且確認定位到確實是保留網段位址導致時,才針對那一小部分網域單獨處理,而不是整體關閉 Fake-IP 退回到真實解析——那樣會讓所有連線都重新承擔一次完整的 DNS 往返延遲,得不償失。理解映射機制之後再做取捨,才能既保留速度優勢,又不影響個別對位址真實性敏感的服務。

下載 Clash